Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Rob Herring @ 2018-05-23 16:29 UTC (permalink / raw)
  To: Jacopo Mondi
  Cc: devicetree, linux-renesas-soc, horms, geert, laurent.pinchart,
	niklas.soderlund, linux-arm-kernel, linux-media
In-Reply-To: <1526488352-898-2-git-send-email-jacopo+renesas@jmondi.org>

On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>        from external SoC pins described in video-interfaces.txt[1].
>        Describing more then one endpoint in port 0 is invalid. Only VIN
>        instances that are connected to external pins should have port 0.
> +
> +      - Optional properties for endpoint nodes of port@0:
> +        - hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> +	  respectively. Default is active high.
> +        - vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> +	  respectively. Default is active high.
> +
> +	If both HSYNC and VSYNC polarities are not specified, embedded
> +	synchronization is selected.

No need to copy-n-paste from video-interfaces.txt. Just "see 
video-interfaces.txt" for the description is fine.

> +
>      - port 1 - sub-nodes describing one or more endpoints connected to
>        the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>        use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>          - Endpoint 2 - sub-node describing the endpoint connected to CSI40
>          - Endpoint 3 - sub-node describing the endpoint connected to CSI41
> 
> +      Endpoint nodes of port@1 do not support any optional endpoint property.
> +
>  Device node example for Gen2 platforms
>  --------------------------------------
> 
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
> 
>                  vin1ep0: endpoint {
>                          remote-endpoint = <&adv7180>;
> -                        bus-width = <8>;
>                  };
>          };
>  };
> --
> 2.7.4
> 

^ permalink raw reply

* Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Ray Jui @ 2018-05-23 16:29 UTC (permalink / raw)
  To: Robin Murphy, Scott Branden, Guenter Roeck
  Cc: Mark Rutland, devicetree, linux-watchdog, Catalin Marinas,
	Will Deacon, linux-kernel, Rob Herring, bcm-kernel-feedback-list,
	Wim Van Sebroeck, Frank Rowand, linux-arm-kernel
In-Reply-To: <76d47e02-7a5f-3fc2-3905-cd4aa03ac69c@arm.com>

Hi Robin,

On 5/23/2018 4:48 AM, Robin Murphy wrote:
> On 23/05/18 08:52, Scott Branden wrote:
>>
>>
>> On 18-05-22 04:24 PM, Ray Jui wrote:
>>> Hi Guenter,
>>>
>>> On 5/22/2018 1:54 PM, Guenter Roeck wrote:
>>>> On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
>>>>> If the watchdog hardware is already enabled during the boot process,
>>>>> when the Linux watchdog driver loads, it should reset the watchdog and
>>>>> tell the watchdog framework. As a result, ping can be generated from
>>>>> the watchdog framework, until the userspace watchdog daemon takes over
>>>>> control
>>>>>
>>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>>> Reviewed-by: Vladimir Olovyannikov 
>>>>> <vladimir.olovyannikov@broadcom.com>
>>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>>   drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
>>>>>   1 file changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/drivers/watchdog/sp805_wdt.c 
>>>>> b/drivers/watchdog/sp805_wdt.c
>>>>> index 1484609..408ffbe 100644
>>>>> --- a/drivers/watchdog/sp805_wdt.c
>>>>> +++ b/drivers/watchdog/sp805_wdt.c
>>>>> @@ -42,6 +42,7 @@
>>>>>       /* control register masks */
>>>>>       #define    INT_ENABLE    (1 << 0)
>>>>>       #define    RESET_ENABLE    (1 << 1)
>>>>> +    #define    ENABLE_MASK    (INT_ENABLE | RESET_ENABLE)
>>>>>   #define WDTINTCLR        0x00C
>>>>>   #define WDTRIS            0x010
>>>>>   #define WDTMIS            0x014
>>>>> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
>>>>>   MODULE_PARM_DESC(nowayout,
>>>>>           "Set to 1 to keep watchdog running after device release");
>>>>>   +/* returns true if wdt is running; otherwise returns false */
>>>>> +static bool wdt_is_running(struct watchdog_device *wdd)
>>>>> +{
>>>>> +    struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>>>> +
>>>>> +    if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
>>>>> +        ENABLE_MASK)
>>>>> +        return true;
>>>>> +    else
>>>>> +        return false;
>>>>
>>>>     return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>>>
>>>
>>> Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE); 
>>> therefore, a simple !!(expression) would not work? That is, the 
>>> masked result needs to be compared against the mask again to ensure 
>>> both bits are set, right?
>> Ray - your original code looks correct to me.  Easier to read and less 
>> prone to errors as shown in the attempted translation to a single 
>> statement.
> 
>      if (<boolean condition>)
>          return true;
>      else
>          return false;
> 
> still looks really dumb, though, and IMO is actually harder to read than 
> just "return <boolean condition>;" because it forces you to stop and 
> double-check that the logic is, in fact, only doing the obvious thing.

If you can propose a way to modify my original code above to make it 
more readable, I'm fine to make the change.

As I mentioned, I don't think the following change proposed by Guenter 
will work due to the reason I pointed out:

return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));

> 
> Robin.
> 
> 
> 
> p.s. No thanks for making me remember the mind-boggling horror of 
> briefly maintaining part of this legacy codebase... :P
> 
> $ grep -r '? true : false' --include=*.cpp . | wc -l
> 951

^ permalink raw reply

* Re: [PATCH V2] mfd: dt: Add bindings for DA9063L
From: Rob Herring @ 2018-05-23 16:26 UTC (permalink / raw)
  To: Marek Vasut
  Cc: devicetree, Marek Vasut, Geert Uytterhoeven, Lee Jones,
	Steve Twiss, Wolfram Sang, linux-renesas-soc
In-Reply-To: <20180523122140.6275-1-marek.vasut+renesas@gmail.com>

