* [PATCH] i2c: add 'single-master' property to generic bindings
From: Wolfram Sang @ 2020-05-27 11:30 UTC (permalink / raw)
To: linux-i2c; +Cc: devicetree, Rob Herring, Wolfram Sang, Laine Jaakko EXT
It is useful to know if we are the only master on a given bus. Because
this is a HW description of the bus, add it to the generic bindings.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Laine Jaakko EXT <ext-jaakko.laine@vaisala.com>
---
We added 'multi-master' back then because most busses are single-master
and 'multi-master' was the exception. In hindsight, however, this was a
bad choice because 'multi-master' should be the default, i.e. if you
know nothing, you should assume there could be another master.
So, we can't deduce that a missing 'multi-master' property automatically
means 'single-master'. That's why we need this new property.
I am a bit tempted to mark 'multi-master' as deprecated because the
default should be multi-master. However, it might also be a bit more
descriptive to let "no property" still mean "we don't know". I'd be
thankful for more opinions here.
Thanks and happy hacking,
Wolfram
Documentation/devicetree/bindings/i2c/i2c.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 819436b48fae..438ae123107e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -70,7 +70,12 @@ wants to support one of the below features, it should adapt these bindings.
- multi-master
states that there is another master active on this bus. The OS can use
this information to adapt power management to keep the arbitration awake
- all the time, for example.
+ all the time, for example. Can not be combined with 'single-master'.
+
+- single-master
+ states that there is no other master active on this bus. The OS can use
+ this information to detect a stalled bus more reliably, for example.
+ Can not be combined with 'multi-master'.
Required properties (per child device)
--------------------------------------
--
2.20.1
^ permalink raw reply related
* RE: [PATCH] i2c: xiic: Support disabling multi-master in DT
From: Laine Jaakko EXT @ 2020-05-27 11:27 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rob Herring, Shubhrajyoti Datta, linux-i2c@vger.kernel.org,
michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <20200527110732.GA4875@ninjato>
Thanks Wolfram for helping me out with this.
I will make Version 2 patch with proposed changes.
Happy hacking for you too!
-Jaakko
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: ASoC: renesas,rsnd: Add r8a7742 support
From: Mark Brown @ 2020-05-27 11:25 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Liam Girdwood,
alsa-devel, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar
In-Reply-To: <1590526904-13855-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Tue, May 26, 2020 at 10:01:43PM +0100, Lad Prabhakar wrote:
> Examples with soctypes are:
> + - "renesas,rcar_sound-r8a7742" (RZ/G1H)
> - "renesas,rcar_sound-r8a7743" (RZ/G1M)
> - "renesas,rcar_sound-r8a7744" (RZ/G1N)
> - "renesas,rcar_sound-r8a7745" (RZ/G1E)
I'd expect a matching patch adding this compatible to the driver.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
From: Lad, Prabhakar @ 2020-05-27 11:22 UTC (permalink / raw)
To: Rob Herring
Cc: Lad Prabhakar, Geert Uytterhoeven, Jens Axboe, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux I2C, Linux MMC List, netdev, Linux-Renesas,
Linux Watchdog Mailing List
In-Reply-To: <20200527013136.GA838011@bogus>
Hi Rob,
On Wed, May 27, 2020 at 2:31 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 04:08:56PM +0100, Lad Prabhakar wrote:
> > RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
> > therefore add relevant documentation.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> > ---
> > Documentation/devicetree/bindings/watchdog/renesas,wdt.txt | 1 +
> > 1 file changed, 1 insertion(+)
>
> Meanwhile in the DT tree, converting this schema landed. Can you prepare
> a version based on the schema.
>
This was kindly taken care by Stephen during merge in linux-next [1].
[1] https://lkml.org/lkml/2020/5/26/32
Cheers,
--Prabhakar
> Rob
^ permalink raw reply
* Re: [PATCH v3 01/12] scripts/dtc: check: Add 10bit/slave i2c reg flags support
From: Serge Semin @ 2020-05-27 11:20 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Frank Rowand,
Alexey Malahov, Thomas Bogendoerfer, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527011704.GA808104@bogus>
On Tue, May 26, 2020 at 07:17:04PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 12:55:17AM +0300, Serge Semin wrote:
> > Recently the I2C-controllers slave interface support was added to the
> > kernel I2C subsystem. In this case Linux can be used as, for example,
> > a I2C EEPROM machine. See [1] for details. Other than instantiating
> > the EEPROM-slave device from user-space there is a way to declare the
> > device in dts. In this case firstly the I2C bus controller must support
> > the slave interface. Secondly I2C-slave sub-node of that controller
> > must have "reg"-property with flag I2C_OWN_SLAVE_ADDRESS set (flag is
> > declared in [2]). That flag is declared as (1 << 30), which when set
> > makes dtc unhappy about too big address set for a I2C-slave:
> >
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
> >
> > Similar problem would have happened if we had set the 10-bit address
> > flag I2C_TEN_BIT_ADDRESS in the "reg"-property.
> >
> > In order to fix the problem we suggest to alter the I2C-bus reg-check
> > algorithm, so one would be aware of the upper bits set. Normally if no
> > flag specified, the 7-bit address is expected in the "reg"-property.
> > If I2C_TEN_BIT_ADDRESS is set, then the 10-bit address check will be
> > performed. The I2C_OWN_SLAVE_ADDRESS flag will be just ignored.
> >
> > [1] Documentation/i2c/slave-interface.rst
> > [2] include/dt-bindings/i2c/i2c.h
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Cc: linux-mips@vger.kernel.org
> > Cc: linux-i2c@vger.kernel.org
> > ---
> > scripts/dtc/checks.c | 13 +++++++++----
> > 1 file changed, 9 insertions(+), 4 deletions(-)
>
> I've lost track of who all I've said this to already for this issue, but
> patches to dtc should be against upstream and a version of this has been
> sent there already. But it seems they've lost interest in addressing the
> review comments. So feel free to send another one. The same comment
> applies here.
There is another patch in this series:
[PATCH v3 04/12] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
which is also waiting for your review. I've updated it as you requested.
Could you take a look at that too?
-Sergey
>
> Rob
^ permalink raw reply
* Re: [PATCH v6 8/9] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: Mark Brown @ 2020-05-27 11:18 UTC (permalink / raw)
To: dillon min
Cc: Rob Herring, p.zabel, Maxime Coquelin, Alexandre Torgue,
thierry.reding, Sam Ravnborg, Dave Airlie, Daniel Vetter,
Michael Turquette, Stephen Boyd, Andy Shevchenko,
Noralf Trønnes, Linus Walleij,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-spi, linux-stm32,
open list:DRM PANEL DRIVERS, linux-clk, Hua Dillon
In-Reply-To: <CAL9mu0JA=XRTj_HONQGtj74X05TAV0__dW2At0AAeymwNvJhEw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
On Wed, May 27, 2020 at 06:45:53PM +0800, dillon min wrote:
> sorry, forget to remove these two patch from this submits, will not
> include it in later submits
> which ack other's review result.
Ah, OK - no problem.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: xiic: Support disabling multi-master in DT
From: Wolfram Sang @ 2020-05-27 11:07 UTC (permalink / raw)
To: Laine Jaakko EXT
Cc: Rob Herring, Shubhrajyoti Datta, linux-i2c@vger.kernel.org,
michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <AM0PR06MB51857F4CDC7AE643CE160F9ED4A60@AM0PR06MB5185.eurprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
Hi Jaako,
> The changes required to this patch at XIIC driver from suggested DT
> changes are pretty minor. Basically only checking a different
> property, reversing logic and some naming changes. I can make these
> changes already for the driver if this solution is what will be
> chosen, or would you prefer to still think about this?
I think we can go forward this way. Although I didn't find an example, I
am quite sure YAML format can have exclusive properties. If not, it
should be added ;) I'll try again to get some information from people
more experienced with YAML. But we don't depend on it.
> Regarding the device tree changes: I am not very familiar with the
> needed documentation changes, YAML bindings or what needs to be done
> for new bindings in general. Would you prefer to still consider them
> and/or get these subsystem level bindings done by someone more
> familiar with them? Another option would be for me to try find time to
> do the suggested bindings changes anyway, but it will likely require
> some effort from me to familiarize with device tree bindings changes
> and schedule the time for it.
No need to. Luckily, the I2C main bindings file is still text, so it is
easy to modify. I will send a patch out in a few minutes, so you can
base your driver code on that. Converting to YAML is a completely
different step, not related to your patch here. (Sidenote: I am looking
for volunteers to do that)
I think this covers it?
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH v13 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
From: Vishal Sagar @ 2020-05-27 11:02 UTC (permalink / raw)
To: Luca Ceresoli, Hyun Kwon, laurent.pinchart@ideasonboard.com,
mchehab@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com,
Michal Simek, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Dinesh Kumar, Sandip Kothari,
Jacopo Mondi
Cc: Hyun Kwon
In-Reply-To: <e3ccf942-0a0d-1c4c-30bf-db9f127126f4@lucaceresoli.net>
Hi Luca,
Thanks for reviewing!
> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Monday, May 25, 2020 6:44 PM
> To: Vishal Sagar <vsagar@xilinx.com>; Hyun Kwon <hyunk@xilinx.com>;
> laurent.pinchart@ideasonboard.com; mchehab@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Michal Simek
> <michals@xilinx.com>; linux-media@vger.kernel.org;
> devicetree@vger.kernel.org; hans.verkuil@cisco.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Dinesh Kumar
> <dineshk@xilinx.com>; Sandip Kothari <sandipk@xilinx.com>; Jacopo Mondi
> <jacopo@jmondi.org>
> Cc: Hyun Kwon <hyunk@xilinx.com>
> Subject: Re: [PATCH v13 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx
> Subsystem driver
>
> Hi Vishal,
>
> thanks. I have only a few minor nitpicking comments.
>
> On 12/05/20 17:19, Vishal Sagar wrote:
> > The Xilinx MIPI CSI-2 Rx Subsystem soft IP is used to capture images
> > from MIPI CSI-2 camera sensors and output AXI4-Stream video data ready
> > for image processing. Please refer to PG232 for details.
> >
> > The CSI2 Rx controller filters out all packets except for the packets
> > with data type fixed in hardware. RAW8 packets are always allowed to
> > pass through.
> >
> > It is also used to setup and handle interrupts and enable the core. It
> > logs all the events in respective counters between streaming on and off.
> >
> > The driver supports only the video format bridge enabled configuration.
> > Some data types like YUV 422 10bpc, RAW16, RAW20 are supported when
> > the CSI v2.0 feature is enabled in design. When the VCX feature is
> > enabled, the maximum number of virtual channels becomes 16 from 4.
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> [...]
>
> > +static int xcsi2rxss_start_stream(struct xcsi2rxss_state *state) {
> > + int ret = 0;
> > +
> > + /* enable core */
> > + xcsi2rxss_set(state, XCSI_CCR_OFFSET, XCSI_CCR_ENABLE);
> > +
> > + ret = xcsi2rxss_soft_reset(state);
> > + if (ret < 0) {
>
> 'if (ret)' is enough, it's a classic nonzero-on-error return value.
>
Agreed. I will fix it in next version.
> > +/**
> > + * xcsi2rxss_irq_handler - Interrupt handler for CSI-2
> > + * @irq: IRQ number
> > + * @data: Pointer to device state
> > + *
> > + * In the interrupt handler, a list of event counters are updated for
> > + * corresponding interrupts. This is useful to get status / debug.
> > + *
> > + * Return: IRQ_HANDLED after handling interrupts */ static
> > +irqreturn_t xcsi2rxss_irq_handler(int irq, void *data) {
> > + struct xcsi2rxss_state *state = (struct xcsi2rxss_state *)data;
> > + struct device *dev = state->dev;
> > + u32 status;
> > +
> > + status = xcsi2rxss_read(state, XCSI_ISR_OFFSET) &
> XCSI_ISR_ALLINTR_MASK;
> > + xcsi2rxss_write(state, XCSI_ISR_OFFSET, status);
> > +
> > + /* Received a short packet */
> > + if (status & XCSI_ISR_SPFIFONE) {
> > + u32 count = 0;
> > +
> > + /*
> > + * Drain generic short packet FIFO by reading max 31
> > + * (fifo depth) short packets from fifo or till fifo is empty.
> > + */
> > + for (count = 0; count < XCSI_SPKT_FIFO_DEPTH; ++count) {
> > + u32 spfifostat, spkt;
> > +
> > + spkt = xcsi2rxss_read(state, XCSI_SPKTR_OFFSET);
> > + dev_dbg(dev, "Short packet = 0x%08x\n", spkt);
> > + spfifostat = xcsi2rxss_read(state, XCSI_ISR_OFFSET);
> > + spfifostat &= XCSI_ISR_SPFIFONE;
> > + if (!spfifostat)
> > + break;
> > + xcsi2rxss_write(state, XCSI_ISR_OFFSET, spfifostat);
> > + }
> > + }
> > +
> > + /* Short packet FIFO overflow */
> > + if (status & XCSI_ISR_SPFIFOF)
> > + dev_dbg_ratelimited(dev, "Short packet FIFO overflowed\n");
> > +
> > + /*
> > + * Stream line buffer full
> > + * This means there is a backpressure from downstream IP
> > + */
> > + if (status & XCSI_ISR_SLBF) {
> > + dev_alert_ratelimited(dev, "Stream Line Buffer Full!\n");
> > +
> > + /* disable interrupts */
> > + xcsi2rxss_clr(state, XCSI_IER_OFFSET, XCSI_IER_INTR_MASK);
> > + xcsi2rxss_clr(state, XCSI_GIER_OFFSET, XCSI_GIER_GIE);
> > +
> > + /* disable core */
> > + xcsi2rxss_clr(state, XCSI_CCR_OFFSET, XCSI_CCR_ENABLE);
> > + state->streaming = false;
> > +
> > + /*
> > + * The IP needs to be hard reset before it can be used now.
> > + * This will be done in streamoff.
> > + */
> > +
> > + /*
> > + * TODO: Notify the whole pipeline with v4l2_subdev_notify()
> to
> > + * inform userspace.
> > + */
> > + }
> > +
> > + /* Increment event counters */
> > + if (status & XCSI_ISR_ALLINTR_MASK) {
> > + unsigned int i;
> > +
> > + for (i = 0; i < XCSI_NUM_EVENTS; i++) {
> > + if (!(status & xcsi2rxss_events[i].mask))
> > + continue;
> > + state->events[i]++;
> > + dev_dbg_ratelimited(dev, "%s: %u\n",
> > + xcsi2rxss_events[i].name,
> > + state->events[i]);
> > + }
> > +
> > + if (status & XCSI_ISR_VCXFE && state->en_vcx) {
> > + u32 vcxstatus;
> > +
> > + vcxstatus = xcsi2rxss_read(state, XCSI_VCXR_OFFSET);
> > + vcxstatus &= XCSI_VCXR_VCERR;
> > + for (i = 0; i < XCSI_VCX_NUM_EVENTS; i++) {
> > + if (!(vcxstatus & (1 << i)))
>
> You can use BIT(i) instead of (1 << i).
Yep that is a good alternative.
>
> > +/**
> > + * xcsi2rxss_set_format - This is used to set the pad format
> > + * @sd: Pointer to V4L2 Sub device structure
> > + * @cfg: Pointer to sub device pad information structure
> > + * @fmt: Pointer to pad level media bus format
> > + *
> > + * This function is used to set the pad format. Since the pad format
> > +is fixed
> > + * in hardware, it can't be modified on run time. So when a format
> > +set is
> > + * requested by application, all parameters except the format type is
> > +saved
> > + * for the pad and the original pad format is sent back to the application.
> > + *
> > + * Return: 0 on success
> > + */
> > +static int xcsi2rxss_set_format(struct v4l2_subdev *sd,
> > + struct v4l2_subdev_pad_config *cfg,
> > + struct v4l2_subdev_format *fmt)
> > +{
> > + struct xcsi2rxss_state *xcsi2rxss = to_xcsi2rxssstate(sd);
> > + struct v4l2_mbus_framefmt *__format;
> > + u32 dt;
> > +
> > + /* only sink pad format can be updated */
>
> This comment should be placed...
>
> > + mutex_lock(&xcsi2rxss->lock);
> > +
> > + /*
> > + * Only the format->code parameter matters for CSI as the
> > + * CSI format cannot be changed at runtime.
> > + * Ensure that format to set is copied to over to CSI pad format
> > + */
> > + __format = __xcsi2rxss_get_pad_format(xcsi2rxss, cfg,
> > + fmt->pad, fmt->which);
> > +
>
> ...here.
>
Ok will move the comment here.
> > + if (fmt->pad == XVIP_PAD_SOURCE) {
> > + fmt->format = *__format;
> > + mutex_unlock(&xcsi2rxss->lock);
> > + return 0;
> > + }
> > +
> > + /*
> > + * RAW8 is supported in all datatypes. So if requested media bus
> format
> > + * is of RAW8 type, then allow to be set. In case core is configured to
> > + * other RAW, YUV422 8/10 or RGB888, set appropriate media bus
> format.
> > + */
> > + dt = xcsi2rxss_get_dt(fmt->format.code);
> > + if (dt != xcsi2rxss->datatype && dt != XCSI_DT_RAW8) {
> > + dev_dbg(xcsi2rxss->dev, "Unsupported media bus format");
> > + /* set the default format for the data type */
> > + fmt->format.code = xcsi2rxss_get_nth_mbus(xcsi2rxss-
> >datatype,
> > + 0);
> > + }
> > +
> > + *__format = fmt->format;
> > + mutex_unlock(&xcsi2rxss->lock);
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * xcsi2rxss_enum_mbus_code - Handle pixel format enumeration
> > + * @sd : pointer to v4l2 subdev structure
> > + * @cfg: V4L2 subdev pad configuration
> > + * @code : pointer to v4l2_subdev_mbus_code_enum structure
>
> Remove space before colon here.
>
> Looks good otherwise, and my comments are minor details so:
> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
That’s great. Thanks for reviewing this again.
>
> I tried to runtime test this driver as well replacing the v10 driver that I'm using
> at the moment, but ran into many problems, apparently in the media entity
> navigation. The diff between v10 and v13 does not justify these problems, so
> I'm assuming v13 needs a more recent kernel than the 4.19 I'm currentl stuck
> on.
>
> --
> Luca Ceresoli
Regards
Vishal Sagar
^ permalink raw reply
* Re: [PATCH V5 4/8] clk: qcom: Add DT bindings for ipq6018 apss clock controller
From: Sivaprakash Murugesan @ 2020-05-27 11:00 UTC (permalink / raw)
To: Stephen Boyd, agross, bjorn.andersson, devicetree, jassisinghbrar,
linux-arm-msm, linux-clk, linux-kernel, mturquette, robh+dt
In-Reply-To: <159054661322.88029.16916819048155217664@swboyd.mtv.corp.google.com>
On 5/27/2020 8:00 AM, Stephen Boyd wrote:
> Quoting Sivaprakash Murugesan (2020-05-24 03:04:42)
>> add dt-binding for ipq6018 apss clock controller
> Capitalize 'add' because it starts the sentence.
ok.
>
>> Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
>> ---
>> include/dt-bindings/clock/qcom,apss-ipq.h | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>> create mode 100644 include/dt-bindings/clock/qcom,apss-ipq.h
>>
>> diff --git a/include/dt-bindings/clock/qcom,apss-ipq.h b/include/dt-bindings/clock/qcom,apss-ipq.h
>> new file mode 100644
>> index 0000000..77b6e05
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/qcom,apss-ipq.h
>> @@ -0,0 +1,12 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#ifndef _DT_BINDINGS_CLOCK_QCA_APSS_IPQ6018_H
>> +#define _DT_BINDINGS_CLOCK_QCA_APSS_IPQ6018_H
>> +
>> +#define APCS_ALIAS0_CLK_SRC 0
>> +#define APCS_ALIAS0_CORE_CLK 1
> Will this be extended in the future? I hope that this is the only two
> clks we expect to see in this file.
yes you're right. these are the only two clocks.
^ permalink raw reply
* Re: [PATCH v5 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses
From: Kishon Vijay Abraham I @ 2020-05-27 10:49 UTC (permalink / raw)
To: Rob Herring
Cc: Tom Joseph, Lorenzo Pieralisi, Bjorn Helgaas, PCI,
linux-kernel@vger.kernel.org, Arnd Bergmann, Greg Kroah-Hartman,
devicetree, linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqLy9T8O81stSW8RHpsUXFFjon80VG9-Jgync1eVR4iTew@mail.gmail.com>
Hi Rob,
On 5/26/2020 8:42 PM, Rob Herring wrote:
> On Sun, May 24, 2020 at 9:30 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>> Hi Rob,
>>
>> On 5/22/2020 9:24 PM, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 9:37 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>
>>>> Certain platforms like TI's J721E using Cadence PCIe IP can perform only
>>>> 32-bit accesses for reading or writing to Cadence registers. Convert all
>>>> read and write accesses to 32-bit in Cadence PCIe driver in preparation
>>>> for adding PCIe support in TI's J721E SoC.
>>>
>>> Looking more closely I don't think cdns_pcie_ep_assert_intx is okay
>>> with this and never can be given the PCI_COMMAND and PCI_STATUS
>>> registers are in the same word (IIRC, that's the main reason 32-bit
>>> config space accesses are broken). So this isn't going to work at
>>
>> right, PCI_STATUS has write '1' to clear bits and there's a chance that it
>> could be reset while raising legacy interrupt. While this cannot be avoided for
>> TI's J721E, other platforms doesn't have to have this limitation.
>>> least for EP accesses. And maybe you need a custom .raise_irq() hook
>>> to minimize any problems (such as making the RMW atomic at least from
>>> the endpoint's perspective).
>>
>> This is to make sure EP doesn't update in-consistent state when RC is updating
>> the PCI_STATUS register? Since this involves two different systems, how do we
>> make this atomic?
>
> You can't make it atomic WRT both systems, but is there locking around
> each RMW? Specifically, are preemption and interrupts disabled to
> ensure time between a read and write are minimized? You wouldn't want
> interrupts disabled during the delay too though (i.e. around
> .raise_irq()).
Okay, I'll add spin spin_lock_irqsave() in cdns_pcie_write_sz(). As you also
pointed below that delay for legacy interrupt is wrong and it has to be fixed
(with a later series).
How do you want to handle cdns_pcie_ep_fn_writew() now? Because now we are
changing the default implementation to perform only 32-bit access (used for
legacy interrupt, msi-x interrupt and while writing standard headers) and it's
not okay only for legacy interrupts for platforms other than TI.
So just for legacy interrupt, you want me to add a different accessor which
does not perform 32-bit writes (while we add a different .raise_irq for TI
platform?
>
> BTW, I've asked this question before, but aren't PCI legacy interrupts
> level triggered? If so, isn't generating a pulse wrong?
You are right. This is wrong and it has to be fixed. I'll work on this later.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH v6 8/9] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: dillon min @ 2020-05-27 10:45 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, p.zabel, Maxime Coquelin, Alexandre Torgue,
thierry.reding, Sam Ravnborg, Dave Airlie, Daniel Vetter,
Michael Turquette, Stephen Boyd, Andy Shevchenko,
Noralf Trønnes, Linus Walleij,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-spi, linux-stm32,
open list:DRM PANEL DRIVERS, linux-clk, Hua Dillon
In-Reply-To: <20200527095109.GA5308@sirena.org.uk>
On Wed, May 27, 2020 at 5:51 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, May 27, 2020 at 03:27:32PM +0800, dillon.minfei@gmail.com wrote:
> > From: dillon min <dillon.minfei@gmail.com>
> >
> > in l3gd20 driver startup, there is a setup failed error return from
> > stm32 spi driver
>
> Please do not submit new versions of already applied patches, please
> submit incremental updates to the existing code. Modifying existing
> commits creates problems for other users building on top of those
> commits so it's best practice to only change pubished git commits if
> absolutely essential.
Hi Mark,
sorry, forget to remove these two patch from this submits, will not
include it in later submits
which ack other's review result.
thanks.
best regards
Dillon,
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: usb: Add documentation for SG trb cache size quirk
From: Tejas Joglekar @ 2020-05-27 10:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Tejas Joglekar, linux-usb, devicetree,
Rob Herring
Cc: John Youn
In-Reply-To: <cover.1590415123.git.joglekar@synopsys.com>
This commit adds the documentation for sgl-trb-cache-size-quirk, and
snps,sgl-trb-cache-size-quirk property. These when set enables the
quirk for XHCI driver for consolidation of sg list into a temporary
buffer when small buffer sizes are scattered over the sg list not
making up to MPS or total transfer size within TRB cache size with
Synopsys xHC.
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
---
Documentation/devicetree/bindings/usb/dwc3.txt | 4 ++++
Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 +++
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index d03edf9d3935..0fcbaa51f66e 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -102,6 +102,10 @@ Optional properties:
this and tx-thr-num-pkt-prd to a valid, non-zero value
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
+ - snps,sgl-trb-cache-size-quirk: enable sg list consolidation - host mode
+ only. Set to use SG buffers of at least MPS size
+ by consolidating smaller SG buffers list into a
+ single buffer.
- <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
- snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index dc025f126d71..c53eb19ae67e 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -44,6 +44,9 @@ Optional properties:
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
- imod-interval-ns: default interrupt moderation interval is 5000ns
- phys : see usb-hcd.yaml in the current directory
+ - sgl-trb-cache-size-quirk: set if you need to consolidate sg list into a
+ temporary buffer when small SG buffer sizes does not make upto MPS
+ size or total transfer size across the TRB cache size.
additionally the properties from usb-hcd.yaml (in the current directory) are
supported.
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/4] Add logic to consolidate TRBs for Synopsys xHC
From: Tejas Joglekar @ 2020-05-27 10:40 UTC (permalink / raw)
To: Felipe Balbi, Greg Kroah-Hartman, Tejas Joglekar, linux-usb,
devicetree, Rob Herring, Mathias Nyman
Cc: John Youn
The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for
each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8
for HS. The controller loads and updates the TRB cache from the
transfer ring in system memory whenever the driver issues a start
transfer or update transfer command.
For chained TRBs, the Synopsys xHC requires that the total amount of
bytes for all TRBs loaded in the TRB cache be greater than or equal to
1 MPS. Or the chain ends within the TRB cache (with a last TRB).
If this requirement is not met, the controller will not be able to
send or receive a packet and it will hang causing a driver timeout and
error.
This patch set adds logic to the XHCI driver to detect and prevent this
from happening along with the quirk to enable this logic for Synopsys
HAPS platform.
Based on Mathias's feedback on previous implementation where consolidation
was done in TRB cache, with this patch series the implementation is done
during mapping of the URB by consolidating the SG list into a temporary
buffer if the SG list buffer sizes within TRB_CACHE_SIZE is less than MPS.
Changes since v2:
- Modified the xhci_unmap_temp_buffer function to unmap dma and clear
the dma flag
- Removed RFC tag
Changes since v1:
- Comments from Greg are addressed on [PATCH 4/4] and [PATCH 1/4]
- Renamed the property and quirk as in other patches based on [PATCH 1/4]
Tejas Joglekar (4):
dt-bindings: usb: Add documentation for SG trb cache size quirk
usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK
usb: dwc3: Add device property sgl-trb-cache-size-quirk
usb: xhci: Use temporary buffer to consolidate SG
Documentation/devicetree/bindings/usb/dwc3.txt | 4 +
Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 +
drivers/usb/dwc3/core.c | 2 +
drivers/usb/dwc3/core.h | 2 +
drivers/usb/dwc3/dwc3-haps.c | 1 +
drivers/usb/dwc3/host.c | 6 +-
drivers/usb/host/xhci-pci.c | 3 +
drivers/usb/host/xhci-plat.c | 4 +
drivers/usb/host/xhci-ring.c | 2 +-
drivers/usb/host/xhci.c | 135 +++++++++++++++++++++
drivers/usb/host/xhci.h | 5 +
11 files changed, 165 insertions(+), 2 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v3 11/12] i2c: designware: Move reg-space remapping into a dedicated function
From: Andy Shevchenko @ 2020-05-27 10:18 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Andy Shevchenko,
Mika Westerberg, Alexey Malahov, Thomas Bogendoerfer, Rob Herring,
linux-mips, devicetree, linux-i2c, Linux Kernel Mailing List
In-Reply-To: <20200527095034.xd52qv45nzcnkbnz@mobilestation>
On Wed, May 27, 2020 at 12:50 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
> On Wed, May 27, 2020 at 12:26:09PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 4:03 AM Serge Semin
> > <Sergey.Semin@baikalelectronics.ru> wrote:
...
> > Wolfram, did my last series make your tree? I think there was a patch
> > that touched this part...
>
> Right. It is there. I'll rebase the series on top of the i2c/for-next branch.
Ah, my memory did a trick. Thank you!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V7 3/7] i2c: i2c-qcom-geni: Add interconnect support
From: Wolfram Sang @ 2020-05-27 10:04 UTC (permalink / raw)
To: Akash Asthana
Cc: gregkh, agross, bjorn.andersson, broonie, mark.rutland, robh+dt,
linux-i2c, linux-spi, devicetree, swboyd, mgautam, linux-arm-msm,
linux-serial, mka, dianders, msavaliy, evgreen
In-Reply-To: <1590497690-29035-4-git-send-email-akashast@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Tue, May 26, 2020 at 06:24:46PM +0530, Akash Asthana wrote:
> Get the interconnect paths for I2C based Serial Engine device
> and vote according to the bus speed of the driver.
>
> Signed-off-by: Akash Asthana <akashast@codeaurora.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 8/9] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: Mark Brown @ 2020-05-27 9:51 UTC (permalink / raw)
To: dillon.minfei
Cc: robh+dt, p.zabel, mcoquelin.stm32, alexandre.torgue,
thierry.reding, sam, airlied, daniel, mturquette, sboyd,
andy.shevchenko, noralf, linus.walleij, devicetree,
linux-arm-kernel, linux-kernel, linux-spi, linux-stm32, dri-devel,
linux-clk, dillonhua
In-Reply-To: <1590564453-24499-9-git-send-email-dillon.minfei@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
On Wed, May 27, 2020 at 03:27:32PM +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> in l3gd20 driver startup, there is a setup failed error return from
> stm32 spi driver
Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code. Modifying existing
commits creates problems for other users building on top of those
commits so it's best practice to only change pubished git commits if
absolutely essential.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 11/12] i2c: designware: Move reg-space remapping into a dedicated function
From: Serge Semin @ 2020-05-27 9:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Andy Shevchenko,
Mika Westerberg, Alexey Malahov, Thomas Bogendoerfer, Rob Herring,
linux-mips, devicetree, linux-i2c, Linux Kernel Mailing List
In-Reply-To: <CAHp75Veygd2y8Tp28p+ZX8Hm_u975QdqatKbsNOG9tNz6HOCAg@mail.gmail.com>
On Wed, May 27, 2020 at 12:26:09PM +0300, Andy Shevchenko wrote:
> On Wed, May 27, 2020 at 4:03 AM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> wrote:
> >
> > This is a preparation patch before adding a quirk with custom registers
> > map creation required for the Baikal-T1 System I2C support. Since we've
> > touched this code anyway let's replace
> > platform_get_resource()-devm_ioremap_resource() tuple with ready-to-use
> > helper devm_platform_get_and_ioremap_resource().
>
> ...
>
> > +static int dw_i2c_plat_request_regs(struct dw_i2c_dev *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev->dev);
>
> > + int ret = 0;
>
> Redundant.
>
> > + dev->base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
>
> What's the point of this API if you don't use resource parameter?
>
> > + if (IS_ERR(dev->base))
> > + ret = PTR_ERR(dev->base);
> > +
> > + return ret;
>
> return PTR_ERR_OR_ZERO(dev->base);
>
> > +}
>
> > - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - dev->base = devm_ioremap_resource(&pdev->dev, mem);
> > - if (IS_ERR(dev->base))
> > - return PTR_ERR(dev->base);
>
> Wolfram, did my last series make your tree? I think there was a patch
> that touched this part...
Right. It is there. I'll rebase the series on top of the i2c/for-next branch.
-Serge
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 01/12] scripts/dtc: check: Add 10bit/slave i2c reg flags support
From: Serge Semin @ 2020-05-27 9:46 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Frank Rowand,
Alexey Malahov, Thomas Bogendoerfer, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527011704.GA808104@bogus>
On Tue, May 26, 2020 at 07:17:04PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 12:55:17AM +0300, Serge Semin wrote:
> > Recently the I2C-controllers slave interface support was added to the
> > kernel I2C subsystem. In this case Linux can be used as, for example,
> > a I2C EEPROM machine. See [1] for details. Other than instantiating
> > the EEPROM-slave device from user-space there is a way to declare the
> > device in dts. In this case firstly the I2C bus controller must support
> > the slave interface. Secondly I2C-slave sub-node of that controller
> > must have "reg"-property with flag I2C_OWN_SLAVE_ADDRESS set (flag is
> > declared in [2]). That flag is declared as (1 << 30), which when set
> > makes dtc unhappy about too big address set for a I2C-slave:
> >
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
> >
> > Similar problem would have happened if we had set the 10-bit address
> > flag I2C_TEN_BIT_ADDRESS in the "reg"-property.
> >
> > In order to fix the problem we suggest to alter the I2C-bus reg-check
> > algorithm, so one would be aware of the upper bits set. Normally if no
> > flag specified, the 7-bit address is expected in the "reg"-property.
> > If I2C_TEN_BIT_ADDRESS is set, then the 10-bit address check will be
> > performed. The I2C_OWN_SLAVE_ADDRESS flag will be just ignored.
> >
> > [1] Documentation/i2c/slave-interface.rst
> > [2] include/dt-bindings/i2c/i2c.h
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Cc: linux-mips@vger.kernel.org
> > Cc: linux-i2c@vger.kernel.org
> > ---
> > scripts/dtc/checks.c | 13 +++++++++----
> > 1 file changed, 9 insertions(+), 4 deletions(-)
>
> I've lost track of who all I've said this to already for this issue, but
> patches to dtc should be against upstream and a version of this has been
> sent there already. But it seems they've lost interest in addressing the
> review comments. So feel free to send another one. The same comment
> applies here.
Agreed. Rob, could you also take a look at the patch
[PATCH v3 03/12] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
from this series? You must have missed that. I've created that patch in
accordance with your suggestion from v2:
https://lore.kernel.org/linux-i2c/20200511160924.GA9628@bogus/
-Sergey
>
> Rob
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add Purism Librem 5 section to the list
From: Marco Felsch @ 2020-05-27 9:40 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200514155737.12160-2-martin.kepplinger@puri.sm>
On 20-05-14 17:57, Martin Kepplinger wrote:
> Add development information for the devicetree files for hardware
> by Purism SPC.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0abba1aff1ae..176efec31010 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13775,6 +13775,14 @@ T: git git://linuxtv.org/media_tree.git
> F: Documentation/admin-guide/media/pulse8-cec.rst
> F: drivers/media/cec/usb/pulse8/
>
> +PURISM LIBREM 5
> +M: Purism Kernel Team <kernel@puri.sm>
> +S: Supported
> +B: https://source.puri.sm/Librem5/linux-next/issues
> +T: https://source.puri.sm/Librem5/linux-next
> +F: arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
> +F: arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
Is it okay to take care of all imx8mq-librem5* files?
F: arch/arm64/boot/dts/freescale/imx8mq-librem5*
Regards,
Marco
> +
> PVRUSB2 VIDEO4LINUX DRIVER
> M: Mike Isely <isely@pobox.com>
> L: pvrusb2@isely.net (subscribers-only)
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Marco Felsch @ 2020-05-27 9:35 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
Hi Martin,
On 20-05-14 17:57, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
> 2 files changed, 1175 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index cd38d04da5a7..342579121f98 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
> new file mode 100644
> index 000000000000..95c105b4c120
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
> @@ -0,0 +1,1174 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018-2020 Purism SPC
> + */
> +
> +/dts-v1/;
> +
> +#include "dt-bindings/input/input.h"
> +#include "dt-bindings/pwm/pwm.h"
> +#include "dt-bindings/usb/pd.h"
> +#include "imx8mq.dtsi"
> +
> +/ {
> + model = "Purism Librem 5";
> + compatible = "purism,librem5", "fsl,imx8mq";
> +
> + backlight_dsi: backlight-dsi {
> + compatible = "led-backlight";
> + leds = <&led_backlight>;
> + brightness-levels = <255>;
> + default-brightness-level = <100>;
> + };
> +
> + bm818_codec: sound-wwan-codec {
> + compatible = "broadmobi,bm818", "option,gtm601";
> + #sound-dai-cells = <0>;
> + };
Please sort the node names alpabetical.
> +
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_keys>, <&pinctrl_hp>;
> +
> + hp-det {
> + label = "HP_DET";
> + gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
> + wakeup-source;
> + linux,code = <KEY_HP>;
Nit: I would add the wakeup-source behind the linux,code.
> + };
> +
> + vol-down {
> + label = "VOL_DOWN";
> + gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_VOLUMEDOWN>;
> + };
> +
> + vol-up {
> + label = "VOL_UP";
> + gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_VOLUMEUP>;
> + };
> + };
> +
> + pwmleds {
> + compatible = "pwm-leds";
> +
> + blue {
> + label = "phone:blue:front";
> + max-brightness = <248>;
> + pwms = <&pwm2 0 50000>;
> + };
> +
> + green {
> + label = "phone:green:front";
> + max-brightness = <248>;
> + pwms = <&pwm4 0 50000>;
> + };
> +
> + red {
> + label = "phone:red:front";
> + max-brightness = <248>;
> + pwms = <&pwm3 0 50000>;
> + };
> + };
> +
> + pmic_osc: clock-pmic {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + clock-output-names = "pmic_osc";
> + };
Please sort nodes alphabetical.
> +
> + reg_audio_pwr_en: regulator-audio-pwr-en {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_audiopwr>;
> + regulator-name = "AUDIO_PWR_EN";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
Why should this regulator be always on? The wm8962.c driver can handle
the regualtor enable/disable.
> + };
> +
> + reg_aud_1v8: regulator-audio-v1v8 {
^
regulator-audio-1v8?
> + compatible = "regulator-fixed";
> + regulator-name = "aud_1v8";
Is it intended to use capitalized and no-capitalized regulator-name's?
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <®_audio_pwr_en>;
> + };
Can we squash regulator-audio-pwr-en and regulator-audio-v1v8?
> +
> + reg_gnss: regulator-gnss {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gnsspwr>;
> + regulator-name = "GNSS";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 12 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_hub: regulator-hub {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hub_pwr>;
> + regulator-name = "HUB";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_lcd_1v8: regulator-lcd-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dsien>;
> + vin-supply = <®_vdd_1v8>;
> + enable-active-high;
> + gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> + };
This regulator is never used.
> +
> + reg_lcd_3v4: regulator-lcd-3v4 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_3v4";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dsibiasen>;
> + vin-supply = <®_vsys_3v4>;
> + enable-active-high;
> + gpio = <&gpio1 20 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_vdd_sen: regulator-vdd-sen {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_sen";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + reg_vdd_3v3: regulator-vdd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + reg_vdd_1v8: regulator-vdd-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + reg_vsys_3v4: regulator-vsys-3v4 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_3v4";
> + regulator-min-microvolt = <3400000>;
> + regulator-max-microvolt = <3400000>;
> + regulator-always-on;
> + };
> +
> + reg_3v3_wifi: regulator-3v3-wifi {
^
reg_wifi_3v3: regulator-wifi-3v3?
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "wm8962";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone",
> + "Microphone", "Headset Mic",
> + "Microphone", "Digital Mic",
> + "Speaker", "Speaker";
> + simple-audio-card,routing =
> + "Headphone", "HPOUTL",
> + "Headphone", "HPOUTR",
> + "Speaker", "SPKOUTL",
> + "Speaker", "SPKOUTR",
> + "Headset Mic", "MICBIAS",
> + "IN3R", "Headset Mic",
> + "DMICDAT", "Digital Mic";
> + simple-audio-card,cpu {
> + sound-dai = <&sai2>;
> + };
> + simple-audio-card,codec {
> + sound-dai = <&codec>;
> + clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
> + frame-master;
> + bitclock-master;
> + };
> + };
> +
> + sound-wwan {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "MODEM";
> + simple-audio-card,format = "i2s";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&sai6>;
> + frame-inversion;
> + };
> +
> + telephony_link_master: simple-audio-card,codec {
^
useless phandle?
> + sound-dai = <&bm818_codec>;
> + frame-master;
> + bitclock-master;
> + };
> + };
> +
> + vibrator {
> + compatible = "pwm-vibrator";
> + pwms = <&pwm1 0 1000000000 0>;
> + pwm-names = "enable";
> + vcc-supply = <®_vdd_3v3>;
> + };
> +};
> +
> +&A53_0 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&A53_1 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&A53_2 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&A53_3 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&clk {
> + assigned-clocks = <&clk IMX8MQ_AUDIO_PLL1>, <&clk IMX8MQ_AUDIO_PLL2>;
> + assigned-clock-rates = <786432000>, <722534400>;
> +};
Either I would bundle all clock settings here or within the sai nodes.
> +
> +&ddrc {
> + operating-points-v2 = <&ddrc_opp_table>;
> +
> + ddrc_opp_table: ddrc-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-25M {
> + opp-hz = /bits/ 64 <25000000>;
> + };
> + opp-100M {
> + opp-hz = /bits/ 64 <100000000>;
> + };
> + opp-800M {
> + opp-hz = /bits/ 64 <800000000>;
> + };
> + };
> +};
> +
> +&dphy {
> + status = "okay";
> +};
> +
> +&ecspi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi1>;
> + cs-gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
Missmatch with the pinctrl_ecspi1?
> + status = "okay";
Status is always the last property.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nor_flash: flash@0 {
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <1000000>;
> + reg = <0>;
> + };
> +};
> +
> +&gpio1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pmic_5v>;
> +
> + pmic-5v {
> + gpio-hog;
> + gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> + input;
> + };
> +};
> +
> +&iomuxc {
> + pinctrl_audiopwr: audiopwrgrp {
> + fsl,pins = <
> + /* AUDIO_POWER_EN_3V3 */
> + MX8MQ_IOMUXC_GPIO1_IO04_GPIO1_IO4 0x83
> + >;
> + };
> +
> + pinctrl_bl: blgrp {
> + fsl,pins = <
> + /* BACKLINGE_EN */
> + MX8MQ_IOMUXC_NAND_DQS_GPIO3_IO14 0x83
> + >;
> + };
> +
> + pinctrl_charger_in: chargeringrp {
> + fsl,pins = <
> + /* CHRG_INT */
> + MX8MQ_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x80
> + /* CHG_STATUS_B */
> + MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x80
> + >;
> + };
> +
> + pinctrl_dsibiasen: dsibiasengrp {
> + fsl,pins = <
> + /* DSI_BIAS_EN */
> + MX8MQ_IOMUXC_ENET_TD1_GPIO1_IO20 0x83
> + >;
> + };
> +
> + pinctrl_dsien: dsiengrp {
> + fsl,pins = <
> + /* DSI_EN_3V3 */
> + MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x83
> + >;
> + };
> +
> + pinctrl_ecspi1: spi1grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x83
> + MX8MQ_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x83
> + MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19
> + MX8MQ_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x83
> + /* SPI_SS1 */
> + MX8MQ_IOMUXC_UART4_RXD_GPIO5_IO28 0x19
> + >;
> + };
> +
> + pinctrl_gauge: gaugegrp {
> + fsl,pins = <
> + /* BAT_LOW */
> + MX8MQ_IOMUXC_SAI5_RXC_GPIO3_IO20 0x80
> + >;
> + };
> +
> + pinctrl_gnsspwr: gnsspwrgrp {
> + fsl,pins = <
> + /* GPS3V3_EN */
> + MX8MQ_IOMUXC_NAND_DATA06_GPIO3_IO12 0x83
> + >;
> + };
> +
> + pinctrl_haptic: hapticgrp {
> + fsl,pins = <
> + /* MOTO */
> + MX8MQ_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT 0x83
> + >;
> + };
> +
> + pinctrl_hp: hpgrp {
> + fsl,pins = <
> + /* HEADPHONE_DET_1V8 */
> + MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x180
> + >;
> + };
> +
> + pinctrl_hub_pwr: hubpwrgrp {
> + fsl,pins = <
> + /* HUB_PWR_3V3_EN */
> + MX8MQ_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x83
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x40000026
> + MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x40000026
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x40000026
> + MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x40000026
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x40000026
> + MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x40000026
> + >;
> + };
> +
> + pinctrl_i2c4: i2c4grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_I2C4_SCL_I2C4_SCL 0x40000026
> + MX8MQ_IOMUXC_I2C4_SDA_I2C4_SDA 0x40000026
> + >;
> + };
> +
> + pinctrl_keys: keysgrp {
> + fsl,pins = <
> + /* 4G_WAKE */
> + MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x80
> + /* PWR_KEY */
> + MX8MQ_IOMUXC_NAND_CLE_GPIO3_IO5 0x01C0
gpio3 5/15 are never used was this intended?
> + /* VOL- */
> + MX8MQ_IOMUXC_ENET_MDIO_GPIO1_IO17 0x01C0
> + /* VOL+ */
> + MX8MQ_IOMUXC_ENET_MDC_GPIO1_IO16 0x01C0
> + >;
> + };
> +
> + pinctrl_led_b: ledbgrp {
> + fsl,pins = <
> + /* LED_B */
> + MX8MQ_IOMUXC_GPIO1_IO13_PWM2_OUT 0x06
> + >;
> + };
> +
> + pinctrl_led_g: ledggrp {
> + fsl,pins = <
> + /* LED_G */
> + MX8MQ_IOMUXC_SAI3_MCLK_PWM4_OUT 0x06
> + >;
> + };
> +
> + pinctrl_led_r: ledrgrp {
> + fsl,pins = <
> + /* LED_R */
> + MX8MQ_IOMUXC_SPDIF_TX_PWM3_OUT 0x06
> + >;
> + };
> +
> + pinctrl_mag: maggrp {
> + fsl,pins = <
> + /* INT_MAG */
> + MX8MQ_IOMUXC_SAI5_RXD1_GPIO3_IO22 0x80
> + >;
> + };
> +
> + pinctrl_pmic: pmicgrp {
> + fsl,pins = <
> + /* PMIC_NINT */
> + MX8MQ_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x80
> + >;
> + };
> +
> + pinctrl_pmic_5v: pmic5vgrp {
> + fsl,pins = <
> + /* PMIC_5V */
> + MX8MQ_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x80
> + >;
> + };
> +
> + pinctrl_prox: proxgrp {
> + fsl,pins = <
> + /* INT_LIGHT */
> + MX8MQ_IOMUXC_NAND_DATA01_GPIO3_IO7 0x80
> + >;
> + };
> +
> + pinctrl_rtc: rtcgrp {
> + fsl,pins = <
> + /* RTC_INT */
> + MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x80
> + >;
> + };
> +
> + pinctrl_sai2: sai2grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0xd6
> + MX8MQ_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0xd6
> + MX8MQ_IOMUXC_SAI2_MCLK_SAI2_MCLK 0xd6
> + MX8MQ_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0xd6
> + MX8MQ_IOMUXC_SAI2_TXC_SAI2_TX_BCLK 0xd6
> + >;
> + };
> +
> + pinctrl_sai6: sai6grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SAI1_RXD5_SAI6_RX_DATA0 0xd6
> + MX8MQ_IOMUXC_SAI1_RXD6_SAI6_RX_SYNC 0xd6
> + MX8MQ_IOMUXC_SAI1_TXD4_SAI6_RX_BCLK 0xd6
> + MX8MQ_IOMUXC_SAI1_TXD5_SAI6_TX_DATA0 0xd6
> + >;
> + };
> +
> + pinctrl_tcpc: tcpcgrp {
> + fsl,pins = <
> + /* TCPC_INT */
> + MX8MQ_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x01C0
> + >;
> + };
> +
> + pinctrl_typec: typecgrp {
> + fsl,pins = <
> + /* TYPEC_MUX_EN */
> + MX8MQ_IOMUXC_GPIO1_IO11_GPIO1_IO11 0x83
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
> + MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
> + MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
> + >;
> + };
> +
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
> + MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x49
> + MX8MQ_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x49
> + MX8MQ_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x49
> + MX8MQ_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x49
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
> + MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
> + MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
> + MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
> + MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
> + MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
> + MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
> + MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
> + MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
> + MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
> + MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
> + MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcf
> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcf
> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcf
> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcf
> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcf
> + MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
> + >;
> + };
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + /* nWDOG */
> + MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x1f
> + >;
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <387000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +
> + typec_pd: usb-pd@3f {
> + compatible = "ti,tps6598x";
> + reg = <0x3f>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_typec>, <&pinctrl_tcpc>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> +
> + connector {
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb_con_hs: endpoint {
> + remote-endpoint = <&typec_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_con_ss: endpoint {
> + remote-endpoint = <&typec_ss>;
> + };
> + };
> + };
> + };
> + };
> +
> + pmic: pmic@4b {
> + compatible = "rohm,bd71837";
> + reg = <0x4b>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pmic>;
> + clocks = <&pmic_osc>;
> + clock-names = "osc";
> + clock-output-names = "pmic_clk";
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 GPIO_ACTIVE_LOW>;
> + interrupt-names = "irq";
> + rohm,reset-snvs-powered;
> +
> + regulators {
> + buck1_reg: BUCK1 {
> + regulator-name = "buck1";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-ramp-delay = <1250>;
> + rohm,dvs-run-voltage = <900000>;
> + rohm,dvs-idle-voltage = <850000>;
> + rohm,dvs-suspend-voltage = <800000>;
> + regulator-always-on;
> + };
> +
> + buck2_reg: BUCK2 {
> + regulator-name = "buck2";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-ramp-delay = <1250>;
> + rohm,dvs-run-voltage = <1000000>;
> + rohm,dvs-idle-voltage = <900000>;
> + regulator-always-on;
> + };
> +
> + buck3_reg: BUCK3 {
> + regulator-name = "buck3";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1300000>;
> + rohm,dvs-run-voltage = <900000>;
> + regulator-always-on;
> + };
> +
> + buck4_reg: BUCK4 {
> + regulator-name = "buck4";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1300000>;
> + rohm,dvs-run-voltage = <1000000>;
> + };
> +
> + buck5_reg: BUCK5 {
> + regulator-name = "buck5";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-always-on;
> + };
> +
> + buck6_reg: BUCK6 {
> + regulator-name = "buck6";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + buck7_reg: BUCK7 {
> + regulator-name = "buck7";
> + regulator-min-microvolt = <1605000>;
> + regulator-max-microvolt = <1995000>;
> + regulator-always-on;
> + };
> +
> + buck8_reg: BUCK8 {
> + regulator-name = "buck8";
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-always-on;
> + };
> +
> + ldo1_reg: LDO1 {
> + regulator-name = "ldo1";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + /* leave on for snvs power button */
> + regulator-always-on;
> + };
> +
> + ldo2_reg: LDO2 {
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + /* leave on for snvs power button */
> + regulator-always-on;
> + };
> +
> + ldo3_reg: LDO3 {
> + regulator-name = "ldo3";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + ldo4_reg: LDO4 {
> + regulator-name = "ldo4";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + ldo5_reg: LDO5 {
> + /* VDD_PHY_0V9 - MIPI and HDMI domains */
> + regulator-name = "ldo5";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + ldo6_reg: LDO6 {
> + /* VDD_PHY_0V9 - MIPI, HDMI and USB domains */
> + regulator-name = "ldo6";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + ldo7_reg: LDO7 {
> + /* VDD_PHY_3V3 - USB domain */
> + regulator-name = "ldo7";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
Out of curiosity, why did you marked all regulators as
regulator-always-on? I thought the librem5 is a smartphone.
> + };
> + };
> +
> + rtc@68 {
> + compatible = "microcrystal,rv4162";
> + reg = <0x68>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rtc>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&i2c2 {
> + clock-frequency = <387000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + magnetometer@1e {
> + compatible = "st,lsm9ds1-magn";
> + reg = <0x1e>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mag>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
> + vdd-supply = <®_vdd_sen>;
> + vddio-supply = <®_vdd_1v8>;
> + };
> +
> + regulator@3e {
> + compatible = "tps65132";
> + reg = <0x3e>;
> + reg_lcd_avdd: outp {
> + regulator-name = "lcd_avdd";
> + vin-supply = <®_lcd_3v4>;
> + };
> +
> + reg_lcd_avee: outn {
> + regulator-name = "lcd_avee";
> + vin-supply = <®_lcd_3v4>;
> + };
both phandles are not used.
> + };
> +
> + flash@53 {
> + compatible = "lm3560";
> + reg = <0x53>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + flash@0 {
> + reg = <0x0>;
> + flash-timeout-us = <150000>;
> + flash-max-microamp = <320000>;
> + led-max-microamp = <60000>;
> + label = "lm3560:flash";
> + };
> +
> + torch@1 {
> + reg = <0x1>;
> + led-max-microamp = <10000>;
> + label = "lm3560:torch";
> + };
> +
> + };
> +
> + prox@60 {
> + compatible = "vishay,vcnl4040";
> + reg = <0x60>;
> + pinctrl-0 = <&pinctrl_prox>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + accel-gyro@6a {
> + compatible = "st,lsm9ds1-imu";
> + reg = <0x6a>;
> + vdd-supply = <®_vdd_sen>;
> + vddio-supply = <®_vdd_1v8>;
> + mount-matrix = "1", "0", "0",
> + "0", "1", "0",
> + "0", "0", "-1";
> + };
> +};
> +
> +&i2c3 {
> + clock-frequency = <387000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + status = "okay";
> +
> + codec: wm8962@1a {
Please use generic names.
> + compatible = "wlf,wm8962";
> + reg = <0x1a>; // 0x4a is the test address
> + clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
> + assigned-clocks = <&clk IMX8MQ_CLK_SAI2>;
> + assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
> + assigned-clock-rates = <24576000>;
> + #sound-dai-cells = <0>;
> + mic-cfg = <0x200>;
> + DCVDD-supply = <®_aud_1v8>;
> + DBVDD-supply = <®_aud_1v8>;
> + AVDD-supply = <®_aud_1v8>;
> + CPVDD-supply = <®_aud_1v8>;
> + MICVDD-supply = <®_aud_1v8>;
> + PLLVDD-supply = <®_aud_1v8>;
> + SPKVDD1-supply = <®_vsys_3v4>;
> + SPKVDD2-supply = <®_vsys_3v4>;
> + gpio-cfg = <
> + 0x0000 /* n/c */
> + 0x0001 /* gpio2, 1: default */
> + 0x0013 /* gpio3, 2: dmicclk */
> + 0x0000 /* n/c, 3: default */
> + 0x8014 /* gpio5, 4: dmic_dat */
> + 0x0000 /* gpio6, 5: default */
> + >;
> + status = "okay";
status can be dropped
> + };
> +
> + backlight@36 {
> + compatible = "ti,lm36922";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_bl>;
> + reg = <0x36>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enable-gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
> + vled-supply = <®_vsys_3v4>;
> + ti,ovp-microvolt = <25000000>;
> +
> + led_backlight: led@0 {
> + reg = <0>;
> + label = "white:backlight_cluster";
> + linux,default-trigger = "backlight";
> + led-max-microamp = <20000>;
> + };
> + };
> +
> + touchscreen@38 {
> + compatible = "edt,edt-ft5506";
> + reg = <0x38>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
You need to mux the irq gpio.
> + irq-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
irq-gpios is not supported by the driver. We only have a
wake/reset-gpio.
> + touchscreen-size-x = <720>;
> + touchscreen-size-y = <1440>;
> + };
> +};
> +
> +&i2c4 {
> + clock-frequency = <387000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c4>;
> + status = "okay";
> +
> + bat: fuel-gauge@36 {
> + compatible = "maxim,max17055";
> + interrupt-parent = <&gpio3>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gauge>;
> + reg = <0x36>;
Please check that "reg" is always the 2nd property after the
"compatible".
> + maxim,over-heat-temp = <700>;
> + maxim,over-volt = <4500>;
> + maxim,rsns-microohm = <5000>;
> + };
> +
> + charger@6a { /* bq25895 */
> + compatible = "ti,bq25890";
The compatible should be "ti,bq25895" if it is a bq25895. So we can drop
the comment too.
> + reg = <0x6a>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_charger_in>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> + phys = <&usb3_phy0>;
> + ti,battery-regulation-voltage = <4192000>; /* 4.192V */
> + ti,charge-current = <1600000>; /* 1.6A */
> + ti,termination-current = <66000>; /* 66mA */
> + ti,precharge-current = <130000>; /* 130mA */
> + ti,minimum-sys-voltage = <3700000>; /* 3.7V */
> + ti,boost-voltage = <5000000>; /* 5V */
> + ti,boost-max-current = <50000>; /* 50mA */
> + ti,use-vinmin-threshold = <1>; /* enable VINDPM */
> + ti,vinmin-threshold = <3900000>; /* 3.9V */
I would only mention the units within a comment because comments like
this begin to divergence after you fix something.
Regards,
Marco
> + monitored-battery = <&bat>;
> + };
> +};
> +
> +&pgc_gpu {
> + power-supply = <&buck3_reg>;
> +};
> +
> +&pgc_mipi {
> + power-supply = <&ldo5_reg>;
> +};
> +
> +&pgc_vpu {
> + power-supply = <&buck4_reg>;
> +};
> +
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_haptic>;
> + status = "okay";
> +};
> +
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_led_b>;
> + status = "okay";
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_led_g>;
> + status = "okay";
> +};
> +
> +&pwm4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_led_r>;
> + status = "okay";
> +};
> +
> +&sai2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai2>;
> + assigned-clocks = <&clk IMX8MQ_CLK_SAI2>;
> + assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
> + assigned-clock-rates = <24576000>;
> + status = "okay";
> +};
> +
> +&sai6 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai6>;
> + assigned-clocks = <&clk IMX8MQ_CLK_SAI6>;
> + assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
> + assigned-clock-rates = <24576000>;
> + fsl,sai-synchronous-rx;
> + status = "okay";
> +};
> +
> +&snvs_pwrkey {
> + status = "okay";
> +};
> +
> +&snvs_rtc {
> + status = "disabled";
> +};
> +
> +&uart1 { /* console */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +&uart2 { /* TPS - GPS - DEBUG */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +
> + gnss {
> + compatible = "globaltop,pa6h";
> + vcc-supply = <®_gnss>;
> + current-speed = <9600>;
> + };
> +};
> +
> +&uart3 { /* SMC */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + status = "okay";
> +};
> +
> +&uart4 { /* BT */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + uart-has-rtscts;
> + status = "okay";
> +};
> +
> +&usb3_phy0 {
> + status = "okay";
> +};
> +
> +&usb3_phy1 {
> + vbus-supply = <®_hub>;
> + status = "okay";
> +};
> +
> +&usb_dwc3_0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dr_mode = "otg";
> + snps,dis_u3_susphy_quirk;
> + status = "okay";
> +
> + port@0 {
> + reg = <0>;
> +
> + typec_hs: endpoint {
> + remote-endpoint = <&usb_con_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + typec_ss: endpoint {
> + remote-endpoint = <&usb_con_ss>;
> + };
> + };
> +};
> +
> +&usb_dwc3_1 {
> + dr_mode = "host";
> + snps,dis_u2_susphy_quirk;
> + snps,dis_u3_susphy_quirk;
> + status = "okay";
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + bus-width = <8>;
> + vmmc-supply = <®_vdd_3v3>;
> + power-supply = <®_vdd_1v8>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> + bus-width = <4>;
> + vmmc-supply = <®_3v3_wifi>;
> + broken-cd;
> + disable-wp;
> + cap-sdio-irq;
> + keep-power-in-suspend;
> + wakeup-source;
> + status = "okay";
> +};
> +
> +&wdog1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + fsl,ext-reset-output;
> + status = "okay";
> +};
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/12] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Andy Shevchenko @ 2020-05-27 9:30 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Rob Herring, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Andy Shevchenko,
Mika Westerberg, linux-mips, linux-i2c, devicetree,
Linux Kernel Mailing List
In-Reply-To: <20200526215528.16417-4-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 1:00 AM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> i2c "reg" property. If it is the compiler will print a warning:
Shouldn't be dtc whatever tools fixed?
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
>
> In order to silence dtc up let's discard the flag from the DW I2C DT
> binding example for now. Just revert this commit when dtc is fixed.
Doesn't sound like a good idea. If user happens in between of these
ping-pong change, how they will know this subtle issue?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 11/12] i2c: designware: Move reg-space remapping into a dedicated function
From: Andy Shevchenko @ 2020-05-27 9:26 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Andy Shevchenko, Mika Westerberg,
Serge Semin, Alexey Malahov, Thomas Bogendoerfer, Rob Herring,
linux-mips, devicetree, linux-i2c, Linux Kernel Mailing List
In-Reply-To: <20200526215528.16417-12-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 4:03 AM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> This is a preparation patch before adding a quirk with custom registers
> map creation required for the Baikal-T1 System I2C support. Since we've
> touched this code anyway let's replace
> platform_get_resource()-devm_ioremap_resource() tuple with ready-to-use
> helper devm_platform_get_and_ioremap_resource().
...
> +static int dw_i2c_plat_request_regs(struct dw_i2c_dev *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev->dev);
> + int ret = 0;
Redundant.
> + dev->base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
What's the point of this API if you don't use resource parameter?
> + if (IS_ERR(dev->base))
> + ret = PTR_ERR(dev->base);
> +
> + return ret;
return PTR_ERR_OR_ZERO(dev->base);
> +}
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - dev->base = devm_ioremap_resource(&pdev->dev, mem);
> - if (IS_ERR(dev->base))
> - return PTR_ERR(dev->base);
Wolfram, did my last series make your tree? I think there was a patch
that touched this part...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Daniel Drake @ 2020-05-27 9:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
Linux Kernel, devicetree, linux-clk, linux-i2c,
Linux Upstreaming Team
In-Reply-To: <20200527091335.7wc3uy67lbz7j4di@gilmour.lan>
On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> want.
That would be great, although given the potentially inconsistent
results we've been seeing so far it would be great if you could
additionally push a git branch somewhere.
That way we can have higher confidence that we are applying exactly
the same patches to the same base etc.
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH v1 2/2] Add PWM driver for LGM
From: Andy Shevchenko @ 2020-05-27 9:15 UTC (permalink / raw)
To: Tanwar, Rahul
Cc: Uwe Kleine-König, thierry.reding, p.zabel, linux-pwm,
robh+dt, linux-kernel, devicetree, songjun.Wu, cheol.yong.kim,
qi-ming.wu
In-Reply-To: <3a1f1e83-2d9d-ddbf-e2e6-9c8bab87372b@linux.intel.com>
On Wed, May 27, 2020 at 02:28:53PM +0800, Tanwar, Rahul wrote:
> On 22/5/2020 4:56 pm, Uwe Kleine-König wrote:
> > On Fri, May 22, 2020 at 03:41:59PM +0800, Rahul Tanwar wrote:
...
> > I'm a unhappy to have this in the PWM driver. The PWM driver is supposed
> > to be generic and I think this belongs into a dedicated driver.
>
> Well noted about all other review concerns. I will rework the driver in v2.
> However, i am not very sure about the above point - of having a separate
> dedicated driver for tach_work because its logic is tightly coupled with
> this driver.
Actually I agree with Uwe.
Here is layering violation, i.e. provider and consumer in the same pot. It's
not good from design perspective.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Maxime Ripard @ 2020-05-27 9:13 UTC (permalink / raw)
To: Daniel Drake
Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
Linux Kernel, devicetree, linux-clk, linux-i2c,
Linux Upstreaming Team
In-Reply-To: <CAD8Lp467DiYWLwH6T1Jeq-uyN4VEuef-gGWw0_bBTtmSPr00Ag@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
Hi Daniel,
On Wed, May 27, 2020 at 11:49:36AM +0800, Daniel Drake wrote:
> Hi Maxime,
>
> On Tue, May 26, 2020 at 6:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
> > seems that I fixed it along the way
>
> Is your latest work available in a git branch anywhere that we could
> test directly?
I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
want.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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