* Re: [PATCH V1 3/4] qcom: spmi-wled: Add support for OVP interrupt handling
From: kgunda @ 2017-12-11 9:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, Lee Jones, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <20171205044523.GF28761@minitux>
On 2017-12-05 10:15, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
>> WLED peripheral has over voltage protection(OVP) circuitry and the OVP
>> fault is notified through an interrupt. Though this fault condition
>> rising
>> is due to an incorrect hardware configuration is mitigated in the
>> hardware,
>> it still needs to be detected and handled. Add support for it.
>>
>> When WLED module is enabled, keep OVP fault interrupt disabled for 10
>> ms to
>> account for soft start delay.
>>
>> Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
>> ---
>> .../bindings/leds/backlight/qcom-spmi-wled.txt | 7 +-
>> drivers/video/backlight/qcom-spmi-wled.c | 83
>> ++++++++++++++++++++++
>> 2 files changed, 87 insertions(+), 3 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> index 768608c..d39ee93 100644
>> ---
>> a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> +++
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> @@ -92,7 +92,7 @@ The PMIC is connected to the host processor via SPMI
>> bus.
>> Usage: optional
>> Value type: <string>
>> Definition: Interrupt names associated with the interrupts.
>> - Must be "sc-irq".
>> + Currently supported interrupts are "sc-irq" and "ovp-irq".
>>
>
> As before, we know this is an IRQ, so omit the -irq from the name.
>
> [..]
Sure. Will change it in the next series.
>> diff --git a/drivers/video/backlight/qcom-spmi-wled.c
>> b/drivers/video/backlight/qcom-spmi-wled.c
> [..]
>> @@ -115,6 +123,28 @@ static int qcom_wled_module_enable(struct
>> qcom_wled *wled, int val)
>> rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
>> QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
>> val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
>> + if (rc < 0)
>> + return rc;
>> + /*
>> + * Wait for at least 10ms before enabling OVP fault interrupt after
>> + * enabling the module so that soft start is completed. Keep the OVP
>> + * interrupt disabled when the module is disabled.
>> + */
>> + if (val) {
>> + usleep_range(QCOM_WLED_SOFT_START_DLY_US,
>> + QCOM_WLED_SOFT_START_DLY_US + 1000);
>
> This is sleeping in the brightness/enable code path, can you
> schedule_delayed_work() instead to not block this code path
> unnecessarily?
>
Sure. Will change it in the next series.
>> +
>> + if (wled->cfg.ovp_irq > 0 && wled->ovp_irq_disabled) {
>> + enable_irq(wled->cfg.ovp_irq);
>> + wled->ovp_irq_disabled = false;
>> + }
>> + } else {
>> + if (wled->cfg.ovp_irq > 0 && !wled->ovp_irq_disabled) {
>> + disable_irq(wled->cfg.ovp_irq);
>> + wled->ovp_irq_disabled = true;
>> + }
>> + }
>> +
>> return rc;
>> }
>>
>> @@ -264,12 +294,42 @@ static irqreturn_t qcom_wled_sc_irq_handler(int
>> irq, void *_wled)
>> return IRQ_HANDLED;
>> }
>>
>> +static irqreturn_t qcom_wled_ovp_irq_handler(int irq, void *_wled)
>> +{
>> + struct qcom_wled *wled = _wled;
>> + int rc;
>> + u32 int_sts, fault_sts;
>> +
>> + rc = regmap_read(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_INT_RT_STS, &int_sts);
>> + if (rc < 0) {
>> + pr_err("Error in reading WLED_INT_RT_STS rc=%d\n", rc);
>> + return IRQ_HANDLED;
>> + }
>> +
>> + rc = regmap_read(wled->regmap, wled->ctrl_addr +
>> + QCOM_WLED_CTRL_FAULT_STATUS, &fault_sts);
>> + if (rc < 0) {
>> + pr_err("Error in reading WLED_FAULT_STATUS rc=%d\n", rc);
>> + return IRQ_HANDLED;
>> + }
>> +
>> + if (fault_sts &
>> + (QCOM_WLED_CTRL_OVP_FAULT_BIT | QCOM_WLED_CTRL_ILIM_FAULT_BIT))
>> + pr_err("WLED OVP fault detected, int_sts=%x fault_sts= %x\n",
>> + int_sts, fault_sts);
>
> All this function does is print things to the log. When is this
> information consumed and by whom? dev_dbg() instead?
>
Sure. Will change it in the next series.
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> static int qcom_wled_setup(struct qcom_wled *wled)
>> {
>> int rc, temp, i;
>> u8 sink_en = 0;
>> + u32 val;
>> u8 string_cfg = wled->cfg.string_cfg;
>> int sc_irq = wled->cfg.sc_irq;
>> + int ovp_irq = wled->cfg.ovp_irq;
>>
>> rc = regmap_update_bits(wled->regmap,
>> wled->ctrl_addr + QCOM_WLED_CTRL_OVP,
>> @@ -367,6 +427,25 @@ static int qcom_wled_setup(struct qcom_wled
>> *wled)
>> }
>> }
>>
>> + if (ovp_irq >= 0) {
>
> As with the previous patch.
>
> [..]
Sure. Will change it in the next series.
>> @@ -539,6 +618,10 @@ static int qcom_wled_configure(struct qcom_wled
>> *wled, struct device *dev)
> [..]
>> + wled->cfg.ovp_irq = platform_get_irq_byname(wled->pdev, "ovp-irq");
>> + if (wled->cfg.ovp_irq < 0)
>> + dev_dbg(&wled->pdev->dev, "ovp irq is not used\n");
>> +
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Rasmus Villemoes @ 2017-12-11 9:30 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper, Rob Herring,
Mark Rutland
Cc: Alexander Stein, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <da843420-cede-e787-838d-1fd48e3ca7dd-5wv7dgnIgG8@public.gmane.org>
On 2017-12-08 17:02, Marc Zyngier wrote:
>> +
>> +#define INTPCR_REG 0x01ac
>> +#define NIRQ 6
>
> These should come from the DT, specially if as suggested above, there
> are other similar HW in the wild.
OK, but see below.
>> +static int
>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type)
>> +{
>> + irq_hw_number_t hwirq = data->hwirq;
>> + struct extirq_chip_data *chip_data = data->chip_data;
>> + u32 value, mask;
>> + int ret;
>> +
>> + mask = 1U << (31 - hwirq);
>> + if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
>> + if (type == IRQ_TYPE_LEVEL_LOW)
>> + type = IRQ_TYPE_LEVEL_HIGH;
>> + else
>> + type = IRQ_TYPE_EDGE_RISING;
>> + value = mask;
>> + } else {
>> + value = 0;
>> + }
>> +
>> + /* Don't do the INTPCR_REG update if the parent irq_set_type will EINVAL. */
>> + if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
>> + return -EINVAL;
>
> How about starting by rejecting the values that you cannot handle (which
> seems to only be IRQ_TYPE_EDGE_BOTH)? Actually, if you wrote the whole
> thing as a swtch/case, it'd be a lot more readable.
OK, will try that.
>> +
>> + /* regmap does internal locking, but do we need to provide our
>> + * own across the parent irq_set_type call? */
>
> Comment format.
[Somewhat deliberate, I never meant for that comment to stay in a final
version. It's gone once I figure out the answer.]
>> + regmap_update_bits(chip_data->syscon, INTPCR_REG, mask, value);
>> +
>> + data = data->parent_data;
>> + ret = data->chip->irq_set_type(data, type);
>
> Restore the previous regmap configuration on failure?
Not sure what one would get from that?
> Also, given that
> you end-up changing the interrupt polarity in a non-atomic way (you have
> two independent irqchips), it'd feel safer if you'd use
> IRQCHIP_SET_TYPE_MASKED.
Ah, yes, makes sense. Will do.
>> +
>> + return ret;
>> +}
>> +
>> +static struct irq_chip extirq_chip = {
>> + .name = "LS1021A_EXTIRQ",
>
> Care to make this shorter?
Sure, I'll just call it extirq.
>> +static int
>> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>> + unsigned int nr_irqs, void *arg)
>> +{
>> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169};
>
> This should really come from your DT.
>
>> + int i;
>> + irq_hw_number_t hwirq;
>> + struct irq_fwspec *fwspec = arg;
>> + struct irq_fwspec gic_fwspec;
>> +
>> + if (fwspec->param_count != 3)
>> + return -EINVAL;
>> +
>> + if (fwspec->param[0])
>> + return -EINVAL;
>> +
>> + hwirq = fwspec->param[1];
>> + for (i = 0; i < nr_irqs; i++)
>
> This loop is pointless, as nr_irqs can only be >1 in the multi-MSI case.
OK, thanks.
>> +static int __init
>> +ls1021a_extirq_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +
>> + struct irq_domain *domain, *domain_parent;
>> + struct extirq_chip_data *chip_data;
>> + int ret;
>> +
>> + domain_parent = irq_find_host(parent);
>> + if (!domain_parent) {
>> + pr_err("interrupt-parent not found\n");
>> + return -EINVAL;
>> + }
>> +
>> + chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
>> + if (!chip_data)
>> + return -ENOMEM;
>> +
>> + chip_data->syscon = syscon_regmap_lookup_by_phandle(node, "syscon");
>> + if (IS_ERR(chip_data->syscon)) {
>> + ret = PTR_ERR(chip_data->syscon);
>> + goto out_free_chip;
>> + }
>> +
>> + domain = irq_domain_add_hierarchy(domain_parent, 0, NIRQ, node,
>> + &extirq_domain_ops, chip_data);
>> + if (!domain) {
>> + ret = -ENOMEM;
>> + goto out_free_chip;
>> + }
>> +
>> + return 0;
>> +
>> +out_free_chip:
>> + kfree(chip_data);
>> + return ret;
>> +}
>> +
>> +IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq", ls1021a_extirq_of_init);
>>
>
> Overall, it is a bit annoying that you just copied the driver altogether
> instead of trying to allow the common stuff to be shared between
> drivers. Most of this is just boilerplate code...
Yes, it did annoy me as well. However, the real meat of this is which
bits of which register to poke to support a negative polarity irq, and
there doesn't seem to be a good way to express that in DT. The register
offset and the mapping from external irq# to the GIC one is reasonably
easy (and would thus get rid of my NIRQ and INTPCR macros), but
describing the mapping from IRQ# to the bit that needs to be set (or
cleared) seems much harder. I cannot generalize from one example, so
lacking documentation for any other Layerscape SOC, whatever I might
come up with might not actually be useful for other hardware, making it
rather pointless. But if you have any suggestions for how the DT
bindings might look, I'm all ears.
Thanks a lot for your feedback!
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V1 2/4] qcom: spmi-wled: Add support for short circuit handling
From: kgunda @ 2017-12-11 9:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, Lee Jones, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <20171205043515.GE28761@minitux>
On 2017-12-05 10:05, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
>> Handle the short circuit(SC) interrupt and check if the SC interrupt
>> is valid. Re-enable the module to check if it goes away. Disable the
>> module altogether if the SC event persists.
>>
>> Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
>> ---
>> .../bindings/leds/backlight/qcom-spmi-wled.txt | 22 ++++
>> drivers/video/backlight/qcom-spmi-wled.c | 126
>> ++++++++++++++++++++-
>> 2 files changed, 142 insertions(+), 6 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> index f1ea25b..768608c 100644
>> ---
>> a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> +++
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> @@ -74,6 +74,26 @@ The PMIC is connected to the host processor via
>> SPMI bus.
>> Definition: Specify if cabc (content adaptive backlight control) is
>> needed.
>>
>> +- qcom,ext-pfet-sc-pro-en
>
> Please use readable names, rather than a bunch of abbreviations.
>
Ok. Will address it in next series.
>> + Usage: optional
>> + Value type: <bool>
>> + Definition: Specify if external PFET control for short circuit
>> + protection is needed.
>
> What does this mean? At least change the wording to "...protection is
> used".
>
Ok. Will address it in next series.
>> +
>> +- interrupts
>> + Usage: optional
>> + Value type: <prop encoded array>
>> + Definition: Interrupts associated with WLED. Interrupts can be
>> + specified as per the encoding listed under
>> + Documentation/devicetree/bindings/spmi/
>> + qcom,spmi-pmic-arb.txt.
>> +
>> +- interrupt-names
>> + Usage: optional
>> + Value type: <string>
>> + Definition: Interrupt names associated with the interrupts.
>> + Must be "sc-irq".
>
> This is obviously an irq, so no need to include that in the name. I
> would also prefer if you use the name "short" to make this easier to
> read.
>
Ok. Will address it in next series.
>> +
>> Example:
>>
>> qcom-wled@d800 {
>> @@ -82,6 +102,8 @@ qcom-wled@d800 {
>> reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
>> label = "backlight";
>>
>> + interrupts = <0x3 0xd8 0x2 IRQ_TYPE_EDGE_RISING>;
>
> We tend to write these on the form <decimal, hex, decimal, enum>,
> please
> follow this.
>
Ok. Will address it in next series.
>> + interrupt-names = "sc-irq";
>> qcom,fs-current-limit = <25000>;
>> qcom,current-boost-limit = <970>;
>> qcom,switching-freq = <800>;
>> diff --git a/drivers/video/backlight/qcom-spmi-wled.c
>> b/drivers/video/backlight/qcom-spmi-wled.c
>> index 14c3adc..7dbaaa7 100644
>> --- a/drivers/video/backlight/qcom-spmi-wled.c
>> +++ b/drivers/video/backlight/qcom-spmi-wled.c
>> @@ -11,6 +11,9 @@
>> * GNU General Public License for more details.
>> */
>>
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/ktime.h>
>> #include <linux/kernel.h>
>> #include <linux/backlight.h>
>> #include <linux/module.h>
>> @@ -23,7 +26,13 @@
>> #define QCOM_WLED_DEFAULT_BRIGHTNESS 2048
>> #define QCOM_WLED_MAX_BRIGHTNESS 4095
>>
>> +#define QCOM_WLED_SC_DLY_MS 20
>> +#define QCOM_WLED_SC_CNT_MAX 5
>> +#define QCOM_WLED_SC_RESET_CNT_DLY_US 1000000
>
> With times of this ballpark you can just use jiffies, with this just
> being HZ.
>
Ok. Will address it in next series.
>> +
>> /* WLED control registers */
>> +#define QCOM_WLED_CTRL_FAULT_STATUS 0x08
>> +
>> #define QCOM_WLED_CTRL_MOD_ENABLE 0x46
>> #define QCOM_WLED_CTRL_MOD_EN_MASK BIT(7)
>> #define QCOM_WLED_CTRL_MODULE_EN_SHIFT 7
>> @@ -37,6 +46,15 @@
>> #define QCOM_WLED_CTRL_ILIM 0x4e
>> #define QCOM_WLED_CTRL_ILIM_MASK GENMASK(2, 0)
>>
>> +#define QCOM_WLED_CTRL_SHORT_PROTECT 0x5e
>> +#define QCOM_WLED_CTRL_SHORT_EN_MASK BIT(7)
>> +
>> +#define QCOM_WLED_CTRL_SEC_ACCESS 0xd0
>> +#define QCOM_WLED_CTRL_SEC_UNLOCK 0xa5
>> +
>> +#define QCOM_WLED_CTRL_TEST1 0xe2
>> +#define QCOM_WLED_EXT_FET_DTEST2 0x09
>> +
>> /* WLED sink registers */
>> #define QCOM_WLED_SINK_CURR_SINK_EN 0x46
>> #define QCOM_WLED_SINK_CURR_SINK_MASK GENMASK(7, 4)
>> @@ -71,19 +89,23 @@ struct qcom_wled_config {
>> u32 switch_freq;
>> u32 fs_current;
>> u32 string_cfg;
>> + int sc_irq;
>
> Keep data parsed directly from DT in the config and move this to
> qcom_wled.
>
Ok. Will address it in next series.
>> bool en_cabc;
>> + bool ext_pfet_sc_pro_en;
>
> This name is long and hard to parse. "external_pfet" would be much
> easier to read.
>
Ok. Will address it in next series.
>> };
>>
>> struct qcom_wled {
>> const char *name;
>> struct platform_device *pdev;
>> struct regmap *regmap;
>> + struct mutex lock;
>> + struct qcom_wled_config cfg;
>> + ktime_t last_sc_event_time;
>> u16 sink_addr;
>> u16 ctrl_addr;
>> u32 brightness;
>> + u32 sc_count;
>> bool prev_state;
>> -
>> - struct qcom_wled_config cfg;
>
> Moving this seems unnecessary.
>
Ok. Will address it in next series.
>> };
>>
>> static int qcom_wled_module_enable(struct qcom_wled *wled, int val)
>> @@ -157,25 +179,26 @@ static int qcom_wled_update_status(struct
>> backlight_device *bl)
>> bl->props.state & BL_CORE_FBBLANK)
>> brightness = 0;
>>
>> + mutex_lock(&wled->lock);
>
> Is this lock necessary?
>
Yes. It avoid the race between the upate_status and sc_irq as the module
is enabled
at one place and disabled at other place respectively.
>> +static irqreturn_t qcom_wled_sc_irq_handler(int irq, void *_wled)
>> +{
>> + struct qcom_wled *wled = _wled;
>> + int rc;
>> + u32 val;
>> + s64 elapsed_time;
>> +
>> + rc = regmap_read(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_FAULT_STATUS, &val);
>> + if (rc < 0) {
>> + pr_err("Error in reading WLED_FAULT_STATUS rc=%d\n", rc);
>> + return IRQ_HANDLED;
>> + }
>> +
>> + wled->sc_count++;
>> + pr_err("WLED short circuit detected %d times fault_status=%x\n",
>> + wled->sc_count, val);
>
> Who will read this and is it worth the extra read of FAULT_STATUS just
> to produce this print?
>
As this SC irq gets triggered in very rare conditions, i think it is
okay
to have a print for the information purpose.
>> + mutex_lock(&wled->lock);
>> + rc = qcom_wled_module_enable(wled, false);
>> + if (rc < 0) {
>> + pr_err("wled disable failed rc:%d\n", rc);
>> + goto unlock_mutex;
>> + }
>> +
>> + elapsed_time = ktime_us_delta(ktime_get(),
>> + wled->last_sc_event_time);
>> + if (elapsed_time > QCOM_WLED_SC_RESET_CNT_DLY_US) {
>> + wled->sc_count = 0;
>> + } else if (wled->sc_count > QCOM_WLED_SC_CNT_MAX) {
>
> This isn't really "else elapsed_time was more than DLY_US". Split this
> into:
>
> if (elapsed_time > xyz)
> wled->sc_count = 0;
>
> if (wled->sc_count > QCOM_WLED_SC_CNT_MAX)
> ...
>
Ok. sure.
>> + pr_err("SC trigged %d times, disabling WLED forever!\n",
>
> "forever" as in "until someone turns it on again"?
>
Yes. It is turned on for the next reboot or some one forcefully enables
it form the
sysfs.
>> + wled->sc_count);
>> + goto unlock_mutex;
>> + }
>> +
>> + wled->last_sc_event_time = ktime_get();
>> +
>> + msleep(QCOM_WLED_SC_DLY_MS);
>> + rc = qcom_wled_module_enable(wled, true);
>> + if (rc < 0)
>> + pr_err("wled enable failed rc:%d\n", rc);
>> +
>> +unlock_mutex:
>> + mutex_unlock(&wled->lock);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> static int qcom_wled_setup(struct qcom_wled *wled)
>> {
>> int rc, temp, i;
>> u8 sink_en = 0;
>> u8 string_cfg = wled->cfg.string_cfg;
>> + int sc_irq = wled->cfg.sc_irq;
>>
>> rc = regmap_update_bits(wled->regmap,
>> wled->ctrl_addr + QCOM_WLED_CTRL_OVP,
>> @@ -261,6 +334,39 @@ static int qcom_wled_setup(struct qcom_wled
>> *wled)
>> return rc;
>> }
>>
>> + if (sc_irq >= 0) {
>
> I think things will be cleaner if you let qcom_wled_setup() configure
> the hardware based on the wled->cfg (as is done to this point) and then
> deal with the interrupts in a separate code path from the probe
> function.
>
Ok. sure.
>> + rc = devm_request_threaded_irq(&wled->pdev->dev, sc_irq,
>> + NULL, qcom_wled_sc_irq_handler, IRQF_ONESHOT,
>> + "qcom_wled_sc_irq", wled);
>> + if (rc < 0) {
>> + pr_err("Unable to request sc(%d) IRQ(err:%d)\n",
>> + sc_irq, rc);
>
> sc_irq is just a number without meaning, no need to print it.
>
Sure. Will remove it.
>> + return rc;
>> + }
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_SHORT_PROTECT,
>> + QCOM_WLED_CTRL_SHORT_EN_MASK,
>> + QCOM_WLED_CTRL_SHORT_EN_MASK);
>> + if (rc < 0)
>> + return rc;
>> +
>> + if (wled->cfg.ext_pfet_sc_pro_en) {
>> + /* unlock the secure access regisetr */
>
> Spelling of register, and this operation does "Unlock the secure
> register access" it doesn't unlock the secure access register.
>
Sure. Will correct it.
>> + rc = regmap_write(wled->regmap, wled->ctrl_addr +
>> + QCOM_WLED_CTRL_SEC_ACCESS,
>> + QCOM_WLED_CTRL_SEC_UNLOCK);
>> + if (rc < 0)
>> + return rc;
>> +
>> + rc = regmap_write(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_TEST1,
>> + QCOM_WLED_EXT_FET_DTEST2);
>
> What is the relationship between DTEST2 and the external FET?
> External FET is controlled through the DTEST2 register. External FET is
> not part of the
WLED IP so it is controlled from the DTEST pins.
>> + if (rc < 0)
>> + return rc;
>> + }
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -271,6 +377,7 @@ static int qcom_wled_setup(struct qcom_wled *wled)
>> .switch_freq = 11,
>> .string_cfg = 0xf,
>> .en_cabc = 0,
>> + .ext_pfet_sc_pro_en = 1,
>> };
>>
>> struct qcom_wled_var_cfg {
>> @@ -376,6 +483,7 @@ static int qcom_wled_configure(struct qcom_wled
>> *wled, struct device *dev)
>> bool *val_ptr;
>> } bool_opts[] = {
>> { "qcom,en-cabc", &cfg->en_cabc, },
>> + { "qcom,ext-pfet-sc-pro", &cfg->ext_pfet_sc_pro_en, },
>> };
>>
>> prop_addr = of_get_address(dev->of_node, 0, NULL, NULL);
>> @@ -427,6 +535,10 @@ static int qcom_wled_configure(struct qcom_wled
>> *wled, struct device *dev)
>> *bool_opts[i].val_ptr = true;
>> }
>>
>> + wled->cfg.sc_irq = platform_get_irq_byname(wled->pdev, "sc-irq");
>> + if (wled->cfg.sc_irq < 0)
>> + dev_dbg(&wled->pdev->dev, "sc irq is not used\n");
>> +
>
> Move this to qcom_wled_probe() or into its own code path, together with
> the rest of the sc_irq initialization.
>
> And as you're not enabling or disabling it you can store it in a local
> variable.
>
Ok. Sure.
>> return 0;
>> }
>>
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH v6 4/6] clk: meson: make the spinlock naming more specific
From: Jerome Brunet @ 2017-12-11 9:26 UTC (permalink / raw)
To: Yixun Lan, Neil Armstrong, Kevin Hilman
Cc: Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Carlo Caione, Qiufang Dai, Jian Hu,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171211064853.32111-5-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On Mon, 2017-12-11 at 14:48 +0800, Yixun Lan wrote:
> Make the spinlock more specific, so better for lockdep
> debugging and ctags/grep.
>
> Suggested-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Yixun,
This change is not related to the main task describe in the cover letter.
Next time, please send it after your series, or before as a dependency to avoid
mixing topics
Thanks
Jerome
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
From: Katsuhiro Suzuki @ 2017-12-11 9:21 UTC (permalink / raw)
To: 'Mark Brown'
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
Yamada, Masahiro/山田 真弘,
Masami Hiramatsu, Jassi Brar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171206125817.GF1827@finisterre>
Hello,
> One example is how all the drivers that use the generic dmaengine code
> instantiate their DMA drivers, or how all the drivers for CODECs that
> have both I2C and SPIi control interfaces instantiate - given that the
> device specific code here seems to be mostly data tables that's probably
> the closest thing.
Thank you. I'm checking the ALSA drivers of other companies, I found Qualcomm's
QTi LPASS driver is similar with my wanted.
> > Thanks, I'll try it. Is there Documentation in
sound/designes/compress-offload.rst?
> > And best sample is... Intel's driver?
>
> Yes.
I read Intel's driver, I understand how to define the compress CPU DAI and
snd_compr_ops. The driver of Intel Atom (at sst-mfld-platform-pcm.c) defines
following DAI:
{
.name = "compress-cpu-dai",
.compress_new = snd_soc_new_compress,
.ops = &sst_compr_dai_ops,
.playback = {
.stream_name = "Compress Playback",
.channels_min = 1,
},
},
But I can't find how to use/map this DAI in machine driver or Device-Tree or
something. I think that it's same as PCM DAI, am I correct?
I read compress-offload.rst, but I can't find how do I test it. It seems aplay
of
alsa-util doesn't know compress audio formats. Should I use PulseAudio or
Android HAL to test compress audio APIs?
Regards,
--
Katsuhiro Suzuki
> -----Original Message-----
> From: Mark Brown [mailto:broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Wednesday, December 6, 2017 9:58 PM
> To: Suzuki, Katsuhiro/鈴木 勝博 <suzuki.katsuhiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org; Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Yamada, Masahiro/山田 真弘
> <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>; Masami Hiramatsu
> <masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>; Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
>
> On Wed, Dec 06, 2017 at 03:03:18PM +0900, Katsuhiro Suzuki wrote:
>
> > > I'd expect this code to be structured more like a library - have a
> > > driver that handles the specific IPs then have it call into a shared
> > > block of code that does the generic bits. Though in this case the
> > > device specific bit looks like a couple of tiny data tables so I'm not
> > > sure it's worth making it conditional or separate at all.
>
> > Sorry... I agree your opinion, but I can't imagine the detail.
>
> > I think my driver has structure as follows (ex. startup):
> > DAI: uniphier_aio_startup()@aio-core.c
> > Lib: uniphier_aio_init()@aio-regctrl.c
> > SoC specific: uniphier_aio_ld11_spec@aio-ld11.c
>
> > Am I wrong? Would you mean split the functions in aio-regctl.[ch] to other
> > kernel module? I wonder if you could tell me the example from existing
> > drivers. I'll try to fix my driver like as it.
>
> One example is how all the drivers that use the generic dmaengine code
> instantiate their DMA drivers, or how all the drivers for CODECs that
> have both I2C and SPIi control interfaces instantiate - given that the
> device specific code here seems to be mostly data tables that's probably
> the closest thing.
>
> > > At least. I do think we need to get to the bottom of how flexible the
> > > hardware is first though.
>
> > Yes, indeed. This hardware is more flexible and complex, but now I (and our
> > company) don't use it. Of course, I don't want to hide some features of this
> > hardware from ALSA people. I should try to upstream all features in the
future,
> > I think.
>
> My main concern here is to make sure that when you decide you need to
> use the more complex hardware that this can be done without too much
> pain to existing machines (and that they can benefit from as much of the
> enhanced functionality as is possible).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 3/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-11 9:20 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Philippe Ombredanne @ 2017-12-11 9:19 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: David S. Miller, netdev, Andrew Lunn, Florian Fainelli,
Rob Herring, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Masahiro Yamada, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1512979049-15930-3-git-send-email-hayashi.kunihiko@socionext.com>
Dear Kunihiko-san,
On Mon, Dec 11, 2017 at 8:57 AM, Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> The UniPhier platform from Socionext provides the AVE ethernet
> controller that includes MAC and MDIO bus supporting RGMII/RMII
> modes. The controller is named AVE.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
[...]
> --- /dev/null
> +++ b/drivers/net/ethernet/socionext/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
You are correctly using SPDX ids here....
> +obj-$(CONFIG_SNI_AVE) += sni_ave.o
> diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c
> new file mode 100644
> index 0000000..7b293c2
> --- /dev/null
> +++ b/drivers/net/ethernet/socionext/sni_ave.c
> @@ -0,0 +1,1744 @@
> +/**
> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
> + *
> + * Copyright 2014 Panasonic Corporation
> + * Copyright 2015-2017 Socionext Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
... then I guess you could also use them here, replacing at least 7
lines of boilerplate by a single id line?
> +// SDPX-License-Identifier: GPL-2.0
And if you go C++ style all the way, this could be even more compact:
> +// SDPX-License-Identifier: GPL-2.0
> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
> +// Copyright 2014 Panasonic Corporation
> +// Copyright 2015-2017 Socionext Inc.
Thank you for your kind consideration!
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* RE: [PATCH v10 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
From: Shameerali Kolothum Thodi @ 2017-12-11 9:17 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, will.deacon@arm.com,
robin.murphy@arm.com, marc.zyngier@arm.com, joro@8bytes.org
Cc: John Garry, xuwei (O), Guohanjun (Hanjun Guo),
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
devicetree@vger.kernel.org, Linuxarm
In-Reply-To: <20171129141449.120316-1-shameerali.kolothum.thodi@huawei.com>
Hi Lorenzo/Robin,
Any feedback on this series, please?
This one has the platform check(smmu model) moved into iort
code and invoking the helper fn from iommu_dma_get_resv_regions().
Thanks,
Shameer
> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Wednesday, November 29, 2017 2:15 PM
> To: lorenzo.pieralisi@arm.com; will.deacon@arm.com;
> robin.murphy@arm.com; marc.zyngier@arm.com; joro@8bytes.org
> Cc: John Garry <john.garry@huawei.com>; xuwei (O) <xuwei5@hisilicon.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; iommu@lists.linux-
> foundation.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; devicetree@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v10 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
>
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
>
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
>
> This patch implements an ACPI based quirk to reserve the hw msi regions
> in the smmu-v3 driver which means these address regions will not be
> translated and will be excluded from iova allocations.
>
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve and reserve
> the associated ITS base address from a device IORT node. The function
> has a check for smmu model to determine whether the platform requires
> the HW MSI reservation or not.
> 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> dts files so that users are warned about the non-DT support for this
> erratum.
>
> Changelog:
>
> v9 --> v10
> Addressed comments:
> -Moved smmu model check to iort helper function to selectively apply
> the msi reservation which will make the fn call generic from iommu-dma.
> -Removed PCI blacklisting patch, instead added smmu nodes(disabled)
> with comments to hip06/hip07 dts file.
>
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
> translater region only.
> -Removed the DT support for MSI reservation and blacklisted
> HiSilicon PCIe controllers on DT based systems when SMMUv3 is
> enabled.
>
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
> -Modified to use DT compatible string for errata.
> -Changed logic to retrieve the msi-parent for DT case.
>
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
> - added bt binding
> - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
>
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
> is not applicable. Provided a generic function in iommu code and added
> back the quirk implementation in SMMU v3 driver(patch#3)
>
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
> HW topologies are handled while reserving ITS regions(patch #1).
>
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
> iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
>
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
> iort helper function.
>
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
>
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
>
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead of vendor
> specific CSRT table.
>
> Shameer Kolothum (3):
> ACPI/IORT: Add msi address regions reservation helper
> iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
> arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
>
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 55 +++++++++++++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 24 ++++++
> drivers/acpi/arm64/iort.c | 133 ++++++++++++++++++++++++++++++-
> drivers/iommu/dma-iommu.c | 8 +-
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 +-
> 6 files changed, 224 insertions(+), 6 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 32/33] irqchip: Andestech Internal Vector Interrupt Controller driver
From: Marc Zyngier @ 2017-12-11 9:16 UTC (permalink / raw)
To: Greentime Hu, greentime-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
greg-U8xfFu+wG4EAvxtiuMwx3w
Cc: Rick Chen
In-Reply-To: <4fb7bd1cd2619287061fd68a38a774c8aef7dbe9.1512723245.git.green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 08/12/17 09:12, Greentime Hu wrote:
> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>
> This patch adds the Andestech Internal Vector Interrupt Controller
> driver. You can find the spec here. Ch4.9 of AndeStar SPA V3 Manual.
> http://www.andestech.com/product.php?cls=9
>
> Signed-off-by: Rick Chen <rick-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
> Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
Reviewed-by: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
Once there is an agreement on this series being fit for mainline, let me
know how you want to get this merged (either as a whole series, or with
this driver going through the irq tree).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver
From: kgunda @ 2017-12-11 9:11 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, Lee Jones, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <20171205020107.GD28761@minitux>
On 2017-12-05 07:31, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
>> WLED driver provides the interface to the display driver to
>> adjust the brightness of the display backlight.
>>
>> Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
>> ---
>> .../bindings/leds/backlight/qcom-spmi-wled.txt | 90 ++++
>> drivers/video/backlight/Kconfig | 9 +
>> drivers/video/backlight/Makefile | 1 +
>> drivers/video/backlight/qcom-spmi-wled.c | 504
>> +++++++++++++++++++++
>> 4 files changed, 604 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> create mode 100644 drivers/video/backlight/qcom-spmi-wled.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> new file mode 100644
>> index 0000000..f1ea25b
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/leds/backlight/qcom-spmi-wled.txt
>> @@ -0,0 +1,90 @@
>> +Binding for Qualcomm WLED driver
>> +
>
> This binding document quite well describe the pm8941 as well, so please
> improve the existing binding (changing to this style is preferable).
>
Sure. Will do it in the next series, where I will re-use pm8941 driver
for
PMI8998 as well.
>> +WLED (White Light Emitting Diode) driver is used for controlling
>> display
>> +backlight that is part of PMIC on Qualcomm Technologies reference
>> platforms.
>> +The PMIC is connected to the host processor via SPMI bus.
>> +
>> +- compatible
>> + Usage: required
>> + Value type: <string>
>> + Definition: should be "qcom,pm8998-spmi-wled".
>
> There's no WLED in the pm8998, so please make this pmi8998. This pmic
> is
> SPMI only, so there's no need to keep "spmi" in the compatible.
>
Sure. Will change it.
>> +
>> +- reg
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Base address and size of the WLED modules.
>> +
>> +- reg-names
>> + Usage: required
>> + Value type: <string>
>> + Definition: Names associated with base addresses. should be
>> + "qcom-wled-ctrl-base", "qcom-wled-sink-base".
>> +
>> +- label
>> + Usage: required
>> + Value type: <string>
>> + Definition: The name of the backlight device.
>> +
>> +- default-brightness
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: brightness value on boot, value from: 0-4095
>> + default: 2048
>> +
>> +- qcom,fs-current-limit
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: per-string full scale current limit in uA. value from
>> + 0 to 30000 with 5000 uA resolution. default: 25000 uA
>
> "in steps of 5mA"
>
Will address it in next series.
>> +
>> +- qcom,current-boost-limit
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: ILIM threshold in mA. values are 105, 280, 450, 620,
>> 970,
>> + 1150, 1300, 1500. default: 970 mA
>> +
>> +- qcom,switching-freq
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: Switching frequency in KHz. values are
>> + 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
>> + 1600, 1920, 2400, 3200, 4800, 9600.
>> + default: 800 KHz
>> +
>> +- qcom,ovp
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: Over-voltage protection limit in mV. values are 31100,
>> + 29600, 19600, 18100.
>> + default: 29600 mV
>> +
>> +- qcom,string-cfg
>> + Usage: optional
>> + Value type: <u32>
>> + Definition: Bit mask of the wled strings. Bit 0 to 3 indicates
>> strings
>> + 0 to 3 respectively. Wled module has four strings of leds
>> + numbered from 0 to 3. Each string of leds are operated
>> + individually. Specify the strings using the bit mask. Any
>> + combination of led strings can be used.
>> + default value is 15 (b1111).
>
> Please try to avoid expressing things as bitmasks in DT.
>
> The only difference from 8941 here is that there's one additional
> string, so please start off by expressing this as the existing binding.
>
> If you really need this flexibility you can follow up with an addition
> of a property like this, but name it something like
> "qcom,enabled-strings" and make this support available for pm8941 as
> well.
>
Sure. Will address it.
>> +
>> +- qcom,en-cabc
>
> No need for the "en", the presence of a bool property means that it's
> enabled.
>
Will address it in next series.
>> + Usage: optional
>> + Value type: <bool>
>> + Definition: Specify if cabc (content adaptive backlight control) is
>> + needed.
>
> I presume cabc isn't ever "needed", just make the description "Enable
> content adaptive backlight control".
>
Will address it in next series.
>> +
>> +Example:
>> +
>> +qcom-wled@d800 {
>> + compatible = "qcom,pm8998-spmi-wled";
>> + reg = <0xd800 0xd900>;
>> + reg-names = "qcom-wled-ctrl-base", "qcom-wled-sink-base";
>> + label = "backlight";
>> +
>> + qcom,fs-current-limit = <25000>;
>> + qcom,current-boost-limit = <970>;
>> + qcom,switching-freq = <800>;
>> + qcom,ovp = <29600>;
>> + qcom,string-cfg = <15>;
>> +};
> [..]
>> diff --git a/drivers/video/backlight/qcom-spmi-wled.c
>> b/drivers/video/backlight/qcom-spmi-wled.c
>
> After reviewing your arguments and comparing the drivers I still think
> it's beneficial to support both these hardware revisions in the same
> driver.
>
> The majority of the register differences relates to the current sink
> being split out, but this can easily be handled by a few well places
> accessor functions - which depends on this being the case or not.
>
> The addition of OVP handling would benefit 8941 as well.
>
> The short circuit handling in your patches are isolated and not taking
> this code path on 8941 should not pose any problems.
>
> [..]
Ok. I will reuse the pm8941-wled.c driver for pmi8998.
>> +/* General definitions */
>> +#define QCOM_WLED_DEFAULT_BRIGHTNESS 2048
>> +#define QCOM_WLED_MAX_BRIGHTNESS 4095
>> +
>> +/* WLED control registers */
>> +#define QCOM_WLED_CTRL_MOD_ENABLE 0x46
>> +#define QCOM_WLED_CTRL_MOD_EN_MASK BIT(7)
>> +#define QCOM_WLED_CTRL_MODULE_EN_SHIFT 7
>> +
>> +#define QCOM_WLED_CTRL_SWITCH_FREQ 0x4c
>> +#define QCOM_WLED_CTRL_SWITCH_FREQ_MASK GENMASK(3, 0)
>> +
>> +#define QCOM_WLED_CTRL_OVP 0x4d
>> +#define QCOM_WLED_CTRL_OVP_MASK GENMASK(1, 0)
>> +
>> +#define QCOM_WLED_CTRL_ILIM 0x4e
>> +#define QCOM_WLED_CTRL_ILIM_MASK GENMASK(2, 0)
>> +
>> +/* WLED sink registers */
>> +#define QCOM_WLED_SINK_CURR_SINK_EN 0x46
>> +#define QCOM_WLED_SINK_CURR_SINK_MASK GENMASK(7, 4)
>> +#define QCOM_WLED_SINK_CURR_SINK_SHFT 0x04
>
> Shifts are typically not given as hex...
>
Will address it in next series.
>> +
>> +#define QCOM_WLED_SINK_SYNC 0x47
>> +#define QCOM_WLED_SINK_SYNC_MASK GENMASK(3, 0)
>> +#define QCOM_WLED_SINK_SYNC_LED1 BIT(0)
>> +#define QCOM_WLED_SINK_SYNC_LED2 BIT(1)
>> +#define QCOM_WLED_SINK_SYNC_LED3 BIT(2)
>> +#define QCOM_WLED_SINK_SYNC_LED4 BIT(3)
>> +#define QCOM_WLED_SINK_SYNC_CLEAR 0x00
>> +
>> +#define QCOM_WLED_SINK_MOD_EN_REG(n) (0x50 + (n * 0x10))
>> +#define QCOM_WLED_SINK_REG_STR_MOD_MASK BIT(7)
>> +#define QCOM_WLED_SINK_REG_STR_MOD_EN BIT(7)
>> +
>> +#define QCOM_WLED_SINK_SYNC_DLY_REG(n) (0x51 + (n * 0x10))
>> +#define QCOM_WLED_SINK_FS_CURR_REG(n) (0x52 + (n * 0x10))
>> +#define QCOM_WLED_SINK_FS_MASK GENMASK(3, 0)
>> +
>> +#define QCOM_WLED_SINK_CABC_REG(n) (0x56 + (n * 0x10))
>> +#define QCOM_WLED_SINK_CABC_MASK BIT(7)
>> +#define QCOM_WLED_SINK_CABC_EN BIT(7)
>> +
>> +#define QCOM_WLED_SINK_BRIGHT_LSB_REG(n) (0x57 + (n * 0x10))
>> +#define QCOM_WLED_SINK_BRIGHT_MSB_REG(n) (0x58 + (n * 0x10))
>> +
>> +struct qcom_wled_config {
>> + u32 i_boost_limit;
>> + u32 ovp;
>> + u32 switch_freq;
>> + u32 fs_current;
>> + u32 string_cfg;
>> + bool en_cabc;
>> +};
>> +
>> +struct qcom_wled {
>> + const char *name;
>> + struct platform_device *pdev;
>
> Lug around the struct device * instead of the platform_device, and use
> this for dev_* prints throughout the code.
>
Will address it in next series.
>> + struct regmap *regmap;
>> + u16 sink_addr;
>> + u16 ctrl_addr;
>> + u32 brightness;
>> + bool prev_state;
>
> You can derive prev_state from wled->brightness in
> qcom_wled_update_status().
>
Will remove it in next series.
>> +
>> + struct qcom_wled_config cfg;
>> +};
>> +
>> +static int qcom_wled_module_enable(struct qcom_wled *wled, int val)
>> +{
>> + int rc;
>> +
>> + rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
>> + QCOM_WLED_CTRL_MOD_ENABLE, QCOM_WLED_CTRL_MOD_EN_MASK,
>> + val << QCOM_WLED_CTRL_MODULE_EN_SHIFT);
>
> This shift obfuscate the fact that val is only 0 or 1, make val a bool
> and make the macro for the enabled state be BIT(7).
>
Will address it in next series.
>> + return rc;
>> +}
>> +
>> +static int qcom_wled_get_brightness(struct backlight_device *bl)
>> +{
>> + struct qcom_wled *wled = bl_get_data(bl);
>> +
>> + return wled->brightness;
>> +}
>> +
>> +static int qcom_wled_sync_toggle(struct qcom_wled *wled)
>> +{
>> + int rc;
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->sink_addr + QCOM_WLED_SINK_SYNC,
>> + QCOM_WLED_SINK_SYNC_MASK, QCOM_WLED_SINK_SYNC_MASK);
>> + if (rc < 0)
>> + return rc;
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->sink_addr + QCOM_WLED_SINK_SYNC,
>> + QCOM_WLED_SINK_SYNC_MASK, QCOM_WLED_SINK_SYNC_CLEAR);
>> +
>> + return rc;
>> +}
>> +
>> +static int qcom_wled_set_brightness(struct qcom_wled *wled, u16
>> brightness)
>> +{
>> + int rc, i;
>> + u16 low_limit = QCOM_WLED_MAX_BRIGHTNESS * 4 / 1000;
>> + u8 string_cfg = wled->cfg.string_cfg;
>> + u8 v[2];
>> +
>> + /* WLED's lower limit of operation is 0.4% */
>> + if (brightness > 0 && brightness < low_limit)
>> + brightness = low_limit;
>
> What happens between 0 and 0.4%? Is this policy or is this related to
> some hardware issue?
>
This is related to a HW bug and if the brightness goes below 0.4% when
the module is enabled, we see the continuous OVP interrupts.
> Also, this function will not be called with brightness = 0, so you
> don't
> need to check that case.
>
We are disabling the module when the brightness is '0'. We update the
brightness
and enable the module for the next update request. So it is not needed
to call this
function for '0' brightness.
>> +
>> + v[0] = brightness & 0xff;
>> + v[1] = (brightness >> 8) & 0xf;
>> +
>> + for (i = 0; (string_cfg >> i) != 0; i++) {
>
> The condition looks optimal... Just loop from 0 to 3 and it will be
> easier to read without any measurable losses.
>
sure. will address it in next series.
>> + if (string_cfg & BIT(i)) {
>
> Flip this condition around and use "continue" to reduce the indentation
> level of the rest of the block.
>
sure. will address it in next series.
>> + rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
>> + QCOM_WLED_SINK_BRIGHT_LSB_REG(i), v, 2);
>> + if (rc < 0)
>> + return rc;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_wled_update_status(struct backlight_device *bl)
>> +{
>> + struct qcom_wled *wled = bl_get_data(bl);
>> + u16 brightness = bl->props.brightness;
>> + int rc;
>> +
>> + if (bl->props.power != FB_BLANK_UNBLANK ||
>> + bl->props.fb_blank != FB_BLANK_UNBLANK ||
>> + bl->props.state & BL_CORE_FBBLANK)
>> + brightness = 0;
>> +
>> + if (brightness) {
>> + rc = qcom_wled_set_brightness(wled, brightness);
>> + if (rc < 0) {
>> + pr_err("wled failed to set brightness rc:%d\n", rc);
>
> Use dev_err() and dev_dbg() throughout the driver.
>
sure. will address it in next series.
>> + return rc;
>> + }
>> +
>> + if (!!brightness != wled->prev_state) {
>> + rc = qcom_wled_module_enable(wled, !!brightness);
>> + if (rc < 0) {
>> + pr_err("wled enable failed rc:%d\n", rc);
>> + return rc;
>> + }
>> + }
>
> This block is exactly the same as the else statement, there's no need
> to
> repeat yourself.
>
This else is for the "if (brightness) {" not for the just above it.
>> + } else {
>> + rc = qcom_wled_module_enable(wled, brightness);
>> + if (rc < 0) {
>> + pr_err("wled disable failed rc:%d\n", rc);
>> + return rc;
>> + }
>> + }
>> +
>> + wled->prev_state = !!brightness;
>> +
>> + rc = qcom_wled_sync_toggle(wled);
>> + if (rc < 0) {
>> + pr_err("wled sync failed rc:%d\n", rc);
>> + return rc;
>> + }
>> +
>> + wled->brightness = brightness;
>> +
>> + return rc;
>> +}
>> +
>> +static int qcom_wled_setup(struct qcom_wled *wled)
>> +{
>> + int rc, temp, i;
>> + u8 sink_en = 0;
>> + u8 string_cfg = wled->cfg.string_cfg;
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_OVP,
>> + QCOM_WLED_CTRL_OVP_MASK, wled->cfg.ovp);
>> + if (rc < 0)
>> + return rc;
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_ILIM,
>> + QCOM_WLED_CTRL_ILIM_MASK, wled->cfg.i_boost_limit);
>> + if (rc < 0)
>> + return rc;
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->ctrl_addr + QCOM_WLED_CTRL_SWITCH_FREQ,
>> + QCOM_WLED_CTRL_SWITCH_FREQ_MASK, wled->cfg.switch_freq);
>> + if (rc < 0)
>> + return rc;
>> +
>> + for (i = 0; (string_cfg >> i) != 0; i++) {
>> + if (string_cfg & BIT(i)) {
>
> Same as above.
>
Ok. Will address it in next series.
>> + u16 addr = wled->sink_addr +
>> + QCOM_WLED_SINK_MOD_EN_REG(i);
>> +
>> + rc = regmap_update_bits(wled->regmap, addr,
>> + QCOM_WLED_SINK_REG_STR_MOD_MASK,
>> + QCOM_WLED_SINK_REG_STR_MOD_EN);
>> + if (rc < 0)
>> + return rc;
>> +
>> + addr = wled->sink_addr +
>> + QCOM_WLED_SINK_FS_CURR_REG(i);
>> + rc = regmap_update_bits(wled->regmap, addr,
>> + QCOM_WLED_SINK_FS_MASK,
>> + wled->cfg.fs_current);
>> + if (rc < 0)
>> + return rc;
>> +
>> + addr = wled->sink_addr +
>> + QCOM_WLED_SINK_CABC_REG(i);
>> + rc = regmap_update_bits(wled->regmap, addr,
>> + QCOM_WLED_SINK_CABC_MASK,
>> + wled->cfg.en_cabc ?
>> + QCOM_WLED_SINK_CABC_EN : 0);
>> + if (rc)
>> + return rc;
>> +
>> + temp = i + QCOM_WLED_SINK_CURR_SINK_SHFT;
>> + sink_en |= 1 << temp;
>
> I'm failing to see the reason for the "temp" variable here. Please do:
>
> sink_en |= BIT(i + QCOM_WLED_SINK_CURR_SINK_SHFT)
>
Ok. Will address it in next series.
>> + }
>> + }
>> +
>> + rc = regmap_update_bits(wled->regmap,
>> + wled->sink_addr + QCOM_WLED_SINK_CURR_SINK_EN,
>> + QCOM_WLED_SINK_CURR_SINK_MASK, sink_en);
>> + if (rc < 0)
>> + return rc;
>> +
>> + rc = qcom_wled_sync_toggle(wled);
>> + if (rc < 0) {
>> + pr_err("Failed to toggle sync reg rc:%d\n", rc);
>> + return rc;
>> + }
>> +
>> + return 0;
>> +}
>> +
> [..]
>> +static int qcom_wled_configure(struct qcom_wled *wled, struct device
>> *dev)
>> +{
>> + struct qcom_wled_config *cfg = &wled->cfg;
>> + const __be32 *prop_addr;
>> + u32 val, c;
>> + int rc, i, j;
>> +
>> + const struct {
>> + const char *name;
>> + u32 *val_ptr;
>> + const struct qcom_wled_var_cfg *cfg;
>> + } u32_opts[] = {
>
> I suggest that you tie this list of options to the compatible (through
> of_device_id->data) and pass it as a parameter to this function. That
> way you can handle variation in properties and their values between
> different compatibles.
>
Ok. Will address it in next series.
> [..]
>> + *cfg = wled_config_defaults;
>> + for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
>> + rc = of_property_read_u32(dev->of_node, u32_opts[i].name, &val);
>
> of_property_read_u32() returns -ENODATA when there's no associated
> data,
> you can probably use this to implement support for the boolean types in
> the same list of opts.
>
> [..]
>> + }
>> +
>> + for (i = 0; i < ARRAY_SIZE(bool_opts); ++i) {
>> + if (of_property_read_bool(dev->of_node, bool_opts[i].name))
>> + *bool_opts[i].val_ptr = true;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static const struct backlight_ops qcom_wled_ops = {
>> + .update_status = qcom_wled_update_status,
>> + .get_brightness = qcom_wled_get_brightness,
>> +};
>> +
>> +static int qcom_wled_probe(struct platform_device *pdev)
>> +{
>> + struct backlight_properties props;
>> + struct backlight_device *bl;
>> + struct qcom_wled *wled;
>> + struct regmap *regmap;
>> + u32 val;
>> + int rc;
>> +
>> + regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> + if (!regmap) {
>> + pr_err("Unable to get regmap\n");
>> + return -EINVAL;
>> + }
>> +
>> + wled = devm_kzalloc(&pdev->dev, sizeof(*wled), GFP_KERNEL);
>> + if (!wled)
>> + return -ENOMEM;
>> +
>> + wled->regmap = regmap;
>> + wled->pdev = pdev;
>> +
>> + rc = qcom_wled_configure(wled, &pdev->dev);
>> + if (rc < 0) {
>> + pr_err("wled configure failed rc:%d\n", rc);
>
> qcom_wled_configure() already printed an error message for you, no need
> to repeat this.
>
Will address it in next series.
>> + return rc;
>> + }
>> +
>
> Please also run checkpatch.pl with the --strict option and fix the
> indentation issues reported.
>
Sure.
> Regards,
> Bjorn
^ permalink raw reply
* Re: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Rasmus Villemoes @ 2017-12-11 9:08 UTC (permalink / raw)
To: Marc Zyngier, Alexander Stein
Cc: Thomas Gleixner, Jason Cooper, Rob Herring, Mark Rutland,
linux-kernel, devicetree
In-Reply-To: <9eab29c0-3347-635c-af92-4e8429064ed3@arm.com>
On 2017-12-08 17:09, Marc Zyngier wrote:
> On 08/12/17 15:11, Alexander Stein wrote:
>> Hi Rasmus,
>>
>>> +
>>> +Required properties:
>>> +- compatible: should be "fsl,ls1021a-extirq"
>>> +- interrupt-controller: Identifies the node as an interrupt controller
>>> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
>>
>> Do you really need 3 interrupt-cells here? As you've written below you don't
>> support PPI anyway the 1st flag might be dropped then. So support just 2 cells:
>> * IRQ number (IRQ0 - IRQ5)
>> * IRQ flags
>
> The convention for irqchip stacked on top of a GIC is to keep the
> interrupt specifier the same. It makes the maintenance if the DT much
> easier, and doesn't hurt at all.
Yes, I just followed the lead of existing drivers.
>>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>>> index b842dfdc903f..d4576dce24b2 100644
>>> --- a/drivers/irqchip/Makefile
>>> +++ b/drivers/irqchip/Makefile
>>> @@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
>>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>>> obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
>>> obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
>>> +obj-$(CONFIG_SOC_LS1021A) += irq-ls1021a.o
>>
>> I guess this should be kept sorted alphabetically.
>
> There is no such requirement. But grouping it next to the other FSL
> irqchip would make more sense.
Yeah, if the Makefile had been at least somewhat sorted already I'd have
followed that. I'll move it next to LS_SCFG_MSI in next version.
>>> +static int
>>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type)
>>> +{
>>> + irq_hw_number_t hwirq = data->hwirq;
>>> + struct extirq_chip_data *chip_data = data->chip_data;
>>> + u32 value, mask;
>>> + int ret;
>>> +
>>> + mask = 1U << (31 - hwirq);
>>
>> Is this really correct? IRQ0 is still at bit position 0. Don't be mislead
>> by the left most position in the register layout. This is just strange way
>> to express bit-endian access.
Yes, I'm sure. The 26 unused bits in the INTPCR register are marked as
reserved with a POR value of 0. Fortunately, they can still be set and
read back, and when I did 1U << hwirq it was some of those bits that got
set (the POR value of the six used bits are all 1, so the hardware still
worked on my board because all the lines happen to be of negative polarity).
>> Anyway, please use BIT(x) instead.
I really prefer not to, that macro obfuscates the type, and unsigned
long is the wrong thing to use for something that must be a 32 bit
quantity. Sure, BITS_PER_LONG==32 in this case, but I don't think
BIT(foo) is any easier to read than 1U << (foo).
>>> +
>>> + /* Don't do the INTPCR_REG update if the parent irq_set_type will EINVAL. */
>>> + if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
>>> + return -EINVAL;
>>
>> I wonder if it is better to call data->parent_data->chip->irq_set_type(data, type)
>> here instead and call regmap if this suceeded.
>
> Not really. In both cases, you need to evaluate the failure (which is
> not don here). So ordering doesn't matter. What actually matters is
> error handling and atomicity (in this case, making sure that drivers
> cannot observe an interrupt flood between the two reconfigurations).
I'm not really sure when the interrupt gets unmasked, but if it happens
during the parent ->set_type, we must have set the polarity beforehand.
Also, I don't see why one would need to undo the INTPCR update - the
polarity of the external line is a property of whatever hardware is
attached (right?), so setting the INTPCR according to the DT just
ensures the GIC gets a positive signal. Anyway, if I do need to add
unwind code, I suppose the answer to
>>> + /* regmap does internal locking, but do we need to provide our
>>> + * own across the parent irq_set_type call? */
is yes.
>>> + *hwirq = fwspec->param[1];
>>
>> Is a check for the hwirq value required here? I'm not an expert on
>> irqchip API, so I just wonder.
>
> In general, the driver is not in the business of validating the DT. But
> that wouldn't hurt...
Yeah, wasn't sure about this, but I can certainly add a check.
>>
>>> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
>>> + return 0;
>>> +}
>>> +
>>> +static int
>>> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>> + unsigned int nr_irqs, void *arg)
>>> +{
>>> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169};
>> ^^^^^^
>> No need for static here.
>
> Why would you store this on the stack each time you enter the function?
Exactly, it takes a lot less .rodata to make this static than having gcc
generate .text to build this array on the stack.
> That's the wrong construct (these values should come from DT), but
> static is perfectly fine.
OK.
> [...]
>
>>> + domain_parent = irq_find_host(parent);
>>> + if (!domain_parent) {
>>> + pr_err("interrupt-parent not found\n");
>>> + return -EINVAL;
>>> + }
>>
>> Mh, does this mean if GIC has not been probed, this probe is not deferred?
>> Is there an API to check for that?
>
> This is not a normal driver, there is not deferred probing. You'd get
> this error if the kernel had gone really wrong.
Yes, isn't this what the code in of_irq_init does? Initialize parent
interrupt controllers before their children (even if this maybe doesn't
qualify as a real interrupt controller)?
Rasmus
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels
From: Philippe Ombredanne @ 2017-12-11 9:06 UTC (permalink / raw)
To: David Lechner
Cc: dri-devel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Noralf Trønnes, limor, Linus Walleij, Rob Herring,
Mark Rutland, LKML
In-Reply-To: <1512943833-31352-3-git-send-email-david@lechnology.com>
David,
On Sun, Dec 10, 2017 at 11:10 PM, David Lechner <david@lechnology.com> wrote:
> This adds a new driver for Sitronix ST7735R display panels.
>
> This has been tested using an Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/st7735r.c
> @@ -0,0 +1,219 @@
> +/*
> + * DRM driver for Sitronix ST7735R panels
> + *
> + * Copyright 2017 David Lechner <david@lechnology.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
Have you considered using the new SPDX ids? Check the doc patches from
Thomas for details.
This could come out this way if you are using the C++ comment style
all the way, a style that you should at least use for the license id
as requested and commented by Linus:
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2017 David Lechner <david@lechnology.com>
> +// DRM driver for Sitronix ST7735R panels
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [PATCH v9 0/2] media: ov7740: Add a V4L2 sensor-level driver
From: Philippe Ombredanne @ 2017-12-11 9:02 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, LKML,
Nicolas Ferre,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sakari Ailus, Jonathan Corbet, Hans Verkuil,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20171211013146.2497-1-wenyou.yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On Mon, Dec 11, 2017 at 2:31 AM, Wenyou Yang <wenyou.yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org> wrote:
> Add a Video4Linux2 sensor-level driver for the OmniVision OV7740
> VGA camera image sensor.
>
> Changes in v9:
> - Use the new SPDX ids.
Thank you for this
Acked-by: Philippe Ombredanne <pombredanne-od1rfyK75/E@public.gmane.org>
--
Cordially
Philippe Ombredanne
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/5] ARM: dts: stm32: use dedicated files for pinctrl on stm32f7 family
From: Alexandre Torgue @ 2017-12-11 8:54 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland,
Jonathan Corbet, Russell King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Currently, same stm32f746-pinctrl driver is used for stm32f746 and
stm32f769 MCU. As pin map is different between those 2 MCUs,
a stm32f769-pinctrl driver has been recently added.
This patch
-allows to use stm32f769-pinctrl driver for stm32f769 boards
-reworks stm32 devicetree files to fit with stm32f746 / stm32f769
Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index 2d4e717..b2d4b8c 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -42,6 +42,7 @@
/dts-v1/;
#include "stm32f746.dtsi"
+#include "stm32f746-pinctrl.dtsi"
#include <dt-bindings/input/input.h>
/ {
diff --git a/arch/arm/boot/dts/stm32f7-pinctrl.dtsi b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
new file mode 100644
index 0000000..4c66fa40
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
@@ -0,0 +1,227 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright (C) STMicroelectronics 2017 - All Rights Reserved
+ * Author: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> for STMicroelectronics.
+ */
+
+#include <dt-bindings/pinctrl/stm32-pinfunc.h>
+#include <dt-bindings/mfd/stm32f7-rcc.h>
+
+/ {
+ soc {
+ pinctrl: pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x40020000 0x3000>;
+ interrupt-parent = <&exti>;
+ st,syscfg = <&syscfg 0x8>;
+ pins-are-numbered;
+
+ gpioa: gpio@40020000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x0 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOA)>;
+ st,bank-name = "GPIOA";
+ };
+
+ gpiob: gpio@40020400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x400 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOB)>;
+ st,bank-name = "GPIOB";
+ };
+
+ gpioc: gpio@40020800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x800 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOC)>;
+ st,bank-name = "GPIOC";
+ };
+
+ gpiod: gpio@40020c00 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOD)>;
+ st,bank-name = "GPIOD";
+ };
+
+ gpioe: gpio@40021000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x1000 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOE)>;
+ st,bank-name = "GPIOE";
+ };
+
+ gpiof: gpio@40021400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x1400 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOF)>;
+ st,bank-name = "GPIOF";
+ };
+
+ gpiog: gpio@40021800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x1800 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOG)>;
+ st,bank-name = "GPIOG";
+ };
+
+ gpioh: gpio@40021c00 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x1c00 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOH)>;
+ st,bank-name = "GPIOH";
+ };
+
+ gpioi: gpio@40022000 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x2000 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOI)>;
+ st,bank-name = "GPIOI";
+ };
+
+ gpioj: gpio@40022400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x2400 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOJ)>;
+ st,bank-name = "GPIOJ";
+ };
+
+ gpiok: gpio@40022800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x2800 0x400>;
+ clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOK)>;
+ st,bank-name = "GPIOK";
+ };
+
+ cec_pins_a: cec@0 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 15, AF4)>; /* HDMI CEC */
+ slew-rate = <0>;
+ drive-open-drain;
+ bias-disable;
+ };
+ };
+
+ usart1_pins_a: usart1@0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('A', 9, AF7)>; /* USART1_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('A', 10, AF7)>; /* USART1_RX */
+ bias-disable;
+ };
+ };
+
+ usart1_pins_b: usart1@1 {
+ pins1 {
+ pinmux = <STM32_PINMUX('A', 9, AF7)>; /* USART1_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('B', 7, AF7)>; /* USART1_RX */
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_b: i2c1@0 {
+ pins {
+ pinmux = <STM32_PINMUX('B', 9, AF4)>, /* I2C1 SDA */
+ <STM32_PINMUX('B', 8, AF4)>; /* I2C1 SCL */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
+ usbotg_hs_pins_a: usbotg-hs@0 {
+ pins {
+ pinmux = <STM32_PINMUX('H', 4, AF10)>, /* OTG_HS_ULPI_NXT */
+ <STM32_PINMUX('I', 11, AF10)>, /* OTG_HS_ULPI_DIR */
+ <STM32_PINMUX('C', 0, AF10)>, /* OTG_HS_ULPI_STP */
+ <STM32_PINMUX('A', 5, AF10)>, /* OTG_HS_ULPI_CK */
+ <STM32_PINMUX('A', 3, AF10)>, /* OTG_HS_ULPI_D0 */
+ <STM32_PINMUX('B', 0, AF10)>, /* OTG_HS_ULPI_D1 */
+ <STM32_PINMUX('B', 1, AF10)>, /* OTG_HS_ULPI_D2 */
+ <STM32_PINMUX('B', 10, AF10)>, /* OTG_HS_ULPI_D3 */
+ <STM32_PINMUX('B', 11, AF10)>, /* OTG_HS_ULPI_D4 */
+ <STM32_PINMUX('B', 12, AF10)>, /* OTG_HS_ULPI_D5 */
+ <STM32_PINMUX('B', 13, AF10)>, /* OTG_HS_ULPI_D6 */
+ <STM32_PINMUX('B', 5, AF10)>; /* OTG_HS_ULPI_D7 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ };
+
+ usbotg_hs_pins_b: usbotg-hs@1 {
+ pins {
+ pinmux = <STM32_PINMUX('H', 4, AF10)>, /* OTG_HS_ULPI_NXT */
+ <STM32_PINMUX('C', 2, AF10)>, /* OTG_HS_ULPI_DIR */
+ <STM32_PINMUX('C', 0, AF10)>, /* OTG_HS_ULPI_STP */
+ <STM32_PINMUX('A', 5, AF10)>, /* OTG_HS_ULPI_CK */
+ <STM32_PINMUX('A', 3, AF10)>, /* OTG_HS_ULPI_D0 */
+ <STM32_PINMUX('B', 0, AF10)>, /* OTG_HS_ULPI_D1 */
+ <STM32_PINMUX('B', 1, AF10)>, /* OTG_HS_ULPI_D2 */
+ <STM32_PINMUX('B', 10, AF10)>, /* OTG_HS_ULPI_D3 */
+ <STM32_PINMUX('B', 11, AF10)>, /* OTG_HS_ULPI_D4 */
+ <STM32_PINMUX('B', 12, AF10)>, /* OTG_HS_ULPI_D5 */
+ <STM32_PINMUX('B', 13, AF10)>, /* OTG_HS_ULPI_D6 */
+ <STM32_PINMUX('B', 5, AF10)>; /* OTG_HS_ULPI_D7 */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ };
+
+ usbotg_fs_pins_a: usbotg-fs@0 {
+ pins {
+ pinmux = <STM32_PINMUX('A', 10, AF10)>, /* OTG_FS_ID */
+ <STM32_PINMUX('A', 11, AF10)>, /* OTG_FS_DM */
+ <STM32_PINMUX('A', 12, AF10)>; /* OTG_FS_DP */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/stm32f746-disco.dts b/arch/arm/boot/dts/stm32f746-disco.dts
index 4d85dba..623b6f2 100644
--- a/arch/arm/boot/dts/stm32f746-disco.dts
+++ b/arch/arm/boot/dts/stm32f746-disco.dts
@@ -42,6 +42,7 @@
/dts-v1/;
#include "stm32f746.dtsi"
+#include "stm32f746-pinctrl.dtsi"
#include <dt-bindings/input/input.h>
/ {
diff --git a/arch/arm/boot/dts/stm32f746-pinctrl.dtsi b/arch/arm/boot/dts/stm32f746-pinctrl.dtsi
new file mode 100644
index 0000000..f0e6309
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f746-pinctrl.dtsi
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright (C) STMicroelectronics 2017 - All Rights Reserved
+ * Author: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> for STMicroelectronics.
+ */
+
+#include "stm32f7-pinctrl.dtsi"
+
+&pinctrl{
+ compatible = "st,stm32f746-pinctrl";
+};
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 5f66d15..8fe96d6 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -42,7 +42,6 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
-#include <dt-bindings/pinctrl/stm32-pinfunc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
#include <dt-bindings/mfd/stm32f7-rcc.h>
@@ -498,222 +497,6 @@
reg = <0x40007000 0x400>;
};
- pin-controller {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "st,stm32f746-pinctrl";
- ranges = <0 0x40020000 0x3000>;
- interrupt-parent = <&exti>;
- st,syscfg = <&syscfg 0x8>;
- pins-are-numbered;
-
- gpioa: gpio@40020000 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x0 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOA)>;
- st,bank-name = "GPIOA";
- };
-
- gpiob: gpio@40020400 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x400 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOB)>;
- st,bank-name = "GPIOB";
- };
-
- gpioc: gpio@40020800 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x800 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOC)>;
- st,bank-name = "GPIOC";
- };
-
- gpiod: gpio@40020c00 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0xc00 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOD)>;
- st,bank-name = "GPIOD";
- };
-
- gpioe: gpio@40021000 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x1000 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOE)>;
- st,bank-name = "GPIOE";
- };
-
- gpiof: gpio@40021400 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x1400 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOF)>;
- st,bank-name = "GPIOF";
- };
-
- gpiog: gpio@40021800 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x1800 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOG)>;
- st,bank-name = "GPIOG";
- };
-
- gpioh: gpio@40021c00 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x1c00 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOH)>;
- st,bank-name = "GPIOH";
- };
-
- gpioi: gpio@40022000 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x2000 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOI)>;
- st,bank-name = "GPIOI";
- };
-
- gpioj: gpio@40022400 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x2400 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOJ)>;
- st,bank-name = "GPIOJ";
- };
-
- gpiok: gpio@40022800 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x2800 0x400>;
- clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOK)>;
- st,bank-name = "GPIOK";
- };
-
- cec_pins_a: cec@0 {
- pins {
- pinmux = <STM32_PINMUX('A', 15, AF4)>; /* HDMI CEC */
- slew-rate = <0>;
- drive-open-drain;
- bias-disable;
- };
- };
-
- usart1_pins_a: usart1@0 {
- pins1 {
- pinmux = <STM32_PINMUX('A', 9, AF7)>; /* USART1_TX */
- bias-disable;
- drive-push-pull;
- slew-rate = <0>;
- };
- pins2 {
- pinmux = <STM32_PINMUX('A', 10, AF7)>; /* USART1_RX */
- bias-disable;
- };
- };
-
- usart1_pins_b: usart1@1 {
- pins1 {
- pinmux = <STM32_PINMUX('A', 9, AF7)>; /* USART1_TX */
- bias-disable;
- drive-push-pull;
- slew-rate = <0>;
- };
- pins2 {
- pinmux = <STM32_PINMUX('B', 7, AF7)>; /* USART1_RX */
- bias-disable;
- };
- };
-
- i2c1_pins_b: i2c1@0 {
- pins {
- pinmux = <STM32_PINMUX('B', 9, AF4)>, /* I2C1 SDA */
- <STM32_PINMUX('B', 8, AF4)>; /* I2C1 SCL */
- bias-disable;
- drive-open-drain;
- slew-rate = <0>;
- };
- };
-
- usbotg_hs_pins_a: usbotg-hs@0 {
- pins {
- pinmux = <STM32_PINMUX('H', 4, AF10)>, /* OTG_HS_ULPI_NXT */
- <STM32_PINMUX('I', 11, AF10)>, /* OTG_HS_ULPI_DIR */
- <STM32_PINMUX('C', 0, AF10)>, /* OTG_HS_ULPI_STP */
- <STM32_PINMUX('A', 5, AF10)>, /* OTG_HS_ULPI_CK */
- <STM32_PINMUX('A', 3, AF10)>, /* OTG_HS_ULPI_D0 */
- <STM32_PINMUX('B', 0, AF10)>, /* OTG_HS_ULPI_D1 */
- <STM32_PINMUX('B', 1, AF10)>, /* OTG_HS_ULPI_D2 */
- <STM32_PINMUX('B', 10, AF10)>, /* OTG_HS_ULPI_D3 */
- <STM32_PINMUX('B', 11, AF10)>, /* OTG_HS_ULPI_D4 */
- <STM32_PINMUX('B', 12, AF10)>, /* OTG_HS_ULPI_D5 */
- <STM32_PINMUX('B', 13, AF10)>, /* OTG_HS_ULPI_D6 */
- <STM32_PINMUX('B', 5, AF10)>; /* OTG_HS_ULPI_D7 */
- bias-disable;
- drive-push-pull;
- slew-rate = <2>;
- };
- };
-
- usbotg_hs_pins_b: usbotg-hs@1 {
- pins {
- pinmux = <STM32_PINMUX('H', 4, AF10)>, /* OTG_HS_ULPI_NXT */
- <STM32_PINMUX('C', 2, AF10)>, /* OTG_HS_ULPI_DIR */
- <STM32_PINMUX('C', 0, AF10)>, /* OTG_HS_ULPI_STP */
- <STM32_PINMUX('A', 5, AF10)>, /* OTG_HS_ULPI_CK */
- <STM32_PINMUX('A', 3, AF10)>, /* OTG_HS_ULPI_D0 */
- <STM32_PINMUX('B', 0, AF10)>, /* OTG_HS_ULPI_D1 */
- <STM32_PINMUX('B', 1, AF10)>, /* OTG_HS_ULPI_D2 */
- <STM32_PINMUX('B', 10, AF10)>, /* OTG_HS_ULPI_D3 */
- <STM32_PINMUX('B', 11, AF10)>, /* OTG_HS_ULPI_D4 */
- <STM32_PINMUX('B', 12, AF10)>, /* OTG_HS_ULPI_D5 */
- <STM32_PINMUX('B', 13, AF10)>, /* OTG_HS_ULPI_D6 */
- <STM32_PINMUX('B', 5, AF10)>; /* OTG_HS_ULPI_D7 */
- bias-disable;
- drive-push-pull;
- slew-rate = <2>;
- };
- };
-
- usbotg_fs_pins_a: usbotg-fs@0 {
- pins {
- pinmux = <STM32_PINMUX('A', 10, AF10)>, /* OTG_FS_ID */
- <STM32_PINMUX('A', 11, AF10)>, /* OTG_FS_DM */
- <STM32_PINMUX('A', 12, AF10)>; /* OTG_FS_DP */
- bias-disable;
- drive-push-pull;
- slew-rate = <2>;
- };
- };
- };
-
crc: crc@40023000 {
compatible = "st,stm32f7-crc";
reg = <0x40023000 0x400>;
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
index 4463ca1..9dba286 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -42,11 +42,12 @@
/dts-v1/;
#include "stm32f746.dtsi"
+#include "stm32f769-pinctrl.dtsi"
#include <dt-bindings/input/input.h>
/ {
model = "STMicroelectronics STM32F769-DISCO board";
- compatible = "st,stm32f769-disco", "st,stm32f7";
+ compatible = "st,stm32f769-disco", "st,stm32f769";
chosen {
bootargs = "root=/dev/ram";
diff --git a/arch/arm/boot/dts/stm32f769-pinctrl.dtsi b/arch/arm/boot/dts/stm32f769-pinctrl.dtsi
new file mode 100644
index 0000000..787da27
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f769-pinctrl.dtsi
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright (C) STMicroelectronics 2017 - All Rights Reserved
+ * Author: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> for STMicroelectronics.
+ */
+
+#include "stm32f7-pinctrl.dtsi"
+
+&pinctrl{
+ compatible = "st,stm32f769-pinctrl";
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/5] ARM: mach-stm32: add new STM32F769 MCU
From: Alexandre Torgue @ 2017-12-11 8:54 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland,
Jonathan Corbet, Russell King
Cc: linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue@st.com>
Add new st,stm32f769 compatible machine name for STM32F769 MCU and update
documentation.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/Documentation/arm/stm32/stm32f769-overview.txt b/Documentation/arm/stm32/stm32f769-overview.txt
new file mode 100644
index 0000000..9ab7e60
--- /dev/null
+++ b/Documentation/arm/stm32/stm32f769-overview.txt
@@ -0,0 +1,36 @@
+ STM32F769 Overview
+ ==================
+
+ Introduction
+ ------------
+ The STM32F769 is a Cortex-M7 MCU aimed at various applications.
+ It features:
+ - Cortex-M7 core running up to @216MHz
+ - 2MB internal flash, 512KBytes internal RAM (+4KB of backup SRAM)
+ - FMC controller to connect SDRAM, NOR and NAND memories
+ - Dual mode QSPI
+ - SD/MMC/SDIO support*2
+ - Ethernet controller
+ - USB OTFG FS & HS controllers
+ - I2C*4, SPI*6, CAN*3 busses support
+ - Several 16 & 32 bits general purpose timers
+ - Serial Audio interface *2
+ - LCD controller
+ - HDMI-CEC
+ - DSI
+ - SPDIFRX
+ - MDIO salave interface
+
+ Resources
+ ---------
+ Datasheet and reference manual are publicly available on ST website:
+ - http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f7-series/stm32f7x9/stm32f769ni.html
+
+ Document Author
+ ---------------
+ Alexandre Torgue <alexandre.torgue@st.com>
+
+
+
+
+
diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
index e918686..4824632 100644
--- a/arch/arm/mach-stm32/board-dt.c
+++ b/arch/arm/mach-stm32/board-dt.c
@@ -12,6 +12,7 @@ static const char *const stm32_compat[] __initconst = {
"st,stm32f429",
"st,stm32f469",
"st,stm32f746",
+ "st,stm32f769",
"st,stm32h743",
NULL
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: mach-stm32: Kconfig: introduce MACH_STM32F769 flag
From: Alexandre Torgue @ 2017-12-11 8:54 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland,
Jonathan Corbet, Russell King
Cc: linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue@st.com>
This patch introduces the MACH_STM32F769 to make possible to only select
STM32F769 pinctrl driver.
By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index 0d1889b..33b07db3 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -25,6 +25,11 @@ config MACH_STM32F746
depends on ARCH_STM32
default y
+config MACH_STM32F769
+ bool "STMicroelectronics STM32F769"
+ depends on ARCH_STM32
+ default y
+
config MACH_STM32H743
bool "STMicrolectronics STM32H743"
depends on ARCH_STM32
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] pinctrl: stm32: add STM32F769 MCU support
From: Alexandre Torgue @ 2017-12-11 8:54 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland,
Jonathan Corbet, Russell King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
This patch which adds STM32F769 pinctrl and GPIO support, relies on the
generic STM32 pinctrl driver.
Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index 7e1fe39..397f8c1 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -27,6 +27,12 @@ config PINCTRL_STM32F746
default MACH_STM32F746
select PINCTRL_STM32
+config PINCTRL_STM32F769
+ bool "STMicroelectronics STM32F769 pin control" if COMPILE_TEST && !MACH_STM32F769
+ depends on OF
+ default MACH_STM32F769
+ select PINCTRL_STM32
+
config PINCTRL_STM32H743
bool "STMicroelectronics STM32H743 pin control" if COMPILE_TEST && !MACH_STM32H743
depends on OF
diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
index d13ca35..7d63e4a 100644
--- a/drivers/pinctrl/stm32/Makefile
+++ b/drivers/pinctrl/stm32/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_PINCTRL_STM32) += pinctrl-stm32.o
obj-$(CONFIG_PINCTRL_STM32F429) += pinctrl-stm32f429.o
obj-$(CONFIG_PINCTRL_STM32F469) += pinctrl-stm32f469.o
obj-$(CONFIG_PINCTRL_STM32F746) += pinctrl-stm32f746.o
+obj-$(CONFIG_PINCTRL_STM32F769) += pinctrl-stm32f769.o
obj-$(CONFIG_PINCTRL_STM32H743) += pinctrl-stm32h743.o
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f769.c b/drivers/pinctrl/stm32/pinctrl-stm32f769.c
new file mode 100644
index 0000000..f81c51c
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32f769.c
@@ -0,0 +1,1827 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2017
+ * Author: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org> for STMicroelectronics.
+ */
+#include <linux/init.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "pinctrl-stm32.h"
+
+static const struct stm32_desc_pin stm32f769_pins[] = {
+ STM32_PIN(
+ PINCTRL_PIN(0, "PA0"),
+ STM32_FUNCTION(0, "GPIOA0"),
+ STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+ STM32_FUNCTION(3, "TIM5_CH1"),
+ STM32_FUNCTION(4, "TIM8_ETR"),
+ STM32_FUNCTION(8, "USART2_CTS"),
+ STM32_FUNCTION(9, "UART4_TX"),
+ STM32_FUNCTION(11, "SAI2_SD_B"),
+ STM32_FUNCTION(12, "ETH_MII_CRS"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(1, "PA1"),
+ STM32_FUNCTION(0, "GPIOA1"),
+ STM32_FUNCTION(2, "TIM2_CH2"),
+ STM32_FUNCTION(3, "TIM5_CH2"),
+ STM32_FUNCTION(8, "USART2_RTS"),
+ STM32_FUNCTION(9, "UART4_RX"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO3"),
+ STM32_FUNCTION(11, "SAI2_MCLK_B"),
+ STM32_FUNCTION(12, "ETH_MII_RX_CLK ETH_RMII_REF_CLK"),
+ STM32_FUNCTION(15, "LCD_R2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(2, "PA2"),
+ STM32_FUNCTION(0, "GPIOA2"),
+ STM32_FUNCTION(2, "TIM2_CH3"),
+ STM32_FUNCTION(3, "TIM5_CH3"),
+ STM32_FUNCTION(4, "TIM9_CH1"),
+ STM32_FUNCTION(8, "USART2_TX"),
+ STM32_FUNCTION(9, "SAI2_SCK_B"),
+ STM32_FUNCTION(12, "ETH_MDIO"),
+ STM32_FUNCTION(13, "MDIOS_MDIO"),
+ STM32_FUNCTION(15, "LCD_R1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(3, "PA3"),
+ STM32_FUNCTION(0, "GPIOA3"),
+ STM32_FUNCTION(2, "TIM2_CH4"),
+ STM32_FUNCTION(3, "TIM5_CH4"),
+ STM32_FUNCTION(4, "TIM9_CH2"),
+ STM32_FUNCTION(8, "USART2_RX"),
+ STM32_FUNCTION(10, "LCD_B2"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D0"),
+ STM32_FUNCTION(12, "ETH_MII_COL"),
+ STM32_FUNCTION(15, "LCD_B5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(4, "PA4"),
+ STM32_FUNCTION(0, "GPIOA4"),
+ STM32_FUNCTION(6, "SPI1_NSS I2S1_WS"),
+ STM32_FUNCTION(7, "SPI3_NSS I2S3_WS"),
+ STM32_FUNCTION(8, "USART2_CK"),
+ STM32_FUNCTION(9, "SPI6_NSS"),
+ STM32_FUNCTION(13, "OTG_HS_SOF"),
+ STM32_FUNCTION(14, "DCMI_HSYNC"),
+ STM32_FUNCTION(15, "LCD_VSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(5, "PA5"),
+ STM32_FUNCTION(0, "GPIOA5"),
+ STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+ STM32_FUNCTION(4, "TIM8_CH1N"),
+ STM32_FUNCTION(6, "SPI1_SCK I2S1_CK"),
+ STM32_FUNCTION(9, "SPI6_SCK"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_CK"),
+ STM32_FUNCTION(15, "LCD_R4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(6, "PA6"),
+ STM32_FUNCTION(0, "GPIOA6"),
+ STM32_FUNCTION(2, "TIM1_BKIN"),
+ STM32_FUNCTION(3, "TIM3_CH1"),
+ STM32_FUNCTION(4, "TIM8_BKIN"),
+ STM32_FUNCTION(6, "SPI1_MISO"),
+ STM32_FUNCTION(9, "SPI6_MISO"),
+ STM32_FUNCTION(10, "TIM13_CH1"),
+ STM32_FUNCTION(13, "MDIOS_MDC"),
+ STM32_FUNCTION(14, "DCMI_PIXCLK"),
+ STM32_FUNCTION(15, "LCD_G2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(7, "PA7"),
+ STM32_FUNCTION(0, "GPIOA7"),
+ STM32_FUNCTION(2, "TIM1_CH1N"),
+ STM32_FUNCTION(3, "TIM3_CH2"),
+ STM32_FUNCTION(4, "TIM8_CH1N"),
+ STM32_FUNCTION(6, "SPI1_MOSI I2S1_SD"),
+ STM32_FUNCTION(9, "SPI6_MOSI"),
+ STM32_FUNCTION(10, "TIM14_CH1"),
+ STM32_FUNCTION(12, "ETH_MII_RX_DV ETH_RMII_CRS_DV"),
+ STM32_FUNCTION(13, "FMC_SDNWE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(8, "PA8"),
+ STM32_FUNCTION(0, "GPIOA8"),
+ STM32_FUNCTION(1, "MCO1"),
+ STM32_FUNCTION(2, "TIM1_CH1"),
+ STM32_FUNCTION(4, "TIM8_BKIN2"),
+ STM32_FUNCTION(5, "I2C3_SCL"),
+ STM32_FUNCTION(8, "USART1_CK"),
+ STM32_FUNCTION(11, "OTG_FS_SOF"),
+ STM32_FUNCTION(12, "CAN3_RX"),
+ STM32_FUNCTION(13, "UART7_RX"),
+ STM32_FUNCTION(14, "LCD_B3"),
+ STM32_FUNCTION(15, "LCD_R6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(9, "PA9"),
+ STM32_FUNCTION(0, "GPIOA9"),
+ STM32_FUNCTION(2, "TIM1_CH2"),
+ STM32_FUNCTION(5, "I2C3_SMBA"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(8, "USART1_TX"),
+ STM32_FUNCTION(14, "DCMI_D0"),
+ STM32_FUNCTION(15, "LCD_R5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(10, "PA10"),
+ STM32_FUNCTION(0, "GPIOA10"),
+ STM32_FUNCTION(2, "TIM1_CH3"),
+ STM32_FUNCTION(8, "USART1_RX"),
+ STM32_FUNCTION(10, "LCD_B4"),
+ STM32_FUNCTION(11, "OTG_FS_ID"),
+ STM32_FUNCTION(13, "MDIOS_MDIO"),
+ STM32_FUNCTION(14, "DCMI_D1"),
+ STM32_FUNCTION(15, "LCD_B1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(11, "PA11"),
+ STM32_FUNCTION(0, "GPIOA11"),
+ STM32_FUNCTION(2, "TIM1_CH4"),
+ STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+ STM32_FUNCTION(7, "UART4_RX"),
+ STM32_FUNCTION(8, "USART1_CTS"),
+ STM32_FUNCTION(10, "CAN1_RX"),
+ STM32_FUNCTION(11, "OTG_FS_DM"),
+ STM32_FUNCTION(15, "LCD_R4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(12, "PA12"),
+ STM32_FUNCTION(0, "GPIOA12"),
+ STM32_FUNCTION(2, "TIM1_ETR"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(7, "UART4_TX"),
+ STM32_FUNCTION(8, "USART1_RTS"),
+ STM32_FUNCTION(9, "SAI2_FS_B"),
+ STM32_FUNCTION(10, "CAN1_TX"),
+ STM32_FUNCTION(11, "OTG_FS_DP"),
+ STM32_FUNCTION(15, "LCD_R5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(13, "PA13"),
+ STM32_FUNCTION(0, "GPIOA13"),
+ STM32_FUNCTION(1, "JTMS SWDIO"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(14, "PA14"),
+ STM32_FUNCTION(0, "GPIOA14"),
+ STM32_FUNCTION(1, "JTCK SWCLK"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(15, "PA15"),
+ STM32_FUNCTION(0, "GPIOA15"),
+ STM32_FUNCTION(1, "JTDI"),
+ STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+ STM32_FUNCTION(5, "HDMI_CEC"),
+ STM32_FUNCTION(6, "SPI1_NSS I2S1_WS"),
+ STM32_FUNCTION(7, "SPI3_NSS I2S3_WS"),
+ STM32_FUNCTION(8, "SPI6_NSS"),
+ STM32_FUNCTION(9, "UART4_RTS"),
+ STM32_FUNCTION(12, "CAN3_TX"),
+ STM32_FUNCTION(13, "UART7_TX"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(16, "PB0"),
+ STM32_FUNCTION(0, "GPIOB0"),
+ STM32_FUNCTION(2, "TIM1_CH2N"),
+ STM32_FUNCTION(3, "TIM3_CH3"),
+ STM32_FUNCTION(4, "TIM8_CH2N"),
+ STM32_FUNCTION(7, "DFSDM_CKOUT"),
+ STM32_FUNCTION(9, "UART4_CTS"),
+ STM32_FUNCTION(10, "LCD_R3"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D1"),
+ STM32_FUNCTION(12, "ETH_MII_RXD2"),
+ STM32_FUNCTION(15, "LCD_G1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(17, "PB1"),
+ STM32_FUNCTION(0, "GPIOB1"),
+ STM32_FUNCTION(2, "TIM1_CH3N"),
+ STM32_FUNCTION(3, "TIM3_CH4"),
+ STM32_FUNCTION(4, "TIM8_CH3N"),
+ STM32_FUNCTION(7, "DFSDM_DATIN1"),
+ STM32_FUNCTION(10, "LCD_R6"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D2"),
+ STM32_FUNCTION(12, "ETH_MII_RXD3"),
+ STM32_FUNCTION(15, "LCD_G0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(18, "PB2"),
+ STM32_FUNCTION(0, "GPIOB2"),
+ STM32_FUNCTION(7, "SAI1_SD_A"),
+ STM32_FUNCTION(8, "SPI3_MOSI I2S3_SD"),
+ STM32_FUNCTION(10, "QUADSPI_CLK"),
+ STM32_FUNCTION(11, "DFSDM_CKIN1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(19, "PB3"),
+ STM32_FUNCTION(0, "GPIOB3"),
+ STM32_FUNCTION(1, "JTDO TRACESWO"),
+ STM32_FUNCTION(2, "TIM2_CH2"),
+ STM32_FUNCTION(6, "SPI1_SCK I2S1_CK"),
+ STM32_FUNCTION(7, "SPI3_SCK I2S3_CK"),
+ STM32_FUNCTION(9, "SPI6_SCK"),
+ STM32_FUNCTION(11, "SDMMC2_D2"),
+ STM32_FUNCTION(12, "CAN3_RX"),
+ STM32_FUNCTION(13, "UART7_RX"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(20, "PB4"),
+ STM32_FUNCTION(0, "GPIOB4"),
+ STM32_FUNCTION(1, "NJTRST"),
+ STM32_FUNCTION(3, "TIM3_CH1"),
+ STM32_FUNCTION(6, "SPI1_MISO"),
+ STM32_FUNCTION(7, "SPI3_MISO"),
+ STM32_FUNCTION(8, "SPI2_NSS I2S2_WS"),
+ STM32_FUNCTION(9, "SPI6_MISO"),
+ STM32_FUNCTION(11, "SDMMC2_D3"),
+ STM32_FUNCTION(12, "CAN3_TX"),
+ STM32_FUNCTION(13, "UART7_TX"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(21, "PB5"),
+ STM32_FUNCTION(0, "GPIOB5"),
+ STM32_FUNCTION(2, "UART5_RX"),
+ STM32_FUNCTION(3, "TIM3_CH2"),
+ STM32_FUNCTION(5, "I2C1_SMBA"),
+ STM32_FUNCTION(6, "SPI1_MOSI I2S1_SD"),
+ STM32_FUNCTION(7, "SPI3_MOSI I2S3_SD"),
+ STM32_FUNCTION(9, "SPI6_MOSI"),
+ STM32_FUNCTION(10, "CAN2_RX"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D7"),
+ STM32_FUNCTION(12, "ETH_PPS_OUT"),
+ STM32_FUNCTION(13, "FMC_SDCKE1"),
+ STM32_FUNCTION(14, "DCMI_D10"),
+ STM32_FUNCTION(15, "LCD_G7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(22, "PB6"),
+ STM32_FUNCTION(0, "GPIOB6"),
+ STM32_FUNCTION(2, "UART5_TX"),
+ STM32_FUNCTION(3, "TIM4_CH1"),
+ STM32_FUNCTION(4, "HDMI_CEC"),
+ STM32_FUNCTION(5, "I2C1_SCL"),
+ STM32_FUNCTION(7, "DFSDM_DATIN5"),
+ STM32_FUNCTION(8, "USART1_TX"),
+ STM32_FUNCTION(10, "CAN2_TX"),
+ STM32_FUNCTION(11, "QUADSPI_BK1_NCS"),
+ STM32_FUNCTION(12, "I2C4_SCL"),
+ STM32_FUNCTION(13, "FMC_SDNE1"),
+ STM32_FUNCTION(14, "DCMI_D5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(23, "PB7"),
+ STM32_FUNCTION(0, "GPIOB7"),
+ STM32_FUNCTION(3, "TIM4_CH2"),
+ STM32_FUNCTION(5, "I2C1_SDA"),
+ STM32_FUNCTION(7, "DFSDM_CKIN5"),
+ STM32_FUNCTION(8, "USART1_RX"),
+ STM32_FUNCTION(12, "I2C4_SDA"),
+ STM32_FUNCTION(13, "FMC_NL"),
+ STM32_FUNCTION(14, "DCMI_VSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(24, "PB8"),
+ STM32_FUNCTION(0, "GPIOB8"),
+ STM32_FUNCTION(2, "I2C4_SCL"),
+ STM32_FUNCTION(3, "TIM4_CH3"),
+ STM32_FUNCTION(4, "TIM10_CH1"),
+ STM32_FUNCTION(5, "I2C1_SCL"),
+ STM32_FUNCTION(7, "DFSDM_CKIN7"),
+ STM32_FUNCTION(8, "UART5_RX"),
+ STM32_FUNCTION(10, "CAN1_RX"),
+ STM32_FUNCTION(11, "SDMMC2_D4"),
+ STM32_FUNCTION(12, "ETH_MII_TXD3"),
+ STM32_FUNCTION(13, "SDMMC1_D4"),
+ STM32_FUNCTION(14, "DCMI_D6"),
+ STM32_FUNCTION(15, "LCD_B6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(25, "PB9"),
+ STM32_FUNCTION(0, "GPIOB9"),
+ STM32_FUNCTION(2, "I2C4_SDA"),
+ STM32_FUNCTION(3, "TIM4_CH4"),
+ STM32_FUNCTION(4, "TIM11_CH1"),
+ STM32_FUNCTION(5, "I2C1_SDA"),
+ STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+ STM32_FUNCTION(7, "DFSDM_DATIN7"),
+ STM32_FUNCTION(8, "UART5_TX"),
+ STM32_FUNCTION(10, "CAN1_TX"),
+ STM32_FUNCTION(11, "SDMMC2_D5"),
+ STM32_FUNCTION(12, "I2C4_SMBA"),
+ STM32_FUNCTION(13, "SDMMC1_D5"),
+ STM32_FUNCTION(14, "DCMI_D7"),
+ STM32_FUNCTION(15, "LCD_B7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(26, "PB10"),
+ STM32_FUNCTION(0, "GPIOB10"),
+ STM32_FUNCTION(2, "TIM2_CH3"),
+ STM32_FUNCTION(5, "I2C2_SCL"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(7, "DFSDM_DATIN7"),
+ STM32_FUNCTION(8, "USART3_TX"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_NCS"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D3"),
+ STM32_FUNCTION(12, "ETH_MII_RX_ER"),
+ STM32_FUNCTION(15, "LCD_G4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(27, "PB11"),
+ STM32_FUNCTION(0, "GPIOB11"),
+ STM32_FUNCTION(2, "TIM2_CH4"),
+ STM32_FUNCTION(5, "I2C2_SDA"),
+ STM32_FUNCTION(7, "DFSDM_CKIN7"),
+ STM32_FUNCTION(8, "USART3_RX"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D4"),
+ STM32_FUNCTION(12, "ETH_MII_TX_EN ETH_RMII_TX_EN"),
+ STM32_FUNCTION(14, "DSI_TE"),
+ STM32_FUNCTION(15, "LCD_G5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(28, "PB12"),
+ STM32_FUNCTION(0, "GPIOB12"),
+ STM32_FUNCTION(2, "TIM1_BKIN"),
+ STM32_FUNCTION(5, "I2C2_SMBA"),
+ STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+ STM32_FUNCTION(7, "DFSDM_DATIN1"),
+ STM32_FUNCTION(8, "USART3_CK"),
+ STM32_FUNCTION(9, "UART5_RX"),
+ STM32_FUNCTION(10, "CAN2_RX"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D5"),
+ STM32_FUNCTION(12, "ETH_MII_TXD0 ETH_RMII_TXD0"),
+ STM32_FUNCTION(13, "OTG_HS_ID"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(29, "PB13"),
+ STM32_FUNCTION(0, "GPIOB13"),
+ STM32_FUNCTION(2, "TIM1_CH1N"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(7, "DFSDM_CKIN1"),
+ STM32_FUNCTION(8, "USART3_CTS"),
+ STM32_FUNCTION(9, "UART5_TX"),
+ STM32_FUNCTION(10, "CAN2_TX"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_D6"),
+ STM32_FUNCTION(12, "ETH_MII_TXD1 ETH_RMII_TXD1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(30, "PB14"),
+ STM32_FUNCTION(0, "GPIOB14"),
+ STM32_FUNCTION(2, "TIM1_CH2N"),
+ STM32_FUNCTION(4, "TIM8_CH2N"),
+ STM32_FUNCTION(5, "USART1_TX"),
+ STM32_FUNCTION(6, "SPI2_MISO"),
+ STM32_FUNCTION(7, "DFSDM_DATIN2"),
+ STM32_FUNCTION(8, "USART3_RTS"),
+ STM32_FUNCTION(9, "UART4_RTS"),
+ STM32_FUNCTION(10, "TIM12_CH1"),
+ STM32_FUNCTION(11, "SDMMC2_D0"),
+ STM32_FUNCTION(13, "OTG_HS_DM"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(31, "PB15"),
+ STM32_FUNCTION(0, "GPIOB15"),
+ STM32_FUNCTION(1, "RTC_REFIN"),
+ STM32_FUNCTION(2, "TIM1_CH3N"),
+ STM32_FUNCTION(4, "TIM8_CH3N"),
+ STM32_FUNCTION(5, "USART1_RX"),
+ STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+ STM32_FUNCTION(7, "DFSDM_CKIN2"),
+ STM32_FUNCTION(9, "UART4_CTS"),
+ STM32_FUNCTION(10, "TIM12_CH2"),
+ STM32_FUNCTION(11, "SDMMC2_D1"),
+ STM32_FUNCTION(13, "OTG_HS_DP"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(32, "PC0"),
+ STM32_FUNCTION(0, "GPIOC0"),
+ STM32_FUNCTION(4, "DFSDM_CKIN0"),
+ STM32_FUNCTION(7, "DFSDM_DATIN4"),
+ STM32_FUNCTION(9, "SAI2_FS_B"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_STP"),
+ STM32_FUNCTION(13, "FMC_SDNWE"),
+ STM32_FUNCTION(15, "LCD_R5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(33, "PC1"),
+ STM32_FUNCTION(0, "GPIOC1"),
+ STM32_FUNCTION(1, "TRACED0"),
+ STM32_FUNCTION(4, "DFSDM_DATIN0"),
+ STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+ STM32_FUNCTION(7, "SAI1_SD_A"),
+ STM32_FUNCTION(11, "DFSDM_CKIN4"),
+ STM32_FUNCTION(12, "ETH_MDC"),
+ STM32_FUNCTION(13, "MDIOS_MDC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(34, "PC2"),
+ STM32_FUNCTION(0, "GPIOC2"),
+ STM32_FUNCTION(4, "DFSDM_CKIN1"),
+ STM32_FUNCTION(6, "SPI2_MISO"),
+ STM32_FUNCTION(7, "DFSDM_CKOUT"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_DIR"),
+ STM32_FUNCTION(12, "ETH_MII_TXD2"),
+ STM32_FUNCTION(13, "FMC_SDNE0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(35, "PC3"),
+ STM32_FUNCTION(0, "GPIOC3"),
+ STM32_FUNCTION(4, "DFSDM_DATIN1"),
+ STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_NXT"),
+ STM32_FUNCTION(12, "ETH_MII_TX_CLK"),
+ STM32_FUNCTION(13, "FMC_SDCKE0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(36, "PC4"),
+ STM32_FUNCTION(0, "GPIOC4"),
+ STM32_FUNCTION(4, "DFSDM_CKIN2"),
+ STM32_FUNCTION(6, "I2S1_MCK"),
+ STM32_FUNCTION(9, "SPDIF_RX2"),
+ STM32_FUNCTION(12, "ETH_MII_RXD0 ETH_RMII_RXD0"),
+ STM32_FUNCTION(13, "FMC_SDNE0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(37, "PC5"),
+ STM32_FUNCTION(0, "GPIOC5"),
+ STM32_FUNCTION(4, "DFSDM_DATIN2"),
+ STM32_FUNCTION(9, "SPDIF_RX3"),
+ STM32_FUNCTION(12, "ETH_MII_RXD1 ETH_RMII_RXD1"),
+ STM32_FUNCTION(13, "FMC_SDCKE0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(38, "PC6"),
+ STM32_FUNCTION(0, "GPIOC6"),
+ STM32_FUNCTION(3, "TIM3_CH1"),
+ STM32_FUNCTION(4, "TIM8_CH1"),
+ STM32_FUNCTION(6, "I2S2_MCK"),
+ STM32_FUNCTION(8, "DFSDM_CKIN3"),
+ STM32_FUNCTION(9, "USART6_TX"),
+ STM32_FUNCTION(10, "FMC_NWAIT"),
+ STM32_FUNCTION(11, "SDMMC2_D6"),
+ STM32_FUNCTION(13, "SDMMC1_D6"),
+ STM32_FUNCTION(14, "DCMI_D0"),
+ STM32_FUNCTION(15, "LCD_HSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(39, "PC7"),
+ STM32_FUNCTION(0, "GPIOC7"),
+ STM32_FUNCTION(3, "TIM3_CH2"),
+ STM32_FUNCTION(4, "TIM8_CH2"),
+ STM32_FUNCTION(7, "I2S3_MCK"),
+ STM32_FUNCTION(8, "DFSDM_DATIN3"),
+ STM32_FUNCTION(9, "USART6_RX"),
+ STM32_FUNCTION(10, "FMC_NE1"),
+ STM32_FUNCTION(11, "SDMMC2_D7"),
+ STM32_FUNCTION(13, "SDMMC1_D7"),
+ STM32_FUNCTION(14, "DCMI_D1"),
+ STM32_FUNCTION(15, "LCD_G6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(40, "PC8"),
+ STM32_FUNCTION(0, "GPIOC8"),
+ STM32_FUNCTION(1, "TRACED1"),
+ STM32_FUNCTION(3, "TIM3_CH3"),
+ STM32_FUNCTION(4, "TIM8_CH3"),
+ STM32_FUNCTION(8, "UART5_RTS"),
+ STM32_FUNCTION(9, "USART6_CK"),
+ STM32_FUNCTION(10, "FMC_NE2 FMC_NCE"),
+ STM32_FUNCTION(13, "SDMMC1_D0"),
+ STM32_FUNCTION(14, "DCMI_D2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(41, "PC9"),
+ STM32_FUNCTION(0, "GPIOC9"),
+ STM32_FUNCTION(1, "MCO2"),
+ STM32_FUNCTION(3, "TIM3_CH4"),
+ STM32_FUNCTION(4, "TIM8_CH4"),
+ STM32_FUNCTION(5, "I2C3_SDA"),
+ STM32_FUNCTION(6, "I2S_CKIN"),
+ STM32_FUNCTION(8, "UART5_CTS"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO0"),
+ STM32_FUNCTION(11, "LCD_G3"),
+ STM32_FUNCTION(13, "SDMMC1_D1"),
+ STM32_FUNCTION(14, "DCMI_D3"),
+ STM32_FUNCTION(15, "LCD_B2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(42, "PC10"),
+ STM32_FUNCTION(0, "GPIOC10"),
+ STM32_FUNCTION(4, "DFSDM_CKIN5"),
+ STM32_FUNCTION(7, "SPI3_SCK I2S3_CK"),
+ STM32_FUNCTION(8, "USART3_TX"),
+ STM32_FUNCTION(9, "UART4_TX"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO1"),
+ STM32_FUNCTION(13, "SDMMC1_D2"),
+ STM32_FUNCTION(14, "DCMI_D8"),
+ STM32_FUNCTION(15, "LCD_R2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(43, "PC11"),
+ STM32_FUNCTION(0, "GPIOC11"),
+ STM32_FUNCTION(4, "DFSDM_DATIN5"),
+ STM32_FUNCTION(7, "SPI3_MISO"),
+ STM32_FUNCTION(8, "USART3_RX"),
+ STM32_FUNCTION(9, "UART4_RX"),
+ STM32_FUNCTION(10, "QUADSPI_BK2_NCS"),
+ STM32_FUNCTION(13, "SDMMC1_D3"),
+ STM32_FUNCTION(14, "DCMI_D4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(44, "PC12"),
+ STM32_FUNCTION(0, "GPIOC12"),
+ STM32_FUNCTION(1, "TRACED3"),
+ STM32_FUNCTION(7, "SPI3_MOSI I2S3_SD"),
+ STM32_FUNCTION(8, "USART3_CK"),
+ STM32_FUNCTION(9, "UART5_TX"),
+ STM32_FUNCTION(13, "SDMMC1_CK"),
+ STM32_FUNCTION(14, "DCMI_D9"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(45, "PC13"),
+ STM32_FUNCTION(0, "GPIOC13"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(46, "PC14"),
+ STM32_FUNCTION(0, "GPIOC14"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(47, "PC15"),
+ STM32_FUNCTION(0, "GPIOC15"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(48, "PD0"),
+ STM32_FUNCTION(0, "GPIOD0"),
+ STM32_FUNCTION(4, "DFSDM_CKIN6"),
+ STM32_FUNCTION(7, "DFSDM_DATIN7"),
+ STM32_FUNCTION(9, "UART4_RX"),
+ STM32_FUNCTION(10, "CAN1_RX"),
+ STM32_FUNCTION(13, "FMC_D2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(49, "PD1"),
+ STM32_FUNCTION(0, "GPIOD1"),
+ STM32_FUNCTION(4, "DFSDM_DATIN6"),
+ STM32_FUNCTION(7, "DFSDM_CKIN7"),
+ STM32_FUNCTION(9, "UART4_TX"),
+ STM32_FUNCTION(10, "CAN1_TX"),
+ STM32_FUNCTION(13, "FMC_D3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(50, "PD2"),
+ STM32_FUNCTION(0, "GPIOD2"),
+ STM32_FUNCTION(1, "TRACED2"),
+ STM32_FUNCTION(3, "TIM3_ETR"),
+ STM32_FUNCTION(9, "UART5_RX"),
+ STM32_FUNCTION(13, "SDMMC1_CMD"),
+ STM32_FUNCTION(14, "DCMI_D11"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(51, "PD3"),
+ STM32_FUNCTION(0, "GPIOD3"),
+ STM32_FUNCTION(4, "DFSDM_CKOUT"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(7, "DFSDM_DATIN0"),
+ STM32_FUNCTION(8, "USART2_CTS"),
+ STM32_FUNCTION(13, "FMC_CLK"),
+ STM32_FUNCTION(14, "DCMI_D5"),
+ STM32_FUNCTION(15, "LCD_G7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(52, "PD4"),
+ STM32_FUNCTION(0, "GPIOD4"),
+ STM32_FUNCTION(7, "DFSDM_CKIN0"),
+ STM32_FUNCTION(8, "USART2_RTS"),
+ STM32_FUNCTION(13, "FMC_NOE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(53, "PD5"),
+ STM32_FUNCTION(0, "GPIOD5"),
+ STM32_FUNCTION(8, "USART2_TX"),
+ STM32_FUNCTION(13, "FMC_NWE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(54, "PD6"),
+ STM32_FUNCTION(0, "GPIOD6"),
+ STM32_FUNCTION(4, "DFSDM_CKIN4"),
+ STM32_FUNCTION(6, "SPI3_MOSI I2S3_SD"),
+ STM32_FUNCTION(7, "SAI1_SD_A"),
+ STM32_FUNCTION(8, "USART2_RX"),
+ STM32_FUNCTION(11, "DFSDM_DATIN1"),
+ STM32_FUNCTION(12, "SDMMC2_CK"),
+ STM32_FUNCTION(13, "FMC_NWAIT"),
+ STM32_FUNCTION(14, "DCMI_D10"),
+ STM32_FUNCTION(15, "LCD_B2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(55, "PD7"),
+ STM32_FUNCTION(0, "GPIOD7"),
+ STM32_FUNCTION(4, "DFSDM_DATIN4"),
+ STM32_FUNCTION(6, "SPI1_MOSI I2S1_SD"),
+ STM32_FUNCTION(7, "DFSDM_CKIN1"),
+ STM32_FUNCTION(8, "USART2_CK"),
+ STM32_FUNCTION(9, "SPDIF_RX0"),
+ STM32_FUNCTION(12, "SDMMC2_CMD"),
+ STM32_FUNCTION(13, "FMC_NE1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(56, "PD8"),
+ STM32_FUNCTION(0, "GPIOD8"),
+ STM32_FUNCTION(4, "DFSDM_CKIN3"),
+ STM32_FUNCTION(8, "USART3_TX"),
+ STM32_FUNCTION(9, "SPDIF_RX1"),
+ STM32_FUNCTION(13, "FMC_D13"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(57, "PD9"),
+ STM32_FUNCTION(0, "GPIOD9"),
+ STM32_FUNCTION(4, "DFSDM_DATIN3"),
+ STM32_FUNCTION(8, "USART3_RX"),
+ STM32_FUNCTION(13, "FMC_D14"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(58, "PD10"),
+ STM32_FUNCTION(0, "GPIOD10"),
+ STM32_FUNCTION(4, "DFSDM_CKOUT"),
+ STM32_FUNCTION(8, "USART3_CK"),
+ STM32_FUNCTION(13, "FMC_D15"),
+ STM32_FUNCTION(15, "LCD_B3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(59, "PD11"),
+ STM32_FUNCTION(0, "GPIOD11"),
+ STM32_FUNCTION(5, "I2C4_SMBA"),
+ STM32_FUNCTION(8, "USART3_CTS"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO0"),
+ STM32_FUNCTION(11, "SAI2_SD_A"),
+ STM32_FUNCTION(13, "FMC_A16 FMC_CLE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(60, "PD12"),
+ STM32_FUNCTION(0, "GPIOD12"),
+ STM32_FUNCTION(3, "TIM4_CH1"),
+ STM32_FUNCTION(4, "LPTIM1_IN1"),
+ STM32_FUNCTION(5, "I2C4_SCL"),
+ STM32_FUNCTION(8, "USART3_RTS"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO1"),
+ STM32_FUNCTION(11, "SAI2_FS_A"),
+ STM32_FUNCTION(13, "FMC_A17 FMC_ALE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(61, "PD13"),
+ STM32_FUNCTION(0, "GPIOD13"),
+ STM32_FUNCTION(3, "TIM4_CH2"),
+ STM32_FUNCTION(4, "LPTIM1_OUT"),
+ STM32_FUNCTION(5, "I2C4_SDA"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO3"),
+ STM32_FUNCTION(11, "SAI2_SCK_A"),
+ STM32_FUNCTION(13, "FMC_A18"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(62, "PD14"),
+ STM32_FUNCTION(0, "GPIOD14"),
+ STM32_FUNCTION(3, "TIM4_CH3"),
+ STM32_FUNCTION(9, "UART8_CTS"),
+ STM32_FUNCTION(13, "FMC_D0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(63, "PD15"),
+ STM32_FUNCTION(0, "GPIOD15"),
+ STM32_FUNCTION(3, "TIM4_CH4"),
+ STM32_FUNCTION(9, "UART8_RTS"),
+ STM32_FUNCTION(13, "FMC_D1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(64, "PE0"),
+ STM32_FUNCTION(0, "GPIOE0"),
+ STM32_FUNCTION(3, "TIM4_ETR"),
+ STM32_FUNCTION(4, "LPTIM1_ETR"),
+ STM32_FUNCTION(9, "UART8_RX"),
+ STM32_FUNCTION(11, "SAI2_MCLK_A"),
+ STM32_FUNCTION(13, "FMC_NBL0"),
+ STM32_FUNCTION(14, "DCMI_D2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(65, "PE1"),
+ STM32_FUNCTION(0, "GPIOE1"),
+ STM32_FUNCTION(4, "LPTIM1_IN2"),
+ STM32_FUNCTION(9, "UART8_TX"),
+ STM32_FUNCTION(13, "FMC_NBL1"),
+ STM32_FUNCTION(14, "DCMI_D3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(66, "PE2"),
+ STM32_FUNCTION(0, "GPIOE2"),
+ STM32_FUNCTION(1, "TRACECLK"),
+ STM32_FUNCTION(6, "SPI4_SCK"),
+ STM32_FUNCTION(7, "SAI1_MCLK_A"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO2"),
+ STM32_FUNCTION(12, "ETH_MII_TXD3"),
+ STM32_FUNCTION(13, "FMC_A23"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(67, "PE3"),
+ STM32_FUNCTION(0, "GPIOE3"),
+ STM32_FUNCTION(1, "TRACED0"),
+ STM32_FUNCTION(7, "SAI1_SD_B"),
+ STM32_FUNCTION(13, "FMC_A19"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(68, "PE4"),
+ STM32_FUNCTION(0, "GPIOE4"),
+ STM32_FUNCTION(1, "TRACED1"),
+ STM32_FUNCTION(6, "SPI4_NSS"),
+ STM32_FUNCTION(7, "SAI1_FS_A"),
+ STM32_FUNCTION(11, "DFSDM_DATIN3"),
+ STM32_FUNCTION(13, "FMC_A20"),
+ STM32_FUNCTION(14, "DCMI_D4"),
+ STM32_FUNCTION(15, "LCD_B0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(69, "PE5"),
+ STM32_FUNCTION(0, "GPIOE5"),
+ STM32_FUNCTION(1, "TRACED2"),
+ STM32_FUNCTION(4, "TIM9_CH1"),
+ STM32_FUNCTION(6, "SPI4_MISO"),
+ STM32_FUNCTION(7, "SAI1_SCK_A"),
+ STM32_FUNCTION(11, "DFSDM_CKIN3"),
+ STM32_FUNCTION(13, "FMC_A21"),
+ STM32_FUNCTION(14, "DCMI_D6"),
+ STM32_FUNCTION(15, "LCD_G0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(70, "PE6"),
+ STM32_FUNCTION(0, "GPIOE6"),
+ STM32_FUNCTION(1, "TRACED3"),
+ STM32_FUNCTION(2, "TIM1_BKIN2"),
+ STM32_FUNCTION(4, "TIM9_CH2"),
+ STM32_FUNCTION(6, "SPI4_MOSI"),
+ STM32_FUNCTION(7, "SAI1_SD_A"),
+ STM32_FUNCTION(11, "SAI2_MCLK_B"),
+ STM32_FUNCTION(13, "FMC_A22"),
+ STM32_FUNCTION(14, "DCMI_D7"),
+ STM32_FUNCTION(15, "LCD_G1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(71, "PE7"),
+ STM32_FUNCTION(0, "GPIOE7"),
+ STM32_FUNCTION(2, "TIM1_ETR"),
+ STM32_FUNCTION(7, "DFSDM_DATIN2"),
+ STM32_FUNCTION(9, "UART7_RX"),
+ STM32_FUNCTION(11, "QUADSPI_BK2_IO0"),
+ STM32_FUNCTION(13, "FMC_D4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(72, "PE8"),
+ STM32_FUNCTION(0, "GPIOE8"),
+ STM32_FUNCTION(2, "TIM1_CH1N"),
+ STM32_FUNCTION(7, "DFSDM_CKIN2"),
+ STM32_FUNCTION(9, "UART7_TX"),
+ STM32_FUNCTION(11, "QUADSPI_BK2_IO1"),
+ STM32_FUNCTION(13, "FMC_D5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(73, "PE9"),
+ STM32_FUNCTION(0, "GPIOE9"),
+ STM32_FUNCTION(2, "TIM1_CH1"),
+ STM32_FUNCTION(7, "DFSDM_CKOUT"),
+ STM32_FUNCTION(9, "UART7_RTS"),
+ STM32_FUNCTION(11, "QUADSPI_BK2_IO2"),
+ STM32_FUNCTION(13, "FMC_D6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(74, "PE10"),
+ STM32_FUNCTION(0, "GPIOE10"),
+ STM32_FUNCTION(2, "TIM1_CH2N"),
+ STM32_FUNCTION(7, "DFSDM_DATIN4"),
+ STM32_FUNCTION(9, "UART7_CTS"),
+ STM32_FUNCTION(11, "QUADSPI_BK2_IO3"),
+ STM32_FUNCTION(13, "FMC_D7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(75, "PE11"),
+ STM32_FUNCTION(0, "GPIOE11"),
+ STM32_FUNCTION(2, "TIM1_CH2"),
+ STM32_FUNCTION(6, "SPI4_NSS"),
+ STM32_FUNCTION(7, "DFSDM_CKIN4"),
+ STM32_FUNCTION(11, "SAI2_SD_B"),
+ STM32_FUNCTION(13, "FMC_D8"),
+ STM32_FUNCTION(15, "LCD_G3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(76, "PE12"),
+ STM32_FUNCTION(0, "GPIOE12"),
+ STM32_FUNCTION(2, "TIM1_CH3N"),
+ STM32_FUNCTION(6, "SPI4_SCK"),
+ STM32_FUNCTION(7, "DFSDM_DATIN5"),
+ STM32_FUNCTION(11, "SAI2_SCK_B"),
+ STM32_FUNCTION(13, "FMC_D9"),
+ STM32_FUNCTION(15, "LCD_B4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(77, "PE13"),
+ STM32_FUNCTION(0, "GPIOE13"),
+ STM32_FUNCTION(2, "TIM1_CH3"),
+ STM32_FUNCTION(6, "SPI4_MISO"),
+ STM32_FUNCTION(7, "DFSDM_CKIN5"),
+ STM32_FUNCTION(11, "SAI2_FS_B"),
+ STM32_FUNCTION(13, "FMC_D10"),
+ STM32_FUNCTION(15, "LCD_DE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(78, "PE14"),
+ STM32_FUNCTION(0, "GPIOE14"),
+ STM32_FUNCTION(2, "TIM1_CH4"),
+ STM32_FUNCTION(6, "SPI4_MOSI"),
+ STM32_FUNCTION(11, "SAI2_MCLK_B"),
+ STM32_FUNCTION(13, "FMC_D11"),
+ STM32_FUNCTION(15, "LCD_CLK"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(79, "PE15"),
+ STM32_FUNCTION(0, "GPIOE15"),
+ STM32_FUNCTION(2, "TIM1_BKIN"),
+ STM32_FUNCTION(13, "FMC_D12"),
+ STM32_FUNCTION(15, "LCD_R7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(80, "PF0"),
+ STM32_FUNCTION(0, "GPIOF0"),
+ STM32_FUNCTION(5, "I2C2_SDA"),
+ STM32_FUNCTION(13, "FMC_A0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(81, "PF1"),
+ STM32_FUNCTION(0, "GPIOF1"),
+ STM32_FUNCTION(5, "I2C2_SCL"),
+ STM32_FUNCTION(13, "FMC_A1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(82, "PF2"),
+ STM32_FUNCTION(0, "GPIOF2"),
+ STM32_FUNCTION(5, "I2C2_SMBA"),
+ STM32_FUNCTION(13, "FMC_A2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(83, "PF3"),
+ STM32_FUNCTION(0, "GPIOF3"),
+ STM32_FUNCTION(13, "FMC_A3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(84, "PF4"),
+ STM32_FUNCTION(0, "GPIOF4"),
+ STM32_FUNCTION(13, "FMC_A4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(85, "PF5"),
+ STM32_FUNCTION(0, "GPIOF5"),
+ STM32_FUNCTION(13, "FMC_A5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(86, "PF6"),
+ STM32_FUNCTION(0, "GPIOF6"),
+ STM32_FUNCTION(4, "TIM10_CH1"),
+ STM32_FUNCTION(6, "SPI5_NSS"),
+ STM32_FUNCTION(7, "SAI1_SD_B"),
+ STM32_FUNCTION(9, "UART7_RX"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(87, "PF7"),
+ STM32_FUNCTION(0, "GPIOF7"),
+ STM32_FUNCTION(4, "TIM11_CH1"),
+ STM32_FUNCTION(6, "SPI5_SCK"),
+ STM32_FUNCTION(7, "SAI1_MCLK_B"),
+ STM32_FUNCTION(9, "UART7_TX"),
+ STM32_FUNCTION(10, "QUADSPI_BK1_IO2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(88, "PF8"),
+ STM32_FUNCTION(0, "GPIOF8"),
+ STM32_FUNCTION(6, "SPI5_MISO"),
+ STM32_FUNCTION(7, "SAI1_SCK_B"),
+ STM32_FUNCTION(9, "UART7_RTS"),
+ STM32_FUNCTION(10, "TIM13_CH1"),
+ STM32_FUNCTION(11, "QUADSPI_BK1_IO0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(89, "PF9"),
+ STM32_FUNCTION(0, "GPIOF9"),
+ STM32_FUNCTION(6, "SPI5_MOSI"),
+ STM32_FUNCTION(7, "SAI1_FS_B"),
+ STM32_FUNCTION(9, "UART7_CTS"),
+ STM32_FUNCTION(10, "TIM14_CH1"),
+ STM32_FUNCTION(11, "QUADSPI_BK1_IO1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(90, "PF10"),
+ STM32_FUNCTION(0, "GPIOF10"),
+ STM32_FUNCTION(10, "QUADSPI_CLK"),
+ STM32_FUNCTION(14, "DCMI_D11"),
+ STM32_FUNCTION(15, "LCD_DE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(91, "PF11"),
+ STM32_FUNCTION(0, "GPIOF11"),
+ STM32_FUNCTION(6, "SPI5_MOSI"),
+ STM32_FUNCTION(11, "SAI2_SD_B"),
+ STM32_FUNCTION(13, "FMC_SDNRAS"),
+ STM32_FUNCTION(14, "DCMI_D12"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(92, "PF12"),
+ STM32_FUNCTION(0, "GPIOF12"),
+ STM32_FUNCTION(13, "FMC_A6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(93, "PF13"),
+ STM32_FUNCTION(0, "GPIOF13"),
+ STM32_FUNCTION(5, "I2C4_SMBA"),
+ STM32_FUNCTION(7, "DFSDM_DATIN6"),
+ STM32_FUNCTION(13, "FMC_A7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(94, "PF14"),
+ STM32_FUNCTION(0, "GPIOF14"),
+ STM32_FUNCTION(5, "I2C4_SCL"),
+ STM32_FUNCTION(7, "DFSDM_CKIN6"),
+ STM32_FUNCTION(13, "FMC_A8"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(95, "PF15"),
+ STM32_FUNCTION(0, "GPIOF15"),
+ STM32_FUNCTION(5, "I2C4_SDA"),
+ STM32_FUNCTION(13, "FMC_A9"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(96, "PG0"),
+ STM32_FUNCTION(0, "GPIOG0"),
+ STM32_FUNCTION(13, "FMC_A10"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(97, "PG1"),
+ STM32_FUNCTION(0, "GPIOG1"),
+ STM32_FUNCTION(13, "FMC_A11"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(98, "PG2"),
+ STM32_FUNCTION(0, "GPIOG2"),
+ STM32_FUNCTION(13, "FMC_A12"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(99, "PG3"),
+ STM32_FUNCTION(0, "GPIOG3"),
+ STM32_FUNCTION(13, "FMC_A13"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(100, "PG4"),
+ STM32_FUNCTION(0, "GPIOG4"),
+ STM32_FUNCTION(13, "FMC_A14 FMC_BA0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(101, "PG5"),
+ STM32_FUNCTION(0, "GPIOG5"),
+ STM32_FUNCTION(13, "FMC_A15 FMC_BA1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(102, "PG6"),
+ STM32_FUNCTION(0, "GPIOG6"),
+ STM32_FUNCTION(13, "FMC_NE3"),
+ STM32_FUNCTION(14, "DCMI_D12"),
+ STM32_FUNCTION(15, "LCD_R7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(103, "PG7"),
+ STM32_FUNCTION(0, "GPIOG7"),
+ STM32_FUNCTION(7, "SAI1_MCLK_A"),
+ STM32_FUNCTION(9, "USART6_CK"),
+ STM32_FUNCTION(13, "FMC_INT"),
+ STM32_FUNCTION(14, "DCMI_D13"),
+ STM32_FUNCTION(15, "LCD_CLK"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(104, "PG8"),
+ STM32_FUNCTION(0, "GPIOG8"),
+ STM32_FUNCTION(6, "SPI6_NSS"),
+ STM32_FUNCTION(8, "SPDIF_RX2"),
+ STM32_FUNCTION(9, "USART6_RTS"),
+ STM32_FUNCTION(12, "ETH_PPS_OUT"),
+ STM32_FUNCTION(13, "FMC_SDCLK"),
+ STM32_FUNCTION(15, "LCD_G7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(105, "PG9"),
+ STM32_FUNCTION(0, "GPIOG9"),
+ STM32_FUNCTION(6, "SPI1_MISO"),
+ STM32_FUNCTION(8, "SPDIF_RX3"),
+ STM32_FUNCTION(9, "USART6_RX"),
+ STM32_FUNCTION(10, "QUADSPI_BK2_IO2"),
+ STM32_FUNCTION(11, "SAI2_FS_B"),
+ STM32_FUNCTION(12, "SDMMC2_D0"),
+ STM32_FUNCTION(13, "FMC_NE2 FMC_NCE"),
+ STM32_FUNCTION(14, "DCMI_VSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(106, "PG10"),
+ STM32_FUNCTION(0, "GPIOG10"),
+ STM32_FUNCTION(6, "SPI1_NSS I2S1_WS"),
+ STM32_FUNCTION(10, "LCD_G3"),
+ STM32_FUNCTION(11, "SAI2_SD_B"),
+ STM32_FUNCTION(12, "SDMMC2_D1"),
+ STM32_FUNCTION(13, "FMC_NE3"),
+ STM32_FUNCTION(14, "DCMI_D2"),
+ STM32_FUNCTION(15, "LCD_B2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(107, "PG11"),
+ STM32_FUNCTION(0, "GPIOG11"),
+ STM32_FUNCTION(6, "SPI1_SCK I2S1_CK"),
+ STM32_FUNCTION(8, "SPDIF_RX0"),
+ STM32_FUNCTION(11, "SDMMC2_D2"),
+ STM32_FUNCTION(12, "ETH_MII_TX_EN ETH_RMII_TX_EN"),
+ STM32_FUNCTION(14, "DCMI_D3"),
+ STM32_FUNCTION(15, "LCD_B3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(108, "PG12"),
+ STM32_FUNCTION(0, "GPIOG12"),
+ STM32_FUNCTION(4, "LPTIM1_IN1"),
+ STM32_FUNCTION(6, "SPI6_MISO"),
+ STM32_FUNCTION(8, "SPDIF_RX1"),
+ STM32_FUNCTION(9, "USART6_RTS"),
+ STM32_FUNCTION(10, "LCD_B4"),
+ STM32_FUNCTION(12, "SDMMC2_D3"),
+ STM32_FUNCTION(13, "FMC_NE4"),
+ STM32_FUNCTION(15, "LCD_B1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(109, "PG13"),
+ STM32_FUNCTION(0, "GPIOG13"),
+ STM32_FUNCTION(1, "TRACED0"),
+ STM32_FUNCTION(4, "LPTIM1_OUT"),
+ STM32_FUNCTION(6, "SPI6_SCK"),
+ STM32_FUNCTION(9, "USART6_CTS"),
+ STM32_FUNCTION(12, "ETH_MII_TXD0 ETH_RMII_TXD0"),
+ STM32_FUNCTION(13, "FMC_A24"),
+ STM32_FUNCTION(15, "LCD_R0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(110, "PG14"),
+ STM32_FUNCTION(0, "GPIOG14"),
+ STM32_FUNCTION(1, "TRACED1"),
+ STM32_FUNCTION(4, "LPTIM1_ETR"),
+ STM32_FUNCTION(6, "SPI6_MOSI"),
+ STM32_FUNCTION(9, "USART6_TX"),
+ STM32_FUNCTION(10, "QUADSPI_BK2_IO3"),
+ STM32_FUNCTION(12, "ETH_MII_TXD1 ETH_RMII_TXD1"),
+ STM32_FUNCTION(13, "FMC_A25"),
+ STM32_FUNCTION(15, "LCD_B0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(111, "PG15"),
+ STM32_FUNCTION(0, "GPIOG15"),
+ STM32_FUNCTION(9, "USART6_CTS"),
+ STM32_FUNCTION(13, "FMC_SDNCAS"),
+ STM32_FUNCTION(14, "DCMI_D13"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(112, "PH0"),
+ STM32_FUNCTION(0, "GPIOH0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(113, "PH1"),
+ STM32_FUNCTION(0, "GPIOH1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(114, "PH2"),
+ STM32_FUNCTION(0, "GPIOH2"),
+ STM32_FUNCTION(4, "LPTIM1_IN2"),
+ STM32_FUNCTION(10, "QUADSPI_BK2_IO0"),
+ STM32_FUNCTION(11, "SAI2_SCK_B"),
+ STM32_FUNCTION(12, "ETH_MII_CRS"),
+ STM32_FUNCTION(13, "FMC_SDCKE0"),
+ STM32_FUNCTION(15, "LCD_R0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(115, "PH3"),
+ STM32_FUNCTION(0, "GPIOH3"),
+ STM32_FUNCTION(10, "QUADSPI_BK2_IO1"),
+ STM32_FUNCTION(11, "SAI2_MCLK_B"),
+ STM32_FUNCTION(12, "ETH_MII_COL"),
+ STM32_FUNCTION(13, "FMC_SDNE0"),
+ STM32_FUNCTION(15, "LCD_R1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(116, "PH4"),
+ STM32_FUNCTION(0, "GPIOH4"),
+ STM32_FUNCTION(5, "I2C2_SCL"),
+ STM32_FUNCTION(10, "LCD_G5"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_NXT"),
+ STM32_FUNCTION(15, "LCD_G4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(117, "PH5"),
+ STM32_FUNCTION(0, "GPIOH5"),
+ STM32_FUNCTION(5, "I2C2_SDA"),
+ STM32_FUNCTION(6, "SPI5_NSS"),
+ STM32_FUNCTION(13, "FMC_SDNWE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(118, "PH6"),
+ STM32_FUNCTION(0, "GPIOH6"),
+ STM32_FUNCTION(5, "I2C2_SMBA"),
+ STM32_FUNCTION(6, "SPI5_SCK"),
+ STM32_FUNCTION(10, "TIM12_CH1"),
+ STM32_FUNCTION(12, "ETH_MII_RXD2"),
+ STM32_FUNCTION(13, "FMC_SDNE1"),
+ STM32_FUNCTION(14, "DCMI_D8"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(119, "PH7"),
+ STM32_FUNCTION(0, "GPIOH7"),
+ STM32_FUNCTION(5, "I2C3_SCL"),
+ STM32_FUNCTION(6, "SPI5_MISO"),
+ STM32_FUNCTION(12, "ETH_MII_RXD3"),
+ STM32_FUNCTION(13, "FMC_SDCKE1"),
+ STM32_FUNCTION(14, "DCMI_D9"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(120, "PH8"),
+ STM32_FUNCTION(0, "GPIOH8"),
+ STM32_FUNCTION(5, "I2C3_SDA"),
+ STM32_FUNCTION(13, "FMC_D16"),
+ STM32_FUNCTION(14, "DCMI_HSYNC"),
+ STM32_FUNCTION(15, "LCD_R2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(121, "PH9"),
+ STM32_FUNCTION(0, "GPIOH9"),
+ STM32_FUNCTION(5, "I2C3_SMBA"),
+ STM32_FUNCTION(10, "TIM12_CH2"),
+ STM32_FUNCTION(13, "FMC_D17"),
+ STM32_FUNCTION(14, "DCMI_D0"),
+ STM32_FUNCTION(15, "LCD_R3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(122, "PH10"),
+ STM32_FUNCTION(0, "GPIOH10"),
+ STM32_FUNCTION(3, "TIM5_CH1"),
+ STM32_FUNCTION(5, "I2C4_SMBA"),
+ STM32_FUNCTION(13, "FMC_D18"),
+ STM32_FUNCTION(14, "DCMI_D1"),
+ STM32_FUNCTION(15, "LCD_R4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(123, "PH11"),
+ STM32_FUNCTION(0, "GPIOH11"),
+ STM32_FUNCTION(3, "TIM5_CH2"),
+ STM32_FUNCTION(5, "I2C4_SCL"),
+ STM32_FUNCTION(13, "FMC_D19"),
+ STM32_FUNCTION(14, "DCMI_D2"),
+ STM32_FUNCTION(15, "LCD_R5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(124, "PH12"),
+ STM32_FUNCTION(0, "GPIOH12"),
+ STM32_FUNCTION(3, "TIM5_CH3"),
+ STM32_FUNCTION(5, "I2C4_SDA"),
+ STM32_FUNCTION(13, "FMC_D20"),
+ STM32_FUNCTION(14, "DCMI_D3"),
+ STM32_FUNCTION(15, "LCD_R6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(125, "PH13"),
+ STM32_FUNCTION(0, "GPIOH13"),
+ STM32_FUNCTION(4, "TIM8_CH1N"),
+ STM32_FUNCTION(9, "UART4_TX"),
+ STM32_FUNCTION(10, "CAN1_TX"),
+ STM32_FUNCTION(13, "FMC_D21"),
+ STM32_FUNCTION(15, "LCD_G2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(126, "PH14"),
+ STM32_FUNCTION(0, "GPIOH14"),
+ STM32_FUNCTION(4, "TIM8_CH2N"),
+ STM32_FUNCTION(9, "UART4_RX"),
+ STM32_FUNCTION(10, "CAN1_RX"),
+ STM32_FUNCTION(13, "FMC_D22"),
+ STM32_FUNCTION(14, "DCMI_D4"),
+ STM32_FUNCTION(15, "LCD_G3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(127, "PH15"),
+ STM32_FUNCTION(0, "GPIOH15"),
+ STM32_FUNCTION(4, "TIM8_CH3N"),
+ STM32_FUNCTION(13, "FMC_D23"),
+ STM32_FUNCTION(14, "DCMI_D11"),
+ STM32_FUNCTION(15, "LCD_G4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(128, "PI0"),
+ STM32_FUNCTION(0, "GPIOI0"),
+ STM32_FUNCTION(3, "TIM5_CH4"),
+ STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+ STM32_FUNCTION(13, "FMC_D24"),
+ STM32_FUNCTION(14, "DCMI_D13"),
+ STM32_FUNCTION(15, "LCD_G5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(129, "PI1"),
+ STM32_FUNCTION(0, "GPIOI1"),
+ STM32_FUNCTION(4, "TIM8_BKIN2"),
+ STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+ STM32_FUNCTION(13, "FMC_D25"),
+ STM32_FUNCTION(14, "DCMI_D8"),
+ STM32_FUNCTION(15, "LCD_G6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(130, "PI2"),
+ STM32_FUNCTION(0, "GPIOI2"),
+ STM32_FUNCTION(4, "TIM8_CH4"),
+ STM32_FUNCTION(6, "SPI2_MISO"),
+ STM32_FUNCTION(13, "FMC_D26"),
+ STM32_FUNCTION(14, "DCMI_D9"),
+ STM32_FUNCTION(15, "LCD_G7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(131, "PI3"),
+ STM32_FUNCTION(0, "GPIOI3"),
+ STM32_FUNCTION(4, "TIM8_ETR"),
+ STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+ STM32_FUNCTION(13, "FMC_D27"),
+ STM32_FUNCTION(14, "DCMI_D10"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(132, "PI4"),
+ STM32_FUNCTION(0, "GPIOI4"),
+ STM32_FUNCTION(4, "TIM8_BKIN"),
+ STM32_FUNCTION(11, "SAI2_MCLK_A"),
+ STM32_FUNCTION(13, "FMC_NBL2"),
+ STM32_FUNCTION(14, "DCMI_D5"),
+ STM32_FUNCTION(15, "LCD_B4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(133, "PI5"),
+ STM32_FUNCTION(0, "GPIOI5"),
+ STM32_FUNCTION(4, "TIM8_CH1"),
+ STM32_FUNCTION(11, "SAI2_SCK_A"),
+ STM32_FUNCTION(13, "FMC_NBL3"),
+ STM32_FUNCTION(14, "DCMI_VSYNC"),
+ STM32_FUNCTION(15, "LCD_B5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(134, "PI6"),
+ STM32_FUNCTION(0, "GPIOI6"),
+ STM32_FUNCTION(4, "TIM8_CH2"),
+ STM32_FUNCTION(11, "SAI2_SD_A"),
+ STM32_FUNCTION(13, "FMC_D28"),
+ STM32_FUNCTION(14, "DCMI_D6"),
+ STM32_FUNCTION(15, "LCD_B6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(135, "PI7"),
+ STM32_FUNCTION(0, "GPIOI7"),
+ STM32_FUNCTION(4, "TIM8_CH3"),
+ STM32_FUNCTION(11, "SAI2_FS_A"),
+ STM32_FUNCTION(13, "FMC_D29"),
+ STM32_FUNCTION(14, "DCMI_D7"),
+ STM32_FUNCTION(15, "LCD_B7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(136, "PI8"),
+ STM32_FUNCTION(0, "GPIOI8"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(137, "PI9"),
+ STM32_FUNCTION(0, "GPIOI9"),
+ STM32_FUNCTION(9, "UART4_RX"),
+ STM32_FUNCTION(10, "CAN1_RX"),
+ STM32_FUNCTION(13, "FMC_D30"),
+ STM32_FUNCTION(15, "LCD_VSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(138, "PI10"),
+ STM32_FUNCTION(0, "GPIOI10"),
+ STM32_FUNCTION(12, "ETH_MII_RX_ER"),
+ STM32_FUNCTION(13, "FMC_D31"),
+ STM32_FUNCTION(15, "LCD_HSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(139, "PI11"),
+ STM32_FUNCTION(0, "GPIOI11"),
+ STM32_FUNCTION(10, "LCD_G6"),
+ STM32_FUNCTION(11, "OTG_HS_ULPI_DIR"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(140, "PI12"),
+ STM32_FUNCTION(0, "GPIOI12"),
+ STM32_FUNCTION(15, "LCD_HSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(141, "PI13"),
+ STM32_FUNCTION(0, "GPIOI13"),
+ STM32_FUNCTION(15, "LCD_VSYNC"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(142, "PI14"),
+ STM32_FUNCTION(0, "GPIOI14"),
+ STM32_FUNCTION(15, "LCD_CLK"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(143, "PI15"),
+ STM32_FUNCTION(0, "GPIOI15"),
+ STM32_FUNCTION(10, "LCD_G2"),
+ STM32_FUNCTION(15, "LCD_R0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(144, "PJ0"),
+ STM32_FUNCTION(0, "GPIOJ0"),
+ STM32_FUNCTION(10, "LCD_R7"),
+ STM32_FUNCTION(15, "LCD_R1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(145, "PJ1"),
+ STM32_FUNCTION(0, "GPIOJ1"),
+ STM32_FUNCTION(15, "LCD_R2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(146, "PJ2"),
+ STM32_FUNCTION(0, "GPIOJ2"),
+ STM32_FUNCTION(14, "DSI_TE"),
+ STM32_FUNCTION(15, "LCD_R3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(147, "PJ3"),
+ STM32_FUNCTION(0, "GPIOJ3"),
+ STM32_FUNCTION(15, "LCD_R4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(148, "PJ4"),
+ STM32_FUNCTION(0, "GPIOJ4"),
+ STM32_FUNCTION(15, "LCD_R5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(149, "PJ5"),
+ STM32_FUNCTION(0, "GPIOJ5"),
+ STM32_FUNCTION(15, "LCD_R6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(150, "PJ6"),
+ STM32_FUNCTION(0, "GPIOJ6"),
+ STM32_FUNCTION(15, "LCD_R7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(151, "PJ7"),
+ STM32_FUNCTION(0, "GPIOJ7"),
+ STM32_FUNCTION(15, "LCD_G0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(152, "PJ8"),
+ STM32_FUNCTION(0, "GPIOJ8"),
+ STM32_FUNCTION(15, "LCD_G1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(153, "PJ9"),
+ STM32_FUNCTION(0, "GPIOJ9"),
+ STM32_FUNCTION(15, "LCD_G2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(154, "PJ10"),
+ STM32_FUNCTION(0, "GPIOJ10"),
+ STM32_FUNCTION(15, "LCD_G3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(155, "PJ11"),
+ STM32_FUNCTION(0, "GPIOJ11"),
+ STM32_FUNCTION(15, "LCD_G4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(156, "PJ12"),
+ STM32_FUNCTION(0, "GPIOJ12"),
+ STM32_FUNCTION(10, "LCD_G3"),
+ STM32_FUNCTION(15, "LCD_B0"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(157, "PJ13"),
+ STM32_FUNCTION(0, "GPIOJ13"),
+ STM32_FUNCTION(10, "LCD_G4"),
+ STM32_FUNCTION(15, "LCD_B1"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(158, "PJ14"),
+ STM32_FUNCTION(0, "GPIOJ14"),
+ STM32_FUNCTION(15, "LCD_B2"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(159, "PJ15"),
+ STM32_FUNCTION(0, "GPIOJ15"),
+ STM32_FUNCTION(15, "LCD_B3"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(160, "PK0"),
+ STM32_FUNCTION(0, "GPIOK0"),
+ STM32_FUNCTION(15, "LCD_G5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(161, "PK1"),
+ STM32_FUNCTION(0, "GPIOK1"),
+ STM32_FUNCTION(15, "LCD_G6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(162, "PK2"),
+ STM32_FUNCTION(0, "GPIOK2"),
+ STM32_FUNCTION(15, "LCD_G7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(163, "PK3"),
+ STM32_FUNCTION(0, "GPIOK3"),
+ STM32_FUNCTION(15, "LCD_B4"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(164, "PK4"),
+ STM32_FUNCTION(0, "GPIOK4"),
+ STM32_FUNCTION(15, "LCD_B5"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(165, "PK5"),
+ STM32_FUNCTION(0, "GPIOK5"),
+ STM32_FUNCTION(15, "LCD_B6"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(166, "PK6"),
+ STM32_FUNCTION(0, "GPIOK6"),
+ STM32_FUNCTION(15, "LCD_B7"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+ STM32_PIN(
+ PINCTRL_PIN(167, "PK7"),
+ STM32_FUNCTION(0, "GPIOK7"),
+ STM32_FUNCTION(15, "LCD_DE"),
+ STM32_FUNCTION(16, "EVENTOUT"),
+ STM32_FUNCTION(17, "ANALOG")
+ ),
+};
+
+static struct stm32_pinctrl_match_data stm32f769_match_data = {
+ .pins = stm32f769_pins,
+ .npins = ARRAY_SIZE(stm32f769_pins),
+};
+
+static const struct of_device_id stm32f769_pctrl_match[] = {
+ {
+ .compatible = "st,stm32f769-pinctrl",
+ .data = &stm32f769_match_data,
+ },
+ { }
+};
+
+static struct platform_driver stm32f769_pinctrl_driver = {
+ .probe = stm32_pctl_probe,
+ .driver = {
+ .name = "stm32f769-pinctrl",
+ .of_match_table = stm32f769_pctrl_match,
+ },
+};
+
+static int __init stm32f769_pinctrl_init(void)
+{
+ return platform_driver_register(&stm32f769_pinctrl_driver);
+}
+arch_initcall(stm32f769_pinctrl_init);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: pinctrl: Add st, stm32f769-pinctrl compatible to stm32-pinctrl
From: Alexandre Torgue @ 2017-12-11 8:54 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland,
Jonathan Corbet, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel
Add new compatible for stm32f769 MCU.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
index 58c2a4c..fd7a4c7 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -11,6 +11,7 @@ Required properies:
"st,stm32f429-pinctrl"
"st,stm32f469-pinctrl"
"st,stm32f746-pinctrl"
+ "st,stm32f769-pinctrl"
"st,stm32h743-pinctrl"
- #address-cells: The value of this property must be 1
- #size-cells : The value of this property must be 1
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 11/12] cpufreq: Add module to register cpufreq on Krait CPUs
From: Viresh Kumar @ 2017-12-11 8:39 UTC (permalink / raw)
To: Sricharan R
Cc: mturquette, sboyd, devicetree, linux-pm, linux-arm-msm,
linux-kernel, linux-arm-kernel
In-Reply-To: <1512726150-7204-12-git-send-email-sricharan@codeaurora.org>
On 08-12-17, 15:12, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Register a cpufreq-generic device whenever we detect that a
> "qcom,krait" compatible CPU is present in DT.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,pvs.txt | 38 ++++
> drivers/cpufreq/Kconfig.arm | 9 +
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/qcom-cpufreq.c | 204 +++++++++++++++++++++
> 4 files changed, 252 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
> create mode 100644 drivers/cpufreq/qcom-cpufreq.c
This must be done differently as we have enhanced OPP core to support such
hardware. Look at: dev_pm_opp_set_prop_name() and the binding around it
(opp-microvolt-<name>). Talk to Stephen, he was part of all those discussions.
--
viresh
^ permalink raw reply
* Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813
From: Quentin Schulz @ 2017-12-11 8:35 UTC (permalink / raw)
To: Jonathan Cameron
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20171210164910.415da6f5@archlinux>
Hi Jonathan,
On 10/12/2017 17:49, Jonathan Cameron wrote:
> On Mon, 4 Dec 2017 15:12:51 +0100
> Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> The X-Powers AXP813 PMIC has got some slight differences from
>> AXP20X/AXP22X PMICs:
>> - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24
>> for AXP20X/AXP22X,
>> - the constant charge current formula is different,
>>
>> It also has a bit to tell whether the battery percentage returned by the
>> PMIC is valid.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> I'd use switch statements when matching the IDs as that'll be more elegant
> as you perhaps add further devices going forward...
>
> Other than that, looks good to me.
>
Well, I was wondering if it shouldn't be better to define a structure
for each device containing their quirks, functions, etc... like it is
done for the ADC or the ACIN power supply driver part.
struct axp20x_data {
bool has_valid_fg_reg;
void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val);
void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val);
int get_max_voltage(struct axp20x_batt_ps *axp, int *val);
[...]
};
static const struct of_device_id axp20x_battery_ps_id[] = {
{ .compatible = "x-powers,axp209-battery-power-supply", .data = (void
*)&axp209_data, }, {}
};
void probe()
{
[...]
axp20x_batt->info = of_device_get_match_data(&pdev->dev);
[...]
}
Sebastian, any objection on doing this?
Thanks,
Quentin
> Jonathan
>
>> ---
>> drivers/power/supply/axp20x_battery.c | 44 +++++++++++++++++++++++++++-
>> 1 file changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
>> index 7494f0f..cb30302 100644
>> --- a/drivers/power/supply/axp20x_battery.c
>> +++ b/drivers/power/supply/axp20x_battery.c
>> @@ -46,6 +46,8 @@
>> #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
>> #define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
>>
>> +#define AXP813_CHRG_CTRL1_TGT_4_35V (3 << 5)
>> +
>> #define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
>> #define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
>>
>> @@ -123,10 +125,41 @@ static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
>> return 0;
>> }
>>
>> +static int axp813_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
>> + int *val)
>> +{
>> + int ret, reg;
>> +
>> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
>> + if (ret)
>> + return ret;
>> +
>> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
>
> You could do a lookup based from a table instead which might
> be ever so slightly more elegant..
>
>> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
>> + *val = 4100000;
>> + break;
>> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
>> + *val = 4150000;
>> + break;
>> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
>> + *val = 4200000;
>> + break;
>> + case AXP813_CHRG_CTRL1_TGT_4_35V:
>> + *val = 4350000;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
>> {
>> if (axp->axp_id == AXP209_ID)
>> *val = *val * 100000 + 300000;
>> + else if (axp->axp_id == AXP813_ID)
>> + *val = *val * 200000 + 200000;
>> else
>> *val = *val * 150000 + 300000;
>
> Switch?
>
>> }
>> @@ -135,6 +168,8 @@ static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val)
>> {
>> if (axp->axp_id == AXP209_ID)
>> *val = (*val - 300000) / 100000;
>> + else if (axp->axp_id == AXP813_ID)
>> + *val = (*val - 200000) / 200000;
>> else
>> *val = (*val - 300000) / 150000;
>> }
>> @@ -269,7 +304,8 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
>> if (ret)
>> return ret;
>>
>> - if (axp20x_batt->axp_id == AXP221_ID &&
>> + if ((axp20x_batt->axp_id == AXP221_ID ||
>> + axp20x_batt->axp_id == AXP813_ID) &&
>> !(reg & AXP22X_FG_VALID))
>> return -EINVAL;
>>
>> @@ -284,6 +320,9 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
>> if (axp20x_batt->axp_id == AXP209_ID)
>> return axp20x_battery_get_max_voltage(axp20x_batt,
>> &val->intval);
>> + else if (axp20x_batt->axp_id == AXP813_ID)
>> + return axp813_battery_get_max_voltage(axp20x_batt,
>> + &val->intval);
>> return axp22x_battery_get_max_voltage(axp20x_batt,
>> &val->intval);
>
> Worth converting to a switch statement to make it more elegant for future
> devices?
>
>>
>> @@ -467,6 +506,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
>> }, {
>> .compatible = "x-powers,axp221-battery-power-supply",
>> .data = (void *)AXP221_ID,
>> + }, {
>> + .compatible = "x-powers,axp813-battery-power-supply",
>> + .data = (void *)AXP813_ID,
>> }, { /* sentinel */ },
>> };
>> MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 12/12] cpufreq: dt: Reintroduce independent_clocks platform data
From: Viresh Kumar @ 2017-12-11 8:33 UTC (permalink / raw)
To: Sricharan R
Cc: mturquette, sboyd, devicetree, linux-pm, linux-arm-msm,
linux-kernel, linux-arm-kernel
In-Reply-To: <1512726150-7204-13-git-send-email-sricharan@codeaurora.org>
On 08-12-17, 15:12, Sricharan R wrote:
> The Platform data was removed earlier by,
> 'commit eb96924acddc ("cpufreq: dt: Kill platform-data")'
> since there were no users at that time.
> Now this is required when the each of the cpu clocks
> can be scaled independently, which is the case
> for krait cores. So reintroduce it.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
> drivers/cpufreq/cpufreq-dt.c | 7 ++++++-
> drivers/cpufreq/cpufreq-dt.h | 6 ++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
Nack. This information should come from the OPP layer (Hint:
dev_pm_opp_of_get_sharing_cpus()).
--
viresh
^ permalink raw reply
* Re: [PATCH 1/5] arm: dts: sun8i: a83t: Add I2C0 node
From: Chen-Yu Tsai @ 2017-12-11 8:31 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mylène Josserand, Rob Herring, Mark Rutland, Russell King,
Chen-Yu Tsai, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
simon.budig-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB, linux-kernel,
devicetree, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20171211071513.xgni3t6ihmeeebre-ZC1Zs529Oq4@public.gmane.org>
On Mon, Dec 11, 2017 at 3:15 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Fri, Dec 08, 2017 at 10:54:15PM +0100, Mylène Josserand wrote:
>> Add I2C0 node for A83T.
>>
>> Signed-off-by: Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> arch/arm/boot/dts/sun8i-a83t.dtsi | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> index 19acae1b4089..848cf3f19962 100644
>> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> @@ -177,6 +177,17 @@
>> #dma-cells = <1>;
>> };
>>
>> + i2c0: i2c@01c2ac00 {
>
> Drop the leading 0, it generates a warning in dtc.
>
>> + compatible = "allwinner,sun6i-a31-i2c";
>
> Can you add a SoC-specific compatible there please?
>
>> + reg = <0x01c2ac00 0x400>;
>
> And you should order your nodes by physical address.
I have a similar patch in my A83T I2S branch:
https://github.com/wens/linux/commit/8b76a3e555b39a06f3f8182e4ff5645de4c4cbc3
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC
From: Quentin Schulz @ 2017-12-11 8:18 UTC (permalink / raw)
To: Jonathan Cameron
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20171210163655.43fbd3c0@archlinux>
Hi Jonathan,
On 10/12/2017 17:36, Jonathan Cameron wrote:
> On Mon, 4 Dec 2017 15:12:48 +0100
> Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
>> The X-Powers AXP813 PMIC is really close to what is already done for
>> AXP20X/AXP22X.
>>
>> There are two pairs of bits to set the rate (one for Voltage and Current
>> measurements and one for TS/GPIO0 voltage measurements) instead of one.
>
> This would normally imply we need to split the device into two logical
> IIO devices. However, that only becomes relevant if we are using
> buffered output which this driver doesn't support.
> > It'll be nasty to deal with this if we add that support down the line
> though. Up to you though as it's more likely to be your problem than
> anyone else's :)
>
I have no plans for supporting buffered output for the AXPs at the
moment. But that's an interesting (and important) limitation to raise.
Wouldn't be more of a hack to have two IIO devices representing the
actual same IP?
> For now you could elect to support the different sampling frequencies
> if you wanted to but just providing controls for each channel.
>
I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
info_mask_separate for each channel?
> Given the driver doesn't currently expose these at all (I think)
> this is all rather immaterial ;)
I'm not giving the user the option to chose the sampling frequency for
now. I have no plans to do it either, but I think it would be rather
simple to later add support for setting frequency sampling since we only
need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
exist yet. Don't you think? Am I missing something?
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] dt-bindings: net: wireless: Add sg parameters dts parsing
From: Chi-Hsien Lin @ 2017-12-11 8:11 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, brcm80211-dev-list,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w, Arend van Spriel,
Kalle Valo
broken_sg_support, sd_head_align, and sd_sgentry_align are used in
brcmfmac code but not configurable in dts file. Add the parsing logic.
Now they can be configured like below in dts:
brcm,broken_sg_support;
brcm,sd_head_align = <4>;
brcm,sd_sgentry_align = <4>;
Signed-off-by: Chi-hsien Lin <chi-hsien.lin-+wT8y+m8/X5BDgjK7y7TUQ@public.gmane.org>
---
.../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index 86602f2..4d42f0d 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -17,6 +17,11 @@ Optional properties:
When not specified the device will use in-band SDIO interrupts.
- interrupt-names : name of the out-of-band interrupt, which must be set
to "host-wake".
+ - broken_sg_support : flag for broken sg list support of SDIO host controller.
+ Set this to true if the SDIO host controller has higher align
+ requirement than 32 bytes for each scatterlist item.
+ - sg_head_align : alignment requirement for start of data buffer.
+ - sg_sgentry_align : length alignment requirement for each sg entry.
Example:
@@ -36,5 +41,8 @@ mmc3: mmc@1c12000 {
interrupt-parent = <&pio>;
interrupts = <10 8>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
+ brcm,broken_sg_support;
+ brcm,sd_head_align = <4>;
+ brcm,sd_sgentry_align = <4>;
};
};
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 05/20] ARM: dts: aspeed: Add proper clock references
From: Arnd Bergmann @ 2017-12-11 8:09 UTC (permalink / raw)
To: Joel Stanley
Cc: Rob Herring, Mark Rutland, Andrew Jeffery, Patrick Venture,
Xo Wang, Lei YU, Cédric Le Goater, Benjamin Herrenschmidt,
Jeremy Kerr, DTML, Linux ARM, Linux Kernel Mailing List,
linux-aspeed-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20171211050704.20621-6-joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> The existing device trees use fixed-clocks in order to boot without a
> clk driver. The newly added clk driver provides proper clock support,
> including gating, so we move the device trees over to properly request
> clocks.
>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
Can you clarify here whether this will break running old kernels with
new DT files or vice versa, and why this is ok here?
I assume you have thought about it carefully, but I'd still like to document
every time we intentionally break compatibility like this. It looks like
you too care to merge the driver changes and the DT binding change first,
so we don't get any bisection problems.
What I'm not completely clear about is the difference between the
"aspeed,g4-scu" binding and the "aspeed,ast2400-scu" binding.
They are listed as equal in
Documentation/devicetree/bindings/mfd/aspeed-scu.txt, so why do you
change it here?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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