On Wed, May 23, 2018 at 02:21:40PM +0200, Marek Vasut wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
> 
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only
>     regulators in that single list
> ---
>  Documentation/devicetree/bindings/mfd/da9063.txt | 32 +++++++++++++-----------
>  1 file changed, 17 insertions(+), 15 deletions(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Ray Jui @ 2018-05-23 16:25 UTC (permalink / raw)
  To: Robin Murphy, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
	Mark Rutland, Frank Rowand, Catalin Marinas, Will Deacon
  Cc: devicetree, linux-watchdog, linux-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <af81ea74-fb80-11e2-7bdc-d3607bdbd46b@arm.com>



On 5/23/2018 3:57 AM, Robin Murphy wrote:
> On 22/05/18 19:47, Ray Jui wrote:
>> Update the SP805 binding document to add optional 'timeout-sec'
>> devicetree property
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> ---
>>   Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt 
>> b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>> index edc4f0e..f898a86 100644
>> --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>> @@ -19,6 +19,8 @@ Required properties:
>>   Optional properties:
>>   - interrupts : Should specify WDT interrupt number.
>> +- timeout-sec : Should specify default WDT timeout in seconds. If 
>> unset, the
>> +                default timeout is 30 seconds
> 
> According to the SP805 TRM, the default interval is dependent on the 
> rate of WDOGCLK, but would typically be a lot longer than that :/
> 
> On a related note, anyone have any idea why we seem to have two subtly 
> different SP805 bindings defined?

Interesting, I did not even know that until you pointed this out (and 
it's funny that I found that I actually reviewed arm,sp805.txt 
internally in Broadcom code review).

It looks like one was done by Bhupesh Sharma (sp805-wdt.txt) and the 
other was done by Anup Patel (arm,sp805.txt). Both were merged at the 
same time around March 20, 2016: 915c56bc01d6. I'd assume both were sent 
out at around the same time.

It sounds like we should definitely remove one of them. Given that 
sp805-wdt.txt appears to have more detailed descriptions on the use of 
the clocks, should we remove arm,sp805.txt?

Thanks,

Ray

> 
> Robin.
> 
>>   Examples:
>>

^ permalink raw reply

* Re: [PATCH v3 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Rob Herring @ 2018-05-23 16:24 UTC (permalink / raw)
  To: Marco Felsch; +Cc: mark.rutland, devicetree, thierry.reding, kernel, dri-devel
In-Reply-To: <20180523092504.5142-3-m.felsch@pengutronix.de>

On Wed, May 23, 2018 at 11:25:04AM +0200, Marco Felsch wrote:
> From: Philipp Zabel <p.zabel@pengutronix.de>
> 
> This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
> to the simple-panel driver.
> 
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> [m.felsch@pengutronix.de: fix typo in compatible dt-binding]
> [m.felsch@pengutronix.de: add property bindings]
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>  .../display/panel/dlc,dlc0700yzg-1.txt        | 13 ++++++++
>  drivers/gpu/drm/panel/panel-simple.c          | 32 +++++++++++++++++++
>  2 files changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt

Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v3 12/13] dt-bindings: add binding for px30 power domains
From: Rob Herring @ 2018-05-23 16:24 UTC (permalink / raw)
  To: Elaine Zhang
  Cc: heiko, mark.rutland, devicetree, rjw, khilman, ulf.hansson,
	linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel, wxt,
	xxx, xf, huangtao, Finley Xiao
In-Reply-To: <1527058371-10706-1-git-send-email-zhangqing@rock-chips.com>

On Wed, May 23, 2018 at 02:52:51PM +0800, Elaine Zhang wrote:
> From: Finley Xiao <finley.xiao@rock-chips.com>
> 
> Add binding documentation for the power domains
> found on Rockchip PX30 SoCs.
> 
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
>  Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v3 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Rob Herring @ 2018-05-23 16:23 UTC (permalink / raw)
  To: Elaine Zhang
  Cc: heiko, mark.rutland, devicetree, rjw, khilman, ulf.hansson,
	linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel, wxt,
	xxx, xf, huangtao, Finley Xiao
In-Reply-To: <1527058341-10658-1-git-send-email-zhangqing@rock-chips.com>

On Wed, May 23, 2018 at 02:52:21PM +0800, Elaine Zhang wrote:
> From: Finley Xiao <finley.xiao@rock-chips.com>
> 
> According to a description from TRM, add all the power domains.
> 
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
>  include/dt-bindings/power/px30-power.h | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 include/dt-bindings/power/px30-power.h

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v3 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain
From: Rob Herring @ 2018-05-23 16:23 UTC (permalink / raw)
  To: Elaine Zhang
  Cc: heiko, mark.rutland, devicetree, rjw, khilman, ulf.hansson,
	linux-pm, linux-arm-kernel, linux-rockchip, linux-kernel, wxt,
	xxx, xf, huangtao
In-Reply-To: <1527058286-10503-1-git-send-email-zhangqing@rock-chips.com>

On Wed, May 23, 2018 at 02:51:26PM +0800, Elaine Zhang wrote:
> According to a description from TRM, add all the power domains.
> 
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
>  include/dt-bindings/power/rk3228-power.h | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 include/dt-bindings/power/rk3228-power.h

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Rob Herring @ 2018-05-23 16:22 UTC (permalink / raw)
  To: David Collins
  Cc: broonie, lgirdwood, mark.rutland, linux-arm-msm, linux-arm-kernel,
	devicetree, linux-kernel, rnayak, sboyd, dianders
In-Reply-To: <6d03576cf90f06afb1194301cb41fc31704def1d.1527040878.git.collinsd@codeaurora.org>

On Tue, May 22, 2018 at 07:43:17PM -0700, David Collins wrote:
> Introduce bindings for RPMh regulator devices found on some
> Qualcomm Technlogies, Inc. SoCs.  These devices allow a given
> processor within the SoC to make PMIC regulator requests which
> are aggregated within the RPMh hardware block along with requests
> from other processors in the SoC to determine the final PMIC
> regulator hardware state.
> 
> Signed-off-by: David Collins <collinsd@codeaurora.org>
> ---
>  .../bindings/regulator/qcom,rpmh-regulator.txt     | 185 +++++++++++++++++++++
>  .../dt-bindings/regulator/qcom,rpmh-regulator.h    |  36 ++++
>  2 files changed, 221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
>  create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v5 3/3] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
From: Rob Herring @ 2018-05-23 16:13 UTC (permalink / raw)
  To: Can Guo
  Cc: subhashj, asutoshd, vivek.gautam, mgautam, kishon, mark.rutland,
	linux-kernel, devicetree
In-Reply-To: <20180523034712.3420-4-cang@codeaurora.org>

On Wed, May 23, 2018 at 11:47:12AM +0800, Can Guo wrote:
> Update the compatible string for UFS QMP PHY on SDM845.
> 
> Signed-off-by: Can Guo <cang@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware
From: Sudeep Holla @ 2018-05-23 16:08 UTC (permalink / raw)
  To: Saravana Kannan
  Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
	Mark Rutland, Rajendra Nayak, Amit Kucheria, linux-pm, devicetree,
	linux-kernel, Sudeep Holla
In-Reply-To: <1526629965-28729-1-git-send-email-skannan@codeaurora.org>

As mentioned on the thread that add firmware based cpufreq support, IMO
these 2 bindings look too similar and can be combined or at-least aligned.

On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote:
> The firmware present in some QCOM chipsets offloads the steps necessary for
> changing the frequency of some devices (Eg: L3). This driver implements the
> devfreq interface for this firmware so that various governors could be used
> to scale the frequency of these devices.
>

Is this firmware the same one which controls the CPUFreq described in the
other thread adding cpufreq support ?

> Each client (say cluster 0 and cluster 1) that wants to vote for a
> particular device's frequency (say, L3 frequency) is represented as a
> separate voter device (qcom,devfreq-fw-voter) that's a child of the
> firmware device (qcom,devfreq-fw).
> 
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> ---
>  .../bindings/devfreq/devfreq-qcom-fw.txt           |  41 +++
>  drivers/devfreq/Kconfig                            |  14 +
>  drivers/devfreq/Makefile                           |   1 +
>  drivers/devfreq/devfreq_qcom_fw.c                  | 330 +++++++++++++++++++++
>  4 files changed, 386 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
>  create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
> new file mode 100644
> index 0000000..f882a0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
> @@ -0,0 +1,41 @@
> +QCOM Devfreq firmware device
> +
> +Some Qualcomm Technologies, Inc. (QTI) chipsets have a firmware that
> +offloads the steps for frequency switching. It provides a table of
> +supported frequencies and a register to request one of the supported
> +freqencies.
> +
> +The qcom,devfreq-fw represents this firmware as a device. Sometimes,

As a whole or just a part of it ? I am getting an impression that this
firmware is divided into 'n' different pieces and each of them is
represented as a separate device.

> +multiple entities want to vote on the frequency request that is sent to the
> +firmware. The qcom,devfreq-fw-voter represents these voters as child
> +devices of the corresponding qcom,devfreq-fw device.
> +
> +Required properties:
> +- compatible:		Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"

If this is the same firmware, name it after. What do you need one name
per subsystem in Linux for the same firmware ?

> +Only for qcom,devfreq-fw:
> +- reg:			Pairs of physical base addresses and region sizes of
> +			memory mapped registers.
> +- reg-names:		Names of the bases for the above registers.
> +			Required register regions are:
> +			- "en-base": address of register to check if the
> +			  firmware is enabled.
> +			- "ftbl-base": address region for the frequency
> +			  table.

It's called "lut-base" in the cpufreq binding and that's the only difference
I see.

> +			- "perf-base": address of register to request a
> +			  frequency.
> +

[...]

> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lut-base");
> +	if (!res) {
> +		dev_err(dev, "Unable to find lut-base!\n");
> +		return -EINVAL;
> +	}
> +
...but in the binding it's called "ftbl-base"

--
Regards,
Sudeep

^ permalink raw reply

* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-23 15:56 UTC (permalink / raw)
  To: Doug Anderson
  Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
	linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
	Stephen Boyd
