* [PATCH] net: mvpp2: fix dma unmapping of TX buffers for fragments
From: David Miller @ 2016-12-17 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217162658.63bc2423@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Sat, 17 Dec 2016 16:26:58 +0100
> Yes, I was thinking of moving towards a single array, as it's indeed
> crazy to have three arrays for that. However, since it's a fix going
> into stable, I also wanted to keep it as simple/straightforward as
> possible and avoid refactoring other parts of the code.
By the same token, by adding a third array you are making the code
more complex, adding more error recovery paths, etc.
> If you however believe moving to one array should be done as part of
> the fix, I'll do this.
Please do.
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-12-17 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5855560E.4050609@math.uni-bielefeld.de>
2016-12-18 0:13 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
> Hey guys,
>
> Chanwoo Choi wrote:
>> Hi Lin,
>>
>> 2016-11-24 18:54 GMT+09:00 Chanwoo Choi <cw00.choi@samsung.com>:
>>> Hi Lin,
>>>
>>> On 2016? 11? 24? 18:28, Chanwoo Choi wrote:
>>>> Hi Lin,
>>>>
>>>> On 2016? 11? 24? 17:34, hl wrote:
>>>>> Hi Chanwoo Choi,
>>>>>
>>>>>
>>>>> On 2016?11?24? 16:16, Chanwoo Choi wrote:
>>>>>> Hi Lin,
>>>>>>
>>>>>> On 2016? 11? 24? 16:34, hl wrote:
>>>>>>> Hi Chanwoo Choi,
>>>>>>>
>>>>>>> I think the dev_pm_opp_get_suspend_opp() have implement most of
>>>>>>> the funtion, all we need is just define the node in dts, like following:
>>>>>>>
>>>>>>> &dmc_opp_table {
>>>>>>> opp06 {
>>>>>>> opp-suspend;
>>>>>>> };
>>>>>>> };
>>>>>> Two approaches use the 'opp-suspend' property.
>>>>>>
>>>>>> I think that the method to support suspend-opp have to
>>>>>> guarantee following conditions:
>>>>>> - Support the all of devfreq's governors.
>>>>> As MyungJoo Ham suggestion, i will set the suspend frequency in devfreq_suspend_device(),
>>>>> which will ingore governor.
>>>>
>>>> Other approach already support the all of governors.
>>>> Before calling the mail, I discussed with Myungjoo Ham.
>>>> Myungjoo prefer to use the devfreq_suspend/devfreq_resume().
>>>
>>> It is not correct expression. We need to wait the reply from Myungjoo
>>> to clarify this.
>>>
>>>>
>>>> To Myungjoo,
>>>> Please add your opinion how to support the suspend frequency.
>>>
>>>>
>>>>>> - Devfreq framework have the responsibility to change the
>>>>>> frequency/voltage for suspend-opp. If we uses the
>>>>>> new devfreq_suspend(), each devfreq device don't care
>>>>>> how to support the suspend-opp. Just the developer of each
>>>>>> devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
>>>>> Why should support change the voltage in devfreq framework, i think it shuold be handle in
>>>>> specific driver, i think the devfreq only handle it can get the right frequency, then pass it to
>>>>
>>>> No, the frequency should be handled by governor or framework.
>>>> The each devfreq device has no any responsibility of next frequency/voltage.
>>>> The governor and core of devfreq can decide the next frequency/voltage.
>>>> You can refer to the cpufreq subsystem.
>>>>
>>>>> specific driver, i think the voltage should handle in the devfreq->profile->target();
>>>>
>>>> The call of devfreq->profile->target() have to be handled by devfreq framework.
>>>> If user want to set the suspend frequency, user can add the 'suspend-opp' property.
>>>> It think this way is easy.
>>>>
>>>> But,
>>>> If the each devfreq device want to decide the next frequency/voltage only for
>>>> suspend state. We can check the cpufreq subsystem.
>>>>
>>>> If specific devfreq device want to handle the suspend frequency,
>>>> each devfreq will add the own suspend/resume functions as following:
>>>>
>>>> struct devfreq_dev_profile {
>>>> int (*suspend)(struct devfreq *dev); // new function pointer
>>>> int (*resume)(struct devfreq *dev); // new function pointer
>>>> } a_profile;
>>>>
>>>> a_profile = devfreq_generic_suspend;
>>>>
>>>> The devfreq framework will provide the devfreq_generic_suspend() funticon.
>>>> int devfreq_generic_suspend(struce devfreq *dev) {
>>>> ...
>>>> devfreq->profile->target(..., devfreq->suspend_freq);
>>>> ...
>>>> }
>>>>
>>>> or
>>>>
>>>> a_profile = a_devfreq_suspend; // specific function of each devfreq device
>>>>
>>>> The devfreq_suspend() will call 'devfreq->profile->suspend()' function
>>>> instead of devfreq->profile->target();
>>>>
>>>> The devfreq call the 'devfreq->profile->suspend()'
>>>> to support the suspend frequency.
>>>>
>>>> Regards,
>>>> Chanwoo Choi
>>>
>>> The key difference between two approaches:
>>>
>>> Your approach:
>>> - The each developer should add the 'opp-suspend' property to the dts file.
>>> - The each devfreq should call the devfreq_suspend_device()
>>> to support the suspend frequency.
>>>
>>> If each devfreq doesn't call the devfreq_suspend_device(), devfreq framework
>>> can support the suspend frequency.
>>>
>>> Other approach:
>>> - The each developer only should add the 'opp-suspend' property to the dts file
>>> without the additional behavior.
>>>
>>> In the cpufreq subsystem,
>>> When support the suspend frequency of cpufreq, we just add 'opp-suspend' property
>>> without the additional behavior.
>>
>> I'm missing the use-case when using the devfreq_suspend_device()
>> before entering the suspend mode. We should consider the case when
>> devfreq device
>> calls the devfreq_suspend_device() directly. Because devfreq_suspend_device()
>> is exported function, each devfreq device call this function on the fly
>> without entering the suspend mode.
>>
>> I correct my opinion. Your approach is necessary. I'm sorry to confuse you.
>> So, I make the following patch. This patch set the suspend frequency
>> in devfreq_suspend_device() after stoping the governor.
>> It consider the all governors of devfreq.
>>
>> What do you think?
>> If you are ok, I'll send this patch with your author.
> The problem I see here is that we need to keep track of the suspended
> state when suspending the (entire) devfreq subsystem. When doing that,
> we don't know if any device driver has previously called
> devfreq_suspend_device() and might end up calling it twice.
>
> Same thing on devfreq subsystem resume.
>
> I've prepared a new RFC of my series (going to send it shortly), but I'm
> not so happy with the current design. I think it would be much cleaner
> to keep some suspend_refcount in struct devfreq so that I can call
> devfreq_suspend_device() multiple times, while keeping a sane internal
> state.
I agree the devfreq need reference count for devfreq_suspend/resume_device.
This patch focus on when changing the suspend frequency.
>
> Something like devfreq_device_runtime_{put,get}() perhaps?
Why do devfreq need new additional functions?
I think the devfreq_suspend/resume_device are enough.
Thanks,
Chanwoo Choi
>
> - Tobias
>
>
>
>>
>> int devfreq_suspend_device(struct devfreq *devfreq)
>> {
>> + int ret = 0;
>> +
>> if (!devfreq)
>> return -EINVAL;
>>
>> if (!devfreq->governor)
>> return 0;
>>
>> - return devfreq->governor->event_handler(devfreq,
>> + ret = devfreq->governor->event_handler(devfreq,
>> DEVFREQ_GOV_SUSPEND, NULL);
>> + if (ret < 0) {
>> + dev_err(devfreq->dev.parent, "failed to suspend governor\n");
>> + return ret;
>> + }
>> +
>> + if (devfreq->suspend_freq) {
>> + ret = devfreq->profile->target(devfreq->dev.parent,
>> + &devfreq->suspend_freq, 0);
>> + if (ret < 0) {
>> + dev_err(devfreq->dev.parent,
>> + "failed to set suspend-freq\n");
>> + return ret;
>> + }
>> + dev_dbg(devfreq->dev.parent, "Setting suspend-freq: %lu\n",
>> + devfreq->suspend_freq);
>> + }
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL(devfreq_suspend_device);
>>
>
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Tobias Jakobi @ 2016-12-17 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH0HDuexEHR5aqBxWifFKL1fBT1K80XGFX27YqHtDf_7hw@mail.gmail.com>
Hey Chanwoo,
Chanwoo Choi wrote:
> 2016-12-18 0:13 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
>> Hey guys,
>>
>> Chanwoo Choi wrote:
>>> Hi Lin,
>>>
>>> 2016-11-24 18:54 GMT+09:00 Chanwoo Choi <cw00.choi@samsung.com>:
>>>> Hi Lin,
>>>>
>>>> On 2016? 11? 24? 18:28, Chanwoo Choi wrote:
>>>>> Hi Lin,
>>>>>
>>>>> On 2016? 11? 24? 17:34, hl wrote:
>>>>>> Hi Chanwoo Choi,
>>>>>>
>>>>>>
>>>>>> On 2016?11?24? 16:16, Chanwoo Choi wrote:
>>>>>>> Hi Lin,
>>>>>>>
>>>>>>> On 2016? 11? 24? 16:34, hl wrote:
>>>>>>>> Hi Chanwoo Choi,
>>>>>>>>
>>>>>>>> I think the dev_pm_opp_get_suspend_opp() have implement most of
>>>>>>>> the funtion, all we need is just define the node in dts, like following:
>>>>>>>>
>>>>>>>> &dmc_opp_table {
>>>>>>>> opp06 {
>>>>>>>> opp-suspend;
>>>>>>>> };
>>>>>>>> };
>>>>>>> Two approaches use the 'opp-suspend' property.
>>>>>>>
>>>>>>> I think that the method to support suspend-opp have to
>>>>>>> guarantee following conditions:
>>>>>>> - Support the all of devfreq's governors.
>>>>>> As MyungJoo Ham suggestion, i will set the suspend frequency in devfreq_suspend_device(),
>>>>>> which will ingore governor.
>>>>>
>>>>> Other approach already support the all of governors.
>>>>> Before calling the mail, I discussed with Myungjoo Ham.
>>>>> Myungjoo prefer to use the devfreq_suspend/devfreq_resume().
>>>>
>>>> It is not correct expression. We need to wait the reply from Myungjoo
>>>> to clarify this.
>>>>
>>>>>
>>>>> To Myungjoo,
>>>>> Please add your opinion how to support the suspend frequency.
>>>>
>>>>>
>>>>>>> - Devfreq framework have the responsibility to change the
>>>>>>> frequency/voltage for suspend-opp. If we uses the
>>>>>>> new devfreq_suspend(), each devfreq device don't care
>>>>>>> how to support the suspend-opp. Just the developer of each
>>>>>>> devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
>>>>>> Why should support change the voltage in devfreq framework, i think it shuold be handle in
>>>>>> specific driver, i think the devfreq only handle it can get the right frequency, then pass it to
>>>>>
>>>>> No, the frequency should be handled by governor or framework.
>>>>> The each devfreq device has no any responsibility of next frequency/voltage.
>>>>> The governor and core of devfreq can decide the next frequency/voltage.
>>>>> You can refer to the cpufreq subsystem.
>>>>>
>>>>>> specific driver, i think the voltage should handle in the devfreq->profile->target();
>>>>>
>>>>> The call of devfreq->profile->target() have to be handled by devfreq framework.
>>>>> If user want to set the suspend frequency, user can add the 'suspend-opp' property.
>>>>> It think this way is easy.
>>>>>
>>>>> But,
>>>>> If the each devfreq device want to decide the next frequency/voltage only for
>>>>> suspend state. We can check the cpufreq subsystem.
>>>>>
>>>>> If specific devfreq device want to handle the suspend frequency,
>>>>> each devfreq will add the own suspend/resume functions as following:
>>>>>
>>>>> struct devfreq_dev_profile {
>>>>> int (*suspend)(struct devfreq *dev); // new function pointer
>>>>> int (*resume)(struct devfreq *dev); // new function pointer
>>>>> } a_profile;
>>>>>
>>>>> a_profile = devfreq_generic_suspend;
>>>>>
>>>>> The devfreq framework will provide the devfreq_generic_suspend() funticon.
>>>>> int devfreq_generic_suspend(struce devfreq *dev) {
>>>>> ...
>>>>> devfreq->profile->target(..., devfreq->suspend_freq);
>>>>> ...
>>>>> }
>>>>>
>>>>> or
>>>>>
>>>>> a_profile = a_devfreq_suspend; // specific function of each devfreq device
>>>>>
>>>>> The devfreq_suspend() will call 'devfreq->profile->suspend()' function
>>>>> instead of devfreq->profile->target();
>>>>>
>>>>> The devfreq call the 'devfreq->profile->suspend()'
>>>>> to support the suspend frequency.
>>>>>
>>>>> Regards,
>>>>> Chanwoo Choi
>>>>
>>>> The key difference between two approaches:
>>>>
>>>> Your approach:
>>>> - The each developer should add the 'opp-suspend' property to the dts file.
>>>> - The each devfreq should call the devfreq_suspend_device()
>>>> to support the suspend frequency.
>>>>
>>>> If each devfreq doesn't call the devfreq_suspend_device(), devfreq framework
>>>> can support the suspend frequency.
>>>>
>>>> Other approach:
>>>> - The each developer only should add the 'opp-suspend' property to the dts file
>>>> without the additional behavior.
>>>>
>>>> In the cpufreq subsystem,
>>>> When support the suspend frequency of cpufreq, we just add 'opp-suspend' property
>>>> without the additional behavior.
>>>
>>> I'm missing the use-case when using the devfreq_suspend_device()
>>> before entering the suspend mode. We should consider the case when
>>> devfreq device
>>> calls the devfreq_suspend_device() directly. Because devfreq_suspend_device()
>>> is exported function, each devfreq device call this function on the fly
>>> without entering the suspend mode.
>>>
>>> I correct my opinion. Your approach is necessary. I'm sorry to confuse you.
>>> So, I make the following patch. This patch set the suspend frequency
>>> in devfreq_suspend_device() after stoping the governor.
>>> It consider the all governors of devfreq.
>>>
>>> What do you think?
>>> If you are ok, I'll send this patch with your author.
>> The problem I see here is that we need to keep track of the suspended
>> state when suspending the (entire) devfreq subsystem. When doing that,
>> we don't know if any device driver has previously called
>> devfreq_suspend_device() and might end up calling it twice.
>>
>> Same thing on devfreq subsystem resume.
>>
>> I've prepared a new RFC of my series (going to send it shortly), but I'm
>> not so happy with the current design. I think it would be much cleaner
>> to keep some suspend_refcount in struct devfreq so that I can call
>> devfreq_suspend_device() multiple times, while keeping a sane internal
>> state.
>
> I agree the devfreq need reference count for devfreq_suspend/resume_device.
> This patch focus on when changing the suspend frequency.
>
>>
>> Something like devfreq_device_runtime_{put,get}() perhaps?
>
> Why do devfreq need new additional functions?
> I think the devfreq_suspend/resume_device are enough.
Just thinking out loud here. I would prefer a naming that implies that
some refcounting is going on. When I see a pair of function with
put/get, then I usually know what is going on.
Here I would have to look at the actual implementation to realize, at
the moment, that I have to be careful calling these functions twice.
-Tobias
>
> Thanks,
> Chanwoo Choi
>
>>
>> - Tobias
>>
>>
>>
>>>
>>> int devfreq_suspend_device(struct devfreq *devfreq)
>>> {
>>> + int ret = 0;
>>> +
>>> if (!devfreq)
>>> return -EINVAL;
>>>
>>> if (!devfreq->governor)
>>> return 0;
>>>
>>> - return devfreq->governor->event_handler(devfreq,
>>> + ret = devfreq->governor->event_handler(devfreq,
>>> DEVFREQ_GOV_SUSPEND, NULL);
>>> + if (ret < 0) {
>>> + dev_err(devfreq->dev.parent, "failed to suspend governor\n");
>>> + return ret;
>>> + }
>>> +
>>> + if (devfreq->suspend_freq) {
>>> + ret = devfreq->profile->target(devfreq->dev.parent,
>>> + &devfreq->suspend_freq, 0);
>>> + if (ret < 0) {
>>> + dev_err(devfreq->dev.parent,
>>> + "failed to set suspend-freq\n");
>>> + return ret;
>>> + }
>>> + dev_dbg(devfreq->dev.parent, "Setting suspend-freq: %lu\n",
>>> + devfreq->suspend_freq);
>>> + }
>>> +
>>> + return 0;
>>> }
>>> EXPORT_SYMBOL(devfreq_suspend_device);
>>>
>>
^ permalink raw reply
* [PATCH net-next v4 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202233238.17561-1-martin.blumenstingl@googlemail.com>
Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
cycle (= 2ns) TX clock delay. This seems to work fine for many boards
(for example Odroid-C2 or Amlogic's reference boards) but there are
some others where TX traffic is simply broken.
There are probably multiple reasons why it's working on some boards
while it's broken on others:
- some of Amlogic's reference boards are using a Micrel PHY
- hardware circuit design
- maybe more...
iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
TX clock delay disabled on the MAC (as it's enabled in the PHY driver).
TX throughput was virtually zero before:
$ iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 108 MBytes 901 Mbits/sec
[ 4] 1.00-2.00 sec 94.2 MBytes 791 Mbits/sec
[ 4] 2.00-3.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 3.00-4.00 sec 96.2 MBytes 808 Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 6.00-7.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 7.00-8.00 sec 96.5 MBytes 809 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1000 MBytes 839 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 998 MBytes 837 Mbits/sec receiver
iperf Done.
$ iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139 KBytes
[ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7 KBytes
[ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187 KBytes
[ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143 KBytes
[ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129 KBytes
[ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195 KBytes
[ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7 KBytes
[ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6 KBytes
[ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107 KBytes
[ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 1.02 GBytes 874 Mbits/sec 1189 sender
[ 4] 0.00-10.01 sec 1.02 GBytes 873 Mbits/sec receiver
iperf Done.
I get similar TX throughput on my Meson GXBB "MXQ Pro+" board when I
disable the PHY's TX-delay and configure a 4ms TX-delay on the MAC.
So changes to at least the RTL8211F PHY driver are needed to get it
working properly in all situations.
Changes since v3:
- rebased to apply against current net-next branch (fixes a conflict
with d2ed0a7755fe14c7 "net: ethernet: stmmac: fix of-node and
fixed-link-phydev leaks")
-
Changes since v2:
- moved all .dts patches (3-7) to a separate series
- removed the default 2ns TX delay when phy-mode RGMII is specified
- (rebased against current net-next)
Changes since v1:
- renamed the devicetree property "amlogic,tx-delay" to
"amlogic,tx-delay-ns", which makes the .dts easier to read as we can
simply specify human-readable values instead of having "preprocessor
defines and calculation in human brain". Thanks to Andrew Lunn for
the suggestion!
- improved documentation to indicate when the MAC TX-delay should be
configured and how to use the PHY's TX-delay
- changed the default TX-delay in the dwmac-meson8b driver from 2ns
to 0ms when any of the rgmii-*id modes are used (the 2ns default
value still applies for phy-mode "rgmii")
- added patches to properly reset the PHY on Meson GXBB devices and to
use a similar configuration than the one we use on Meson GXL devices
(by passing a phy-handle to stmmac and defining the PHY in the mdio0
bus - patch 3-6)
- add the "amlogic,tx-delay-ns" property to all boards which are using
the RGMII PHY (patch 7)
Martin Blumenstingl (2):
net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
.../devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 +++++++++++++++------
2 files changed, 29 insertions(+), 6 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next v4 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217182119.4037-1-martin.blumenstingl@googlemail.com>
This allows configuring the RGMII TX clock delay. The RGMII clock is
generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
The configuration depends on the actual hardware (no delay may be
needed due to the design of the actual circuit, the PHY might add this
delay, etc.).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
index 89e62ddc69ca..f8bc54094e3c 100644
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -25,6 +25,20 @@ Required properties on Meson8b and newer:
- "clkin0" - first parent clock of the internal mux
- "clkin1" - second parent clock of the internal mux
+Optional properties on Meson8b and newer:
+- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
+ by this driver) in nanoseconds. Allowed values
+ are: 0ns, 2ns, 4ns, 6ns.
+ This must be configured when the phy-mode is
+ "rgmii" (typically a value of 2ns is used in
+ this case).
+ When phy-mode is set to "rgmii-id" or
+ "rgmii-txid" the TX clock delay is already
+ provided by the PHY. In that case this
+ property should be set to 0ns (which disables
+ the TX clock delay in the MAC to prevent the
+ clock from going off because both PHY and MAC
+ are adding a delay).
Example for Meson6:
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v4 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2016-12-17 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217182119.4037-1-martin.blumenstingl@googlemail.com>
Prior to this patch we were using a hardcoded RGMII TX clock delay of
2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
many boards, but unfortunately not for all (due to the way the actual
circuit is designed, sometimes because the TX delay is enabled in the
PHY, etc.). Making the TX delay on the MAC side configurable allows us
to support all possible hardware combinations.
This allows fixing a compatibility issue on some boards, where the
RTL8211F PHY is configured to generate the TX delay. We can now turn
off the TX delay in the MAC, because otherwise we would be applying the
delay twice (which results in non-working TX traffic).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index ffaed1f35efe..db970cd6600f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -35,10 +35,6 @@
#define PRG_ETH0_TXDLY_SHIFT 5
#define PRG_ETH0_TXDLY_MASK GENMASK(6, 5)
-#define PRG_ETH0_TXDLY_OFF (0x0 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_QUARTER (0x1 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_HALF (0x2 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_THREE_QUARTERS (0x3 << PRG_ETH0_TXDLY_SHIFT)
/* divider for the result of m250_sel */
#define PRG_ETH0_CLK_M250_DIV_SHIFT 7
@@ -69,6 +65,8 @@ struct meson8b_dwmac {
struct clk_divider m25_div;
struct clk *m25_div_clk;
+
+ u32 tx_delay_ns;
};
static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
@@ -179,6 +177,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
{
int ret;
unsigned long clk_rate;
+ u8 tx_dly_val;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
@@ -196,9 +195,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
PRG_ETH0_INVERTED_RMII_CLK, 0);
- /* TX clock delay - all known boards use a 1/4 cycle delay */
+ /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
+ * 8ns are exactly one cycle of the 125MHz RGMII TX clock):
+ * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+ */
+ tx_dly_val = dwmac->tx_delay_ns >> 1;
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- PRG_ETH0_TXDLY_QUARTER);
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
break;
case PHY_INTERFACE_MODE_RMII:
@@ -282,6 +285,12 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "missing phy-mode property\n");
ret = -EINVAL;
goto err_remove_config_dt;
+ } else if (dwmac->phy_mode != PHY_INTERFACE_MODE_RMII) {
+ /* ignore errors as this is an optional property - by default
+ * we assume a TX delay of 0ns.
+ */
+ of_property_read_u32(pdev->dev.of_node, "amlogic,tx-delay-ns",
+ &dwmac->tx_delay_ns);
}
ret = meson8b_init_clk(dwmac);
--
2.11.0
^ permalink raw reply related
* [PATCH v8 6/8] ARM: EXYNOS: remove secondary startup initialization from smp_prepare_cpus
From: Krzysztof Kozlowski @ 2016-12-17 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-7-git-send-email-pankaj.dubey@samsung.com>
On Sat, Dec 10, 2016 at 06:38:41PM +0530, Pankaj Dubey wrote:
> We are taking care of setting secondary cpu boot address in
> exynos_boot_secondary just before sending ipi to secondary CPUs,
> so we can safely remove this setting from smp_prepare_cpus.
Indeed setting boot address is doubled. However between them, the power
is turned on and Exynos3250 is being restarted.
It would be nice to test it on Exynos3250 (Artik5 or Gear2?) and some of
Exynos4 family. Beside that looks good to me, I just want to see some
tested-by.
Best regards,
Krzysztof
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/platsmp.c | 25 -------------------------
> 1 file changed, 25 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index 43eec10..4de254e 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -403,8 +403,6 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
>
> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
> {
> - int i;
> -
> exynos_sysram_init();
>
> exynos_set_delayed_reset_assertion(true);
> @@ -414,29 +412,6 @@ static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
> if (exynos_scu_enable())
> return;
> }
> - /*
> - * Write the address of secondary startup into the
> - * system-wide flags register. The boot monitor waits
> - * until it receives a soft interrupt, and then the
> - * secondary CPU branches to this address.
> - *
> - * Try using firmware operation first and fall back to
> - * boot register if it fails.
> - */
> - for (i = 1; i < max_cpus; ++i) {
> - unsigned long boot_addr;
> - u32 mpidr;
> - u32 core_id;
> - int ret;
> -
> - mpidr = cpu_logical_map(i);
> - core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> - boot_addr = virt_to_phys(exynos4_secondary_startup);
> -
> - ret = exynos_set_boot_addr(core_id, boot_addr);
> - if (ret)
> - break;
> - }
> }
>
> #ifdef CONFIG_HOTPLUG_CPU
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v8 7/8] ARM: EXYNOS: refactor smp specific code and routines
From: Krzysztof Kozlowski @ 2016-12-17 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-8-git-send-email-pankaj.dubey@samsung.com>
On Sat, Dec 10, 2016 at 06:38:42PM +0530, Pankaj Dubey wrote:
> To remove dependency on soc_is_exynosMMMM macros and remove
> multiple checks for such macros lets refactor code in platsmp.c.
> This patch introduces new structure as exynos_cpu_info to
> separate such variable information and routines which vary from
> one Exynos SoC to other SoC. During smp_prepare_cpus lets match
> SoC specific information to select appropriate exynos_cpu_info
> and use it in all other places
>
At first glance, looks fine. I see you deal with cpu_power_down and
disallowed use of of_xxxx() calls. One error plus one nit at then end.
However just like for patch 5, because of renames it is difficult to
spot subtle differences (and possible errors) - could you try to split
this patch a bit?
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/platsmp.c | 244 +++++++++++++++++++++++++++++++++++------
> 1 file changed, 210 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index 4de254e..759a184 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -19,6 +19,7 @@
> #include <linux/smp.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> +#include <linux/sys_soc.h>
> #include <linux/soc/samsung/exynos-regs-pmu.h>
>
> #include <asm/cacheflush.h>
> @@ -27,12 +28,26 @@
> #include <asm/smp_scu.h>
> #include <asm/firmware.h>
>
> -#include <mach/map.h>
> -
> #include "common.h"
>
> extern void exynos4_secondary_startup(void);
>
> +/*
> + * struct exynos_cpu_info - Exynos CPU related info/operations
> + * @cpu_boot_reg: computes cpu boot address for requested cpu
> + * @cpu_power_down: handles cpu power down routine for requested cpu
> + * @cpu_power_up: handles cpu power up routine for requested cpu
> + * @cpu_restart: handles cpu restart routine for requested cpu
> + */
> +struct exynos_cpu_info {
> + void __iomem* (*cpu_boot_reg)(u32 cpu);
> + void (*cpu_power_down)(u32 cpu);
> + void (*cpu_power_up)(u32 cpu);
> + void (*cpu_restart)(u32 cpu);
> +};
> +
> +static const struct exynos_cpu_info *cpu_info;
> +
> #ifdef CONFIG_HOTPLUG_CPU
> static inline void cpu_leave_lowpower(u32 core_id)
> {
> @@ -81,19 +96,39 @@ static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
> }
> #endif /* CONFIG_HOTPLUG_CPU */
>
> -/**
> - * exynos_core_power_down : power down the specified cpu
> +/*
> + * exynos_cpu_power_down - power down the specified cpu
> * @cpu : the cpu to power down
> *
> - * Power down the specified cpu. The sequence must be finished by a
> - * call to cpu_do_idle()
> - *
> + * The sequence must be finished by a call to cpu_do_idle()
> */
> void exynos_cpu_power_down(int cpu)
> {
> + if (cpu_info && cpu_info->cpu_power_down)
> + cpu_info->cpu_power_down(cpu);
> +}
> +
> +/*
> + * exynos_common_cpu_power_down - common cpu power down routine for Exynos SoC
> + * @cpu : the cpu to power down
> + */
> +static void exynos_common_cpu_power_down(u32 cpu)
> +{
> u32 core_conf;
>
> - if (cpu == 0 && (soc_is_exynos5420() || soc_is_exynos5800())) {
> + core_conf = pmu_raw_readl(EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> + core_conf &= ~S5P_CORE_LOCAL_PWR_EN;
> + pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> +}
> +
> +/*
> + * exynos5420_cpu_power_down - Exynos5420/Exynos5800 specific cpu power down
> + * routine
> + * @cpu : the cpu to power down
> + */
> +static void exynos5420_cpu_power_down(u32 cpu)
> +{
> + if (cpu == 0) {
> /*
> * Bypass power down for CPU0 during suspend. Check for
> * the SYS_PWR_REG value to decide if we are suspending
> @@ -105,24 +140,39 @@ void exynos_cpu_power_down(int cpu)
> return;
> }
>
> - core_conf = pmu_raw_readl(EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> - core_conf &= ~S5P_CORE_LOCAL_PWR_EN;
> - pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> + exynos_common_cpu_power_down(cpu);
> }
>
> /**
> * exynos_cpu_power_up : power up the specified cpu
> * @cpu : the cpu to power up
> - *
> - * Power up the specified cpu
> */
> void exynos_cpu_power_up(int cpu)
> {
> + if (cpu_info && cpu_info->cpu_power_up)
> + cpu_info->cpu_power_up(cpu);
> +}
> +
> +/*
> + * exynos_common_cpu_power_up - common cpu power up routine for Exynos SoC
> + * @cpu : the cpu to power up
> + */
> +static void exynos_common_cpu_power_up(u32 cpu)
> +{
> u32 core_conf = S5P_CORE_LOCAL_PWR_EN;
> + pmu_raw_writel(core_conf,
> + EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> +}
>
> - if (soc_is_exynos3250())
> - core_conf |= S5P_CORE_AUTOWAKEUP_EN;
> +/*
> + * exynos3250_cpu_power_up - Exynos3250 specific cpu power up routine
> + * @cpu : the cpu to power down
> + */
> +static void exynos3250_cpu_power_up(u32 cpu)
> +{
> + u32 core_conf = S5P_CORE_LOCAL_PWR_EN;
>
> + core_conf |= S5P_CORE_AUTOWAKEUP_EN;
> pmu_raw_writel(core_conf,
> EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> }
> @@ -130,7 +180,6 @@ void exynos_cpu_power_up(int cpu)
> /**
> * exynos_cpu_power_state : returns the power state of the cpu
> * @cpu : the cpu to retrieve the power state from
> - *
> */
> int exynos_cpu_power_state(int cpu)
> {
> @@ -189,39 +238,76 @@ int exynos_scu_enable(void)
> return 0;
> }
>
> -static void __iomem *cpu_boot_reg_base(void)
> +static inline void __iomem *exynos_cpu_boot_reg(int cpu)
> +{
> + if (cpu_info && cpu_info->cpu_boot_reg)
> + return cpu_info->cpu_boot_reg(cpu);
> + return NULL;
> +}
> +
> +static void __iomem *exynos_common_cpu_boot_reg(u32 cpu)
> {
> - if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
> - return pmu_base_addr + S5P_INFORM5;
> + if (!sysram_base_addr)
> + return IOMEM_ERR_PTR(-ENODEV);
> +
> return sysram_base_addr;
> }
>
> -static inline void __iomem *cpu_boot_reg(int cpu)
> +static void __iomem *exynos4210_cpu_boot_reg(u32 cpu)
> {
> void __iomem *boot_reg;
>
> - boot_reg = cpu_boot_reg_base();
> - if (!boot_reg)
> + if (!pmu_base_addr)
> return IOMEM_ERR_PTR(-ENODEV);
> - if (soc_is_exynos4412())
> - boot_reg += 4*cpu;
> - else if (soc_is_exynos5420() || soc_is_exynos5800())
> - boot_reg += 4;
> + boot_reg = pmu_base_addr + S5P_INFORM5;
> +
> + return boot_reg;
> +}
> +
> +static void __iomem *exynos4412_cpu_boot_reg(u32 cpu)
> +{
> + void __iomem *boot_reg;
> +
> + if (!sysram_base_addr)
> + return IOMEM_ERR_PTR(-ENODEV);
> +
> + boot_reg = sysram_base_addr;
> + boot_reg += 4*cpu;
> +
> + return boot_reg;
> +}
> +
> +static void __iomem *exynos5420_cpu_boot_reg(u32 cpu)
> +{
> + void __iomem *boot_reg;
> +
> + if (!sysram_base_addr)
> + return IOMEM_ERR_PTR(-ENODEV);
> +
> + boot_reg = sysram_base_addr;
> + boot_reg += 4;
> +
> return boot_reg;
> }
>
> +/**
> + * exynos_core_restart : restart the specified cpu
> + * @core_id : the cpu to be restarted
> + */
> +void exynos_core_restart(u32 core_id)
> +{
> + if (cpu_info && cpu_info->cpu_restart)
> + cpu_info->cpu_restart(core_id);
> +}
> +
> /*
> * Set wake up by local power mode and execute software reset for given core.
> - *
> * Currently this is needed only when booting secondary CPU on Exynos3250.
> */
> -void exynos_core_restart(u32 core_id)
> +static void exynos3250_core_restart(u32 core_id)
> {
> u32 val;
>
> - if (!of_machine_is_compatible("samsung,exynos3250"))
> - return;
> -
> while (!pmu_raw_readl(S5P_PMU_SPARE2))
> udelay(10);
> udelay(10);
> @@ -274,7 +360,7 @@ int exynos_set_boot_addr(u32 core_id, unsigned long boot_addr)
> if (ret && ret != -ENOSYS)
> goto fail;
> if (ret == -ENOSYS) {
> - void __iomem *boot_reg = cpu_boot_reg(core_id);
> + void __iomem *boot_reg = exynos_cpu_boot_reg(core_id);
>
> if (IS_ERR(boot_reg)) {
> ret = PTR_ERR(boot_reg);
> @@ -299,7 +385,7 @@ int exynos_get_boot_addr(u32 core_id, unsigned long *boot_addr)
> if (ret && ret != -ENOSYS)
> goto fail;
> if (ret == -ENOSYS) {
> - void __iomem *boot_reg = cpu_boot_reg(core_id);
> + void __iomem *boot_reg = exynos_cpu_boot_reg(core_id);
>
> if (IS_ERR(boot_reg)) {
> ret = PTR_ERR(boot_reg);
> @@ -312,13 +398,93 @@ int exynos_get_boot_addr(u32 core_id, unsigned long *boot_addr)
> return ret;
> }
>
> +static const struct exynos_cpu_info exynos3250_cpu_info = {
> + .cpu_boot_reg = exynos_common_cpu_boot_reg,
> + .cpu_power_down = exynos_common_cpu_power_down,
> + .cpu_power_up = exynos3250_cpu_power_up,
> + .cpu_restart = exynos3250_core_restart,
> +};
> +
> +static const struct exynos_cpu_info exynos5420_cpu_info = {
> + .cpu_boot_reg = exynos5420_cpu_boot_reg,
> + .cpu_power_down = exynos5420_cpu_power_down,
> + .cpu_power_up = exynos_common_cpu_power_up,
> +};
> +
> +static const struct exynos_cpu_info exynos4210_cpu_info = {
> + .cpu_boot_reg = exynos4210_cpu_boot_reg,
> + .cpu_power_down = exynos_common_cpu_power_down,
> + .cpu_power_up = exynos_common_cpu_power_up,
> +};
> +
> +static const struct exynos_cpu_info exynos4412_cpu_info = {
> + .cpu_boot_reg = exynos4412_cpu_boot_reg,
> + .cpu_power_down = exynos_common_cpu_power_down,
> + .cpu_power_up = exynos_common_cpu_power_up,
> +};
> +
> +static const struct exynos_cpu_info exynos_common_cpu_info = {
> + .cpu_boot_reg = exynos_common_cpu_boot_reg,
> + .cpu_power_down = exynos_common_cpu_power_down,
> + .cpu_power_up = exynos_common_cpu_power_up,
> +};
> +
> +static const struct soc_device_attribute exynos_soc_revision[] __initconst = {
> + {
> + .soc_id = "EXYNOS4210", .revision = "11",
Each attribute in new line please.
> + .data = &exynos4210_cpu_info
> + }, {
> + .soc_id = "EXYNOS4210", .revision = "10",
> + .data = &exynos_common_cpu_info
> + }
> +};
> +
> +static const struct of_device_id exynos_pmu_of_device_ids[] __initconst = {
> + {
> + .compatible = "samsung,exynos3250",
> + .data = &exynos3250_cpu_info
> + }, {
> + .compatible = "samsung,exynos4212",
> + .data = &exynos_common_cpu_info
> + }, {
> + .compatible = "samsung,exynos4412",
> + .data = &exynos4412_cpu_info
> + }, {
> + .compatible = "samsung,exynos5250",
> + .data = &exynos_common_cpu_info
> + }, {
> + .compatible = "samsung,exynos5260",
> + .data = &exynos_common_cpu_info
> + }, {
> + .compatible = "samsung,exynos5410",
> + .data = &exynos_common_cpu_info
> + }, {
> + .compatible = "samsung,exynos5420",
> + .data = &exynos5420_cpu_info
> + }, {
> + .compatible = "samsung,exynos5440",
> + .data = &exynos_common_cpu_info
> + }, {
> + .compatible = "samsung,exynos5800",
> + .data = &exynos5420_cpu_info
> + },
> + { /*sentinel*/ },
> +};
> +
> static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> unsigned long timeout;
> + const struct soc_device_attribute *match;
> u32 mpidr = cpu_logical_map(cpu);
> u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> int ret = -ENOSYS;
>
> + if (of_machine_is_compatible("samsung,exynos4210")) {
> + match = soc_device_match(exynos_soc_revision);
The 'exynos_soc_revision' is __initconst but this function is not
__init.
Best regards,
Krzysztof
> + if (match)
> + cpu_info = (const struct exynos_cpu_info *) match->data;
> + }
> +
> /*
> * Set synchronisation state between this boot processor
> * and the secondary one
> @@ -377,7 +543,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
>
> call_firmware_op(cpu_boot, core_id);
>
> - if (soc_is_exynos3250())
> + if (of_machine_is_compatible("samsung,exynos3250"))
> dsb_sev();
> else
> arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> @@ -403,6 +569,16 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
>
> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
> {
> + const struct of_device_id *match;
> + struct device_node *np;
> +
> + np = of_find_matching_node_and_match(NULL,
> + exynos_pmu_of_device_ids, &match);
> + if (!np)
> + pr_err("failed to find supported CPU\n");
> + else
> + cpu_info = (const struct exynos_cpu_info *) match->data;
> +
> exynos_sysram_init();
>
> exynos_set_delayed_reset_assertion(true);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v8 8/8] ARM: EXYNOS: refactor of mach-exynos to use chipid information
From: Krzysztof Kozlowski @ 2016-12-17 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-9-git-send-email-pankaj.dubey@samsung.com>
On Sat, Dec 10, 2016 at 06:38:43PM +0530, Pankaj Dubey wrote:
> Since now we have chipid driver in place and all dependencies of
> soc_is_exynosMMMM macros have been address, lets remove all such
> macros. Also remove static mapping of chipid SFR in exynos.c and
> related helper functions.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/common.h | 92 ----------------------------
> arch/arm/mach-exynos/exynos.c | 38 ------------
> arch/arm/mach-exynos/include/mach/map.h | 21 -------
> arch/arm/plat-samsung/cpu.c | 14 -----
> arch/arm/plat-samsung/include/plat/cpu.h | 2 -
> arch/arm/plat-samsung/include/plat/map-s5p.h | 2 -
> 6 files changed, 169 deletions(-)
> delete mode 100644 arch/arm/mach-exynos/include/mach/map.h
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index cfd55ba..5886646 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -14,97 +14,6 @@
>
> #include <linux/platform_data/cpuidle-exynos.h>
>
> -#define EXYNOS3250_SOC_ID 0xE3472000
> -#define EXYNOS3_SOC_MASK 0xFFFFF000
> -
> -#define EXYNOS4210_CPU_ID 0x43210000
> -#define EXYNOS4212_CPU_ID 0x43220000
> -#define EXYNOS4412_CPU_ID 0xE4412200
> -#define EXYNOS4_CPU_MASK 0xFFFE0000
> -
> -#define EXYNOS5250_SOC_ID 0x43520000
> -#define EXYNOS5410_SOC_ID 0xE5410000
> -#define EXYNOS5420_SOC_ID 0xE5420000
> -#define EXYNOS5440_SOC_ID 0xE5440000
> -#define EXYNOS5800_SOC_ID 0xE5422000
> -#define EXYNOS5_SOC_MASK 0xFFFFF000
> -
> -extern unsigned long samsung_cpu_id;
> -
> -#define IS_SAMSUNG_CPU(name, id, mask) \
> -static inline int is_samsung_##name(void) \
> -{ \
> - return ((samsung_cpu_id & mask) == (id & mask)); \
> -}
> -
> -IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
> -IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
> -IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
> -IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
> -IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
> -IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
> -IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
> -IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
> -IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
> -
> -#if defined(CONFIG_SOC_EXYNOS3250)
> -# define soc_is_exynos3250() is_samsung_exynos3250()
> -#else
> -# define soc_is_exynos3250() 0
> -#endif
> -
> -#if defined(CONFIG_CPU_EXYNOS4210)
> -# define soc_is_exynos4210() is_samsung_exynos4210()
> -#else
> -# define soc_is_exynos4210() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS4212)
> -# define soc_is_exynos4212() is_samsung_exynos4212()
> -#else
> -# define soc_is_exynos4212() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS4412)
> -# define soc_is_exynos4412() is_samsung_exynos4412()
> -#else
> -# define soc_is_exynos4412() 0
> -#endif
> -
> -#define EXYNOS4210_REV_0 (0x0)
> -#define EXYNOS4210_REV_1_0 (0x10)
> -#define EXYNOS4210_REV_1_1 (0x11)
> -
> -#if defined(CONFIG_SOC_EXYNOS5250)
> -# define soc_is_exynos5250() is_samsung_exynos5250()
> -#else
> -# define soc_is_exynos5250() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5410)
> -# define soc_is_exynos5410() is_samsung_exynos5410()
> -#else
> -# define soc_is_exynos5410() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5420)
> -# define soc_is_exynos5420() is_samsung_exynos5420()
> -#else
> -# define soc_is_exynos5420() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5440)
> -# define soc_is_exynos5440() is_samsung_exynos5440()
> -#else
> -# define soc_is_exynos5440() 0
> -#endif
> -
> -#if defined(CONFIG_SOC_EXYNOS5800)
> -# define soc_is_exynos5800() is_samsung_exynos5800()
> -#else
> -# define soc_is_exynos5800() 0
> -#endif
> -
> extern u32 cp15_save_diag;
> extern u32 cp15_save_power;
>
> @@ -156,7 +65,6 @@ extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
>
> extern void exynos_set_delayed_reset_assertion(bool enable);
>
> -extern unsigned int samsung_rev(void);
> extern void exynos_core_restart(u32 core_id);
> extern int exynos_set_boot_addr(u32 core_id, unsigned long boot_addr);
> extern int exynos_get_boot_addr(u32 core_id, unsigned long *boot_addr);
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 040ea66..66bd612 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -21,10 +21,6 @@
> #include <asm/cacheflush.h>
> #include <asm/hardware/cache-l2x0.h>
> #include <asm/mach/arch.h>
> -#include <asm/mach/map.h>
> -
> -#include <mach/map.h>
> -#include <plat/cpu.h>
>
> #include "common.h"
>
> @@ -58,39 +54,6 @@ void __init exynos_sysram_init(void)
> }
> }
>
> -static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
> - int depth, void *data)
> -{
> - struct map_desc iodesc;
> - const __be32 *reg;
> - int len;
> -
> - if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
> - !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
That's the problem with 5440. It comes without chipid binding. I think
with removal of this the SoC/board would becom broken?
Best regards,
Krzysztof
> - return 0;
> -
> - reg = of_get_flat_dt_prop(node, "reg", &len);
> - if (reg == NULL || len != (sizeof(unsigned long) * 2))
> - return 0;
> -
> - iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
> - iodesc.length = be32_to_cpu(reg[1]) - 1;
> - iodesc.virtual = (unsigned long)S5P_VA_CHIPID;
> - iodesc.type = MT_DEVICE;
> - iotable_init(&iodesc, 1);
> - return 1;
> -}
> -
> -static void __init exynos_init_io(void)
> -{
> - debug_ll_io_init();
> -
> - of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
> -
> - /* detect cpu id and rev. */
> - s5p_init_cpu(S5P_VA_CHIPID);
> -}
> -
> /*
> * Set or clear the USE_DELAYED_RESET_ASSERTION option. Used by smp code
> * and suspend.
> @@ -203,7 +166,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
> .l2c_aux_val = 0x3c400001,
> .l2c_aux_mask = 0xc20fffff,
> .smp = smp_ops(exynos_smp_ops),
> - .map_io = exynos_init_io,
> .init_early = exynos_firmware_init,
> .init_irq = exynos_init_irq,
> .init_machine = exynos_dt_machine_init,
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> deleted file mode 100644
> index 0eef407..0000000
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/*
> - * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com/
> - *
> - * EXYNOS - Memory map definitions
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> -*/
> -
> -#ifndef __ASM_ARCH_MAP_H
> -#define __ASM_ARCH_MAP_H __FILE__
> -
> -#include <plat/map-base.h>
> -
> -#include <plat/map-s5p.h>
> -
> -#define EXYNOS_PA_CHIPID 0x10000000
> -
> -#endif /* __ASM_ARCH_MAP_H */
> diff --git a/arch/arm/plat-samsung/cpu.c b/arch/arm/plat-samsung/cpu.c
> index a107b3a..e58f0f6 100644
> --- a/arch/arm/plat-samsung/cpu.c
> +++ b/arch/arm/plat-samsung/cpu.c
> @@ -21,12 +21,6 @@
> unsigned long samsung_cpu_id;
> static unsigned int samsung_cpu_rev;
>
> -unsigned int samsung_rev(void)
> -{
> - return samsung_cpu_rev;
> -}
> -EXPORT_SYMBOL(samsung_rev);
> -
> void __init s3c64xx_init_cpu(void)
> {
> samsung_cpu_id = readl_relaxed(S3C_VA_SYS + 0x118);
> @@ -43,11 +37,3 @@ void __init s3c64xx_init_cpu(void)
>
> pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
> }
> -
> -void __init s5p_init_cpu(const void __iomem *cpuid_addr)
> -{
> - samsung_cpu_id = readl_relaxed(cpuid_addr);
> - samsung_cpu_rev = samsung_cpu_id & 0xFF;
> -
> - pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
> -}
> diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h
> index b7b702a..913c176 100644
> --- a/arch/arm/plat-samsung/include/plat/cpu.h
> +++ b/arch/arm/plat-samsung/include/plat/cpu.h
> @@ -115,8 +115,6 @@ extern void s3c24xx_init_io(struct map_desc *mach_desc, int size);
> extern void s3c64xx_init_cpu(void);
> extern void s5p_init_cpu(const void __iomem *cpuid_addr);
>
> -extern unsigned int samsung_rev(void);
> -
> extern void s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no);
>
> extern void s3c24xx_init_clocks(int xtal);
> diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
> index 512ed1f..d6853f1 100644
> --- a/arch/arm/plat-samsung/include/plat/map-s5p.h
> +++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
> @@ -13,8 +13,6 @@
> #ifndef __ASM_PLAT_MAP_S5P_H
> #define __ASM_PLAT_MAP_S5P_H __FILE__
>
> -#define S5P_VA_CHIPID S3C_ADDR(0x02000000)
> -
> #define VA_VIC(x) (S3C_VA_IRQ + ((x) * 0x10000))
> #define VA_VIC0 VA_VIC(0)
> #define VA_VIC1 VA_VIC(1)
> --
> 2.7.4
>
^ permalink raw reply
* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Krzysztof Kozlowski @ 2016-12-17 19:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
After our discussions about not-breaking out-of-tree DTB with SCU
change in DeviceTree, I prepared an updated pull request without
the questioned changes.
Ten days ago I prepared a tag, pushed it... and apparently forgot to send pull
request. At least, I don't have such email in my outbox. Dunno.
So let's send it now, better late then never. With just few commits (without
the DT SCU changes). These were sitting in the next for very long.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.10-2
for you to fetch changes up to da6b21e97e39d42f90ab490ce7b54a0fe2c3fe35:
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms (2016-12-07 18:42:11 +0200)
----------------------------------------------------------------
Samsung mach/soc update for v4.10:
1. Minor cleanup in smp_operations.
2. Another step in switching s3c24xx to new DMA API.
3. Drop fixed requirement for HZ=200 on Samsung platforms.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
Pankaj Dubey (1):
ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
Sylwester Nawrocki (1):
ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
arch/arm/Kconfig | 3 +-
arch/arm/mach-exynos/platsmp.c | 31 -----------------
arch/arm/mach-s3c24xx/common.c | 76 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 77 insertions(+), 33 deletions(-)
^ permalink raw reply
* [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Krzysztof Kozlowski @ 2016-12-17 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481897676-13578-1-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 16, 2016 at 03:14:36PM +0100, Marek Szyprowski wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings and allow to make cleanup of the existing code and device tree
> files, lets mark Samsung Exynos SoC platform bindings as unstable. This
> means that bindings can may change at any time and users should use the
> dtb file compiled from the same kernel source tree as the kernel image.
I agree but please re-send it after merge window. This is not the best
time to start discussions about it.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Martin Blumenstingl @ 2016-12-17 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202234739.22929-1-martin.blumenstingl@googlemail.com>
Hi Kevin,
On Sat, Dec 3, 2016 at 12:47 AM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
> networks which are not affected by the EEE problem, as reported here:
> [1]).
> The actual problem for the TX throughput issues was that the TX delay
> was applied twice:
> - once "accidentally" by the PHY (this was fixed with [2])
> - once by the MAC because there was a hardcoded TX delay (of 2ns),
> this will be configurable with the changes from [0]
>
> These are the dts changes which belong to my other series (in v2
> these patches were part of the other series, upon request of the
> net maintainers I have split the .dts changes into their own series so
> we are able to take both through different trees):
> "[PATCH net-next v3 0/2] stmmac: dwmac-meson8b: configurable
> RGMII TX delay": [0].
> Thus this series depends on the ACK for the binding changes in the
> other series!
>
> I based these changes on my other series "[PATCH v2 0/2] GXL and GXM
> SCPI improvements": [3]
the DT binding changes for the meson8b-dwmac driver were ACK'ed by Rob
Herring, so you can proceed with this series once you applied the SCPI
patches.
Thank you!
Regards,
Martin
^ permalink raw reply
* [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
From: Nipun Gupta @ 2016-12-17 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad6b6a4937b1fe183e6d48ccbaf4cb46db92fed4.1481893907.git.robin.murphy@arm.com>
> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Robin Murphy
> Sent: Friday, December 16, 2016 18:49
> To: iommu at lists.linux-foundation.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Cc: mark.rutland at arm.com; will.deacon at arm.com; Stuart Yoder
> <stuart.yoder@nxp.com>
> Subject: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
>
> The current SMR masking support using a 2-cell iommu-specifier is
> primarily intended to handle individual masters with large and/or
> complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> use-cases where we just want to consistently mask out the same part of
> every Stream ID (e.g. for MMU-500 configurations where the appended TBU
> number gets in the way unnecessarily). Let's add a new property to allow
> a single global mask value to better fit the latter situation.
>
> CC: Stuart Yoder <stuart.yoder@nxp.com>
Tested-by: Nipun Gupta <nipun.gupta@nxp.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> Compile-tested only...
>
> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 ++++++++
> drivers/iommu/arm-smmu.c | 4 +++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d1485205..98f5cbe5fdb4 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -60,6 +60,14 @@ conditions.
> aliases of secure registers have to be used during
> SMMU configuration.
>
> +- stream-match-mask : Specifies a fixed SMR mask value to combine with
> + the Stream ID value from every iommu-specifier. This
> + may be used instead of an "#iommu-cells" value of 2
> + when there is no need for per-master SMR masks, but
> + it is still desired to mask some portion of every
> + Stream ID (e.g. for certain MMU-500 configurations
> + given globally unique external IDs).
> +
> ** Deprecated properties:
>
> - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f7281444551..f1abcb7dde36 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct
> iommu_domain *domain,
>
> static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> {
> - u32 fwid = 0;
> + u32 mask, fwid = 0;
>
> if (args->args_count > 0)
> fwid |= (u16)args->args[0];
>
> if (args->args_count > 1)
> fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
> + else if (!of_property_read_u32(args->np, "stream-match-mask",
> &mask))
> + fwid |= (u16)mask << SMR_MASK_SHIFT;
>
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
> --
> 2.10.2.dirty
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [BISECTED] v4.9: OMAP MMC regression
From: Aaro Koskinen @ 2016-12-17 22:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
OMAP MMC is silently missing when booting v4.9 on Nokia 770 (OMAP1).
Bisected to:
commit 2d1a9a946faebfedd660a1f1c2b90984fff41f91
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date: Wed Jul 20 11:50:29 2016 +0300
dmaengine: omap-dma: Dynamically allocate memory for lch_map
Reveting the commit makes MMC to appear and work again...
A.
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-12-17 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58558195.20907@math.uni-bielefeld.de>
2016-12-18 3:19 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
> Hey Chanwoo,
>
>
> Chanwoo Choi wrote:
>> 2016-12-18 0:13 GMT+09:00 Tobias Jakobi <tjakobi@math.uni-bielefeld.de>:
>>> Hey guys,
>>>
>>> Chanwoo Choi wrote:
>>>> Hi Lin,
>>>>
>>>> 2016-11-24 18:54 GMT+09:00 Chanwoo Choi <cw00.choi@samsung.com>:
>>>>> Hi Lin,
>>>>>
>>>>> On 2016? 11? 24? 18:28, Chanwoo Choi wrote:
>>>>>> Hi Lin,
>>>>>>
>>>>>> On 2016? 11? 24? 17:34, hl wrote:
>>>>>>> Hi Chanwoo Choi,
>>>>>>>
>>>>>>>
>>>>>>> On 2016?11?24? 16:16, Chanwoo Choi wrote:
>>>>>>>> Hi Lin,
>>>>>>>>
>>>>>>>> On 2016? 11? 24? 16:34, hl wrote:
>>>>>>>>> Hi Chanwoo Choi,
>>>>>>>>>
>>>>>>>>> I think the dev_pm_opp_get_suspend_opp() have implement most of
>>>>>>>>> the funtion, all we need is just define the node in dts, like following:
>>>>>>>>>
>>>>>>>>> &dmc_opp_table {
>>>>>>>>> opp06 {
>>>>>>>>> opp-suspend;
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>> Two approaches use the 'opp-suspend' property.
>>>>>>>>
>>>>>>>> I think that the method to support suspend-opp have to
>>>>>>>> guarantee following conditions:
>>>>>>>> - Support the all of devfreq's governors.
>>>>>>> As MyungJoo Ham suggestion, i will set the suspend frequency in devfreq_suspend_device(),
>>>>>>> which will ingore governor.
>>>>>>
>>>>>> Other approach already support the all of governors.
>>>>>> Before calling the mail, I discussed with Myungjoo Ham.
>>>>>> Myungjoo prefer to use the devfreq_suspend/devfreq_resume().
>>>>>
>>>>> It is not correct expression. We need to wait the reply from Myungjoo
>>>>> to clarify this.
>>>>>
>>>>>>
>>>>>> To Myungjoo,
>>>>>> Please add your opinion how to support the suspend frequency.
>>>>>
>>>>>>
>>>>>>>> - Devfreq framework have the responsibility to change the
>>>>>>>> frequency/voltage for suspend-opp. If we uses the
>>>>>>>> new devfreq_suspend(), each devfreq device don't care
>>>>>>>> how to support the suspend-opp. Just the developer of each
>>>>>>>> devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
>>>>>>> Why should support change the voltage in devfreq framework, i think it shuold be handle in
>>>>>>> specific driver, i think the devfreq only handle it can get the right frequency, then pass it to
>>>>>>
>>>>>> No, the frequency should be handled by governor or framework.
>>>>>> The each devfreq device has no any responsibility of next frequency/voltage.
>>>>>> The governor and core of devfreq can decide the next frequency/voltage.
>>>>>> You can refer to the cpufreq subsystem.
>>>>>>
>>>>>>> specific driver, i think the voltage should handle in the devfreq->profile->target();
>>>>>>
>>>>>> The call of devfreq->profile->target() have to be handled by devfreq framework.
>>>>>> If user want to set the suspend frequency, user can add the 'suspend-opp' property.
>>>>>> It think this way is easy.
>>>>>>
>>>>>> But,
>>>>>> If the each devfreq device want to decide the next frequency/voltage only for
>>>>>> suspend state. We can check the cpufreq subsystem.
>>>>>>
>>>>>> If specific devfreq device want to handle the suspend frequency,
>>>>>> each devfreq will add the own suspend/resume functions as following:
>>>>>>
>>>>>> struct devfreq_dev_profile {
>>>>>> int (*suspend)(struct devfreq *dev); // new function pointer
>>>>>> int (*resume)(struct devfreq *dev); // new function pointer
>>>>>> } a_profile;
>>>>>>
>>>>>> a_profile = devfreq_generic_suspend;
>>>>>>
>>>>>> The devfreq framework will provide the devfreq_generic_suspend() funticon.
>>>>>> int devfreq_generic_suspend(struce devfreq *dev) {
>>>>>> ...
>>>>>> devfreq->profile->target(..., devfreq->suspend_freq);
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> or
>>>>>>
>>>>>> a_profile = a_devfreq_suspend; // specific function of each devfreq device
>>>>>>
>>>>>> The devfreq_suspend() will call 'devfreq->profile->suspend()' function
>>>>>> instead of devfreq->profile->target();
>>>>>>
>>>>>> The devfreq call the 'devfreq->profile->suspend()'
>>>>>> to support the suspend frequency.
>>>>>>
>>>>>> Regards,
>>>>>> Chanwoo Choi
>>>>>
>>>>> The key difference between two approaches:
>>>>>
>>>>> Your approach:
>>>>> - The each developer should add the 'opp-suspend' property to the dts file.
>>>>> - The each devfreq should call the devfreq_suspend_device()
>>>>> to support the suspend frequency.
>>>>>
>>>>> If each devfreq doesn't call the devfreq_suspend_device(), devfreq framework
>>>>> can support the suspend frequency.
>>>>>
>>>>> Other approach:
>>>>> - The each developer only should add the 'opp-suspend' property to the dts file
>>>>> without the additional behavior.
>>>>>
>>>>> In the cpufreq subsystem,
>>>>> When support the suspend frequency of cpufreq, we just add 'opp-suspend' property
>>>>> without the additional behavior.
>>>>
>>>> I'm missing the use-case when using the devfreq_suspend_device()
>>>> before entering the suspend mode. We should consider the case when
>>>> devfreq device
>>>> calls the devfreq_suspend_device() directly. Because devfreq_suspend_device()
>>>> is exported function, each devfreq device call this function on the fly
>>>> without entering the suspend mode.
>>>>
>>>> I correct my opinion. Your approach is necessary. I'm sorry to confuse you.
>>>> So, I make the following patch. This patch set the suspend frequency
>>>> in devfreq_suspend_device() after stoping the governor.
>>>> It consider the all governors of devfreq.
>>>>
>>>> What do you think?
>>>> If you are ok, I'll send this patch with your author.
>>> The problem I see here is that we need to keep track of the suspended
>>> state when suspending the (entire) devfreq subsystem. When doing that,
>>> we don't know if any device driver has previously called
>>> devfreq_suspend_device() and might end up calling it twice.
>>>
>>> Same thing on devfreq subsystem resume.
>>>
>>> I've prepared a new RFC of my series (going to send it shortly), but I'm
>>> not so happy with the current design. I think it would be much cleaner
>>> to keep some suspend_refcount in struct devfreq so that I can call
>>> devfreq_suspend_device() multiple times, while keeping a sane internal
>>> state.
>>
>> I agree the devfreq need reference count for devfreq_suspend/resume_device.
>> This patch focus on when changing the suspend frequency.
>>
>>>
>>> Something like devfreq_device_runtime_{put,get}() perhaps?
>>
>> Why do devfreq need new additional functions?
>> I think the devfreq_suspend/resume_device are enough.
> Just thinking out loud here. I would prefer a naming that implies that
> some refcounting is going on. When I see a pair of function with
> put/get, then I usually know what is going on.
The suspend/resume name are already used as pair function name.
I think that devfreq_suspend/resume_device() are appropriate.
Usually, '_runtime_put/get' naming means the 'runtime PM' callback function
which handle the all of resource (e.g., clock, regulator, register and so on).
>
> Here I would have to look at the actual implementation to realize, at
> the moment, that I have to be careful calling these functions twice.
Sure. I'm waiting your patch.
[snip]
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCH v8 6/8] ARM: EXYNOS: remove secondary startup initialization from smp_prepare_cpus
From: Chanwoo Choi @ 2016-12-17 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217184806.GB30265@kozik-lap>
Hi Krzysztof,
2016-12-18 3:48 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Sat, Dec 10, 2016 at 06:38:41PM +0530, Pankaj Dubey wrote:
>> We are taking care of setting secondary cpu boot address in
>> exynos_boot_secondary just before sending ipi to secondary CPUs,
>> so we can safely remove this setting from smp_prepare_cpus.
>
> Indeed setting boot address is doubled. However between them, the power
> is turned on and Exynos3250 is being restarted.
>
> It would be nice to test it on Exynos3250 (Artik5 or Gear2?) and some of
> Exynos4 family. Beside that looks good to me, I just want to see some
> tested-by.
I'll test it on Exynos3250(gear2,artik5) and Exynos4(trats2) on Monday
and send the test result.
Best Regards,
Chanwoo Choi
[snip]
^ permalink raw reply
* [PATCH] staging: vc04_services: Fix bracing on single statement blocks
From: Aaron Moore @ 2016-12-18 5:48 UTC (permalink / raw)
To: linux-arm-kernel
Fix coding style issue caught by checkpatch.pl relating to braces on
single statement blocks. This issue was corrected in 3 locations.
Signed-off-by: Aaron Moore <aaron@atamisk.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
index f76f4d7..e0ba0ed 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
@@ -80,9 +80,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T *header)
return;
while (queue->write == queue->read + queue->size) {
- if (down_interruptible(&queue->pop) != 0) {
+ if (down_interruptible(&queue->pop) != 0)
flush_signals(current);
- }
}
/*
@@ -107,9 +106,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T *header)
VCHIQ_HEADER_T *vchiu_queue_peek(VCHIU_QUEUE_T *queue)
{
while (queue->write == queue->read) {
- if (down_interruptible(&queue->push) != 0) {
+ if (down_interruptible(&queue->push) != 0)
flush_signals(current);
- }
}
up(&queue->push); // We haven't removed anything from the queue.
@@ -128,9 +126,8 @@ VCHIQ_HEADER_T *vchiu_queue_pop(VCHIU_QUEUE_T *queue)
VCHIQ_HEADER_T *header;
while (queue->write == queue->read) {
- if (down_interruptible(&queue->push) != 0) {
+ if (down_interruptible(&queue->push) != 0)
flush_signals(current);
- }
}
/*
--
2.10.2
^ permalink raw reply related
* [PATCH v9 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Ricky Liang @ 2016-12-18 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481702690-10476-3-git-send-email-rick.chang@mediatek.com>
On Wed, Dec 14, 2016 at 4:04 PM, Rick Chang <rick.chang@mediatek.com> wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> ---
> drivers/media/platform/Kconfig | 15 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 1306 ++++++++++++++++++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 139 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 417 +++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 91 ++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c | 160 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h | 25 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 58 +
> 10 files changed, 2215 insertions(+)
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Tested-by: Ricky Liang <jcliang@chromium.org>
^ permalink raw reply
* [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
From: Yury Norov @ 2016-12-18 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode, and as supporting work,
> introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> existing 32-bit architectures but disabled for new arches (so 64-bit
> off_t is is used by new userspace).
>
> This version is based on kernel v4.9-rc1. It works with glibc-2.24,
> and tested with LTP.
Hi Arnd, Catalin
For last few days I'm trying to rebase this series on current master,
and I see significant conflicts and regressions. In fact, every time
I rebase on next rc1, I feel like I play a roulette.
This is not a significant problem now because it's almost for sure
that this series will not get into 4.10, for reasons not related to
kernel code. And I have time to deal with regressions. But in general,
I'd like to try my patches on top of other candidates for next merge
window. I cannot read all emails in LKML, but I can easily detect
problems and join to the discussion at early stage if I see any problem.
This is probably a noob question, and there are well-known branches,
like Andrew Morton's one. But at this stage it's very important to
have this series prepared for merge, and I'd prefer to ask about it.
Yury.
^ permalink raw reply
* [PATCH 3/3] mm: make pagoff_t type 64-bit
From: Christoph Hellwig @ 2016-12-18 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161216105514.GA466@yury-N73SV>
On Fri, Dec 16, 2016 at 04:25:14PM +0530, Yury Norov wrote:
> 1 leave things as is. 32-bit architectures will have no option to
> mmap big offsets, and no one cares - as usual.
And that's the only sensible option.
^ permalink raw reply
* [PATCH] mtd: nand: fsmc: remove stale non-DT probe path
From: Linus Walleij @ 2016-12-18 11:34 UTC (permalink / raw)
To: linux-arm-kernel
The FSMC driver has an execution path and a header file in
<linux/mtd/fsmc.h> that serves to support passing in platform
data through board files, albeit no upstream users of this
mechanism exist.
The header file also contains function headers for functions that
do not exist in the kernel.
Delete this and move the platform data struct, parsing and
handling into the driver, assume we are using OF and make the
driver depend on OF, remove the ifdefs making that optional.
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mtd/nand/Kconfig | 1 +
drivers/mtd/nand/fsmc_nand.c | 153 ++++++++++++++++++++++++++++++++++++------
include/linux/mtd/fsmc.h | 156 -------------------------------------------
3 files changed, 133 insertions(+), 177 deletions(-)
delete mode 100644 include/linux/mtd/fsmc.h
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 353a9ddf6b97..7d5a9cb4594d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -534,6 +534,7 @@ config MTD_NAND_JZ4780
config MTD_NAND_FSMC
tristate "Support for NAND on ST Micros FSMC"
+ depends on OF
depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300
help
Enables support for NAND Flash chips on the ST Microelectronics
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 4924b43977ef..bda1e4667138 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -35,10 +35,133 @@
#include <linux/mtd/partitions.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/mtd/fsmc.h>
#include <linux/amba/bus.h>
#include <mtd/mtd-abi.h>
+#define FSMC_NAND_BW8 1
+#define FSMC_NAND_BW16 2
+
+#define FSMC_MAX_NOR_BANKS 4
+#define FSMC_MAX_NAND_BANKS 4
+
+#define FSMC_FLASH_WIDTH8 1
+#define FSMC_FLASH_WIDTH16 2
+
+/* fsmc controller registers for NOR flash */
+#define CTRL 0x0
+ /* ctrl register definitions */
+ #define BANK_ENABLE (1 << 0)
+ #define MUXED (1 << 1)
+ #define NOR_DEV (2 << 2)
+ #define WIDTH_8 (0 << 4)
+ #define WIDTH_16 (1 << 4)
+ #define RSTPWRDWN (1 << 6)
+ #define WPROT (1 << 7)
+ #define WRT_ENABLE (1 << 12)
+ #define WAIT_ENB (1 << 13)
+
+#define CTRL_TIM 0x4
+ /* ctrl_tim register definitions */
+
+#define FSMC_NOR_BANK_SZ 0x8
+#define FSMC_NOR_REG_SIZE 0x40
+
+#define FSMC_NOR_REG(base, bank, reg) (base + \
+ FSMC_NOR_BANK_SZ * (bank) + \
+ reg)
+
+/* fsmc controller registers for NAND flash */
+#define PC 0x00
+ /* pc register definitions */
+ #define FSMC_RESET (1 << 0)
+ #define FSMC_WAITON (1 << 1)
+ #define FSMC_ENABLE (1 << 2)
+ #define FSMC_DEVTYPE_NAND (1 << 3)
+ #define FSMC_DEVWID_8 (0 << 4)
+ #define FSMC_DEVWID_16 (1 << 4)
+ #define FSMC_ECCEN (1 << 6)
+ #define FSMC_ECCPLEN_512 (0 << 7)
+ #define FSMC_ECCPLEN_256 (1 << 7)
+ #define FSMC_TCLR_1 (1)
+ #define FSMC_TCLR_SHIFT (9)
+ #define FSMC_TCLR_MASK (0xF)
+ #define FSMC_TAR_1 (1)
+ #define FSMC_TAR_SHIFT (13)
+ #define FSMC_TAR_MASK (0xF)
+#define STS 0x04
+ /* sts register definitions */
+ #define FSMC_CODE_RDY (1 << 15)
+#define COMM 0x08
+ /* comm register definitions */
+ #define FSMC_TSET_0 0
+ #define FSMC_TSET_SHIFT 0
+ #define FSMC_TSET_MASK 0xFF
+ #define FSMC_TWAIT_6 6
+ #define FSMC_TWAIT_SHIFT 8
+ #define FSMC_TWAIT_MASK 0xFF
+ #define FSMC_THOLD_4 4
+ #define FSMC_THOLD_SHIFT 16
+ #define FSMC_THOLD_MASK 0xFF
+ #define FSMC_THIZ_1 1
+ #define FSMC_THIZ_SHIFT 24
+ #define FSMC_THIZ_MASK 0xFF
+#define ATTRIB 0x0C
+#define IOATA 0x10
+#define ECC1 0x14
+#define ECC2 0x18
+#define ECC3 0x1C
+#define FSMC_NAND_BANK_SZ 0x20
+
+#define FSMC_NAND_REG(base, bank, reg) (base + FSMC_NOR_REG_SIZE + \
+ (FSMC_NAND_BANK_SZ * (bank)) + \
+ reg)
+
+#define FSMC_BUSY_WAIT_TIMEOUT (1 * HZ)
+
+struct fsmc_nand_timings {
+ uint8_t tclr;
+ uint8_t tar;
+ uint8_t thiz;
+ uint8_t thold;
+ uint8_t twait;
+ uint8_t tset;
+};
+
+enum access_mode {
+ USE_DMA_ACCESS = 1,
+ USE_WORD_ACCESS,
+};
+
+/**
+ * fsmc_nand_platform_data - platform specific NAND controller config
+ * @nand_timings: timing setup for the physical NAND interface
+ * @partitions: partition table for the platform, use a default fallback
+ * if this is NULL
+ * @nr_partitions: the number of partitions in the previous entry
+ * @options: different options for the driver
+ * @width: bus width
+ * @bank: default bank
+ * @select_bank: callback to select a certain bank, this is
+ * platform-specific. If the controller only supports one bank
+ * this may be set to NULL
+ */
+struct fsmc_nand_platform_data {
+ struct fsmc_nand_timings *nand_timings;
+ struct mtd_partition *partitions;
+ unsigned int nr_partitions;
+ unsigned int options;
+ unsigned int width;
+ unsigned int bank;
+
+ enum access_mode mode;
+
+ void (*select_bank)(uint32_t bank, uint32_t busw);
+
+ /* priv structures for dma accesses */
+ void *read_dma_priv;
+ void *write_dma_priv;
+};
+
static int fsmc_ecc1_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
@@ -714,7 +837,6 @@ static bool filter(struct dma_chan *chan, void *slave)
return true;
}
-#ifdef CONFIG_OF
static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
struct device_node *np)
{
@@ -757,13 +879,6 @@ static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
}
return 0;
}
-#else
-static int fsmc_nand_probe_config_dt(struct platform_device *pdev,
- struct device_node *np)
-{
- return -ENOSYS;
-}
-#endif
/*
* fsmc_nand_probe - Probe function
@@ -782,19 +897,15 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
u32 pid;
int i;
- if (np) {
- pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
- pdev->dev.platform_data = pdata;
- ret = fsmc_nand_probe_config_dt(pdev, np);
- if (ret) {
- dev_err(&pdev->dev, "no platform data\n");
- return -ENODEV;
- }
- }
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
- if (!pdata) {
- dev_err(&pdev->dev, "platform data is NULL\n");
- return -EINVAL;
+ pdev->dev.platform_data = pdata;
+ ret = fsmc_nand_probe_config_dt(pdev, np);
+ if (ret) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -ENODEV;
}
/* Allocate memory for the device structure (and zero it) */
diff --git a/include/linux/mtd/fsmc.h b/include/linux/mtd/fsmc.h
deleted file mode 100644
index ad3c3488073c..000000000000
--- a/include/linux/mtd/fsmc.h
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * incude/mtd/fsmc.h
- *
- * ST Microelectronics
- * Flexible Static Memory Controller (FSMC)
- * platform data interface and header file
- *
- * Copyright ? 2010 ST Microelectronics
- * Vipin Kumar <vipin.kumar@st.com>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __MTD_FSMC_H
-#define __MTD_FSMC_H
-
-#include <linux/io.h>
-#include <linux/platform_device.h>
-#include <linux/mtd/physmap.h>
-#include <linux/types.h>
-#include <linux/mtd/partitions.h>
-#include <asm/param.h>
-
-#define FSMC_NAND_BW8 1
-#define FSMC_NAND_BW16 2
-
-#define FSMC_MAX_NOR_BANKS 4
-#define FSMC_MAX_NAND_BANKS 4
-
-#define FSMC_FLASH_WIDTH8 1
-#define FSMC_FLASH_WIDTH16 2
-
-/* fsmc controller registers for NOR flash */
-#define CTRL 0x0
- /* ctrl register definitions */
- #define BANK_ENABLE (1 << 0)
- #define MUXED (1 << 1)
- #define NOR_DEV (2 << 2)
- #define WIDTH_8 (0 << 4)
- #define WIDTH_16 (1 << 4)
- #define RSTPWRDWN (1 << 6)
- #define WPROT (1 << 7)
- #define WRT_ENABLE (1 << 12)
- #define WAIT_ENB (1 << 13)
-
-#define CTRL_TIM 0x4
- /* ctrl_tim register definitions */
-
-#define FSMC_NOR_BANK_SZ 0x8
-#define FSMC_NOR_REG_SIZE 0x40
-
-#define FSMC_NOR_REG(base, bank, reg) (base + \
- FSMC_NOR_BANK_SZ * (bank) + \
- reg)
-
-/* fsmc controller registers for NAND flash */
-#define PC 0x00
- /* pc register definitions */
- #define FSMC_RESET (1 << 0)
- #define FSMC_WAITON (1 << 1)
- #define FSMC_ENABLE (1 << 2)
- #define FSMC_DEVTYPE_NAND (1 << 3)
- #define FSMC_DEVWID_8 (0 << 4)
- #define FSMC_DEVWID_16 (1 << 4)
- #define FSMC_ECCEN (1 << 6)
- #define FSMC_ECCPLEN_512 (0 << 7)
- #define FSMC_ECCPLEN_256 (1 << 7)
- #define FSMC_TCLR_1 (1)
- #define FSMC_TCLR_SHIFT (9)
- #define FSMC_TCLR_MASK (0xF)
- #define FSMC_TAR_1 (1)
- #define FSMC_TAR_SHIFT (13)
- #define FSMC_TAR_MASK (0xF)
-#define STS 0x04
- /* sts register definitions */
- #define FSMC_CODE_RDY (1 << 15)
-#define COMM 0x08
- /* comm register definitions */
- #define FSMC_TSET_0 0
- #define FSMC_TSET_SHIFT 0
- #define FSMC_TSET_MASK 0xFF
- #define FSMC_TWAIT_6 6
- #define FSMC_TWAIT_SHIFT 8
- #define FSMC_TWAIT_MASK 0xFF
- #define FSMC_THOLD_4 4
- #define FSMC_THOLD_SHIFT 16
- #define FSMC_THOLD_MASK 0xFF
- #define FSMC_THIZ_1 1
- #define FSMC_THIZ_SHIFT 24
- #define FSMC_THIZ_MASK 0xFF
-#define ATTRIB 0x0C
-#define IOATA 0x10
-#define ECC1 0x14
-#define ECC2 0x18
-#define ECC3 0x1C
-#define FSMC_NAND_BANK_SZ 0x20
-
-#define FSMC_NAND_REG(base, bank, reg) (base + FSMC_NOR_REG_SIZE + \
- (FSMC_NAND_BANK_SZ * (bank)) + \
- reg)
-
-#define FSMC_BUSY_WAIT_TIMEOUT (1 * HZ)
-
-struct fsmc_nand_timings {
- uint8_t tclr;
- uint8_t tar;
- uint8_t thiz;
- uint8_t thold;
- uint8_t twait;
- uint8_t tset;
-};
-
-enum access_mode {
- USE_DMA_ACCESS = 1,
- USE_WORD_ACCESS,
-};
-
-/**
- * fsmc_nand_platform_data - platform specific NAND controller config
- * @nand_timings: timing setup for the physical NAND interface
- * @partitions: partition table for the platform, use a default fallback
- * if this is NULL
- * @nr_partitions: the number of partitions in the previous entry
- * @options: different options for the driver
- * @width: bus width
- * @bank: default bank
- * @select_bank: callback to select a certain bank, this is
- * platform-specific. If the controller only supports one bank
- * this may be set to NULL
- */
-struct fsmc_nand_platform_data {
- struct fsmc_nand_timings *nand_timings;
- struct mtd_partition *partitions;
- unsigned int nr_partitions;
- unsigned int options;
- unsigned int width;
- unsigned int bank;
-
- enum access_mode mode;
-
- void (*select_bank)(uint32_t bank, uint32_t busw);
-
- /* priv structures for dma accesses */
- void *read_dma_priv;
- void *write_dma_priv;
-};
-
-extern int __init fsmc_nor_init(struct platform_device *pdev,
- unsigned long base, uint32_t bank, uint32_t width);
-extern void __init fsmc_init_board_info(struct platform_device *pdev,
- struct mtd_partition *partitions, unsigned int nr_partitions,
- unsigned int width);
-
-#endif /* __MTD_FSMC_H */
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
From: Ard Biesheuvel @ 2016-12-18 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4112999.Nl7pxYH1YF@wuerfel>
On 16 December 2016 at 21:51, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote:
>>
>> Can't we use the old
>>
>> tst lr, #1
>> moveq pc, lr
>> bx lr
>>
>> trick? (where bx lr needs to be emitted as a plain opcode to hide it
>> from the assembler)
>>
>
> Yes, that should work around the specific problem in theory, but back
> when Jonas tried it, it still didn't work. There may also be other
> problems in that configuration.
>
This should do the trick as well, I think:
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 9f157e7c51e7..3bfb32010234 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -835,7 +835,12 @@ ENDPROC(__switch_to)
.macro usr_ret, reg
#ifdef CONFIG_ARM_THUMB
+#ifdef CONFIG_CPU_32v4
+ str \reg, [sp, #-4]!
+ ldr pc, [sp], #4
+#else
bx \reg
+#endif
#else
ret \reg
#endif
with the added benefit that we don't clobber the N and Z flags. Of
course, this will result in all CPUs using a non-optimal sequence if
support for v4 is compiled in.
^ permalink raw reply related
* [PATCH net-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Martin Blumenstingl @ 2016-12-18 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <162595c2-d403-0070-3399-de03c1653065@gmail.com>
Hi Florian, Hi Jerome,
On Wed, Nov 30, 2016 at 2:15 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/29/2016 05:13 PM, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 29 Nov 2016 16:43:20 -0800
>>
>>> On 11/29/2016 04:38 PM, David Miller wrote:
>>>> From: Jerome Brunet <jbrunet@baylibre.com>
>>>> Date: Mon, 28 Nov 2016 10:46:45 +0100
>>>>
>>>>> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
>>>>> The platform seems to enter LPI on the Rx path too often while performing
>>>>> relatively high TX transfer. This eventually break the link (both Tx and
>>>>> Rx), and require to bring the interface down and up again to get the Rx
>>>>> path working again.
>>>>>
>>>>> The root cause of this issue is not fully understood yet but disabling EEE
>>>>> advertisement on the PHY prevent this feature to be negotiated.
>>>>> With this change, the link is stable and reliable, with the expected
>>>>> throughput performance.
>>>>>
>>>>> The patchset adds options in the generic phy driver to disable EEE
>>>>> advertisement, through device tree. The way it is done is very similar
>>>>> to the handling of the max-speed property.
>>>>
>>>> Patches 1-3 applied to net-next, thanks.
>>>
>>> Meh, there was a v4 submitted shortly after, and I objected to the whole
>>> idea of using that kind of Device Tree properties to disable EEE, we can
>>> send reverts though..
>>
>> Sorry, I lost this in all the discussion, I can revert.
>
> Yeah, I can understand why, these freaking PHYs tend to generate a lot
> of noise and discussion...
>
>>
>> Just send me a revert of the entire merge commit
>> a152c91889556df17ca6d8ea134fb2cb4ac9f893 with a short
>> description of why and I'll apply it.
>
> OK, I will talk with Jerome first to make sure that we are in agreement
> with the solution to deploy to fix the OdroidC2 problem first.
simply because I'm curious: what was the outcome of your discussion?
can we stay with the current solution or are any changes required?
Regards,
Martin
^ permalink raw reply
* [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
From: Russell King - ARM Linux @ 2016-12-18 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_1zbAB45SQ=702_v3H=RetLFsgknmp52iTSV9M4GSqHg@mail.gmail.com>
On Sun, Dec 18, 2016 at 11:57:00AM +0000, Ard Biesheuvel wrote:
> On 16 December 2016 at 21:51, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote:
> >>
> >> Can't we use the old
> >>
> >> tst lr, #1
> >> moveq pc, lr
> >> bx lr
> >>
> >> trick? (where bx lr needs to be emitted as a plain opcode to hide it
> >> from the assembler)
> >>
> >
> > Yes, that should work around the specific problem in theory, but back
> > when Jonas tried it, it still didn't work. There may also be other
> > problems in that configuration.
> >
>
> This should do the trick as well, I think:
>
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 9f157e7c51e7..3bfb32010234 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -835,7 +835,12 @@ ENDPROC(__switch_to)
>
> .macro usr_ret, reg
> #ifdef CONFIG_ARM_THUMB
> +#ifdef CONFIG_CPU_32v4
> + str \reg, [sp, #-4]!
> + ldr pc, [sp], #4
> +#else
> bx \reg
> +#endif
> #else
> ret \reg
> #endif
>
> with the added benefit that we don't clobber the N and Z flags. Of
> course, this will result in all CPUs using a non-optimal sequence if
> support for v4 is compiled in.
We don't clobber those flags anyway. bx doesn't change any of the flags.
'ret' devolves into either bx or a mov instruction. A mov instruction
without 's' does not change the flags either.
So there is no "added benefit". In fact, there's only detrimental
effects. str and ldr are going to be several cycles longer than the
plain mov.
In any case, the "CONFIG_CPU_32v4" alone doesn't hack it, we also have
CONFIG_CPU_32v3 to also consider.
In any case, I prefer the solution previously posted - to test bit 0 of
the PC, and select the instruction based on that. It'll take some
assembly level macros to handle all cases.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
From: Ard Biesheuvel @ 2016-12-18 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161218141630.GP14217@n2100.armlinux.org.uk>
On 18 December 2016 at 14:16, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Sun, Dec 18, 2016 at 11:57:00AM +0000, Ard Biesheuvel wrote:
>> On 16 December 2016 at 21:51, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote:
>> >>
>> >> Can't we use the old
>> >>
>> >> tst lr, #1
>> >> moveq pc, lr
>> >> bx lr
>> >>
>> >> trick? (where bx lr needs to be emitted as a plain opcode to hide it
>> >> from the assembler)
>> >>
>> >
>> > Yes, that should work around the specific problem in theory, but back
>> > when Jonas tried it, it still didn't work. There may also be other
>> > problems in that configuration.
>> >
>>
>> This should do the trick as well, I think:
>>
>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> index 9f157e7c51e7..3bfb32010234 100644
>> --- a/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -835,7 +835,12 @@ ENDPROC(__switch_to)
>>
>> .macro usr_ret, reg
>> #ifdef CONFIG_ARM_THUMB
>> +#ifdef CONFIG_CPU_32v4
>> + str \reg, [sp, #-4]!
>> + ldr pc, [sp], #4
>> +#else
>> bx \reg
>> +#endif
>> #else
>> ret \reg
>> #endif
>>
>> with the added benefit that we don't clobber the N and Z flags. Of
>> course, this will result in all CPUs using a non-optimal sequence if
>> support for v4 is compiled in.
>
> We don't clobber those flags anyway. bx doesn't change any of the flags.
> 'ret' devolves into either bx or a mov instruction. A mov instruction
> without 's' does not change the flags either.
>
The 'added benefit' is with respect to the tst/moveq/bx sequence,
which clobbers the N and Z flags.
> So there is no "added benefit". In fact, there's only detrimental
> effects. str and ldr are going to be several cycles longer than the
> plain mov.
>
Yes, but the kuser helpers are documented as preserving all flags and
registers except the ones that are documents as clobbered. I agree it
is highly unlikely that clobbering the N and Z flags is going to break
anything, but it is an ABI change nonetheless.
> In any case, the "CONFIG_CPU_32v4" alone doesn't hack it, we also have
> CONFIG_CPU_32v3 to also consider.
>
I don't think there are any configurations where CONFIG_CPU_32v3 are
CONFIG_ARM_THUMB are both enabled. The ARMv4 case is significant
because it can be enabled as part of a v4/v5 multiplatform
configuration.
> In any case, I prefer the solution previously posted - to test bit 0 of
> the PC, and select the instruction based on that. It'll take some
> assembly level macros to handle all cases.
>
The only issue I spotted is that the kuser_get_tls routine has only
two instruction slots for the return sequence, but we can easily work
around that by moving the TLS hardware instruction around in the
template (and update the memcpy accordingly in kuser_init()
It does appear that the tst/moveq/bx failed to work correctly when
tested on FA526, according to the link quoted by Arnd. But the below
builds ok for me on a v4/v4t/v5 multiarch configuration (apologies on
behalf of Gmail for the whitespace corruption, I can resend it as a
proper patch)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 9f157e7c51e7..e849965e3136 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -833,9 +833,21 @@ ENDPROC(__switch_to)
*/
THUMB( .arm )
+ .irp i, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14
+ .set .Lreg_\i, \i
+ .endr
+ .set .Lreg_ip, 12
+ .set .Lreg_lr, 14
+
.macro usr_ret, reg
#ifdef CONFIG_ARM_THUMB
+#if defined(CONFIG_CPU_32v3) || defined(CONFIG_CPU_32v4)
+ tst \reg, #1 @ preserves the C and V flags
+ moveq pc, \reg
+ .word 0xe12fff10 | .Lreg_\reg @ correct order for LE and BE32
+#else
bx \reg
+#endif
#else
ret \reg
#endif
@@ -1001,11 +1013,10 @@ kuser_cmpxchg32_fixup:
__kuser_get_tls: @ 0xffff0fe0
ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init
usr_ret lr
- mrc p15, 0, r0, c13, c0, 3 @ 0xffff0fe8 hardware TLS code
kuser_pad __kuser_get_tls, 16
- .rep 3
.word 0 @ 0xffff0ff0 software TLS value, then
- .endr @ pad up to __kuser_helper_version
+ mrc p15, 0, r0, c13, c0, 3 @ 0xffff0ff4 hardware TLS code
+ .word 0 @ pad up to __kuser_helper_version
__kuser_helper_version: @ 0xffff0ffc
.word ((__kuser_helper_end - __kuser_helper_start) >> 5)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index bc698383e822..7746090bd930 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -777,10 +777,10 @@ static void __init kuser_init(void *vectors)
/*
* vectors + 0xfe0 = __kuser_get_tls
- * vectors + 0xfe8 = hardware TLS instruction at 0xffff0fe8
+ * vectors + 0xff4 = hardware TLS instruction at 0xffff0ff4
*/
if (tls_emu || has_tls_reg)
- memcpy(vectors + 0xfe0, vectors + 0xfe8, 4);
+ memcpy(vectors + 0xfe0, vectors + 0xff4, 4);
}
#else
static inline void __init kuser_init(void *vectors)
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox