* [PATCH 2/2] pwm: stm32: initialize raw local variables
From: Thierry Reding @ 2018-05-18 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526657044-14879-3-git-send-email-fabrice.gasnier@st.com>
On Fri, May 18, 2018 at 05:24:04PM +0200, Fabrice Gasnier wrote:
> This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n
> in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and
> 'raw_dty' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> drivers/pwm/pwm-stm32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Lee,
I assume you'll pick this up into your branch where you applied the
initial patches along with 1/2 in this series?
Acked-by: Thierry Reding <thierry.reding@gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/a4364ea1/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 2/6] mfd: at91-usart: added mfd driver for usart
From: Rob Herring @ 2018-05-18 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-3-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 01:38:18PM +0300, Radu Pirea wrote:
> This mfd driver is just a wrapper over atmel_serial driver and
> spi-at91-usart driver. Selection of one of the drivers is based on a
> property from device tree. If the property is not specified, the default
> driver is atmel_serial.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> drivers/mfd/Kconfig | 10 ++++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/at91-usart.c | 75 ++++++++++++++++++++++++++++
> include/dt-bindings/mfd/at91-usart.h | 17 +++++++
> 4 files changed, 103 insertions(+)
> create mode 100644 drivers/mfd/at91-usart.c
> create mode 100644 include/dt-bindings/mfd/at91-usart.h
>
> +#ifndef __DT_BINDINGS_AT91_USART_H__
> +#define __DT_BINDINGS_AT91_USART_H__
> +
> +#define AT91_USART_MODE_SERIAL 1
> +#define AT91_USART_MODE_SPI 2
Won't this require a DT update for serial mode to add the mode property?
That breaks compatibility.
Rob
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Rob Herring @ 2018-05-18 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <869aad59-1cc5-28ef-1fb5-4ef846696c40@codeaurora.org>
On Thu, May 17, 2018 at 05:16:13PM -0700, David Collins wrote:
> On 05/17/2018 02:22 PM, Doug Anderson wrote:
> > On Fri, May 11, 2018 at 7:28 PM, David Collins <collinsd@codeaurora.org> wrote:
> >> +- qcom,regulator-initial-microvolt
> >> + Usage: optional; VRM regulators only
> >> + Value type: <u32>
> >> + Definition: Specifies the initial voltage in microvolts to request for a
> >> + VRM regulator.
> >
> > Now that Mark has landed the patch adding support for the
> > -ENOTRECOVERABLE error code from get_voltage() / get_voltage_sel(), do
> > we still need the qcom,regulator-initial-microvolt property?
>
> Yes, this is still needed. The -ENOTRECOVERABLE patch ensures that
> qcom-rpmh-regulator devices can be registered even if
> qcom,regulator-initial-microvolt is not specified. However, that will
> result in the regulators being configured for the minimum voltage
> supported in the DT specified min/max range. The
> qcom,regulator-initial-microvolt property allows us to set a specific
> voltage that is larger than the min constraint.
>
> > If this is really still needed, can it be moved to the regulator core?
>
> I'm not opposed to the idea, but I think that Mark is [1]:
>
> >> Do you have a preference for qcom,regulator-initial-microvolt vs a generic
> >> framework supported regulator-initial-microvolt property for configuring a
> >> specific voltage at registration time? We'll need to have support for one
> >> or the other in order for the qcom_rpmh-regulator driver to be functional.
> >
> > This is basically specific to Qualcomm, I can't off hand think of any
> > other devices with similar issues.
>
>
> >> +- regulator-initial-mode
> >> + Usage: optional; VRM regulators only
> >> + Value type: <u32>
> >> + Definition: Specifies the initial mode to request for a VRM regulator.
> >> + Supported values are RPMH_REGULATOR_MODE_* which are defined
> >> + in [1] (i.e. 0 to 3). This property may be specified even
> >> + if the regulator-allow-set-load property is not specified.
> >
> > Every time I read the above I wonder why you're documenting a standard
> > regulator regulator property in your bindings. ...then I realize it's
> > because you're doing it because you want to explicitly document what
> > the valid modes are. I wonder if it makes sense to just put a
> > reference somewhere else in this document to go look at the header
> > file where these are all nicely documented.
>
> Isn't that what the [1] in the above snippet is currently doing. Further
> down in qcom,rpmh-regulator.txt is this line:
>
> +[1] include/dt-bindings/regulator/qcom,rpmh-regulator.h
>
>
> > Speaking of documenting things like that, it might be worth finding
> > somewhere in this doc to mention that the "bob" regulator on PMI8998
> > can support "regulator-allow-bypass". That tidbit got lost when we
> > moved to the standard regulator bindings for bypass.
>
> I suppose that I could add something like this:
>
> +- regulator-allow-bypass
> + Usage: optional; BOB type VRM regulators only
> + Value type: <empty>
> + Definition: See [2] for details.
> ...
> +[2]: Documentation/devicetree/bindings/regulator.txt
>
> However, I don't want the patch to get NACKed because it is defining a
> property that is already defined in the common regulator.txt file.
If all constraints are defined in the common doc, just "see
regulator.txt" is fine. You just need to say what properties this
binding uses.
Rob
^ permalink raw reply
* [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table
From: Janusz Krzysztofik @ 2018-05-18 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VdNUW6KoM6oupyQ80A1WVRk7vewwDt6WEZOyjrAUifqRg@mail.gmail.com>
On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote:
> On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik
>
> <jmkrzyszt@gmail.com> wrote:
> > + gpiod_rdy = devm_gpiod_get_optional(&pdev->dev, "rdy", GPIOD_IN);
> > + if (!IS_ERR_OR_NULL(gpiod_rdy)) {
>
> So, is it optional or not at the end?
> If it is, why do we check for NULL?
As far as I can understand, nand_chip->dev_ready() callback is optional.
That's why I decided to use the _optional variant of devm_gpiod_get(). In case
of ams-delta, the dev_ready() callback depends on availability of the 'rdy'
GPIO pin. As a consequence, I'm checking for both NULL and ERR in order to
decide if dev_ready() will be supported.
I can pretty well replace it with the standard form and check for ERR only if
the purpose of the _optional form is different.
> > this->dev_ready = ams_delta_nand_ready;
> >
> > } else {
> >
> > this->dev_ready = NULL;
> > pr_notice("Couldn't request gpio for Delta NAND
> > ready.\n");
>
> dev_notice() ?
Sure, but maybe in a separate patch? That's not a new code just being added
but an existing one, not the merit of the change.
> > }
> >
> > +err_gpiod:
> > + if (err == -ENODEV || err == -ENOENT)
> > + err = -EPROBE_DEFER;
>
> Hmm...
Amstrad Delta uses gpio-mmio driver. Unfortunatelty that driver is not
availble before device init phase, unlike other crucial GPIO drivers which are
initialized earlier, e.g. during the postcore or at latetst the subsys phase.
Hence, devices which depend on GPIO pins provided by gpio-mmio must either be
declared late or fail softly so they get another chance of being probed
succesfully.
I thought of replacing the gpio-mmio platform driver with bgpio functions it
exports but for now I haven't implemented it, not even shared the idea.
Does it really hurt to return -EPROBE_DEFER if a GPIO pin can't be obtained?
Thanks,
Janusz
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Brüns, Stefan @ 2018-05-19 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518071436.3vvyllghrdxptsxg@flea>
On Freitag, 18. Mai 2018 09:14:36 CEST Maxime Ripard wrote:
> On Mon, May 14, 2018 at 10:36:08PM +0200, Paul Kocialkowski wrote:
> > > > + backlight: backlight {
> > > > + compatible = "pwm-backlight";
> > > > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > > > + brightness-levels = < 0 1 1 1 1 2 2 2
> > > > + 2 3 3 3 3 4 4 4
> > > > + 5 5 5 6 6 6 7 7
> > > > + 8 8 8 9 9 9 10 10
> > > > + 10 11 11 12 12 12 13 13
> > > > + 14 14 14 15 15 16 16 17
> > > > + 17 17 18 18 19 19 20 20
> > > > + 21 21 21 22 22 23 23 24
> > > > + 24 25 25 26 26 27 27 28
> > > > + 28 29 30 30 31 31 32 32
> > > > + 33 33 34 35 35 36 36 37
> > > > + 38 38 39 39 40 41 41 42
> > > > + 43 43 44 44 45 46 47 47
> > > > + 48 49 49 50 51 51 52 53
> > > > + 54 54 55 56 57 57 58 59
> > > > + 60 61 61 62 63 64 65 65
> > > > + 66 67 68 69 70 71 71 72
> > > > + 73 74 75 76 77 78 79 80
> > > > + 81 82 83 84 85 86 87 88
> > > > + 89 90 91 92 93 94 95 96
> > > > + 97 98 99 101 102 103 104 105
> > > > + 106 108 109 110 111 112 114 115
> > > > + 116 117 119 120 121 123 124 125
> > > > + 127 128 129 131 132 133 135 136
> > > > + 138 139 141 142 144 145 147 148
> > > > + 150 151 153 154 156 157 159 161
> > > > + 162 164 166 167 169 171 173 174
> > > > + 176 178 180 181 183 185 187 189
> > > > + 191 192 194 196 198 200 202 204
> > > > + 206 208 210 212 214 216 219 221
> > > > + 223 225 227 229 232 234 236 238
> > > > + 241 242 244 246 248 250 253 255>;
> > >
> > > You kind of overdid it here :)
> > >
> > > What I meant to say before was that if you have 10 elements (and you
> > > really should have something in that magnitude) each step should
> > > increase the perceived brightness by 10%.
> >
> > Mhh I think 10 elements would fall too short to really depict the curve
> > with appropriate precision. Given the usual size for brightness cursors
> > in e.g. gnome-shell, it feels like a bigger number would be more
> > appropriate. Let's make it to 100 with values from 0 to 255!
> >
> > > In this particular case, I really think having something close to <0 4
> > > 8 16 32 64 128 255> would be enough.
> > >
> > > And in general, that kind of odd looking table without any more
> > > context is just screaming for a comment :)
> >
> > Noted, I will explain the idea, but probably without the exact formula
> > that's really a nasty hack written down on a piece of paper sitting in
> > my garbage at this point.
>
> So no one will ever be able to understand where this sequence comes
> from (yourself-in-two-years included). That sounds like a pretty bad
> idea.
>
> Maxime
The following formula yields practically the same table:
out = ceil(255 * (0.245 * in/255 + 0.755 * pow(in/255, 2.6) ))
Maximum error: 4, maximum relative error: 0.33
Kind regards,
Stefan
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: David Collins @ 2018-05-19 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=U-QOQekUHj=ck57YJbTFdFjCAWr4t2A92x+fCNf+yV9A@mail.gmail.com>
On 05/17/2018 06:01 PM, Doug Anderson wrote:
> On Thu, May 17, 2018 at 5:16 PM, David Collins <collinsd@codeaurora.org> wrote:
>> On 05/17/2018 02:22 PM, Doug Anderson wrote:
>>> On Fri, May 11, 2018 at 7:28 PM, David Collins <collinsd@codeaurora.org> wrote:
>>>> +- qcom,regulator-initial-microvolt
>>>> + Usage: optional; VRM regulators only
>>>> + Value type: <u32>
>>>> + Definition: Specifies the initial voltage in microvolts to request for a
>>>> + VRM regulator.
>>>
>>> Now that Mark has landed the patch adding support for the
>>> -ENOTRECOVERABLE error code from get_voltage() / get_voltage_sel(), do
>>> we still need the qcom,regulator-initial-microvolt property?
>>
>> Yes, this is still needed. The -ENOTRECOVERABLE patch ensures that
>> qcom-rpmh-regulator devices can be registered even if
>> qcom,regulator-initial-microvolt is not specified. However, that will
>> result in the regulators being configured for the minimum voltage
>> supported in the DT specified min/max range. The
>> qcom,regulator-initial-microvolt property allows us to set a specific
>> voltage that is larger than the min constraint.
>
> Ah, OK. In the device tree fragment I saw the initial was always
> equal to the min, so I wasn't sure if this was really needed in
> practice. I presume it would only be important if a voltage was left
> high by the bootloader for some peripheral that needs to continue to
> function (and use the existing higher voltage) until a real device
> claims it. For all other voltages, it should be fine if it's set to
> the min until a real device claims it. Do you have real examples of
> devices like this in boards using sdm845?
Something to keep in mind about the downstream rpmh-regulator driver is
that it caches the initial voltages specified in device tree and only
sends them after a consumer driver makes a regulator framework call. This
saves time during boot and ensures that requests are not made for
regulators that no Linux consumer cares about.
It is generally not safe to request all regulators to be set to the
minimum allowed voltage. Special care will be needed with the upstream
qcom-rpmh-regulator driver to avoid disrupting the boot up state of
regulators that are needed by other subsystems. Therefore, I would like
to keep the initial voltage feature supported.
>>>> +- regulator-initial-mode
>>>> + Usage: optional; VRM regulators only
>>>> + Value type: <u32>
>>>> + Definition: Specifies the initial mode to request for a VRM regulator.
>>>> + Supported values are RPMH_REGULATOR_MODE_* which are defined
>>>> + in [1] (i.e. 0 to 3). This property may be specified even
>>>> + if the regulator-allow-set-load property is not specified.
>>>
>>> Every time I read the above I wonder why you're documenting a standard
>>> regulator regulator property in your bindings. ...then I realize it's
>>> because you're doing it because you want to explicitly document what
>>> the valid modes are. I wonder if it makes sense to just put a
>>> reference somewhere else in this document to go look at the header
>>> file where these are all nicely documented.
>>
>> Isn't that what the [1] in the above snippet is currently doing. Further
>> down in qcom,rpmh-regulator.txt is this line:
>>
>> +[1] include/dt-bindings/regulator/qcom,rpmh-regulator.h
>
> Right, but I want to move it so it doesn't look like you're defining a
> property that's already defined in the common bindings. AKA get rid
> of the "regulator-initial-mode" property description. Then add above
> Examples:
>
> ========================
> Regulator Modes
> ========================
>
> RPMh regulators are designed to work with the standard regulator mode
> bindings, using properties like "regulator-initial-mode". See
> include/dt-bindings/regulator/qcom,rpmh-regulator.h for information on
> the modes relevant to RPMh regulators.
>
> Some RPMh regulators (BOB regulators only) also support bypass using
> the standard "regulator-allow-bypass" binding.
>
>
> ...feel fee to reword, but basically the idea is to document it but
> not make it look like you're defining a novel property.
Ok, I'll try rewording the mode explanation and move it into another
section of the binding doc.
>>> Speaking of documenting things like that, it might be worth finding
>>> somewhere in this doc to mention that the "bob" regulator on PMI8998
>>> can support "regulator-allow-bypass". That tidbit got lost when we
>>> moved to the standard regulator bindings for bypass.
>>
>> I suppose that I could add something like this:
>>
>> +- regulator-allow-bypass
>> + Usage: optional; BOB type VRM regulators only
>> + Value type: <empty>
>> + Definition: See [2] for details.
>> ...
>> +[2]: Documentation/devicetree/bindings/regulator.txt
>>
>> However, I don't want the patch to get NACKed because it is defining a
>> property that is already defined in the common regulator.txt file.
>
> See above for my suggestion.
Ok.
>>>> +- qcom,allowed-drms-modes
>>>> + Usage: required if regulator-allow-set-load is specified;
>>>> + VRM regulators only
>>>> + Value type: <prop-encoded-array>
>>>> + Definition: A list of integers specifying the PMIC regulator modes which
>>>> + can be configured at runtime based upon consumer load needs.
>>>> + Supported values are RPMH_REGULATOR_MODE_* which are defined
>>>> + in [1] (i.e. 0 to 3).
>>>
>>> Why is this still here? You moved it to the core regulator framework,
>>> right? It's still in your examples too. Shouldn't this be removed?
>>> It looks like the driver still needs this and it needs to be an exact
>>> duplicate of the common binding. That doesn't seem right...
>>
>> The qcom,allowed-drms-modes property supports a different feature than the
>> regulator-allowed-modes property accepted in [2]. The latter specifies
>> the modes that may be used at all (e.g. in regulator_set_mode() calls) and
>> it lists the mode values in an unordered fashion.
>>
>> qcom,allowed-drms-modes defines a specific subset of the possible allowed
>> modes that should be set based on DRMS (e.g. in regulator_set_load()
>> calls). Its values are listed in a specific order and must match 1-to-1
>> with qcom,drms-mode-max-microamps entries.
>>
>> It would probably be good to change the name of the property from
>> qcom,allowed-drms-modes to qcom,regulator-drms-modes.
>
> Ah, I see. It's unfortunate that now we need to effectively list all
> modes twice. Have you seen real-life examples where these sets of
> modes need to be different, or is this just theoretical? If not can
> we start with one property (that controls both things) and if we
> really see that we need to specify different sets of modes for the two
> cases we can add a separate property? ...actually, even if you do
> have real-life examples of where these need to be different, if 90% of
> the time they are the same it would still be nice to just have one
> property apply to both cases.
I plan to keep qcom,regulator-drms-modes (and
qcom,drms-mode-max-microamps) around as a property specifically handled
for qcom-rpmh-regulator. It serves a purpose that is distinct from that
of the generic regulator-allowed-modes. Without it, there will not be a
way to utilize regulator_set_load() to configure the regulator modes.
>>>> +- qcom,drms-mode-max-microamps
>>>> + Usage: required if regulator-allow-set-load is specified;
>>>> + VRM regulators only
>>>> + Value type: <prop-encoded-array>
>>>> + Definition: A list of integers specifying the maximum allowed load
>>>> + current in microamps for each of the modes listed in
>>>> + qcom,allowed-drms-modes (matched 1-to-1 in order). Elements
>>>> + must be specified in order from lowest to highest value.
>>>
>>> Any reason this can't go into the regulator core? You'd basically
>>> just take the existing concept of rpmh_regulator_vrm_set_load() and
>>> put it in the core.
>>
>> This could be implemented in the core via new constraint elements parsed
>> in of_regulator and a helper function to specify in regulator_ops.
>> However, I'm not sure about the wide-spread applicability of this feature.
>> I'd prefer to leave it in the driver unless Mark would like me to add it
>> into the core.
>
> You're already using pre-existing APIs around specifying the current
> and having the regulator core call you to map the total current into a
> mode. That implies that this is applicable to others. Adding this
> tiny amount of code to the core makes the pre-existing APIs generally
> useful.
I don't see the benefit of making struct regulation_constraints more
complicated with DRMS mode and current arrays that would only every be
used by the qcom-rpmh-regulator driver. Other regulator drivers are able
to hard code this information in the driver code using get_optimum_mode()
callbacks.
As a side note, changing qcom-rpmh-regulator to use a get_optimum_mode()
callback instead of a set_load() callback would probably be a good idea too.
>>>> +- qcom,headroom-microvolt
>>>> + Usage: optional; VRM regulators only
>>>> + Value type: <u32>
>>>> + Definition: Specifies the headroom voltage in microvolts to request for
>>>> + a VRM regulator. RPMh hardware automatically ensures that
>>>> + the parent of this regulator outputs a voltage high enough
>>>> + to satisfy the requested headroom. Supported values are
>>>> + 0 to 511000.
>>>
>>> I'm curious: is this a voted-for value, or a global value?
>>>
>>> Said another way: the whole point of RPMh is that there may be more
>>> than one processor that needs the same rails, right? So the AP might
>>> request 1.1 V for a rail and the modem might request 1.3 V. RPMh
>>> would decide to pick the higher of those two (1.3 V), but if the modem
>>> said it no longer needs the rail it will drop down to 1.1 V.
>>>
>>> ...and as an example of why the headroom needs to be in hardware, if
>>> the source voltage was normally 1.4 V and the headroom was 200 mV then
>>> the hardware would need to know to bump up the source voltage to 1.5V
>>> during the period of of time that the modem wants the rail at 1.3V.
>>>
>>> So my question is: do the AP and modem in the above situation
>>> separately vote for headroom? How is it aggregated? ...or is it a
>>> global value and this sets the headroom for all clients of RPMh? It
>>> would be interesting to document this as it might help with figuring
>>> out how this value should be set.
>>
>> The headroom voltage voting is supported in hardware per-regulator and
>> per-master (AP, modem, etc). The headroom voltage and output voltage are
>> each aggregated (using max) per-regulator across masters. If the
>> aggregated enable state for a regulator is on, then the aggregated output
>> voltage and headroom voltage are added together and applied as a min
>> constraint on the parent's output voltage (if there is a parent).
>
> Ah, interesting. I'm not 100% convinced that the RPMh API is at the
> right abstraction level here. I guess you increase the headroom
> voltage if you expect a lot of current and need the regulator to still
> give a clean signal? If you truly wanted to aggregate then if both
> the modem and AP wanted to draw a lot of current they would both need
> to increase the headroom and then the headroom should maybe not be the
> max but something slightly more (you wouldn't want to add, but ...)
>
> Since it's just a max, in theory it seems like you get 99% of the way
> there by just using the Linux APIs to deal with dropout voltage. If
> Linux was managing it in software then if it needed to account for
> extra headroom it would just increase the supply voltage. That should
> play just fine with the modem (which might be using the hardware
> headroom feature) since it will be making its own completely separate
> requests and they should be aggregated OK.
>
> In another thread you said you'd be OK dropping the headroom voltage
> since it wasn't needed on SDM845. Maybe we should do that? ...and if
> someone later needs to account for a larger dropout they can figure
> out how to hookup the standard linux min_dropout_uV?
I will remove qcom,headroom-microvolt.
Take care,
David
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] firmware: arm_scmi: remove some unnecessary checks
From: Dan Carpenter @ 2018-05-19 6:37 UTC (permalink / raw)
To: linux-arm-kernel
The "pi->dom_info" buffer is allocated in init() and it can't be NULL
here. These tests are sort of weird as well because if "pi->dom_info"
was NULL but "domain" was non-zero then it would lead to an Oops.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 2a219b1261b1..721e6c57beae 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -363,8 +363,6 @@ static int scmi_dvfs_device_opps_add(const struct scmi_handle *handle,
return domain;
dom = pi->dom_info + domain;
- if (!dom)
- return -EIO;
for (opp = dom->opp, idx = 0; idx < dom->opp_count; idx++, opp++) {
freq = opp->perf * dom->mult_factor;
@@ -394,9 +392,6 @@ static int scmi_dvfs_transition_latency_get(const struct scmi_handle *handle,
return domain;
dom = pi->dom_info + domain;
- if (!dom)
- return -EIO;
-
/* uS to nS */
return dom->opp[dom->opp_count - 1].trans_latency_us * 1000;
}
^ permalink raw reply related
* [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
From: hch at lst.de @ 2018-05-19 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c5d27e9-2799-eb38-8b09-47a04c48b5c7@gmx.de>
On Fri, May 18, 2018 at 10:05:51PM +0200, Helge Deller wrote:
> This patch seems to fix the dma issues I faced on my 32bit B160L parisc box.
>
> So it leaves only one open issue on parisc:
> Now every 32 bit parisc system is unnecessarily non-coherent.
I diagree with those comments, let me resend the refactored patch
to make it more clear.
^ permalink raw reply
* [PATCH v3 2/6] mfd: at91-usart: added mfd driver for usart
From: Alexandre Belloni @ 2018-05-19 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518221949.GA13443@rob-hp-laptop>
On 18/05/2018 17:19:49-0500, Rob Herring wrote:
> On Fri, May 11, 2018 at 01:38:18PM +0300, Radu Pirea wrote:
> > This mfd driver is just a wrapper over atmel_serial driver and
> > spi-at91-usart driver. Selection of one of the drivers is based on a
> > property from device tree. If the property is not specified, the default
> > driver is atmel_serial.
> >
> > Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> > ---
> > drivers/mfd/Kconfig | 10 ++++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/at91-usart.c | 75 ++++++++++++++++++++++++++++
> > include/dt-bindings/mfd/at91-usart.h | 17 +++++++
> > 4 files changed, 103 insertions(+)
> > create mode 100644 drivers/mfd/at91-usart.c
> > create mode 100644 include/dt-bindings/mfd/at91-usart.h
> >
>
> > +#ifndef __DT_BINDINGS_AT91_USART_H__
> > +#define __DT_BINDINGS_AT91_USART_H__
> > +
> > +#define AT91_USART_MODE_SERIAL 1
> > +#define AT91_USART_MODE_SPI 2
>
> Won't this require a DT update for serial mode to add the mode property?
> That breaks compatibility.
>
If the mode property is not present, it defaults to serial to keep
compatibility.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
From: Jernej Škrabec @ 2018-05-19 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518152651.lfymc3kj7npj5tww@flea>
Hi,
Dne petek, 18. maj 2018 ob 17:26:51 CEST je Maxime Ripard napisal(a):
> On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej ?krabec wrote:
> > > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to
> > > lookup pll-2 either.
> >
> > It is highly unlikely this will be higher than 2, at least for this HDMI
> > PHY, since it has only 1 bit reserved for parent selection. But since I
> > have to fix it, I'll add ">= 2"
>
> If we're only going to have two parents at most, ever, why don't we
> had just a single other boolean. This would be less intrusive, and we
> wouldn't have to check for those corner cases.
It seems that usage of "bool" data type in structures is not wanted anymore
according to checkpatch and this: https://lkml.org/lkml/2017/11/21/384
I guess I'll use "unsigned int" as recommended by Linus and named it
"has_second_parent" to be unambigous that it's boolean in reality.
Best regards,
Jernej
>
> > BTW, I'll resend fixed version of this patch for my R40 HDMI series, since
> > there is nothing to hold it back, unlike for this.
>
> Awesome, thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC
From: Christian Lamparter @ 2018-05-19 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518023056.7869-5-manivannan.sadhasivam@linaro.org>
On Friday, May 18, 2018 4:30:55 AM CEST Manivannan Sadhasivam wrote:
> Add gpio support to pinctrl driver for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> [...]
> +static int owl_gpio_init(struct owl_pinctrl *pctrl)
> +{
> + struct gpio_chip *chip;
> + int ret;
> +
> + chip = &pctrl->chip;
> + chip->base = -1;
> + chip->ngpio = pctrl->soc->ngpios;
> + chip->label = dev_name(pctrl->dev);
> + chip->parent = pctrl->dev;
> + chip->owner = THIS_MODULE;
> + chip->of_node = pctrl->dev->of_node;
> +
> + ret = gpiochip_add_data(&pctrl->chip, pctrl);
> + if (ret) {
> + dev_err(pctrl->dev, "failed to register gpiochip\n");
> + return ret;
> + }
> +
> + ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev),
> + 0, 0, chip->ngpio);
> + if (ret) {
> + dev_err(pctrl->dev, "failed to add pin range\n");
> + gpiochip_remove(&pctrl->chip);
> + return ret;
> + }
> +
gpiochip_add_pin_range()? That's not going to work with gpio-hogs.
But, you can easily test this. Just add a gpio-hog [0]
( Section 2. gpio-controller nodes) into the Devicetree's
pinctrl node.
something like: (No idea if GPIO1 is already used, but any free
gpio will do)
| [...]
| pinctrl at e01b0000 {
| compatible = "actions,s900-pinctrl";
| reg = <0x0 0xe01b0000 0x0 0x1000>;
| clocks = <&cmu CLK_GPIO>;
| gpio-controller;
| #gpio-cells = <2>;
|
| line_b {
| gpio-hog;
| gpios = <1 GPIO_ACTIVE_HIGH>;
| output-low;
| line-name = "foo-bar-gpio";
| };
| };
The pinctrl probe will fail. You can fix this by
replacing the gpiochip_add_pin_range() and use
the gpio-ranges [0] property to define the range.
[0] <https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt>
^ permalink raw reply
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Christian Lamparter @ 2018-05-19 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518051826.GO14924@minitux>
On Friday, May 18, 2018 7:18:26 AM CEST Bjorn Andersson wrote:
> On Thu 12 Apr 12:01 PDT 2018, Christian Lamparter wrote:
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index 0a6f7952bbb1..18511e782cbd 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -530,6 +530,7 @@
> > reg = <0x01010000 0x300000>;
> > interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> > gpio-controller;
> > + gpio-ranges = <&msmgpio 0 0 150>;
>
> I'm still confused to why this information is in DT at all, it feels
> like an implementation detail, not a system configuration thing.
I did look at the commits and code from back in 2013. From what
I can gather "this implementation detail" was realized the way
it is now, because "devicetree was the new thing" and it seemed
like a good idea to make it as extendable/generic as possible.
You should definitely check out the gpio/gpio.txt [0] file from section
"2.1) gpio- and pin-controller interaction" onwards. (there are way more
bindings in there)
Maybe Linus has the full story.
>
> > #gpio-cells = <2>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> > index e7abc8ba222b..ed889553f01c 100644
> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> > @@ -890,11 +890,24 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
> > return ret;
> > }
> >
> > - ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);
> > - if (ret) {
> > - dev_err(pctrl->dev, "Failed to add pin range\n");
> > - gpiochip_remove(&pctrl->chip);
> > - return ret;
> > + /*
> > + * For DeviceTree-supported systems, the gpio core checks the
> > + * pinctrl's device node for the "gpio-ranges" property.
> > + * If it is present, it takes care of adding the pin ranges
> > + * for the driver. In this case the driver can skip ahead.
> > + *
> > + * In order to remain compatible with older, existing DeviceTree
> > + * files which don't set the "gpio-ranges" property or systems that
> > + * utilize ACPI the driver has to call gpiochip_add_pin_range().
> > + */
> > + if (!of_property_read_bool(pctrl->dev->of_node, "gpio-ranges")) {
> > + ret = gpiochip_add_pin_range(&pctrl->chip,
> > + dev_name(pctrl->dev), 0, 0, chip->ngpio);
> > + if (ret) {
> > + dev_err(pctrl->dev, "Failed to add pin range\n");
> > + gpiochip_remove(&pctrl->chip);
> > + return ret;
> > + }
> > }
>
> The patch looks good, but I would like you to split it in DT and pinctrl
> parts, to make it less likely to collide and to allow Andy to inject the
> missing change of sdm845.dtsi (which is now in linux-next)
>
> Please split it and add my
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> to both patches.
Ok, thanks.
Regards,
Christian
[0] <https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt>
^ permalink raw reply
* [PATCH v3 4/4] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: kbuild test robot @ 2018-05-19 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526538126-51497-5-git-send-email-erin.lo@mediatek.com>
Hi Ben,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Erin-Lo/Add-basic-support-for-Mediatek-MT8183-SoC/20180519-160349
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-alldefconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/mediatek/mt8183.dtsi:137.9-10 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 8591 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/c9534ce8/attachment.gz>
^ permalink raw reply
* [PATCH 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC
From: Manivannan Sadhasivam @ 2018-05-19 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12834501.5lBvNSZm06@debian64>
Hi Christian,
On Sat, May 19, 2018 at 11:18:53AM +0200, Christian Lamparter wrote:
> On Friday, May 18, 2018 4:30:55 AM CEST Manivannan Sadhasivam wrote:
> > Add gpio support to pinctrl driver for Actions Semi S900 SoC.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> > [...]
> > +static int owl_gpio_init(struct owl_pinctrl *pctrl)
> > +{
> > + struct gpio_chip *chip;
> > + int ret;
> > +
> > + chip = &pctrl->chip;
> > + chip->base = -1;
> > + chip->ngpio = pctrl->soc->ngpios;
> > + chip->label = dev_name(pctrl->dev);
> > + chip->parent = pctrl->dev;
> > + chip->owner = THIS_MODULE;
> > + chip->of_node = pctrl->dev->of_node;
> > +
> > + ret = gpiochip_add_data(&pctrl->chip, pctrl);
> > + if (ret) {
> > + dev_err(pctrl->dev, "failed to register gpiochip\n");
> > + return ret;
> > + }
> > +
> > + ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev),
> > + 0, 0, chip->ngpio);
> > + if (ret) {
> > + dev_err(pctrl->dev, "failed to add pin range\n");
> > + gpiochip_remove(&pctrl->chip);
> > + return ret;
> > + }
> > +
> gpiochip_add_pin_range()? That's not going to work with gpio-hogs.
>
Hmmm. Just looked into the gpio-hog mechanism and the patch you have
implemented for MSM driver. I agree with you on replacing
gpiochip_add_pin_range() with gpio-ranges property. But I'm curious
whether we should document it somewhere or not (probably in [1]).
Anyway I will send the v2 incorporating your suggestion.
Thanks,
Mani
[1] Documentation/devicetree/bindings/gpio/gpio.txt
> But, you can easily test this. Just add a gpio-hog [0]
> ( Section 2. gpio-controller nodes) into the Devicetree's
> pinctrl node.
>
> something like: (No idea if GPIO1 is already used, but any free
> gpio will do)
> | [...]
> | pinctrl at e01b0000 {
> | compatible = "actions,s900-pinctrl";
> | reg = <0x0 0xe01b0000 0x0 0x1000>;
> | clocks = <&cmu CLK_GPIO>;
> | gpio-controller;
> | #gpio-cells = <2>;
> |
> | line_b {
> | gpio-hog;
> | gpios = <1 GPIO_ACTIVE_HIGH>;
> | output-low;
> | line-name = "foo-bar-gpio";
> | };
> | };
>
> The pinctrl probe will fail. You can fix this by
> replacing the gpiochip_add_pin_range() and use
> the gpio-ranges [0] property to define the range.
>
> [0] <https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt>
>
>
>
^ permalink raw reply
* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Russell King - ARM Linux @ 2018-05-19 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01094c0d-af69-7e4c-65ec-7acddc778b5e@gmail.com>
On Wed, May 16, 2018 at 09:23:01AM -0700, Florian Fainelli wrote:
> On 05/16/2018 04:00 AM, Russell King wrote:
> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> > index 2da087926ebe..5ad0b67b9e33 100644
> > --- a/arch/arm/kernel/smp.c
> > +++ b/arch/arm/kernel/smp.c
> > @@ -31,6 +31,7 @@
> > #include <linux/irq_work.h>
> >
> > #include <linux/atomic.h>
> > +#include <asm/bugs.h>
> > #include <asm/smp.h>
> > #include <asm/cacheflush.h>
> > #include <asm/cpu.h>
> > @@ -405,6 +406,9 @@ asmlinkage void secondary_start_kernel(void)
> > * before we continue - which happens after __cpu_up returns.
> > */
> > set_cpu_online(cpu, true);
> > +
> > + check_other_bugs();
>
> Given what is currently implemented, I don't think the location of
> check_other_bugs() matters too much, but we might have to move this
> after the local_irq_enable() at some point if we need to check for e.g:
> a bogus local timer or whatever?
We could move it later if we need to.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Marc Zyngier @ 2018-05-19 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOdk+=JKcQP1ieLEkZftRGf-pqCTTzEuYvT_45YNMkEw_wA@mail.gmail.com>
On Fri, 18 May 2018 19:31:50 +0100,
Nick Desaulniers wrote:
>
> On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> > What I'd really like is to apply that patch knowing that:
>
> > - you have checked that with a released version of the compiler, you
> > don't observe any absolute address in any of the objects that are going
> > to be executed at EL2 on a mainline kernel,
>
> To verify, we should disassemble objects from arch/arm64/kvm/hyp/*.o and
> make sure we don't see absolute addresses? I can work with Sami to get a
> sense of what the before and after of this patch looks like in disassembly,
> then verify those changes are pervasive.
That seems sensible. You definitely want to look for things stored in
constant pools and subsequently used as an address. Also, you may have
to look at the .hyp.text section of the vmlinux binary, rather than
the individual *.o files, as the linker will likely rewrite things
(the compiler doesn't know about the kernel link address).
> > - you have successfully run guests with a mainline kernel,
>
> I believe Andrey has already done this. If he can verify (maybe
> during working hours next week), then maybe we can add his Tested-by
> to this patches commit message?
That would definitely be the right thing to do. Make sure you (or
Andrey tests with the latest released mainline kernel (4.16 for now)
or (even better) the tip of Linus' tree.
> > - it works for a reasonable set of common kernel configurations
> > (defconfig and some of the most useful debug options),
>
> It's easy for us to test our kernel configs for Android, ChromeOS,
> and defconfig. I'd be curious to know the shortlist of "most useful
> debug options" just to be a better kernel developer, personally.
Activate the various sanitizers, and all the tracing options, for a
start. They are the most likely to do weird things...
> > - I can reproduce your findings with the same released compiler.
>
> Lets wait for Andrey to confirm his test setup. On the Android side, I
> think you should be able to get by with a released version, but I'd be
> curious to hear from Andrey.
Android has all kind of additional patches, and I'm solely concerned
with mainline. If it is what Andrey runs, that's great.
> > Is that the case? I don't think any of the above is completely outlandish.
>
> These are all reasonable. Thanks for the feedback.
Cheers,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-19 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518014538.duphof6enscpm5vp@vireshk-i7>
commit 4abe2cd7176a43c77e9a462e4f6ec51aa7552e73
Author: Ilia Lin <ilialin@codeaurora.org>
Date: Thu May 17 13:55:12 2018 +0300
cpufreq: Add Kryo CPU scaling driver
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP
of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..b024b23
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP
of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+#define SILVER_LEAD 0
+#define GOLD_LEAD 2
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id
*/
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct device *cpu_dev_silver, *cpu_dev_gold;
+ struct opp_table *opp_silver, *opp_gold;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev_silver = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_silver))
+ return PTR_ERR(cpu_dev_silver);
+
+ cpu_dev_gold = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_gold))
+ return PTR_ERR(cpu_dev_gold);
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
+ if (IS_ERR_OR_NULL(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ opp_silver =
dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
+ if (IS_ERR_OR_NULL(opp_silver)) {
+ dev_err(cpu_dev_silver, "Failed to set supported
hardware\n");
+ ret = PTR_ERR(opp_silver);
+ goto free_np;
+ }
+
+ opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
+ if (IS_ERR_OR_NULL(opp_gold)) {
+ dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_gold);
+ goto free_opp_silver;
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev_silver, "Failed to register platform device\n");
+ dev_pm_opp_put_supported_hw(opp_gold);
+
+free_opp_silver:
+ dev_pm_opp_put_supported_hw(opp_silver);
+
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Friday, May 18, 2018 04:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: mturquette at baylibre.com; sboyd at kernel.org; robh at kernel.org;
> mark.rutland at arm.com; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; andy.gross at linaro.org; david.brown at linaro.org;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; rnayak at codeaurora.org;
> amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
>
> On 17-05-18, 14:19, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret = 0;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev_silver, *cpu_dev_gold;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct platform_device *pdev;
> > + struct opp_table *opp_silver = NULL;
> > + struct opp_table *opp_gold = NULL;
>
> No need to initialize them and you may want to arrange all above in
> decreasing order of their length.
>
> > +
> > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_silver))
> > + return PTR_ERR(cpu_dev_silver);
> > +
> > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_gold))
> > + return PTR_ERR(cpu_dev_gold);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
> ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > + nvmem_cell_put(speedbin_nvmem);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + opp_silver =
> dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_silver)) {
>
> This API doesn't return NULL and so IS_ERR() would be sufficient.
>
> > + dev_err(cpu_dev_silver, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_silver);
> > + goto free_np;
> > + }
> > +
> > + opp_gold =
> dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_gold)) {
>
> same here.
>
> > + dev_err(cpu_dev_gold, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_gold);
> > + goto free_opp_silver;
> > + }
> > +
> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > + if (!IS_ERR_OR_NULL(pdev))
> > + goto out;
>
> Simply return from here and remove the useless label out.
>
> > +
> > + ret = PTR_ERR(pdev);
> > + dev_err(cpu_dev_silver, "Failed to register platform device\n");
> > + dev_pm_opp_put_supported_hw(opp_gold);
> > +
> > +free_opp_silver:
> > + dev_pm_opp_put_supported_hw(opp_silver);
> > +
> > +free_np:
> > + of_node_put(np);
> > +
> > +out:
> > + return ret;
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>
> Please resend only this patch now or just paste the new code in a mail
here
> so that I can review it quickly and then you can resend the final version.
Most
> of the patches aren't changing anyway.
>
> --
> viresh
^ permalink raw reply related
* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-19 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 164 +++++++++++++++++++++++++++++++++++
4 files changed, 178 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..ae2d1b9
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+#define SILVER_LEAD 0
+#define GOLD_LEAD 2
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct device *cpu_dev_silver, *cpu_dev_gold;
+ struct opp_table *opp_silver, *opp_gold;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev_silver = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_silver))
+ return PTR_ERR(cpu_dev_silver);
+
+ cpu_dev_gold = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_gold))
+ return PTR_ERR(cpu_dev_gold);
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
+ if (IS_ERR_OR_NULL(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n", ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ opp_silver = dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
+ if (IS_ERR(opp_silver)) {
+ dev_err(cpu_dev_silver, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_silver);
+ goto free_np;
+ }
+
+ opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
+ if (IS_ERR(opp_gold)) {
+ dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_gold);
+ goto free_opp_silver;
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev_silver, "Failed to register platform device\n");
+ dev_pm_opp_put_supported_hw(opp_gold);
+
+free_opp_silver:
+ dev_pm_opp_put_supported_hw(opp_silver);
+
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Christian Lamparter @ 2018-05-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152654016566.210890.15719083257170941464@swboyd.mtv.corp.google.com>
On Thursday, May 17, 2018 8:56:05 AM CEST Stephen Boyd wrote:
> Quoting Christian Lamparter (2018-05-16 13:29:48)
> > On Wednesday, May 16, 2018 5:31:16 PM CEST Stephen Boyd wrote:
> > > Why can't we register the gpiochip and tell it about the pin ranges in
> > > one API call instead of adding the chip and then adding the ranges? It
> > > doesn't look right to have to go and update all the DT nodes to list
> > > this information that is already known in the driver because the kernel
> > > implementation can't handle the order of operations correctly.
> > The problem is that gpiochip_add_pin_range() was not intended for
> > DT-based pinctrls... but it got used anyway.
>
> Are there more users of this on DT based systems? A quick grep shows a
> couple more potential failures, like the qcom based SPMI gpio controllers
> and a mediatek one.
Yes, it there are a few. In the reply to the original report from Sven I found:
<https://www.spinics.net/lists/linux-arm-msm/msg34726.html>
pinctrl-mt7622, pinctrl-mtk-common.c, pinctrl-abx500.c, pinctrl-msm.c,
pinctrl-as3722.c, pinctrl-at91-pio4.c, pinctrl-axp209.c, pinctrl-coh901.c,
pinctrl-digicolor.c, pinctrl-pistachio.c, pinctrl-sx150x.c
.. And now the new Actions S900 gpio/pinctrl patch as well.
(<https://lkml.org/lkml/2018/5/19/44>)
> It's almost like we should print a huge WARN_ON() if gpio_chip::of_node
> is non-NULL and gpochip_add_pin_range() is called. But that probably
> would be noisy and can't be fixed on older DT blobs. It may also be good
> to bail out of that function if the node pointer exists and the property
> is there in the node so that we don't have to go update each driver for
> the backwards compat mode like was done in this patch. Plus the function
> should get some sort of comment that calling it is not useful on DT
> based platforms so this is all documented.
Agreed. Though, adding a warning now is likely a bit much, since the code
has to be compatible with existing definitions. But if Linus agrees I think
it would be fair to call drivers out with something like "the use of this
function is deprecated for DT" debug level message.
(As for the documentation update to gpiochip_add_pin_range() and
gpiochip_add_pingroup_range(). yeah I'll give it a go.)
> > This topic came up in an earlier post:
> > "Re: pinctrl: qcom: ipq4019: Use of gpio-hog's" [0] (you must have gotten
> > this mail too, since you are on the Cc.) which links to a ML thread titled
> > "Re: [GIT PULL] SPEAr pinctrl updates for v-3.5"
>
> I get quite a bit of email as you can tell.
Everyone does :D.
> >
> > For your convenience: (this post is from 2012-09-03 - so it's 5-6 years
> > old by now and it looks like it predates even the DT pinctrl-msm driver.
> > (Not entirely sure?))
> > <http://thread.gmane.org/gmane.linux.ports.arm.kernel/184943>
> > |[...]
> > |But I want two similar function named:
> > |
> > |gpiochip_add_pin_range();
> > |gpiochip_remove_pin_range();
> > |
> > |*that can be used for platforms that doesn't support DT.*
> > |
> > |For example I'd like to convert over some of my existing
> > |drivers that do not have DT support to do this thing instead
> > |of registering ranges from the pin controller...
> >
> > I think you must have come across similar issues with the
> > "gpio-reserved-ranges" property you recently added. Because
> > from what I can glimpse from the
> > "[2/3] dt-bindings: pinctrl: Add a ngpios-ranges property"
> > <https://patchwork.kernel.org/patch/10153785/> series.
> > The gpio-reserved-ranges property would also need to be added
> > to existing products (msm8996) as well, right?
> > ("I stuck this inside msm8996, but maybe it can go somewhere more generic?")
>
> The gpio-reserved-ranges only affects some SoCs. It should be added to
> the bindings on whatever chips are affected by those firmware quirks as
> optional properties. It would be great if you could add it to the ones
> that may need it. My guess is that it only matters for the pin
> controllers that spread out each pin into a big range of I/O memory
> because otherwise pins aren't locked away from non-secure systems.
(- see text the end - )
> >
> > > Furthermore, it looks like this becomes a silent requirement to add the
> > > gpio-ranges property into the DT so that hogs work, but none of the
> > > bindings have been updated in this patch to indicate that.
> > The pinctrl-msm.c driver will fallback to using gpiochip_add_pin_range(),
> > if the gpio-ranges property is not present. So all existing and compiled
> > devicetree binaries files will remain compatible.
>
> That's good.
> >
> > As for adding the gpio-ranges to the dt binding text files under
> > Documentation/devicetree/bindings/pinctrl/: Sure. No problem. I can add
> > them too :).
>
> Great!
>
> >
> > But I do have a question: Should I also include the missing declaration
> > of the gpio-reserved-ranges properties too? (I can make the patches over
> > the long weekend. If I hear nothing from anyone, I'll post them on Monday).
>
> Sure. Do you have the list of pinctrl devices that may need the
> gpio-reserved-ranges property?
>
Oh, let me clarify. My plan is to add the binding documentation text for
the (now) semi-required gpio-ranges property. And while I'm patching the
files in Documentation/devicetree/bindings/pinctrl/qcom-* I can also add
the new gpio-reserved-ranges as an optional property well. This way it is
in place for the future. (This is nothing fancy. As both properties are
part of the gpio.txt already).
As for the dtsi updates, I don't think I can add any sensible
gpio-reserved-ranges to the individual SoC's dts in
arch/arm(64)/boot/dts/qcom-*dtsi without the HW/SoC or the documentation
which ranges need to be reserved. Because unlike the gpio-ranges values
(which are easy to extract from the drivers in drivers/pinctrl/qcom/)
the gpio-reserved-ranges for each SoCs is not yet documented (or I can't
find it?).
Regards,
Christian
^ permalink raw reply
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-19 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518014538.duphof6enscpm5vp@vireshk-i7>
>From c5804e1d17578a63ca87cc8fd839bf756cfe3567 Mon Sep 17 00:00:00 2001
In-Reply-To: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
References: <1526555955-29960-11-git-send-email-ilialin@codeaurora.org>
From: Ilia Lin <ilialin@codeaurora.org>
Date: Thu, 17 May 2018 13:55:12 +0300
Subject: [PATCH] cpufreq: Add Kryo CPU scaling driver
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 164
+++++++++++++++++++++++++++++++++++
4 files changed, 178 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..ae2d1b9
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP
of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+#define SILVER_LEAD 0
+#define GOLD_LEAD 2
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id
*/
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct device *cpu_dev_silver, *cpu_dev_gold;
+ struct opp_table *opp_silver, *opp_gold;
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev_silver = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_silver))
+ return PTR_ERR(cpu_dev_silver);
+
+ cpu_dev_gold = get_cpu_device(SILVER_LEAD);
+ if (IS_ERR_OR_NULL(cpu_dev_gold))
+ return PTR_ERR(cpu_dev_gold);
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
+ if (IS_ERR_OR_NULL(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ opp_silver =
dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
+ if (IS_ERR(opp_silver)) {
+ dev_err(cpu_dev_silver, "Failed to set supported
hardware\n");
+ ret = PTR_ERR(opp_silver);
+ goto free_np;
+ }
+
+ opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
+ if (IS_ERR(opp_gold)) {
+ dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
+ ret = PTR_ERR(opp_gold);
+ goto free_opp_silver;
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR_OR_NULL(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev_silver, "Failed to register platform device\n");
+ dev_pm_opp_put_supported_hw(opp_gold);
+
+free_opp_silver:
+ dev_pm_opp_put_supported_hw(opp_silver);
+
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Friday, May 18, 2018 04:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: mturquette at baylibre.com; sboyd at kernel.org; robh at kernel.org;
> mark.rutland at arm.com; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; andy.gross at linaro.org; david.brown at linaro.org;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; rnayak at codeaurora.org;
> amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
>
> On 17-05-18, 14:19, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret = 0;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev_silver, *cpu_dev_gold;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct platform_device *pdev;
> > + struct opp_table *opp_silver = NULL;
> > + struct opp_table *opp_gold = NULL;
>
> No need to initialize them and you may want to arrange all above in
> decreasing order of their length.
>
> > +
> > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_silver))
> > + return PTR_ERR(cpu_dev_silver);
> > +
> > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_gold))
> > + return PTR_ERR(cpu_dev_gold);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
> ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > + nvmem_cell_put(speedbin_nvmem);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + opp_silver =
> dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_silver)) {
>
> This API doesn't return NULL and so IS_ERR() would be sufficient.
>
> > + dev_err(cpu_dev_silver, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_silver);
> > + goto free_np;
> > + }
> > +
> > + opp_gold =
> dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_gold)) {
>
> same here.
>
> > + dev_err(cpu_dev_gold, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_gold);
> > + goto free_opp_silver;
> > + }
> > +
> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > + if (!IS_ERR_OR_NULL(pdev))
> > + goto out;
>
> Simply return from here and remove the useless label out.
>
> > +
> > + ret = PTR_ERR(pdev);
> > + dev_err(cpu_dev_silver, "Failed to register platform device\n");
> > + dev_pm_opp_put_supported_hw(opp_gold);
> > +
> > +free_opp_silver:
> > + dev_pm_opp_put_supported_hw(opp_silver);
> > +
> > +free_np:
> > + of_node_put(np);
> > +
> > +out:
> > + return ret;
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>
> Please resend only this patch now or just paste the new code in a mail
here
> so that I can review it quickly and then you can resend the final version.
Most
> of the patches aren't changing anyway.
>
> --
> viresh
^ permalink raw reply related
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518014538.duphof6enscpm5vp@vireshk-i7>
Hi Viresh,
If I send patches in reply, it will produce new patches, instead of answers
in the thread. Please find below the file dump.
->cat drivers/cpufreq/qcom-cpufreq-kryo.c
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*/
/*
* In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
* the CPU frequency subset and voltage value of each OPP varies
* based on the silicon variant in use. Qualcomm Process Voltage Scaling
Tables
* defines the voltage and frequency value based on the msm-id in SMEM
* and speedbin blown in the efuse combination.
* The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
SoC
* to provide the OPP framework with required information.
* This is used to determine the voltage and frequency value for each OPP of
* operating-points-v2 table when it is parsed by the OPP framework.
*/
#include <linux/cpu.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/nvmem-consumer.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/slab.h>
#include <linux/soc/qcom/smem.h>
#define MSM_ID_SMEM 137
#define SILVER_LEAD 0
#define GOLD_LEAD 2
enum _msm_id {
MSM8996V3 = 0xF6ul,
APQ8096V3 = 0x123ul,
MSM8996SG = 0x131ul,
APQ8096SG = 0x138ul,
};
enum _msm8996_version {
MSM8996_V3,
MSM8996_SG,
NUM_OF_MSM8996_VERSIONS,
};
static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
{
size_t len;
u32 *msm_id;
enum _msm8996_version version;
msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
/* The first 4 bytes are format, next to them is the actual msm-id
*/
msm_id++;
switch ((enum _msm_id)*msm_id) {
case MSM8996V3:
case APQ8096V3:
version = MSM8996_V3;
break;
case MSM8996SG:
case APQ8096SG:
version = MSM8996_SG;
break;
default:
version = NUM_OF_MSM8996_VERSIONS;
}
return version;
}
static int __init qcom_cpufreq_kryo_driver_init(void)
{
struct device *cpu_dev_silver, *cpu_dev_gold;
struct opp_table *opp_silver, *opp_gold;
enum _msm8996_version msm8996_version;
struct nvmem_cell *speedbin_nvmem;
struct platform_device *pdev;
struct device_node *np;
u8 *speedbin;
u32 versions;
size_t len;
int ret;
cpu_dev_silver = get_cpu_device(SILVER_LEAD);
if (IS_ERR_OR_NULL(cpu_dev_silver))
return PTR_ERR(cpu_dev_silver);
cpu_dev_gold = get_cpu_device(SILVER_LEAD);
if (IS_ERR_OR_NULL(cpu_dev_gold))
return PTR_ERR(cpu_dev_gold);
msm8996_version = qcom_cpufreq_kryo_get_msm_id();
if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
return -ENODEV;
}
np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
if (IS_ERR_OR_NULL(np))
return PTR_ERR(np);
if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
ret = -ENOENT;
goto free_np;
}
speedbin_nvmem = of_nvmem_cell_get(np, NULL);
if (IS_ERR(speedbin_nvmem)) {
ret = PTR_ERR(speedbin_nvmem);
dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
ret);
goto free_np;
}
speedbin = nvmem_cell_read(speedbin_nvmem, &len);
nvmem_cell_put(speedbin_nvmem);
switch (msm8996_version) {
case MSM8996_V3:
versions = 1 << (unsigned int)(*speedbin);
break;
case MSM8996_SG:
versions = 1 << ((unsigned int)(*speedbin) + 4);
break;
default:
BUG();
break;
}
opp_silver =
dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
if (IS_ERR(opp_silver)) {
dev_err(cpu_dev_silver, "Failed to set supported
hardware\n");
ret = PTR_ERR(opp_silver);
goto free_np;
}
opp_gold = dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
if (IS_ERR(opp_gold)) {
dev_err(cpu_dev_gold, "Failed to set supported hardware\n");
ret = PTR_ERR(opp_gold);
goto free_opp_silver;
}
pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
if (!IS_ERR_OR_NULL(pdev))
return 0;
ret = PTR_ERR(pdev);
dev_err(cpu_dev_silver, "Failed to register platform device\n");
dev_pm_opp_put_supported_hw(opp_gold);
free_opp_silver:
dev_pm_opp_put_supported_hw(opp_silver);
free_np:
of_node_put(np);
return ret;
}
late_initcall(qcom_cpufreq_kryo_driver_init);
MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
MODULE_LICENSE("GPL v2");
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Friday, May 18, 2018 04:46
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: mturquette at baylibre.com; sboyd at kernel.org; robh at kernel.org;
> mark.rutland at arm.com; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; andy.gross at linaro.org; david.brown at linaro.org;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; rnayak at codeaurora.org;
> amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
>
> On 17-05-18, 14:19, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret = 0;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev_silver, *cpu_dev_gold;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct platform_device *pdev;
> > + struct opp_table *opp_silver = NULL;
> > + struct opp_table *opp_gold = NULL;
>
> No need to initialize them and you may want to arrange all above in
> decreasing order of their length.
>
> > +
> > + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_silver))
> > + return PTR_ERR(cpu_dev_silver);
> > +
> > + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev_gold))
> > + return PTR_ERR(cpu_dev_gold);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev_silver, "Could not get nvmem cell: %d\n",
> ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > + nvmem_cell_put(speedbin_nvmem);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + opp_silver =
> dev_pm_opp_set_supported_hw(cpu_dev_silver,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_silver)) {
>
> This API doesn't return NULL and so IS_ERR() would be sufficient.
>
> > + dev_err(cpu_dev_silver, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_silver);
> > + goto free_np;
> > + }
> > +
> > + opp_gold =
> dev_pm_opp_set_supported_hw(cpu_dev_gold,&versions,1);
> > + if (IS_ERR_OR_NULL(opp_gold)) {
>
> same here.
>
> > + dev_err(cpu_dev_gold, "Failed to set supported
> hardware\n");
> > + ret = PTR_ERR(opp_gold);
> > + goto free_opp_silver;
> > + }
> > +
> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> > + if (!IS_ERR_OR_NULL(pdev))
> > + goto out;
>
> Simply return from here and remove the useless label out.
>
> > +
> > + ret = PTR_ERR(pdev);
> > + dev_err(cpu_dev_silver, "Failed to register platform device\n");
> > + dev_pm_opp_put_supported_hw(opp_gold);
> > +
> > +free_opp_silver:
> > + dev_pm_opp_put_supported_hw(opp_silver);
> > +
> > +free_np:
> > + of_node_put(np);
> > +
> > +out:
> > + return ret;
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
>
> Please resend only this patch now or just paste the new code in a mail
here
> so that I can review it quickly and then you can resend the final version.
Most
> of the patches aren't changing anyway.
>
> --
> viresh
^ permalink raw reply
* [RESEND][PATCH] pwm: Set class for exported channels in sysfs
From: Stefan Wahren @ 2018-05-19 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1b6b62e-8fcb-bff0-b532-aa0879d301ed@st.com>
Hello Fabrice,
> Fabrice Gasnier <fabrice.gasnier@st.com> hat am 30. M?rz 2018 um 14:40 geschrieben:
>
>
> On 09/26/2017 01:59 PM, gohai at sukzessiv.net wrote:
> > Notifications for devices without bus or class set get dropped by
> > dev_uevent_filter. Adding the class to the exported child matches
> > what the gpio subsystem is doing.
> >
> > With this change exporting a channel triggers a udev event, which
> > gives userspace a chance to fixup permissions and makes it possible
> > for non-root users to make use of the pwm subsystem.
> >
> > Signed-off-by: Gottfried Haider <gottfried.haider@gmail.com>
> > CC: Thierry Reding <thierry.reding@gmail.com>
> > CC: H Hartley Sweeten <hsweeten@visionengravers.com>
> > CC: linux-pwm at vger.kernel.org
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-rpi-kernel at lists.infradead.org
> > ---
> > drivers/pwm/sysfs.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index a813239..83f2b0b 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
> > @@ -263,6 +263,7 @@ static int pwm_export_child(struct device *parent, struct pwm_device *pwm)
> > export->pwm = pwm;
> > mutex_init(&export->lock);
> >
> > + export->child.class = parent->class;
>
> Hi all,
>
> Sorry to raise this old mail thread. I just figured out this patch is
> causing *regression* on v4.16-rcs.
>
> This patch has side effect at my end, with multiple pwm chip. It creates
> a new entry in '/sys/class/pwm' every time a 'pwmX' is exported:
> - echo X > export
>
> This breaks pwm on platforms that have multiple pwmchip:
> - 1st time export will create a /sys/class/pwm/pwmX
> - when another export happens on another pwmchip, it can't be created
> (e.g. -EEXIST)
>
> I looked at /Documentation/ABI/testing/sysfs-class-pwm:
> - pmwX should be there: /sys/class/pwm/pwmchipN/pwmX (only ?)
>
> With this patch:
> - pwmX symlink is created in addition, directly under /sys/class/pwm
>
> Example on stm32 (stm32429i-eval) platform:
> ---
> $ ls /sys/class/pwm
> pwmchip0 pwmchip4
>
> $ cd /sys/class/pwm/pwmchip0/
> $ echo 0 > export
>
> $ ls /sys/class/pwm
> pwm0 pwmchip0 pwmchip4
>
> $ cd /sys/class/pwm/pwmchip4/
> $ echo 0 > export
>
> sysfs: cannot create duplicate filename '/class/pwm/pwm0'
> CPU: 0 PID: 50 Comm: sh Not tainted 4.16.0-rc7-00020-g3361545 #1682
> Hardware name: STM32 (Device Tree Support)
> [<0000c0f1>] (unwind_backtrace) from [<0000b23b>] (show_stack+0xb/0xc)
> [<0000b23b>] (show_stack) from [<0008d2f1>] (sysfs_warn_dup+0x31/0x48)
> [<0008d2f1>] (sysfs_warn_dup) from [<0008d4a5>]
> (sysfs_do_create_link_sd+0x75/0x88)
> [<0008d4a5>] (sysfs_do_create_link_sd) from [<000e8e91>]
> (device_add+0x111/0x374)
> [<000e8e91>] (device_add) from [<000ca795>] (export_store+0xb5/0x12c)
> [<000ca795>] (export_store) from [<0008c899>] (kernfs_fop_write+0x87/0xda)
> [<0008c899>] (kernfs_fop_write) from [<0005a0a5>] (__vfs_write+0x1d/0xcc)
> [<0005a0a5>] (__vfs_write) from [<0005a1c7>] (vfs_write+0x4f/0x7c)
> [<0005a1c7>] (vfs_write) from [<0005a29b>] (SyS_write+0x33/0x70)
> [<0005a29b>] (SyS_write) from [<00009001>] (ret_fast_syscall+0x1/0x58)
> Exception stack...
> -sh: write error: File exists
>
> Not sure what the best fix would be thought :-(
>
> probably pwmX should be named also according with pwmchipN ?
> - dev_set_name(&export->child, "pwm%u", pwm->hwpwm);
> + dev_set_name(&export->child, "pwmchip%d-pwm%u", chip->base, pwm->hwpwm);
> BUT I think this would break existing ABI...
>
> Also this is quite late in the cycle. Maybe a revert would be wise for now ?
sorry i didn't noticed your mail before. Could you please prepare a revert patch?
Thanks
Stefan
^ permalink raw reply
* [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver
From: Russell King - ARM Linux @ 2018-05-19 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <018701d3ef61$dfd5e700$9f81b500$@codeaurora.org>
On Sat, May 19, 2018 at 02:09:24PM +0300, ilialin at codeaurora.org wrote:
> +static int __init qcom_cpufreq_kryo_driver_init(void)
> +{
> + struct device *cpu_dev_silver, *cpu_dev_gold;
> + struct opp_table *opp_silver, *opp_gold;
> + enum _msm8996_version msm8996_version;
> + struct nvmem_cell *speedbin_nvmem;
> + struct platform_device *pdev;
> + struct device_node *np;
> + u8 *speedbin;
> + u32 versions;
> + size_t len;
> + int ret;
> +
> + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev_silver))
> + return PTR_ERR(cpu_dev_silver);
> +
> + cpu_dev_gold = get_cpu_device(SILVER_LEAD);
> + if (IS_ERR_OR_NULL(cpu_dev_gold))
> + return PTR_ERR(cpu_dev_gold);
> +
> + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> + dev_err(cpu_dev_silver, "Not Snapdragon 820/821!");
> + return -ENODEV;
> + }
> +
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev_silver);
> + if (IS_ERR_OR_NULL(np))
> + return PTR_ERR(np);
This function (qcom_cpufreq_kryo_driver_init) returns zero on success.
You are checking "np" here for being an error pointer, or NULL.
What value do you think PTR_ERR() returns in the case of PTR_ERR(NULL)?
IS_ERR_OR_NULL() is considered by some (me included) as being _very_
harmful because programmers generally fail to look at linux/err.h and
consider what it means when used as above.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-19 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AexXNEGVoXa9K_GAm+aFLNRQOXOhF_SdKAjV1qmuD2nA@mail.gmail.com>
Hi Fabio,
Thanks for your feedback.
> Hi Lukasz,
>
> On Wed, May 9, 2018 at 12:34 PM, Lukasz Majewski <lukma@denx.de>
> wrote:
>
> > +&iomuxc {
> > + imx53-kp-ddc {
>
> No need for keeping this imx53-kp-ddc.
>
> > diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts
> > b/arch/arm/boot/dts/imx53-kp-hsc.dts new file mode 100644
> > index 000000000000..fff358395c9d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
> > @@ -0,0 +1,53 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "imx53-kp.dtsi"
> > +
> > +/ {
> > + model = "K+P imx53 HSC";
> > + compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
> > +
>
> No need for this blank line.
>
> > +};
> > +
> > +&fec {
> > + status = "okay";
>
> We usually put the status in the last line.
After moving status property to the end:
Error: arch/arm/boot/dts/imx53-kp-hsc.dts:21.2-18 Properties must
precede subnodes FATAL ERROR: Unable to parse input tree
So I opt for leaving it as it was.
>
> > + gpio_buttons {
> > + compatible = "gpio-keys";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpiobuttons>;
> > +
> > + button at 1 {
>
> You pass @1 without a reg property. This triggers a warning when
> building with W=1.
>
> You could remove the @1.
>
> Please make sure this patch does not introduce any W=1 dtc warning.
>
> > +&iomuxc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_kp_common>;
> > +
> > + imx53-kp-common {
>
> No need for this imx53-kp-common
After removing imx53-kp-ddc and imx53-kp-common iomux subnodes I do see
following errors in the dmesg (v4.17-rc5):
imx53-pinctrl 53fa8000.iomuxc: function 'iomuxc' not supported
imx53-pinctrl 53fa8000.iomuxc: invalid function iomuxc in map table
Above statements are not visible when I use the v1 code of this patch.
>
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > +
>
> No need for this blank line.
I will sent fixed version in v2.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180519/1f5a7146/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-05-19 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509153428.1440-1-lukma@denx.de>
This commit provides support for HSC and DDC boards from
Kieback&Peter GmbH vendor.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Remove not needed #address-cells and #size-cells in
the gpio_buttons node to pass make W=1
- Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
- Include #include <dt-bindings/input/input.h> to use KEY_F6|F7 directly
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx53-kp-ddc.dts | 146 ++++++++++++++++++++++++++++
arch/arm/boot/dts/imx53-kp-hsc.dts | 51 ++++++++++
arch/arm/boot/dts/imx53-kp.dtsi | 190 +++++++++++++++++++++++++++++++++++++
4 files changed, 389 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fbc04b0db781..00854a5b6ac4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
imx53-cx9020.dtb \
+ imx53-kp-ddc.dtb \
+ imx53-kp-hsc.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-ppd.dtb \
diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts b/arch/arm/boot/dts/imx53-kp-ddc.dts
new file mode 100644
index 000000000000..acaf477a52c5
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 DDC";
+ compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
+
+ backlight_lcd: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 50000>;
+ power-supply = <®_backlight>;
+ brightness-levels = <0 24 28 32 36
+ 40 44 48 52 56
+ 60 64 68 72 76
+ 80 84 88 92 96 100>;
+ default-brightness-level = <20>;
+ };
+
+ lcd_display: disp1 {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_disp>;
+
+ port at 0 {
+ reg = <0>;
+
+ display1_in: endpoint {
+ remote-endpoint = <&ipu_di1_disp1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight-supply";
+ regulator-min-microvolt = <15000000>;
+ regulator-max-microvolt = <15000000>;
+ regulator-always-on;
+ };
+};
+
+&i2c3 {
+ adc at 48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel at 4 {
+ reg = <4>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+
+ channel at 6 {
+ reg = <6>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+ };
+
+ gpio_expander2 at 21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&iomuxc {
+ imx53-kp-ddc {
+ pinctrl_disp: dispgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
+ MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
+ MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
+ MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
+ MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
+ MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
+ MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
+ MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
+ MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
+ MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
+ MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
+ MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
+ MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
+ MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
+ MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
+ MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
+ MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
+ MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
+ MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
+ MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
+ MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
+ MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
+ MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
+ MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
+ MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
+ MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
+ MX53_PAD_GPIO_1__PWM2_PWMO 0x4
+ >;
+ };
+ };
+};
+
+&ipu_di1_disp1 {
+ remote-endpoint = <&display1_in>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&pmic {
+ fsl,mc13xxx-uses-touch;
+};
diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts b/arch/arm/boot/dts/imx53-kp-hsc.dts
new file mode 100644
index 000000000000..d68cdd5da819
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 HSC";
+ compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
+};
+
+&fec {
+ status = "okay";
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ switch: switch at a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <400>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec>;
+ };
+
+ port at 1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx53-kp.dtsi b/arch/arm/boot/dts/imx53-kp.dtsi
new file mode 100644
index 000000000000..f87266843842
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp.dtsi
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-tqma53.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ buzzer {
+ compatible = "pwm-beeper";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_buzzer>;
+
+ pwms = <&pwm1 0 500000>;
+ };
+
+ gpio_buttons {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiobuttons>;
+
+ button_kalt {
+ label = "Kaltstart";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ button_pwr {
+ label = "PowerFailInterrupt";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led_bus {
+ label = "bus";
+ gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_error {
+ label = "error";
+ gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led_flash {
+ label = "flash";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ gpio_expander1 at 22 {
+ compatible = "nxp,pcf8574";
+ reg = <0x22>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ rtc at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_kp_common>;
+
+ imx53-kp-common {
+ pinctrl_buzzer: buzzergrp {
+ fsl,pins = <
+ MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
+ >;
+ };
+
+ pinctrl_gpiobuttons: gpiobuttonsgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_RW__GPIO2_26 0x1e4
+ MX53_PAD_EIM_D22__GPIO3_22 0x1e4
+ >;
+ };
+
+ pinctrl_kp_common: kpcommongrp {
+ fsl,pins = <
+ MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
+ MX53_PAD_GPIO_19__GPIO4_5 0x1e4
+ MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
+ MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
+ MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
+ MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
+ MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
+ MX53_PAD_EIM_D17__GPIO3_17 0x1e4
+ MX53_PAD_EIM_D18__GPIO3_18 0x1e4
+ MX53_PAD_EIM_D21__GPIO3_21 0x1e4
+ MX53_PAD_EIM_D29__GPIO3_29 0x1e4
+ MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
+ MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
+ MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
+ MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
+ MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
+ MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
+ >;
+ };
+
+ pinctrl_leds: ledgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
+ MX53_PAD_EIM_D28__GPIO3_28 0x1d4
+ MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 0x1e4
+ MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 0x1e4
+ >;
+ };
+ };
+};
+
+&pinctrl_uart1 {
+ fsl,pins = <
+ MX53_PAD_EIM_D23__GPIO3_23 0x1e4
+ MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
+ MX53_PAD_EIM_D24__GPIO3_24 0x1e4
+ MX53_PAD_EIM_D25__GPIO3_25 0x1e4
+ MX53_PAD_EIM_D19__GPIO3_19 0x1e4
+ MX53_PAD_EIM_D20__GPIO3_20 0x1e4
+ >;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "disabled";
+};
--
2.11.0
^ 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