In-Reply-To: <CAD=FV=XWVOdJ8rWJnBTwoNqnYqYRYjknkZtUvT86+skbrTdwig@mail.gmail.com>

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

On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
> On Wed, May 23, 2018 at 8:40 AM, Mark Brown <broonie@kernel.org> wrote:

> > It's got to be valid to think about the voltage of a disabled regulator
> > since drivers want to be able make sure that the regulator gets enabled
> > with a sensible config.  With most hardware this is really easy since
> > you can just look at the status reported by the hardware but the RPM
> > makes this hard since there's so much write only stuff in there.

> I should be more clear.  Certainly it should be valid to set the
> voltage before enabling it so, as you said, the regulator turns on at
> the right voltage.  I'm saying that it's weird (to me) to expect that
> setting the voltage for a regulator that a client thinks is disabled
> will affect any real voltages in the system until the regulator is
> enabled.  In RPMh apparently setting a voltage of a regulator you
> think is disabled can affect the regulator output if another client
> (unbeknownst to you) happens to have it enabled.

Yes, that's definitely not what's expected but it's unfortunately what
the firmware chose to implement so we may well be stuck with it
unfortunately.

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

^ permalink raw reply

* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-23 15:50 UTC (permalink / raw)
  To: Mark Brown
  Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
	linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
	Stephen Boyd
In-Reply-To: <20180523154057.GL4828@sirena.org.uk>

Hi,

On Wed, May 23, 2018 at 8:40 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 23, 2018 at 08:23:22AM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
>>
>> > It's arguable either way - you could say that the client gets to specify
>> > a safe range at all times or you could say that the machine constraints
>> > should cover all cases where the hardware is idling.  Of course RPMh
>> > is missing anything like the machine constraints (as we can see from all
>> > the fixing up of undesirable hard coding we have to do) so it's kind of
>> > pushed towards the first case.
>
>> OK, fair enough.  If others all agree that it's OK to make requests
>> about the voltage of a disabled regulator then I won't stand in the
>> way.  I guess it does call into question the whole idea of caching /
>> not sending the voltage until the first enable because it means
>> there's no way for the client to use this feature until they've
>> enabled / disabled the regulator once.  If you think of it as invalid
>> to adjust the voltage of a disabled regulator then the caching
>> argument is super clean, but once you say that you should normally be
>
> It's got to be valid to think about the voltage of a disabled regulator
> since drivers want to be able make sure that the regulator gets enabled
> with a sensible config.  With most hardware this is really easy since
> you can just look at the status reported by the hardware but the RPM
> makes this hard since there's so much write only stuff in there.

I should be more clear.  Certainly it should be valid to set the
voltage before enabling it so, as you said, the regulator turns on at
the right voltage.  I'm saying that it's weird (to me) to expect that
setting the voltage for a regulator that a client thinks is disabled
will affect any real voltages in the system until the regulator is
enabled.  In RPMh apparently setting a voltage of a regulator you
think is disabled can affect the regulator output if another client
(unbeknownst to you) happens to have it enabled.

^ permalink raw reply

* [PATCH V4 8/8] dt-bindings: stm32: add compatible for syscon
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

This patch describes syscon DT bindings.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 Documentation/devicetree/bindings/arm/stm32.txt            | 10 ----------
 .../devicetree/bindings/arm/stm32/stm32-syscon.txt         | 14 ++++++++++++++
 Documentation/devicetree/bindings/arm/stm32/stm32.txt      | 10 ++++++++++
 3 files changed, 24 insertions(+), 10 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt

diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
deleted file mode 100644
index 6808ed9..0000000
--- a/Documentation/devicetree/bindings/arm/stm32.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-STMicroelectronics STM32 Platforms Device Tree Bindings
-
-Each device tree must specify which STM32 SoC it uses,
-using one of the following compatible strings:
-
-  st,stm32f429
-  st,stm32f469
-  st,stm32f746
-  st,stm32h743
-  st,stm32mp157
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt b/Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
new file mode 100644
index 0000000..99980ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
@@ -0,0 +1,14 @@
+STMicroelectronics STM32 Platforms System Controller
+
+Properties:
+   - compatible : should contain two values. First value must be :
+                 - " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
+                 second value must be always "syscon".
+   - reg : offset and length of the register set.
+
+ Example:
+         syscfg: syscon@50020000 {
+                 compatible = "st,stm32mp157-syscfg", "syscon";
+                 reg = <0x50020000 0x400>;
+         };
+
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.txt b/Documentation/devicetree/bindings/arm/stm32/stm32.txt
new file mode 100644
index 0000000..6808ed9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.txt
@@ -0,0 +1,10 @@
+STMicroelectronics STM32 Platforms Device Tree Bindings
+
+Each device tree must specify which STM32 SoC it uses,
+using one of the following compatible strings:
+
+  st,stm32f429
+  st,stm32f469
+  st,stm32f746
+  st,stm32h743
+  st,stm32mp157
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 7/8] ARM: dts: stm32: add support of ethernet on stm32mp157c-ev1
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

MAC is connected to a PHY in RGMII mode.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 arch/arm/boot/dts/stm32mp157c-ev1.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 57e6dbc..a7fee5c 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -17,5 +17,25 @@
 
 	aliases {
 		serial0 = &uart4;
+		ethernet0 = &ethernet0;
+	};
+};
+
+&ethernet0 {
+	status = "okay";
+	pinctrl-0 = <&ethernet0_rgmii_pins_a>;
+	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_a>;
+	pinctrl-names = "default", "sleep";
+	phy-mode = "rgmii";
+	max-speed = <1000>;
+	phy-handle = <&phy0>;
+
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+		phy0: ethernet-phy@0 {
+			reg = <0>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 6/8] net: stmmac: add dwmac-4.20a compatible
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

Manage dwmac-4.20a version from synopsys

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index ebd3e5f..6d141f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -472,7 +472,8 @@ struct plat_stmmacenet_data *
 	}
 
 	if (of_device_is_compatible(np, "snps,dwmac-4.00") ||
-	    of_device_is_compatible(np, "snps,dwmac-4.10a")) {
+	    of_device_is_compatible(np, "snps,dwmac-4.10a") ||
+	    of_device_is_compatible(np, "snps,dwmac-4.20a")) {
 		plat->has_gmac4 = 1;
 		plat->has_gmac = 0;
 		plat->pmt = 1;
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 5/8] ARM: dts: stm32: Add ethernet dwmac on stm32mp1
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

Add Ethernet support (Synopsys MAC IP 4.20a) on stm32mp1 SOC.
Enable feature supported by the stmmac driver, such as TSO.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 3db03a2..ea7b6cb 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -179,5 +179,35 @@
 			clocks = <&rcc USART1_K>;
 			status = "disabled";
 		};
+
+		stmmac_axi_config_0: stmmac-axi-config {
+			snps,wr_osr_lmt = <0x7>;
+			snps,rd_osr_lmt = <0x7>;
+			snps,blen = <0 0 0 0 16 8 4>;
+		};
+
+		ethernet0: ethernet@5800a000 {
+			compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
+			reg = <0x5800a000 0x2000>;
+			reg-names = "stmmaceth";
+			interrupts-extended = <&intc GIC_SPI 61 IRQ_TYPE_NONE>;
+			interrupt-names = "macirq";
+			clock-names = "stmmaceth",
+				      "mac-clk-tx",
+				      "mac-clk-rx",
+				      "ethstp",
+				      "syscfg-clk";
+			clocks = <&rcc ETHMAC>,
+				 <&rcc ETHTX>,
+				 <&rcc ETHRX>,
+				 <&rcc ETHSTP>,
+				 <&rcc SYSCFG>;
+			st,syscon = <&syscfg 0x4>;
+			snps,mixed-burst;
+			snps,pbl = <2>;
+			snps,axi-config = <&stmmac_axi_config_0>;
+			snps,tso;
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 4/8] ARM: dts: stm32: Add syscfg on stm32mp1
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

System configuration controller is mainly used to manage
the compensation cell and other IOs and system related
settings.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index bc3eddc..3db03a2 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -167,6 +167,11 @@
 			#reset-cells = <1>;
 		};
 
+		syscfg: syscon@50020000 {
+			compatible = "st,stm32mp157-syscfg", "syscon";
+			reg = <0x50020000 0x400>;
+		};
+
 		usart1: serial@5c000000 {
 			compatible = "st,stm32h7-uart";
 			reg = <0x5c000000 0x400>;
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 3/8] ARM: dts: stm32: add ethernet pins to stm32mp157c
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

Add ethernet pins on stm32mp157c.

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 46 +++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 6f044100..cf83eb244 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -158,6 +158,52 @@
 					bias-disable;
 				};
 			};
+
+			ethernet0_rgmii_pins_a: rgmii-0 {
+				pins1 {
+					pinmux = <STM32_PINMUX('G', 5, AF11)>, /* ETH_RGMII_CLK125 */
+						 <STM32_PINMUX('G', 4, AF11)>, /* ETH_RGMII_GTX_CLK */
+						 <STM32_PINMUX('G', 13, AF11)>, /* ETH_RGMII_TXD0 */
+						 <STM32_PINMUX('G', 14, AF11)>, /* ETH_RGMII_TXD1 */
+						 <STM32_PINMUX('C', 2, AF11)>, /* ETH_RGMII_TXD2 */
+						 <STM32_PINMUX('E', 2, AF11)>, /* ETH_RGMII_TXD3 */
+						 <STM32_PINMUX('B', 11, AF11)>, /* ETH_RGMII_TX_CTL */
+						 <STM32_PINMUX('A', 2, AF11)>, /* ETH_MDIO */
+						 <STM32_PINMUX('C', 1, AF11)>; /* ETH_MDC */
+					bias-disable;
+					drive-push-pull;
+					slew-rate = <3>;
+				};
+				pins2 {
+					pinmux = <STM32_PINMUX('C', 4, AF11)>, /* ETH_RGMII_RXD0 */
+						 <STM32_PINMUX('C', 5, AF11)>, /* ETH_RGMII_RXD1 */
+						 <STM32_PINMUX('B', 0, AF11)>, /* ETH_RGMII_RXD2 */
+						 <STM32_PINMUX('B', 1, AF11)>, /* ETH_RGMII_RXD3 */
+						 <STM32_PINMUX('A', 1, AF11)>, /* ETH_RGMII_RX_CLK */
+						 <STM32_PINMUX('A', 7, AF11)>; /* ETH_RGMII_RX_CTL */
+					bias-disable;
+				};
+			};
+
+			ethernet0_rgmii_pins_sleep_a: rgmii-sleep-0 {
+				pins1 {
+					pinmux = <STM32_PINMUX('G', 5, ANALOG)>, /* ETH_RGMII_CLK125 */
+						 <STM32_PINMUX('G', 4, ANALOG)>, /* ETH_RGMII_GTX_CLK */
+						 <STM32_PINMUX('G', 13, ANALOG)>, /* ETH_RGMII_TXD0 */
+						 <STM32_PINMUX('G', 14, ANALOG)>, /* ETH_RGMII_TXD1 */
+						 <STM32_PINMUX('C', 2, ANALOG)>, /* ETH_RGMII_TXD2 */
+						 <STM32_PINMUX('E', 2, ANALOG)>, /* ETH_RGMII_TXD3 */
+						 <STM32_PINMUX('B', 11, ANALOG)>, /* ETH_RGMII_TX_CTL */
+						 <STM32_PINMUX('A', 2, ANALOG)>, /* ETH_MDIO */
+						 <STM32_PINMUX('C', 1, ANALOG)>, /* ETH_MDC */
+						 <STM32_PINMUX('C', 4, ANALOG)>, /* ETH_RGMII_RXD0 */
+						 <STM32_PINMUX('C', 5, ANALOG)>, /* ETH_RGMII_RXD1 */
+						 <STM32_PINMUX('B', 0, ANALOG)>, /* ETH_RGMII_RXD2 */
+						 <STM32_PINMUX('B', 1, ANALOG)>, /* ETH_RGMII_RXD3 */
+						 <STM32_PINMUX('A', 1, ANALOG)>, /* ETH_RGMII_RX_CLK */
+						 <STM32_PINMUX('A', 7, ANALOG)>; /* ETH_RGMII_RX_CTL */
+				};
+			};
 		};
 
 		pinctrl_z: pin-controller-z {
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 2/8] dt-bindings: stm32-dwmac: add support of MPU families
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

Add description for Ethernet MPU families fields

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/net/stm32-dwmac.txt | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
index 489dbcb..1341012 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -6,14 +6,28 @@ Please see stmmac.txt for the other unchanged properties.
 The device node has following properties.
 
 Required properties:
-- compatible:  Should be "st,stm32-dwmac" to select glue, and
+- compatible:  For MCU family should be "st,stm32-dwmac" to select glue, and
 	       "snps,dwmac-3.50a" to select IP version.
+	       For MPU family should be "st,stm32mp1-dwmac" to select
+	       glue, and "snps,dwmac-4.20a" to select IP version.
 - clocks: Must contain a phandle for each entry in clock-names.
 - clock-names: Should be "stmmaceth" for the host clock.
 	       Should be "mac-clk-tx" for the MAC TX clock.
 	       Should be "mac-clk-rx" for the MAC RX clock.
+	       For MPU family need to add also "ethstp" for power mode clock and,
+	                                       "syscfg-clk" for SYSCFG clock.
+- interrupt-names: Should contain a list of interrupt names corresponding to
+           the interrupts in the interrupts property, if available.
+		   Should be "macirq" for the main MAC IRQ
+		   Should be "eth_wake_irq" for the IT which wake up system
 - st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
-	      encompases the glue register, and the offset of the control register.
+	       encompases the glue register, and the offset of the control register.
+
+Optional properties:
+- clock-names:     For MPU family "mac-clk-ck" for PHY without quartz
+- st,int-phyclk (boolean) :  valid only where PHY do not have quartz and need to be clock
+	           by RCC
+
 Example:
 
 	ethernet@40028000 {
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 1/8] net: ethernet: stmmac: add adaptation for stm32mp157c.
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>

Glue codes to support stm32mp157c device and stay
compatible with stm32 mcu family

Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 270 ++++++++++++++++++++--
 1 file changed, 255 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 9e6db16..f51e327 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -16,49 +16,183 @@
 #include <linux/of_net.h>
 #include <linux/phy.h>
 #include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
 #include <linux/regmap.h>
 #include <linux/slab.h>
 #include <linux/stmmac.h>
 
 #include "stmmac_platform.h"
 
-#define MII_PHY_SEL_MASK	BIT(23)
+#define SYSCFG_MCU_ETH_MASK		BIT(23)
+#define SYSCFG_MP1_ETH_MASK		GENMASK(23, 16)
+
+#define SYSCFG_PMCR_ETH_CLK_SEL		BIT(16)
+#define SYSCFG_PMCR_ETH_REF_CLK_SEL	BIT(17)
+#define SYSCFG_PMCR_ETH_SEL_MII		BIT(20)
+#define SYSCFG_PMCR_ETH_SEL_RGMII	BIT(21)
+#define SYSCFG_PMCR_ETH_SEL_RMII	BIT(23)
+#define SYSCFG_PMCR_ETH_SEL_GMII	0
+#define SYSCFG_MCU_ETH_SEL_MII		0
+#define SYSCFG_MCU_ETH_SEL_RMII		1
 
 struct stm32_dwmac {
 	struct clk *clk_tx;
 	struct clk *clk_rx;
+	struct clk *clk_eth_ck;
+	struct clk *clk_ethstp;
+	struct clk *syscfg_clk;
+	bool int_phyclk;	/* Clock from RCC to drive PHY */
 	u32 mode_reg;		/* MAC glue-logic mode register */
 	struct regmap *regmap;
 	u32 speed;
+	const struct stm32_ops *ops;
+	struct device *dev;
+};
+
+struct stm32_ops {
+	int (*set_mode)(struct plat_stmmacenet_data *plat_dat);
+	int (*clk_prepare)(struct stm32_dwmac *dwmac, bool prepare);
+	int (*suspend)(struct stm32_dwmac *dwmac);
+	void (*resume)(struct stm32_dwmac *dwmac);
+	int (*parse_data)(struct stm32_dwmac *dwmac,
+			  struct device *dev);
+	u32 syscfg_eth_mask;
 };
 
 static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
 {
 	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
-	u32 reg = dwmac->mode_reg;
-	u32 val;
 	int ret;
 
-	val = (plat_dat->interface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
-	ret = regmap_update_bits(dwmac->regmap, reg, MII_PHY_SEL_MASK, val);
-	if (ret)
-		return ret;
+	if (dwmac->ops->set_mode) {
+		ret = dwmac->ops->set_mode(plat_dat);
+		if (ret)
+			return ret;
+	}
 
 	ret = clk_prepare_enable(dwmac->clk_tx);
 	if (ret)
 		return ret;
 
-	ret = clk_prepare_enable(dwmac->clk_rx);
-	if (ret)
-		clk_disable_unprepare(dwmac->clk_tx);
+	if (!dwmac->dev->power.is_suspended) {
+		ret = clk_prepare_enable(dwmac->clk_rx);
+		if (ret) {
+			clk_disable_unprepare(dwmac->clk_tx);
+			return ret;
+		}
+	}
+
+	if (dwmac->ops->clk_prepare) {
+		ret = dwmac->ops->clk_prepare(dwmac, true);
+		if (ret) {
+			clk_disable_unprepare(dwmac->clk_rx);
+			clk_disable_unprepare(dwmac->clk_tx);
+		}
+	}
 
 	return ret;
 }
 
+static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
+{
+	int ret = 0;
+
+	if (prepare) {
+		ret = clk_prepare_enable(dwmac->syscfg_clk);
+		if (ret)
+			return ret;
+
+		if (dwmac->int_phyclk) {
+			ret = clk_prepare_enable(dwmac->clk_eth_ck);
+			if (ret) {
+				clk_disable_unprepare(dwmac->syscfg_clk);
+				return ret;
+			}
+		}
+	} else {
+		clk_disable_unprepare(dwmac->syscfg_clk);
+		if (dwmac->int_phyclk)
+			clk_disable_unprepare(dwmac->clk_eth_ck);
+	}
+	return ret;
+}
+
+static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
+{
+	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+	u32 reg = dwmac->mode_reg;
+	int val;
+
+	switch (plat_dat->interface) {
+	case PHY_INTERFACE_MODE_MII:
+		val = SYSCFG_PMCR_ETH_SEL_MII;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
+		break;
+	case PHY_INTERFACE_MODE_GMII:
+		val = SYSCFG_PMCR_ETH_SEL_GMII;
+		if (dwmac->int_phyclk)
+			val |= SYSCFG_PMCR_ETH_CLK_SEL;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_GMII\n");
+		break;
+	case PHY_INTERFACE_MODE_RMII:
+		val = SYSCFG_PMCR_ETH_SEL_RMII;
+		if (dwmac->int_phyclk)
+			val |= SYSCFG_PMCR_ETH_REF_CLK_SEL;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
+		break;
+	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
+		val = SYSCFG_PMCR_ETH_SEL_RGMII;
+		if (dwmac->int_phyclk)
+			val |= SYSCFG_PMCR_ETH_CLK_SEL;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RGMII\n");
+		break;
+	default:
+		pr_debug("SYSCFG init :  Do not manage %d interface\n",
+			 plat_dat->interface);
+		/* Do not manage others interfaces */
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(dwmac->regmap, reg,
+				 dwmac->ops->syscfg_eth_mask, val);
+}
+
+static int stm32mcu_set_mode(struct plat_stmmacenet_data *plat_dat)
+{
+	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+	u32 reg = dwmac->mode_reg;
+	int val;
+
+	switch (plat_dat->interface) {
+	case PHY_INTERFACE_MODE_MII:
+		val = SYSCFG_MCU_ETH_SEL_MII;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
+		break;
+	case PHY_INTERFACE_MODE_RMII:
+		val = SYSCFG_MCU_ETH_SEL_RMII;
+		pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
+		break;
+	default:
+		pr_debug("SYSCFG init :  Do not manage %d interface\n",
+			 plat_dat->interface);
+		/* Do not manage others interfaces */
+		return -EINVAL;
+	}
+
+	return regmap_update_bits(dwmac->regmap, reg,
+				 dwmac->ops->syscfg_eth_mask, val);
+}
+
 static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
 {
 	clk_disable_unprepare(dwmac->clk_tx);
 	clk_disable_unprepare(dwmac->clk_rx);
+
+	if (dwmac->ops->clk_prepare)
+		dwmac->ops->clk_prepare(dwmac, false);
 }
 
 static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
@@ -70,15 +204,22 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
 	/*  Get TX/RX clocks */
 	dwmac->clk_tx = devm_clk_get(dev, "mac-clk-tx");
 	if (IS_ERR(dwmac->clk_tx)) {
-		dev_err(dev, "No tx clock provided...\n");
+		dev_err(dev, "No ETH Tx clock provided...\n");
 		return PTR_ERR(dwmac->clk_tx);
 	}
+
 	dwmac->clk_rx = devm_clk_get(dev, "mac-clk-rx");
 	if (IS_ERR(dwmac->clk_rx)) {
-		dev_err(dev, "No rx clock provided...\n");
+		dev_err(dev, "No ETH Rx clock provided...\n");
 		return PTR_ERR(dwmac->clk_rx);
 	}
 
+	if (dwmac->ops->parse_data) {
+		err = dwmac->ops->parse_data(dwmac, dev);
+		if (err)
+			return err;
+	}
+
 	/* Get mode register */
 	dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
 	if (IS_ERR(dwmac->regmap))
@@ -91,11 +232,46 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
 	return err;
 }
 
+static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
+			       struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+
+	dwmac->int_phyclk = of_property_read_bool(np, "st,int-phyclk");
+
+	/* Check if internal clk from RCC selected */
+	if (dwmac->int_phyclk) {
+		/*  Get ETH_CLK clocks */
+		dwmac->clk_eth_ck = devm_clk_get(dev, "eth-ck");
+		if (IS_ERR(dwmac->clk_eth_ck)) {
+			dev_err(dev, "No ETH CK clock provided...\n");
+			return PTR_ERR(dwmac->clk_eth_ck);
+		}
+	}
+
+	/*  Clock used for low power mode */
+	dwmac->clk_ethstp = devm_clk_get(dev, "ethstp");
+	if (IS_ERR(dwmac->clk_ethstp)) {
+		dev_err(dev, "No ETH peripheral clock provided for CStop mode ...\n");
+		return PTR_ERR(dwmac->clk_ethstp);
+	}
+
+	/*  Clock for sysconfig */
+	dwmac->syscfg_clk = devm_clk_get(dev, "syscfg-clk");
+	if (IS_ERR(dwmac->syscfg_clk)) {
+		dev_err(dev, "No syscfg clock provided...\n");
+		return PTR_ERR(dwmac->syscfg_clk);
+	}
+
+	return 0;
+}
+
 static int stm32_dwmac_probe(struct platform_device *pdev)
 {
 	struct plat_stmmacenet_data *plat_dat;
 	struct stmmac_resources stmmac_res;
 	struct stm32_dwmac *dwmac;
+	const struct stm32_ops *data;
 	int ret;
 
 	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
@@ -112,6 +288,16 @@ static int stm32_dwmac_probe(struct platform_device *pdev)
 		goto err_remove_config_dt;
 	}
 
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data) {
+		dev_err(&pdev->dev, "no of match data provided\n");
+		ret = -EINVAL;
+		goto err_remove_config_dt;
+	}
+
+	dwmac->ops = data;
+	dwmac->dev = &pdev->dev;
+
 	ret = stm32_dwmac_parse_data(dwmac, &pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "Unable to parse OF data\n");
@@ -149,15 +335,48 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
 	return ret;
 }
 
+static int stm32mp1_suspend(struct stm32_dwmac *dwmac)
+{
+	int ret = 0;
+
+	ret = clk_prepare_enable(dwmac->clk_ethstp);
+	if (ret)
+		return ret;
+
+	clk_disable_unprepare(dwmac->clk_tx);
+	clk_disable_unprepare(dwmac->syscfg_clk);
+	if (dwmac->int_phyclk)
+		clk_disable_unprepare(dwmac->clk_eth_ck);
+
+	return ret;
+}
+
+static void stm32mp1_resume(struct stm32_dwmac *dwmac)
+{
+	clk_disable_unprepare(dwmac->clk_ethstp);
+}
+
+static int stm32mcu_suspend(struct stm32_dwmac *dwmac)
+{
+	clk_disable_unprepare(dwmac->clk_tx);
+	clk_disable_unprepare(dwmac->clk_rx);
+
+	return 0;
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int stm32_dwmac_suspend(struct device *dev)
 {
 	struct net_device *ndev = dev_get_drvdata(dev);
 	struct stmmac_priv *priv = netdev_priv(ndev);
+	struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
+
 	int ret;
 
 	ret = stmmac_suspend(dev);
-	stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+	if (dwmac->ops->suspend)
+		ret = dwmac->ops->suspend(dwmac);
 
 	return ret;
 }
@@ -166,8 +385,12 @@ static int stm32_dwmac_resume(struct device *dev)
 {
 	struct net_device *ndev = dev_get_drvdata(dev);
 	struct stmmac_priv *priv = netdev_priv(ndev);
+	struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
 	int ret;
 
+	if (dwmac->ops->resume)
+		dwmac->ops->resume(dwmac);
+
 	ret = stm32_dwmac_init(priv->plat);
 	if (ret)
 		return ret;
@@ -181,8 +404,24 @@ static int stm32_dwmac_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
 	stm32_dwmac_suspend, stm32_dwmac_resume);
 
+static struct stm32_ops stm32mcu_dwmac_data = {
+	.set_mode = stm32mcu_set_mode,
+	.suspend = stm32mcu_suspend,
+	.syscfg_eth_mask = SYSCFG_MCU_ETH_MASK
+};
+
+static struct stm32_ops stm32mp1_dwmac_data = {
+	.set_mode = stm32mp1_set_mode,
+	.clk_prepare = stm32mp1_clk_prepare,
+	.suspend = stm32mp1_suspend,
+	.resume = stm32mp1_resume,
+	.parse_data = stm32mp1_parse_data,
+	.syscfg_eth_mask = SYSCFG_MP1_ETH_MASK
+};
+
 static const struct of_device_id stm32_dwmac_match[] = {
-	{ .compatible = "st,stm32-dwmac"},
+	{ .compatible = "st,stm32-dwmac", .data = &stm32mcu_dwmac_data},
+	{ .compatible = "st,stm32mp1-dwmac", .data = &stm32mp1_dwmac_data},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
@@ -199,5 +438,6 @@ static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
 module_platform_driver(stm32_dwmac_driver);
 
 MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@gmail.com>");
-MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_AUTHOR("Christophe Roullier <christophe.roullier@st.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32 DWMAC Specific Glue layer");
 MODULE_LICENSE("GPL v2");
-- 
1.9.1

^ permalink raw reply related

* [PATCH V4 0/8] net: ethernet: stmmac: add support for stm32mp1
From: Christophe Roullier @ 2018-05-23 15:47 UTC (permalink / raw)
  To: mark.rutland, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro
  Cc: devicetree, linux-arm-kernel, netdev, christophe.roullier, andrew

Patches to have Ethernet support on stm32mp1
Changelog:
Remark from Rob Herring
Move Documentation/devicetree/bindings/arm/stm32.txt in 
Documentation/devicetree/bindings/arm/stm32/stm32.txt and create
Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt

Replace also in arch/arm/boot/dts/stm32mp157c.dtsi, syscfg: system-config@50020000 
with syscfg: syscon@50020000syscfg: system-config@50020000 

Christophe Roullier (8):
  net: ethernet: stmmac: add adaptation for stm32mp157c.
  dt-bindings: stm32-dwmac: add support of MPU families
  ARM: dts: stm32: add ethernet pins to stm32mp157c
  ARM: dts: stm32: Add syscfg on stm32mp1
  ARM: dts: stm32: Add ethernet dwmac on stm32mp1
  net: stmmac: add dwmac-4.20a compatible
  ARM: dts: stm32: add support of ethernet on stm32mp157c-ev1
  dt-bindings: stm32: add compatible for syscon

 Documentation/devicetree/bindings/arm/stm32.txt    |  10 -
 .../devicetree/bindings/arm/stm32/stm32-syscon.txt |  14 ++
 .../devicetree/bindings/arm/stm32/stm32.txt        |  10 +
 .../devicetree/bindings/net/stm32-dwmac.txt        |  18 +-
 arch/arm/boot/dts/stm32mp157-pinctrl.dtsi          |  46 ++++
 arch/arm/boot/dts/stm32mp157c-ev1.dts              |  20 ++
 arch/arm/boot/dts/stm32mp157c.dtsi                 |  35 +++
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 270 +++++++++++++++++++--
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   3 +-
 9 files changed, 398 insertions(+), 28 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt

-- 
1.9.1

^ permalink raw reply

* Re: [PATCH v6 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
From: spanda-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-05-23 15:47 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, ryadav-sgV2jX0FEOL9JmXXK+q4OQ,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	robdclark-Re5JQEeQqe8AvxtiuMwx3w, nganji-sgV2jX0FEOL9JmXXK+q4OQ,
	seanpaul-F7+t8E8rja9g9hUCZPvPmw, abhinavk-sgV2jX0FEOL9JmXXK+q4OQ,
	hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
	freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	jsanka-sgV2jX0FEOL9JmXXK+q4OQ, chandanu-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <152648804247.210890.6352930842767133968-n1Xw8LXHxjTHt/MElyovVYaSKrA+ACpX0E9HWUfgJXw@public.gmane.org>

On 2018-05-16 21:57, Stephen Boyd wrote:
> Quoting Sandeep Panda (2018-05-14 22:52:42)
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> new file mode 100644
>> index 0000000..b82bb56
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> @@ -0,0 +1,81 @@
>> +Optional properties:
>> +- interrupts: Specifier for the SN65DSI86 interrupt line.
>> +- hpd-gpios: OF device-tree gpio specifications for HPD pin.
>> +
>> +- gpio-controller: Marks the device has a GPIO controller.
>> +- #gpio-cells    : Should be two. The first cell is the pin number 
>> and
>> +                   the second cell is used to specify flags.
>> +                   See ../../gpio/gpio.txt for more information.
>> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description 
>> of
>> +               the cell formats.
>> +
>> +- clock-names: should be "refclk"
>> +- clocks: OF device-tree clock specification for refclk input. The 
>> reference
> 
> What is "OF device-tree .* specification" providing? This is all an OF
> device-tree specification.
Ok. i will remove OF device tree, only keep specification for refclk 
input.
> 
>> +  clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
>> +
>> +Required nodes:
>> +
>> +This device has two video ports. Their connections are modelled using 
>> the
>> +OF graph bindings specified in 
>> Documentation/devicetree/bindings/graph.txt.
>> +
>> +- Video port 0 for DSI input
>> +- Video port 1 for eDP output
>> +
>> +Example
>> +-------
>> +
>> +edp-bridge@2d {
>> +       compatible = "ti,sn65dsi86";
>> +       #address-cells = <1>;
>> +       #size-cells = <0>;
>> +       reg = <0x2d>;
>> +
>> +       enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
>> +       interrupt-parent = <&gpio3>;
>> +       interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
>> +
>> +       vccio-supply = <&pm8916_l17>;
>> +       vcca-supply = <&pm8916_l6>;
>> +       vpll-supply = <&pm8916_l17>;
>> +       vcc-supply = <&pm8916_l6>;
>> +
>> +       clock-names = "refclk";
>> +       clocks = <&input_refclk>;
>> +
>> +       ports {
>> +               #address-cells = <1>;
>> +               #size-cells = <0>;
>> +
>> +               port@0 {
>> +                       reg = <0>;
>> +
>> +                       edp_bridge_in: endpoint {
>> +                               remote-endpoint = <&dsi_out>;
> 
> How do we know the number of lanes that are connected and if there's 
> one
> channel (A) or two channels (A and B)? Would there be two endpoints in
> that case?
Currently we have hard coded the number of lanes to 4 in driver. And 
regarding supporting 2 DSI input channels dt-binding, we are planning to 
add those entries once we upload a patchset support dual dsi 
configuration in bridge driver.
> 
>> +                       };
>> +               };
>> +
>> +               port@1 {
>> +                       reg = <1>;
>> +
>> +                       edp_bridge_out: endpoint {
>> +                               remote-endpoint = <&edp_panel_in>;
> 
> The hardware looks to support some sort of lane renumbering scheme,
> where the eDP logical lane 0 can be routed through a different pin than
> MLP/N0, same for logical lane 1, etc. I don't have a use case for this
> right now, but I hope that it could be added somewhere in the binding 
> as
> an optional property to describe this lane remapping feature. It also
> has some sort of lane polarity inversion feature. Perhaps there needs 
> to
> be a lane-config property that does this remapping and inversion with
> two cells.
Ok. I will add this feature to dt binding.
> 
> 	lane-config = <0 0>, /* Lane 0 logical is lane 0 phys (!inv) */
> 	              <1 0>, /* Lane 1 logical is lane 1 phys (!inv) */
> 		      <2 0>, /* Lane 2 logical is lane 2 phys (!inv) */
> 		      <3 0>; /* Lane 3 logical is lane 3 phys (!inv) */
> 
> Or
> 
> 	lane-config = <2 1>, /* Lane 2 logical is lane 0 phys (inv) */
> 	              <1 0>, /* Lane 1 logical is lane 1 phys (!inv) */
> 		      <3 1>, /* Lane 3 logical is lane 2 phys (inv) */
> 		      <0 0>; /* Lane 0 logical is lane 3 phys (!inv) */
> 
> 
>> +                       };
>> +               };
>> +       };
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

^ permalink raw reply

* Re: [PATCH RFC 00/24] Lima DRM driver
From: Daniel Vetter @ 2018-05-23 15:44 UTC (permalink / raw)
  To: Qiang Yu
  Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
	Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
	Christian König, Erico Nunes
In-Reply-To: <CAKGbVbsMftEyOv6bh2g-yebj1+yO+BNJ=j1yJzgjwkM59wFz5w@mail.gmail.com>

On Wed, May 23, 2018 at 3:52 PM, Qiang Yu <yuq825@gmail.com> wrote:
> On Wed, May 23, 2018 at 5:29 PM, Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>
>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>
>>> This implementation mainly take amdgpu DRM driver as reference.
>>>
>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>    OpenGL vertex shader processing and PP is for fragment shader
>>>    processing. Each processor has its own MMU so prcessors work in
>>>    virtual address space.
>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>    for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>    togather to handle a single fragment shader task divided by
>>>    FB output tiled pixels. Mali 400 user space driver is
>>>    responsible for assign target tiled pixels to each PP, but mali
>>>    450 has a HW module called DLBU to dynamically balance each
>>>    PP's load.
>>> - User space driver allocate buffer object and map into GPU
>>>    virtual address space, upload command stream and draw data with
>>>    CPU mmap of the buffer object, then submit task to GP/PP with
>>>    a register frame indicating where is the command stream and misc
>>>    settings.
>>> - There's no command stream validation/relocation due to each user
>>>    process has its own GPU virtual address space. GP/PP's MMU switch
>>>    virtual address space before running two tasks from different
>>>    user process. Error or evil user space code just get MMU fault
>>>    or GP/PP error IRQ, then the HW/SW will be recovered.
>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>    lima buffer object which is allocated from TTM page pool. all
>>>    lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>    allocation, so there's no buffer eviction and swap for now. We
>>>    need reverse engineering to see if and how GP/PP support MMU
>>>    fault recovery (continue execution). Otherwise we have to
>>>    pin/unpin each envolved buffer when task creation/deletion.
>>
>>
>> Well pinning all memory is usually a no-go for upstreaming. But since you
>> are already using the drm_sched for GPU task scheduling why are you actually
>> needing this?
>>
>> The scheduler should take care of signaling all fences when the hardware is
>> done with it's magic and that is enough for TTM to note that a buffer object
>> is movable again (e.g. unpin them).
>
> Please correct me if I'm wrong.
>
> One way to implement eviction/swap is like this:
> call validation on each buffers involved in a task, but this won't
> prevent it from
> eviction/swap when executing, so a GPU MMU fault may happen and in the
> handler we need to recover the buffer evicted/swapped.
>
> Another way is pin/unpin buffers evolved when task create/free.
>
> First way is better when memory load is low and second way is better when
> memory load is high. First way also need less memory.
>
> So I'd prefer first way but due to the GPU MMU fault
> HW op need reverse engineering, I have to pin all buffers now. After
> the HW op is clear, I can choose one way to implement.

All the drivers using ttm have something that looks like vram, or a
requirement to move buffers around. Afaiui that includes virtio drm
driver. From your description you don't have such a requirement, and
then doing what etnaviv has done would be a lot simpler. Everything
that's not related to buffer movement handling is also available
outside of ttm already.
-Daniel

> Regards,
> Qiang
>
>>
>> Christian.
>>
>>
>>> - Use drm_sched for GPU task schedule. Each OpenGL context should
>>>    have a lima context object in the kernel to distinguish tasks
>>>    from different user. drm_sched gets task from each lima context
>>>    in a fair way.
>>>
>>> Not implemented:
>>> - Dump buffer support
>>> - Power management
>>> - Performance counter
>>>
>>> This patch serial just pack a pair of .c/.h files in each patch.
>>> For whole history of this driver's development, see:
>>> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>>>
>>> Mesa driver is still in development and not ready for daily usage,
>>> but can run some simple tests like kmscube and glamrk2, see:
>>> https://github.com/yuq/mesa-lima
>>>
>>> Andrei Paulau (1):
>>>    arm64/dts: add switch-delay for meson mali
>>>
>>> Lima Project Developers (10):
>>>    drm/lima: add mali 4xx GPU hardware regs
>>>    drm/lima: add lima core driver
>>>    drm/lima: add GPU device functions
>>>    drm/lima: add PMU related functions
>>>    drm/lima: add PP related functions
>>>    drm/lima: add MMU related functions
>>>    drm/lima: add GPU virtual memory space handing
>>>    drm/lima: add GEM related functions
>>>    drm/lima: add GEM Prime related functions
>>>    drm/lima: add makefile and kconfig
>>>
>>> Qiang Yu (12):
>>>    dt-bindings: add switch-delay property for mali-utgard
>>>    arm64/dts: add switch-delay for meson mali
>>>    Revert "drm: Nerf the preclose callback for modern drivers"
>>>    drm/lima: add lima uapi header
>>>    drm/lima: add L2 cache functions
>>>    drm/lima: add GP related functions
>>>    drm/lima: add BCAST related function
>>>    drm/lima: add DLBU related functions
>>>    drm/lima: add TTM subsystem functions
>>>    drm/lima: add buffer object functions
>>>    drm/lima: add GPU schedule using DRM_SCHED
>>>    drm/lima: add context related functions
>>>
>>> Simon Shields (1):
>>>    ARM: dts: add gpu node to exynos4
>>>
>>>   .../bindings/gpu/arm,mali-utgard.txt          |   4 +
>>>   arch/arm/boot/dts/exynos4.dtsi                |  33 ++
>>>   arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi   |   1 +
>>>   .../boot/dts/amlogic/meson-gxl-mali.dtsi      |   1 +
>>>   drivers/gpu/drm/Kconfig                       |   2 +
>>>   drivers/gpu/drm/Makefile                      |   1 +
>>>   drivers/gpu/drm/drm_file.c                    |   8 +-
>>>   drivers/gpu/drm/lima/Kconfig                  |   9 +
>>>   drivers/gpu/drm/lima/Makefile                 |  19 +
>>>   drivers/gpu/drm/lima/lima_bcast.c             |  65 +++
>>>   drivers/gpu/drm/lima/lima_bcast.h             |  34 ++
>>>   drivers/gpu/drm/lima/lima_ctx.c               | 143 +++++
>>>   drivers/gpu/drm/lima/lima_ctx.h               |  51 ++
>>>   drivers/gpu/drm/lima/lima_device.c            | 407 ++++++++++++++
>>>   drivers/gpu/drm/lima/lima_device.h            | 136 +++++
>>>   drivers/gpu/drm/lima/lima_dlbu.c              |  75 +++
>>>   drivers/gpu/drm/lima/lima_dlbu.h              |  37 ++
>>>   drivers/gpu/drm/lima/lima_drv.c               | 466 ++++++++++++++++
>>>   drivers/gpu/drm/lima/lima_drv.h               |  77 +++
>>>   drivers/gpu/drm/lima/lima_gem.c               | 459 ++++++++++++++++
>>>   drivers/gpu/drm/lima/lima_gem.h               |  41 ++
>>>   drivers/gpu/drm/lima/lima_gem_prime.c         |  66 +++
>>>   drivers/gpu/drm/lima/lima_gem_prime.h         |  31 ++
>>>   drivers/gpu/drm/lima/lima_gp.c                | 293 +++++++++++
>>>   drivers/gpu/drm/lima/lima_gp.h                |  34 ++
>>>   drivers/gpu/drm/lima/lima_l2_cache.c          |  98 ++++
>>>   drivers/gpu/drm/lima/lima_l2_cache.h          |  32 ++
>>>   drivers/gpu/drm/lima/lima_mmu.c               | 154 ++++++
>>>   drivers/gpu/drm/lima/lima_mmu.h               |  34 ++
>>>   drivers/gpu/drm/lima/lima_object.c            | 120 +++++
>>>   drivers/gpu/drm/lima/lima_object.h            |  87 +++
>>>   drivers/gpu/drm/lima/lima_pmu.c               |  85 +++
>>>   drivers/gpu/drm/lima/lima_pmu.h               |  30 ++
>>>   drivers/gpu/drm/lima/lima_pp.c                | 418 +++++++++++++++
>>>   drivers/gpu/drm/lima/lima_pp.h                |  37 ++
>>>   drivers/gpu/drm/lima/lima_regs.h              | 304 +++++++++++
>>>   drivers/gpu/drm/lima/lima_sched.c             | 497 ++++++++++++++++++
>>>   drivers/gpu/drm/lima/lima_sched.h             | 126 +++++
>>>   drivers/gpu/drm/lima/lima_ttm.c               | 409 ++++++++++++++
>>>   drivers/gpu/drm/lima/lima_ttm.h               |  44 ++
>>>   drivers/gpu/drm/lima/lima_vm.c                | 312 +++++++++++
>>>   drivers/gpu/drm/lima/lima_vm.h                |  73 +++
>>>   include/drm/drm_drv.h                         |  23 +-
>>>   include/uapi/drm/lima_drm.h                   | 195 +++++++
>>>   44 files changed, 5565 insertions(+), 6 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/lima/Kconfig
>>>   create mode 100644 drivers/gpu/drm/lima/Makefile
>>>   create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_device.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_device.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_drv.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_drv.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gem.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gem.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gp.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_gp.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_object.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_object.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_pp.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_pp.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_sched.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_sched.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
>>>   create mode 100644 drivers/gpu/drm/lima/lima_vm.c
>>>   create mode 100644 drivers/gpu/drm/lima/lima_vm.h
>>>   create mode 100644 include/uapi/drm/lima_drm.h
>>>
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver
From: Rob Herring @ 2018-05-23 15:42 UTC (permalink / raw)
  To: M P
  Cc: Michel Pollet, open list:MEDIA DRIVERS FOR RENESAS - FCP,
	Simon Horman, Phil Edworthy, Michel Pollet, Magnus Damm,
	Mark Rutland, Michael Turquette, Stephen Boyd, Geert Uytterhoeven,
	devicetree, linux-kernel@vger.kernel.org, linux-clk
In-Reply-To: <CAMMfpEwn3+fCZZZ8ADNxjun+jzNSnH+8xPcA8OUS_jPUJ-o6LA@mail.gmail.com>

On Wed, May 23, 2018 at 1:52 AM, M P <buserror@gmail.com> wrote:
> Hi Rob,
>
> On Tue, 22 May 2018 at 17:09, Rob Herring <robh@kernel.org> wrote:
>
>> On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
>> > to provide the SoC clock infrastructure for Linux.
>> >
>> > This documents the driver bindings.
>> >
>> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>> > ---
>> >  .../bindings/clock/renesas,rzn1-clocks.txt         | 44
> ++++++++++++++++++++++
>> >  1 file changed, 44 insertions(+)
>> >  create mode 100644
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> >
>> > diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > new file mode 100644
>> > index 0000000..0c41137
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > @@ -0,0 +1,44 @@
>> > +* Renesas RZ/N1 Clock Driver
>> > +
>> > +This driver provides the clock infrastructure used by all the other
> drivers.
>
>> Bindings document h/w not drivers.
>
>> > +
>> > +One of the 'special' feature of this infrastructure is that Linux
> doesn't
>
>> Bindings are not just for Linux.
>
>> > +necessary 'own' all the clocks on the SoC, some other OS runs on
>> > +the Cortex-M3 core and that OS can access and claim it's own clocks.
>
>> How is this relevant to the binding?
>
> Well you just said it, if the binding is not just for linux, it's probably
> a good idea to mention it somewhere since I can promise you it's *not*
> documented in the hardware manual. Whatever this binding is for, it's
> relevant to point out it is different from the other clock drivers in the
> same directory... ?

That's not an uncommon issue (sometimes it's secure world that owns
the clocks, not even a different processor). I'm just not sure what I
do with this information. It doesn't tell me which clocks are owned by
the M3 or not.

>> > +
>> > +Required Properties:
>> > +
>> > +  - compatible: Must be
>> > +    - "renesas,r9a06g032-clocks" for the RZ/N1D
>> > +    and "renesas,rzn1-clocks" as a fallback.
>
>> Is "clocks" how the chip reference manual refers to this block?
>
> No, the block is called 'sysctrl' and has tons of other stuff in there.
> I've tried multiple times to get a 'sysctrl' driver in the previous
> versions of the patch, in various shape or form, and I can't because I'd be
> supposed to 'document' binding for stuff that has no code, no purpose, no
> testing, and have all wildly different topics. So, after some more
> lengthily discussion with Geert, we've decided to make the 'primary'
> feature of that block (clocks) as a driver, and see from there onward.

If you are referring to Geert's reply on v4, then this is not how I
interpreted it. I understood it as make the clock driver bind to the
sysctrl node and the clock driver can register other functions like
reset. Then later if you need multiple drivers, you can make an MFD
driver that binds to the sysctrl node and creates child devices to
bind sub-drivers (like clocks) to. But the DT doesn't change in the
process wrt clocks.

You don't have to have a driver for everything, but the binding should
be as complete as possible and done in an extendable way. The way you
have done it now is not. I can already see that at some point you will
want to break things and do something like this:

{
  compatible = "renesas,r9a06g032-sysctrl";
  ...
  {
    compatible = "renesas,r9a06g032-clocks";
    ...
  };
};

Which is likely wrong because there's no need to have a child node
like that. The parent node can be the clock provider (and any other
provider). There are cases when child nodes do make sense, but we need
a more complete binding to make that decision. Evolving it one feature
at a time doesn't work.

Rob

^ permalink raw reply


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