* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2020-06-05 3:28 UTC (permalink / raw)
To: Sakari Ailus
Cc: Tomasz Figa, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Rob Herring, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Sj Huang, Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男), dongchun.zhu
In-Reply-To: <20200604081032.GG16711@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-06-04 at 11:10 +0300, Sakari Ailus wrote:
> On Thu, Jun 04, 2020 at 10:33:38AM +0800, Dongchun Zhu wrote:
> > Hi Tomasz,
> >
> > On Mon, 2020-06-01 at 20:47 +0200, Tomasz Figa wrote:
> > > On Wed, May 27, 2020 at 11:03 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On Mon, 2020-05-25 at 13:45 +0200, Tomasz Figa wrote:
> > > > > On Fri, May 22, 2020 at 11:27 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Tomasz,
> > > > > >
> > > > > > Thanks for the review. My replies are as below.
> > > > > >
> > > > > > On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> > > > > > > Hi Dongchun, Sakari,
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > > > > [snip]
> > > > > > > > + pm_runtime_enable(dev);
> > > > > > > > + if (!pm_runtime_enabled(dev)) {
> > > > > > > > + ret = dw9768_runtime_resume(dev);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > > > > > > + goto entity_cleanup;
> > > > > > > > + }
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > > > > > > > + if (ret < 0)
> > > > > > > > + goto entity_cleanup;
> > > > > > > > +
> > > > > > > > + return 0;
> > > > > > > > +
> > > > > > > > +entity_cleanup:
> > > > > > >
> > > > > > > Need to power off if the code above powered on.
> > > > > > >
> > > > > >
> > > > > > Thanks for the reminder.
> > > > > > If there is something wrong with runtime PM, actuator is to be powered
> > > > > > on via dw9768_runtime_resume() API.
> > > > > > When actuator sub-device is powered on completely and async registered
> > > > > > successfully, we shall power off it afterwards.
> > > > > >
> > > > >
> > > > > The code above calls dw9768_runtime_resume() if
> > > > > !pm_runtime_enabled(dev), but the clean-up code below the
> > > > > entity_cleanup label doesn't have the corresponding
> > > > > dw9768_runtime_suspend() call.
> > > > >
> > > >
> > > > Did you mean the 'entity_cleanup' after v4l2_async_register_subdev()?
> > >
> > > Yes.
> > >
> > > > Actually I made some changes for OV02A V9, according to this comment.
> > > > Could you help review that change? Thanks.
> > >
> > > Sure, I will take a look.
> > >
> >
> > Thanks.
> > Sorry, I just wanna make sure the change is okay for next release.
> > May we use the check like OV02A V9 did?
> > ret = v4l2_async_register_subdev(&dw9768->sd);
> > if (ret < 0) {
> > if (!pm_runtime_enabled(dev))
> > dw9768_runtime_suspend(dev);
>
> Please do this part where you're jumping to, if possible.
>
Fine.
Fixed in next release.
> > goto entity_cleanup;
> > }
> >
>
^ permalink raw reply
* Re: [GIT PULL] Devicetree updates for v5.8
From: pr-tracker-bot @ 2020-06-05 3:30 UTC (permalink / raw)
To: Rob Herring; +Cc: Linus Torvalds, linux-kernel, devicetree, Frank Rowand
In-Reply-To: <20200604220459.GA4123489@bogus>
The pull request you sent on Thu, 4 Jun 2020 16:04:59 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-5.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/571d54ed91c0fae174d933683c0c2e11c84843d9
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [V9, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
From: Dongchun Zhu @ 2020-06-05 3:19 UTC (permalink / raw)
To: Sakari Ailus
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
mark.rutland, drinkcat, tfiga, matthias.bgg, bingbu.cao,
srv_heupstream, linux-mediatek, linux-arm-kernel, sj.huang,
linux-media, devicetree, louis.kuo, shengnan.wang
In-Reply-To: <20200604092616.GJ16711@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-06-04 at 12:26 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, Jun 04, 2020 at 10:14:05AM +0800, Dongchun Zhu wrote:
> > Hi Tomasz, Sakari, and sirs,
> >
> > Could anyone help to review this patch?
> >
> > On Sat, 2020-05-23 at 16:41 +0800, Dongchun Zhu wrote:
> > > Add a V4L2 sub-device driver for OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > MAINTAINERS | 1 +
> > > drivers/media/i2c/Kconfig | 13 +
> > > drivers/media/i2c/Makefile | 1 +
> > > drivers/media/i2c/ov02a10.c | 1025 +++++++++++++++++++++++++++++++++++++++++++
> > > 4 files changed, 1040 insertions(+)
> > > create mode 100644 drivers/media/i2c/ov02a10.c
> > >
> >
> > [snip]
> >
> > > +static int ov02a10_probe(struct i2c_client *client)
> > > +{
> > > + struct device *dev = &client->dev;
> > > + struct ov02a10 *ov02a10;
> > > + unsigned int rotation;
> > > + unsigned int clock_lane_tx_speed;
> > > + unsigned int i;
> > > + int ret;
> > > +
> > > + ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
> > > + if (!ov02a10)
> > > + return -ENOMEM;
> > > +
> > > + ret = ov02a10_check_hwcfg(dev, ov02a10);
> > > + if (ret) {
> > > + dev_err(dev, "failed to check HW configuration: %d", ret);
> > > + return ret;
> > > + }
> > > +
> > > + v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
> > > + ov02a10->mipi_clock_tx_speed = OV02A10_MIPI_TX_SPEED_DEFAULT;
> > > + ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
> > > +
> > > + /* Optional indication of physical rotation of sensor */
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation", &rotation);
> > > + if (!ret && rotation == 180) {
> > > + ov02a10->upside_down = true;
> > > + ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
> > > + }
> > > +
> > > + /* Optional indication of mipi TX speed */
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "ovti,mipi-tx-speed",
> > > + &clock_lane_tx_speed);
> > > +
> > > + if (!ret)
> > > + ov02a10->mipi_clock_tx_speed = clock_lane_tx_speed;
> > > +
> > > + /* Get system clock (eclk) */
> > > + ov02a10->eclk = devm_clk_get(dev, "eclk");
> > > + if (IS_ERR(ov02a10->eclk)) {
> > > + ret = PTR_ERR(ov02a10->eclk);
> > > + dev_err(dev, "failed to get eclk %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
> > > + &ov02a10->eclk_freq);
> > > + if (ret) {
> > > + dev_err(dev, "failed to get eclk frequency\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_set_rate(ov02a10->eclk, ov02a10->eclk_freq);
> > > + if (ret) {
> > > + dev_err(dev, "failed to set eclk frequency (24MHz)\n");
> > > + return ret;
> > > + }
> > > +
> > > + if (clk_get_rate(ov02a10->eclk) != OV02A10_ECLK_FREQ) {
> > > + dev_warn(dev, "wrong eclk frequency %d Hz, expected: %d Hz\n",
> > > + ov02a10->eclk_freq, OV02A10_ECLK_FREQ);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(ov02a10->pd_gpio)) {
> > > + ret = PTR_ERR(ov02a10->pd_gpio);
> > > + dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > > + if (IS_ERR(ov02a10->n_rst_gpio)) {
> > > + ret = PTR_ERR(ov02a10->n_rst_gpio);
> > > + dev_err(dev, "failed to get reset-gpios %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(ov02a10_supply_names); i++)
> > > + ov02a10->supplies[i].supply = ov02a10_supply_names[i];
> > > +
> > > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ov02a10_supply_names),
> > > + ov02a10->supplies);
> > > + if (ret) {
> > > + dev_err(dev, "failed to get regulators\n");
> > > + return ret;
> > > + }
> > > +
> > > + mutex_init(&ov02a10->mutex);
> > > + ov02a10->cur_mode = &supported_modes[0];
> > > + ret = ov02a10_initialize_controls(ov02a10);
> > > + if (ret) {
> > > + dev_err(dev, "failed to initialize controls\n");
> > > + goto err_destroy_mutex;
> > > + }
> > > +
> > > + ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > > + ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
> > > + ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> > > + ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
> > > + ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to init entity pads: %d", ret);
> > > + goto err_free_handler;
> > > + }
> > > +
> > > + pm_runtime_enable(dev);
> > > + if (!pm_runtime_enabled(dev)) {
> > > + ret = ov02a10_power_on(dev);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to power on: %d\n", ret);
> > > + goto err_free_handler;
This is actually wrong, which should be replaced of "err_clean_entity".
> > > + }
> > > + }
> > > +
> > > + ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > > + if (ret) {
> > > + dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > > + if (!pm_runtime_enabled(dev))
> > > + ov02a10_power_off(dev);
>
> This should be moved to error handling section below.
>
Fine.
It would be abstracted as "err_async_register" in next release.
Something like:
err_async_register:
if (!pm_runtime_enabled(dev))
ov02a10_power_off(dev);
err_clean_entity:
media_entity_cleanup(&ov02a10->subdev.entity);
...
> > > + goto err_clean_entity;
> > > + }
> >
> > Tomasz, Sakari, is this ok?
> > or coding like this:
> >
> > ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > if (!pm_runtime_enabled(dev))
> > ov02a10_power_off(dev);
> > if (ret) {
> > dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > goto err_clean_entity;
> > }
> >
> > What's your opinions about the change?
>
> This turns power off if runtime PM is disabled. I'd keep it as-is, as it'd
> require re-implementing what runtime PM is used for now --- and that's not
> a sensor driver's job.
>
> >
> > > +
> > > + return 0;
> > > +
> > > +err_clean_entity:
> > > + media_entity_cleanup(&ov02a10->subdev.entity);
> > > +err_free_handler:
> > > + v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> > > +err_destroy_mutex:
> > > + mutex_destroy(&ov02a10->mutex);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int ov02a10_remove(struct i2c_client *client)
> > > +{
> > > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > > + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > > +
> > > + v4l2_async_unregister_subdev(sd);
> > > + media_entity_cleanup(&sd->entity);
> > > + v4l2_ctrl_handler_free(sd->ctrl_handler);
> > > + pm_runtime_disable(&client->dev);
> > > + if (!pm_runtime_status_suspended(&client->dev))
> > > + ov02a10_power_off(&client->dev);
> > > + pm_runtime_set_suspended(&client->dev);
> > > + mutex_destroy(&ov02a10->mutex);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static const struct of_device_id ov02a10_of_match[] = {
> > > + { .compatible = "ovti,ov02a10" },
> > > + {}
> > > +};
> > > +MODULE_DEVICE_TABLE(of, ov02a10_of_match);
> > > +
> > > +static struct i2c_driver ov02a10_i2c_driver = {
> > > + .driver = {
> > > + .name = "ov02a10",
> > > + .pm = &ov02a10_pm_ops,
> > > + .of_match_table = ov02a10_of_match,
> > > + },
> > > + .probe_new = &ov02a10_probe,
> > > + .remove = &ov02a10_remove,
> > > +};
> > > +
> > > +module_i2c_driver(ov02a10_i2c_driver);
> > > +
> > > +MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
> > > +MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
> > > +MODULE_LICENSE("GPL v2");
> > > +
> >
>
^ permalink raw reply
* RE: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
From: Robin Gong @ 2020-06-05 2:45 UTC (permalink / raw)
To: Matthias Schiffer
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
broonie@kernel.org, robh+dt@kernel.org, catalin.marinas@arm.com,
vkoul@kernel.org, will.deacon@arm.com, shawnguo@kernel.org,
festevam@gmail.com, s.hauer@pengutronix.de,
martin.fuzzey@flowbird.group, u.kleine-koenig@pengutronix.de,
dan.j.williams@intel.com, Markus Niebel
In-Reply-To: <7cb6cf02fc7cf860d1da7ba889887e79623e71a9.camel@ew.tq-group.com>
[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]
On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote:
> On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > wrote:
> > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > > > transfer to be send twice in DMA mode. Please get more information
> > > > from:
> > > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > > > .
> > > >
> > >
> > >
> nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> > > yibin.g
> > > >
> > >
> > >
> ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> > > 4c6fa92
> > > >
> > >
> > >
> cd99c5c301635%7C0%7C1%7C637267698912634476&sdata=hR66H1hP%
> > > 2Fqb6OXe
> > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&reserved=0. The workaround
> is
> > > > adding new sdma ram script which works in XCH mode as PIO inside
> > > > sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0.
> > > > The issue
> > >
> > > should be exist on all legacy i.mx6/7 soc family before i.mx6ul.
> > > > NXP fix this design issue from i.mx6ul, so newer chips including
> > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other
> > > > i.mx6/7/8 chips still need this workaroud. This patch set add new
> > > > 'fsl,imx6ul-ecspi'
> > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if
> > > > need errata or not.
> > > > The first two reverted patches should be the same issue, though,
> > > > it seems 'fixed' by changing to other shp script. Hope Sean or
> > > > Sascha could have the chance to test this patch set if could fix
> > > > their issues.
> > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not
> > > > work on i.mx8mm because the event id is zero.
> > > >
> > > > PS:
> > > > Please get sdma firmware from below linux-firmware and copy it
> > > > to your local rootfs /lib/firmware/imx/sdma.
> > >
> > >
> > > Hello Robin,
> > >
> > > we have tried out this series, and there seems to be an issue with
> > > the
> > > PIO fallback. We are testing on an i.MX6Q board, and our kernel is
> > > a
> > > mostly-unmodified 5.4, on which we backported all SDMA patches from
> > > next-20200602 (imx-sdma.c is identical to next-20200602 version),
> > > and
> > > then applied this whole series.
> > >
> > > We build the SDMA driver as a kernel module, which is loaded by
> > > udev,
> > > so the root filesystem is ready and the SDMA firmware can be
> > > loaded.
> > > The behaviour we're seeing is the following:
> > >
> > > 1. As long as the SDMA driver is not loaded, initializing spi_imx
> > > will
> > > be deferred
> > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this
> > > point
> > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To load
> > > the
> > > BFPT, the driver will attempt to use DMA; this will fail with
> > > EINVAL as
> > > long as the SDMA firmware is not ready, so the fallback to PIO
> > > happens
> > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> > >
> > > The problem happens in step 3: Whenever the driver falls back to
> > > PIO,
> > > the received data is corrupt. The behaviour is specific to the
> > > fallback: When I disable DMA completely via spi_imx.use_dma, or
> > > when
> > > the timing is lucky and the SDMA firmware gets loaded before the
> > > flash
> > > is probed, no corruption can be observed.
> >
> > Thanks Matthias, would you like post log?
> >
>
> I have attached the following log files:
> - pio.log: DMA disabled via module parameter
> - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR probe
> - fallback.log: DMA->PIO fallback
>
> The logs include some additional log messages:
> - Return value of spi_imx_dma_transfer() before PIO fallback
> - SPI-NOR SFPT dump
>
> It can be seen that the BFPT data is identical in pio.log and dma.log,
> and differs almost completely in fallback.log. The corrupted data seems
> to be random, or uninitialized memory; it differs with every boot.
Would you please have a try with the attached patch? Thanks.
[-- Attachment #2: 0006-spi-imx-add-dma_sync_sg_for_device-after-fallback-fr.patch --]
[-- Type: application/octet-stream, Size: 1526 bytes --]
From 08becec165b15663fafea52e3dc6ed5482ad3652 Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Fri, 5 Jun 2020 08:57:19 +0800
Subject: [PATCH v9 06/14] spi: imx: add dma_sync_sg_for_device after fallback
from dma
In case dma transfer failed and fallback to pio, tx_buf/rx_buf need to be
taken care cache since they have already been mapped by dma_map_sg() in
spi.c.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b7a85e3..c51cd3a 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1456,6 +1456,13 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
return -ETIMEDOUT;
}
+ if (transfer->rx_sg.sgl) {
+ struct device *rx_dev = spi->controller->dma_rx->device->dev;
+
+ dma_sync_sg_for_device(rx_dev, transfer->rx_sg.sgl,
+ transfer->rx_sg.nents, DMA_TO_DEVICE);
+ }
+
return transfer->len;
}
@@ -1521,10 +1528,15 @@ static int spi_imx_transfer(struct spi_device *spi,
* firmware may not be updated as ERR009165 required.
*/
if (spi_imx->usedma) {
+ struct device *tx_dev = spi->controller->dma_tx->device->dev;
+
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (ret != -EINVAL)
return ret;
+ dma_sync_sg_for_device(tx_dev, transfer->tx_sg.sgl,
+ transfer->tx_sg.nents, DMA_FROM_DEVICE);
+
spi_imx->devtype_data->disable_dma(spi_imx);
spi_imx->usedma = false;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-05 2:36 UTC (permalink / raw)
To: Marc Zyngier
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada, linux-pci, devicetree,
linux-arm-kernel, linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <9cbfdacba32c5e351fd9e14444768666@kernel.org>
Hi Marc,
On 2020/06/04 19:11, Marc Zyngier wrote:
> On 2020-06-04 10:43, Kunihiko Hayashi wrote:
>
> [...]
>
>>>> -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
>>>> +static void uniphier_pcie_misc_isr(struct pcie_port *pp)
>>>> {
>>>> - struct pcie_port *pp = irq_desc_get_handler_data(desc);
>>>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>>> struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
>>>> - struct irq_chip *chip = irq_desc_get_chip(desc);
>>>> - unsigned long reg;
>>>> - u32 val, bit, virq;
>>>> + u32 val, virq;
>>>>
>>>> - /* INT for debug */
>>>> val = readl(priv->base + PCL_RCV_INT);
>>>>
>>>> if (val & PCL_CFG_BW_MGT_STATUS)
>>>> dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
>>>> +
>>>> if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
>>>> dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
>>>> - if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "Root Error\n");
>>>> - if (val & PCL_CFG_PME_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "PME Interrupt\n");
>>>> +
>>>> + if (pci_msi_enabled()) {
>>>
>>> This checks whether the kernel supports MSIs. Not that they are
>>> enabled in your controller. Is that really what you want to do?
>>
>> The below two status bits are valid when the interrupt for MSI is asserted.
>> That is, pci_msi_enabled() is wrong.
>>
>> I'll modify the function to check the two bits only if this function is
>> called from MSI handler.
>>
>>>
>>>> + if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "Root Error Status\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>> +
>>>> + if (val & PCL_CFG_PME_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "PME Interrupt\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>
>>> These two cases do the exact same thing, calling the same interrupt.
>>> What is the point of dealing with them independently?
>>
>> Both PME and AER are asserted from MSI-0, and each handler checks its own
>> status bit in the PCIe register (aer_irq() in pcie/aer.c and pcie_pme_irq()
>> in pcie/pme.c).
>> So I think this handler calls generic_handle_irq() for the same MSI-0.
>
> So what is wrong with
>
> if (val & (PCL_CFG_AER_RC_ERR_MSI_STATUS |
> PCL_CFG_PME_MSI_STATUS)) {
> // handle interrupt
> }
>
> ?
No problem.
I'll rewrite it in the same way as yours in handling interrupts.
> If you have two handlers for the same interrupt, this is a shared
> interrupt and each handler will be called in turn.
Yes, MSI-0 is shared with PME and AER, and it will be like that.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH v12 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
From: Xin Ji @ 2020-06-05 2:36 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Hsin-Yi Wang, David Airlie, Daniel Vetter, Dan Carpenter,
Nicolas Boichat, linux-kernel, dri-devel, Pi-Hsun Shih, Sheng Pan
In-Reply-To: <20200604222402.GA4153046@bogus>
On Thu, Jun 04, 2020 at 04:24:02PM -0600, Rob Herring wrote:
> On Thu, 04 Jun 2020 15:56:36 +0800, Xin Ji wrote:
> > anx7625: MIPI to DP transmitter DT schema
> >
> > Signed-off-by: Xin Ji <xji@analogixsemi.com>
> > ---
> > .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++
> > 1 file changed, 95 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> >
>
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Hi Rob Herring, thanks for your comment. I'll add tags in the next
versions.
Thanks,
Xin
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-05 2:26 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Bhupesh Sharma
Cc: chenzhou, Simon Horman, Devicetree List, Arnd Bergmann,
Baoquan He, Linux Doc Mailing List, Catalin Marinas, guohanjun,
kexec mailing list, Linux Kernel Mailing List, Will Deacon,
Rob Herring, James Morse, Prabhakar Kushwaha, Thomas Gleixner,
Prabhakar Kushwaha, RuiRui Yang, Ingo Molnar, linux-arm-kernel
In-Reply-To: <751bbe2512628ff38002db33ce02af051d080cd2.camel@suse.de>
On 6/4/20 12:01 PM, Nicolas Saenz Julienne wrote:
> On Thu, 2020-06-04 at 01:17 +0530, Bhupesh Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com>
>> wrote:
>>>
>>>> On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
>>>>> Hi Chen,
>>>>>
>>>>> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com
>>>>>> wrote:
>>>>>>
>>>>>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <
>>>>>>> prabhakar.pkin@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <
>>>>>>> john.p.donnelly@oracle.com> wrote:
>>>>>>>> Hi . See below !
>>>>>>>>
>>>>>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <
>>>>>>>>> John.P.donnelly@oracle.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>>>>>>>>>> Hi Chen,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <
>>>>>>>>>>> chenzhou10@huawei.com> wrote:
>>>>>>>>>>>> This patch series enable reserving crashkernel above 4G in
>>>>>>>>>>>> arm64.
>>>>>>>>>>>>
>>>>>>>>>>>> There are following issues in arm64 kdump:
>>>>>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G,
>>>>>>>>>>>> which will fail
>>>>>>>>>>>> when there is no enough low memory.
>>>>>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve
>>>>>>>>>>>> crashkernel above 4G,
>>>>>>>>>>>> in this case, if swiotlb or DMA buffers are required,
>>>>>>>>>>>> crash dump kernel
>>>>>>>>>>>> will boot failure because there is no low memory available
>>>>>>>>>>>> for allocation.
>>>>>>>>>>>>
>>>>>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump
>>>>>>>>>>> kernel
>>>>>>>>>>> with bootargs as [2] of primary kernel.
>>>>>>>>>>> This error observed on ThunderX2 ARM64 platform.
>>>>>>>>>>>
>>>>>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this
>>>>>>>>>>> patch set
>>>>>>>>>>> and
>>>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>>>>>>>>>> Also **without** this patch-set
>>>>>>>>>>> "
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
>>>>>>>>>>> "
>>>>>>>>>>>
>>>>>>>>>>> This issue comes whenever crashkernel memory is reserved
>>>>>>>>>>> after 0xc000_0000.
>>>>>>>>>>> More details discussed earlier in
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
> without
>>>>>>>>>>> any
>>>>>>>>>>> solution
>>>>>>>>>>>
>>>>>>>>>>> This patch-set is expected to solve similar kind of issue.
>>>>>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above
>>>>>>>>>>> mentioned
>>>>>>>>>>> observation should be considered/fixed. .
>>>>>>>>>>>
>>>>>>>>>>> --pk
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.367696] NET: Registered protocol family 16
>>>>>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>>>>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>>>>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>>>>>>>>>>> 5.7.0-rc3+ #121
>>>>>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.369984] Call trace:
>>>>>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>>>>>>>>>> [ 30.369991] show_stack+0x20/0x30
>>>>>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
>>>>>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
>>>>>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0
>>>>>>>>>>> xb50
>>>>>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>>>>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>>>>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>>>>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>>>>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
>>>>>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>>>>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
>>>>>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
>>>>>>>>>>> [ 30.370036] Mem-Info:
>>>>>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>>>>>>>>>> [ 30.370064] active_file:0 inactive_file:0
>>>>>>>>>>> isolated_file:0
>>>>>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>>>>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>>>>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>>>>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>>>>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>>>>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB
>>>>>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>>>>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB
>>>>>>>>>>> low:664kB
>>>>>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:269700kB managed:256000kB mlocked:0kB
>>>>>>>>>>> kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>>>>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB
>>>>>>>>>>> low:15504kB
>>>>>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB
>>>>>>>>>>> kernel_stack:21672kB
>>>>>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>>>>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB
>>>>>>>>>>> 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>>>>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB
>>>>>>>>>>> 0*64kB 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) =
>>>>>>>>>>> 256000kB
>>>>>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB
>>>>>>>>>>> (UE) 3*32kB
>>>>>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME)
>>>>>>>>>>> 3*1024kB (ME)
>>>>>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>>>>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>>>>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
>>>>>>>>>>> [ 30.370130] 0 total pagecache pages
>>>>>>>>>>> [ 30.370132] 0 pages in swap cache
>>>>>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>>>>>>>>>> [ 30.370135] Free swap = 0kB
>>>>>>>>>>> [ 30.370136] Total swap = 0kB
>>>>>>>>>>> [ 30.370137] 2164609 pages RAM
>>>>>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>>>>>>>>>> [ 30.370140] 612331 pages reserved
>>>>>>>>>>> [ 30.370141] 0 pages hwpoisoned
>>>>>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for
>>>>>>>>>>> atomic
>>>>>>>>>>> coherent allocation
>>>>>>>>>> During my testing I saw the same error and Chen's solution
>>>>>>>>>> corrected it .
>>>>>>>>> Which combination you are using on your side? I am using
>>>>>>>>> Prabhakar's
>>>>>>>>> suggested environment and can reproduce the issue
>>>>>>>>> with or without Chen's crashkernel support above 4G patchset.
>>>>>>>>>
>>>>>>>>> I am also using a ThunderX2 platform with latest makedumpfile
>>>>>>>>> code and
>>>>>>>>> kexec-tools (with the suggested patch
>>>>>>>>> <
>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$
>>>>>>>>>> ).
>>>>>>>>> Thanks,
>>>>>>>>> Bhupesh
>>>>>>>> I did this activity 5 months ago and I have moved on to other
>>>>>>>> activities. My DMA failures were related to PCI devices that could
>>>>>>>> not be enumerated because low-DMA space was not available when
>>>>>>>> crashkernel was moved above 4G; I don’t recall the exact platform.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For this failure ,
>>>>>>>>
>>>>>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
>>>>>>>>>>> coherent allocation
>>>>>>>> Is due to :
>>>>>>>>
>>>>>>>>
>>>>>>>> 3618082c
>>>>>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>>>>>>>>
>>>>>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
>>>>>>>> region below 1G, the crashkernel is placed in the upper 4G
>>>>>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
>>>>>>>> to the ZONE_DMA region, it prints out call trace during bootup.
>>>>>>>>
>>>>>>>> It is due to having this CONFIG item ON :
>>>>>>>>
>>>>>>>>
>>>>>>>> CONFIG_ZONE_DMA=y
>>>>>>>>
>>>>>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
>>>>>>>> use the device tree to specify memory below 1G.
>>>>>>>>
>>>>>>>>
>>>>>>> Disabling ZONE_DMA is temporary solution. We may need proper
>>>>>>> solution
>>>>>> Perhaps the Raspberry platform configuration dependencies need
>>>>>> separated from “server class” Arm equipment ? Or auto-configured on
>>>>>> boot ? Consult an expert ;-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I would like to see Chen’s feature added , perhaps as
>>>>>>>> EXPERIMENTAL, so we can get some configuration testing done on
>>>>>>>> it. It corrects having a DMA zone in low memory while crash-
>>>>>>>> kernel is above 4GB. This has been going on for a year now.
>>>>>>> I will also like this patch to be added in Linux as early as
>>>>>>> possible.
>>>>>>>
>>>>>>> Issue mentioned by me happens with or without this patch.
>>>>>>>
>>>>>>> This patch-set can consider fixing because it uses low memory for
>>>>>>> DMA
>>>>>>> & swiotlb only.
>>>>>>> We can consider restricting crashkernel within the required range
>>>>>>> like below
>>>>>>>
>>>>>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>>>>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
>>>>>>> --- a/kernel/crash_core.c
>>>>>>> +++ b/kernel/crash_core.c
>>>>>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> if (!low_base) {
>>>>>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
>>>>>>> please try smaller size.\n",
>>>>>>> (unsigned long)(low_size >> 20));
>>>>>>>
>>>>>>>
>>>>>> I suspect 0xc0000000 would need to be a CONFIG item and not
>>>>>> hard-coded.
>>>>>>
>>>>> if you consider this as valid change, can you please incorporate as
>>>>> part of your patch-set.
>>>> After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32")，the 0-
>>>> 4G memory is splited
>>>> to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem
>>>> 0x0000000040000000-0x00000000ffffffff] on arm64.
>>>>
>>>> From the above discussion, on your platform, the low crashkernel fall in
>>>> DMA32 region, but your environment needs to access DMA
>>>> region, so there is the call trace.
>>>>
>>>> I have a question, why do you choose 0xc0000000 here?
>>>>
>>>> Besides, this is common code, we also need to consider about x86.
>>>>
>>> + nsaenzjulienne@suse.de
> Thanks for adding me to the conversation, and sorry for the headaches.
>
>>> Exactly . This is why it needs to be a CONFIG option for Raspberry
>>> .., or device tree option.
>>>
>>>
>>> We could revert 1a8e1cef7 since it broke Arm kdump too.
>> Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
>> both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
>> list, thus we couldn't get many eyes on it for a thorough review from
>> kexec/kdump p-o-v.
>>
>> Also we historically never had distinction in common arch code on the
>> basis of the intended end use-case: embedded, server or automotive, so
>> I am not sure introducing a Raspberry specific CONFIG option would be
>> a good idea.
> +1
>
> From the distros perspective it's very important to keep a single kernel image.
>
>> So, rather than reverting the patch, we can look at addressing the
>> same properly this time - especially from a kdump p-o-v.
>> This issue has been reported by some Red Hat arm64 partners with
>> upstream kernel also and as we have noticed in the past as well,
>> hardcoding the placement of the crashkernel base address (unless the
>> base address is specified by a crashkernel=X@Y like bootargs) is also
>> not a portable suggestion.
>>
>> I am working on a possible fix and will have more updates on the same
>> in a day-or-two.
> Please keep me in the loop, we've also had issues pointing to this reported by
> SUSE partners. I can do some testing both on the RPi4 and on big servers that
> need huge crashkernel sizes.
>
> Regards,
> Nicolas
>
Hi Nicolas,
You want want to review this topic with the various email threads . It
has been a long journey.
[1]:https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwQs3C4x$
[v1]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6e-mIEp$
[v2]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJyUVjUta$
[v3]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ3CXBRdT$
[v4]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ7SxW1Vj$
[v5]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ2wyJ9tj$
[v6]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJzvGhWBh$
[v7]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6pAg6tX$
Chen Zhou (5):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property, low-memory-range
kdump: update Documentation about crashkernel on arm64
dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
Documentation/admin-guide/kdump/kdump.rst | 13 ++-
.../admin-guide/kernel-parameters.txt | 12 ++-
Documentation/devicetree/bindings/chosen.txt | 25 ++++++
arch/arm64/kernel/setup.c | 8 +-
arch/arm64/mm/init.c | 61 ++++++++++++-
arch/x86/kernel/setup.c | 66 ++------------
include/linux/crash_core.h | 3 +
include/linux/kexec.h | 2 -
kernel/crash_core.c | 85 +++++++++++++++++++
kernel/kexec_core.c | 17 ----
10 files changed, 208 insertions(+), 84 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Evan Benn @ 2020-06-05 1:42 UTC (permalink / raw)
To: Julius Werner
Cc: Guenter Roeck, Lukas Bulwahn, Wim Van Sebroeck, LINUX-WATCHDOG,
Rob Herring, devicetree, Joe Perches, kernel-janitors, LKML
In-Reply-To: <CAKz_xw0Tqr-idoZbNzg_didSCr5L+L1=76xjF=Sqj4DgpL9g7Q@mail.gmail.com>
AFAICT this has now been merged upstream, I'm not sure what action to take:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c24a28b4eb842ad1256496be6ae01bab15f1dcb
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72a9e7fea5866fc471fda78f05f166595c8c6ba6
On Wed, Jun 3, 2020 at 9:22 AM Evan Benn <evanbenn@chromium.org> wrote:
>
> Apologies for that slip up.
>
> Reviewed-by: Evan Benn <evanbenn@chromium.org>
>
> On Wed, Jun 3, 2020 at 6:16 AM Julius Werner <jwerner@chromium.org> wrote:
> >
> > Reviewed-by: Julius Werner <jwerner@chromium.org>
^ permalink raw reply
* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
From: kernel test robot @ 2020-06-05 1:26 UTC (permalink / raw)
To: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
linux-pwm, linux-watchdog, linux-arm-kernel
Cc: kbuild-all, Linus Walleij, Bartosz Golaszewski, Rob Herring
In-Reply-To: <20200604211039.12689-4-michael@walle.cc>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
Hi Michael,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20200604]
[cannot apply to gpio/for-next hwmon/hwmon-next ljones-mfd/for-mfd-next shawnguo/for-next v5.7 v5.7-rc7 v5.7-rc6 v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Michael-Walle/Add-support-for-Kontron-sl28cpld/20200605-051333
base: d4899e5542c15062cc55cac0ca99025bb64edc61
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/irqchip/irq-sl28cpld.c: In function 'sl28cpld_intc_probe':
>> drivers/irqchip/irq-sl28cpld.c:56:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
56 | if (irq < 0)
| ^
vim +56 drivers/irqchip/irq-sl28cpld.c
35
36 static int sl28cpld_intc_probe(struct platform_device *pdev)
37 {
38 struct device *dev = &pdev->dev;
39 struct sl28cpld_intc *irqchip;
40 unsigned int irq;
41 u32 base;
42 int ret;
43
44 if (!dev->parent)
45 return -ENODEV;
46
47 irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
48 if (!irqchip)
49 return -ENOMEM;
50
51 irqchip->regmap = dev_get_regmap(dev->parent, NULL);
52 if (!irqchip->regmap)
53 return -ENODEV;
54
55 irq = platform_get_irq(pdev, 0);
> 56 if (irq < 0)
57 return irq;
58
59 ret = device_property_read_u32(&pdev->dev, "reg", &base);
60 if (ret)
61 return -EINVAL;
62
63 irqchip->chip.name = "sl28cpld-intc";
64 irqchip->chip.irqs = sl28cpld_irqs;
65 irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
66 irqchip->chip.num_regs = 1;
67 irqchip->chip.status_base = base + INTC_IP;
68 irqchip->chip.mask_base = base + INTC_IE;
69 irqchip->chip.mask_invert = true,
70 irqchip->chip.ack_base = base + INTC_IP;
71
72 return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
73 irqchip->regmap, irq,
74 IRQF_SHARED | IRQF_ONESHOT, 0,
75 &irqchip->chip, &irqchip->irq_data);
76 }
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66540 bytes --]
^ permalink raw reply
* Re: [PATCH v26 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml
From: Dan Murphy @ 2020-06-05 0:08 UTC (permalink / raw)
To: Rob Herring; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604230456.GA6520@bogus>
Rob
On 6/4/20 6:04 PM, Rob Herring wrote:
> On Thu, Jun 04, 2020 at 07:04:55AM -0500, Dan Murphy wrote:
>> Convert the leds-lp55xx.txt to yaml binding.
I will fix all your comments.
But why does your BOT have checkpatch warnings?
https://gitlab.com/robherring/linux-dt-review/-/jobs/581282098/artifacts/file/checkpatch-1303471.log
Is this because checkpatch thinks the .txt file is invalid?
Dan
^ permalink raw reply
* Re: [PATCH v26 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml
From: Rob Herring @ 2020-06-04 23:04 UTC (permalink / raw)
To: Dan Murphy; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604120504.32425-7-dmurphy@ti.com>
On Thu, Jun 04, 2020 at 07:04:55AM -0500, Dan Murphy wrote:
> Convert the leds-lp55xx.txt to yaml binding.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../devicetree/bindings/leds/leds-lp55xx.txt | 228 ------------------
> .../devicetree/bindings/leds/leds-lp55xx.yaml | 220 +++++++++++++++++
> 2 files changed, 220 insertions(+), 228 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> deleted file mode 100644
> index 1b66a413fb9d..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
> +++ /dev/null
> @@ -1,228 +0,0 @@
> -Binding for TI/National Semiconductor LP55xx Led Drivers
> -
> -Required properties:
> -- compatible: one of
> - national,lp5521
> - national,lp5523
> - ti,lp55231
> - ti,lp5562
> - ti,lp8501
> -
> -- reg: I2C slave address
> -- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
> -
> -Each child has own specific current settings
> -- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
> -- max-cur: Maximun current at each led channel.
> -
> -Optional properties:
> -- enable-gpio: GPIO attached to the chip's enable pin
> -- label: Used for naming LEDs
> -- pwr-sel: LP8501 specific property. Power selection for output channels.
> - 0: D1~9 are connected to VDD
> - 1: D1~6 with VDD, D7~9 with VOUT
> - 2: D1~6 with VOUT, D7~9 with VDD
> - 3: D1~9 are connected to VOUT
> -
> -Alternatively, each child can have a specific channel name and trigger:
> -- chan-name (optional): name of channel
> -- linux,default-trigger (optional): see
> - Documentation/devicetree/bindings/leds/common.txt
> -
> -example 1) LP5521
> -3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
> -'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
> -on channel 0.
> -
> -lp5521@32 {
> - compatible = "national,lp5521";
> - reg = <0x32>;
> - label = "lp5521_pri";
> - clock-mode = /bits/ 8 <2>;
> -
> - chan0 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - linux,default-trigger = "heartbeat";
> - };
> -
> - chan1 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - };
> -
> - chan2 {
> - led-cur = /bits/ 8 <0x2f>;
> - max-cur = /bits/ 8 <0x5f>;
> - };
> -};
> -
> -example 2) LP5523
> -9 LED channels with specific name. Internal clock used.
> -The I2C slave address is configurable with ASEL1 and ASEL0 pins.
> -Available addresses are 32/33/34/35h.
> -
> -ASEL1 ASEL0 Address
> --------------------------
> - GND GND 32h
> - GND VEN 33h
> - VEN GND 34h
> - VEN VEN 35h
> -
> -lp5523@32 {
> - compatible = "national,lp5523";
> - reg = <0x32>;
> - clock-mode = /bits/ 8 <1>;
> -
> - chan0 {
> - chan-name = "d1";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan1 {
> - chan-name = "d2";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan2 {
> - chan-name = "d3";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan3 {
> - chan-name = "d4";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan4 {
> - chan-name = "d5";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan5 {
> - chan-name = "d6";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan6 {
> - chan-name = "d7";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan7 {
> - chan-name = "d8";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan8 {
> - chan-name = "d9";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -};
> -
> -example 3) LP5562
> -4 channels are defined.
> -
> -lp5562@30 {
> - compatible = "ti,lp5562";
> - reg = <0x30>;
> - clock-mode = /bits/8 <2>;
> -
> - chan0 {
> - chan-name = "R";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan1 {
> - chan-name = "G";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan2 {
> - chan-name = "B";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -
> - chan3 {
> - chan-name = "W";
> - led-cur = /bits/ 8 <0x20>;
> - max-cur = /bits/ 8 <0x60>;
> - };
> -};
> -
> -example 4) LP8501
> -9 channels are defined. The 'pwr-sel' is LP8501 specific property.
> -Others are same as LP5523.
> -
> -lp8501@32 {
> - compatible = "ti,lp8501";
> - reg = <0x32>;
> - clock-mode = /bits/ 8 <2>;
> - pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
> -
> - chan0 {
> - chan-name = "d1";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan1 {
> - chan-name = "d2";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan2 {
> - chan-name = "d3";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan3 {
> - chan-name = "d4";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan4 {
> - chan-name = "d5";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan5 {
> - chan-name = "d6";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan6 {
> - chan-name = "d7";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan7 {
> - chan-name = "d8";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -
> - chan8 {
> - chan-name = "d9";
> - led-cur = /bits/ 8 <0x14>;
> - max-cur = /bits/ 8 <0x20>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
> new file mode 100644
> index 000000000000..9d6ded5fbc14
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
> @@ -0,0 +1,220 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI/National Semiconductor LP55xx and LP8501 LED Drivers
> +
> +maintainers:
> + - Jacek Anaszewski <jacek.anaszewski@gmail.com>
> + - Pavel Machek <pavel@ucw.cz>
> +
> +description: |
> + Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel
> + LED Drivers.
> +
> + For more product information please see the link below:
> + https://www.ti.com/lit/gpn/lp5521
> + https://www.ti.com/lit/gpn/lp5523
> + https://www.ti.com/lit/gpn/lp55231
> + https://www.ti.com/lit/gpn/lp5562
> + https://www.ti.com/lit/gpn/lp8501
> +
> +properties:
> + #allOf:
> + #- $ref: "common.yaml#"
> + #- $ref: "leds-class-multicolor.yaml#"
> +
> + compatible:
> + enum:
> + - national,lp5521
> + - national,lp5523
> + - ti,lp55231
> + - ti,lp5562
> + - ti,lp8501
> +
> + reg:
> + maxItems: 1
> + description: I2C slave address
> +
> + clock-mode:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
'maxItems' is for an array. This is a scalar, so drop.
> + description: |
> + Input clock mode
> + 0 - automode
> + 1 - internal
> + 2 - external
enum:
- 0 # automode
- 1
- 2
> +
> + enable-gpio:
> + maxItems: 1
> + description: |
> + GPIO attached to the chip's enable pin
> +
> + pwr-sel:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
> + description: |
> + LP8501 specific property. Power selection for output channels.
> + 0 - D1~9 are connected to VDD
> + 1 - D1~6 with VDD, D7~9 with VOUT
> + 2 - D1~6 with VOUT, D7~9 with VDD
> + 3 - D1~9 are connected to VOUT
Similarly here, make this a schema.
> +
> + child-node:
This needs to be a pattern matching the child nodes' names.
> + type: object
> + properties:
> + led-cur:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
Not an array.
> + description: |
> + Current setting at each LED channel (mA x10, 0 if LED is not connected)
0-255 are valid values?
> +
> + max-cur:
> + $ref: /schemas/types.yaml#definitions/uint8
> + maxItems: 1
> + description: Maximun current at each LED channel.
> +
> + reg:
> + maxItems: 1
> + description: |
> + Output channel for the LED. This is zero based channel identifier and
> + the data sheet is a one based channel identifier.
> + reg value to output to LED output number
> + D1 = reg value is 0
> + D2 = reg value is 1
> + D3 = reg value is 2
> + D4 = reg value is 3
> + D5 = reg value is 4
> + D6 = reg value is 5
> + D7 = reg value is 6
> + D8 = reg value is 7
> + D9 = reg value is 8
> +
> + chan-name:
> + $ref: /schemas/types.yaml#definitions/string
> + description: name of channel
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@32 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "ti,lp8501";
> + reg = <0x32>;
> + clock-mode = /bits/ 8 <2>;
> + pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
> +
> + led@0 {
> + reg = <0>;
> + chan-name = "d1";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@1 {
> + reg = <1>;
> + chan-name = "d2";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@2 {
> + reg = <2>;
> + chan-name = "d3";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@3 {
> + reg = <3>;
> + chan-name = "d4";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@4 {
> + reg = <4>;
> + chan-name = "d5";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@5 {
> + reg = <5>;
> + chan-name = "d6";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@6 {
> + reg = <6>;
> + chan-name = "d7";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@7 {
> + reg = <7>;
> + chan-name = "d8";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> +
> + led@8 {
> + reg = <8>;
> + chan-name = "d9";
> + led-cur = /bits/ 8 <0x14>;
> + max-cur = /bits/ 8 <0x20>;
> + };
> + };
> +
> + led-controller@33 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "national,lp5523";
> + reg = <0x33>;
> + clock-mode = /bits/ 8 <0>;
> +
> + multi-led@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2>;
> + color = <LED_COLOR_ID_MULTI>;
> + function = LED_FUNCTION_STANDBY;
> + linux,default-trigger = "heartbeat";
> +
> + led@0 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x0>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + led@1 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x1>;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> +
> + led@6 {
> + led-cur = /bits/ 8 <50>;
> + max-cur = /bits/ 8 <100>;
> + reg = <0x6>;
> + color = <LED_COLOR_ID_RED>;
> + };
> + };
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [V7 PATCH] dt-bindings: Added device tree binding for max98390
From: Rob Herring @ 2020-06-04 23:10 UTC (permalink / raw)
To: Steve Lee
Cc: ryan.lee.maxim, lgirdwood, linux-kernel, steves.lee.maxim,
robh+dt, alsa-devel, broonie, ryans.lee, devicetree
In-Reply-To: <20200602084337.22116-1-steves.lee@maximintegrated.com>
On Tue, 02 Jun 2020 17:43:37 +0900, Steve Lee wrote:
> Add DT binding of max98390 amplifier driver.
>
> Signed-off-by: Steve Lee <steves.lee@maximintegrated.com>
> ---
>
> Changed since V6:
> * Re-confirm yaml dt binding check
> * Add minimum and maximum value for each temperature_calib and r0_calib
> * Add maxim prefix for naming.
> Changed since V5:
> * Change txt to yaml and fix up the examples.
> Changed since V4:
> * No changes.
> Changed since V3:
> * No changes.
> Changed since V2:
> * No changes.
> Changed since V1:
> * Modified sample text in example
>
> .../bindings/sound/maxim,max98390.yaml | 51 +++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/maxim,max98390.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 4/4] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Rob Herring @ 2020-06-04 23:09 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: marex, kernel, michal.simek, laurent.pinchart, xuwei5, robh+dt,
mcoquelin.stm32, linux-arm-kernel, devicetree
In-Reply-To: <20200601063308.13045-5-ricardo.canuelo@collabora.com>
On Mon, 01 Jun 2020 08:33:08 +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
> original binding has been split into two files: adi,adv7511.yaml for
> ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/adi,adv7511.txt | 143 -----------
> .../bindings/display/bridge/adi,adv7511.yaml | 231 ++++++++++++++++++
> .../bindings/display/bridge/adi,adv7533.yaml | 175 +++++++++++++
> 3 files changed, 406 insertions(+), 143 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 07/20] dt-bindings: mtd: Document boolean NAND ECC properties
From: Rob Herring @ 2020-06-04 23:08 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Boris Brezillon, Thomas Petazzoni, linux-arm-kernel, Mason Yang,
Julien Su, Mark Rutland, devicetree
In-Reply-To: <20200603175759.19948-8-miquel.raynal@bootlin.com>
On Wed, Jun 03, 2020 at 07:57:46PM +0200, Miquel Raynal wrote:
> Document nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
> The former is here to force software correction, the latter prevents
> any correction to happen.
>
> These properties (along with nand-ecc-engine) are supposed to be more
> accurate than the current nand-ecc-modes wich is very misleading and
> very often people think it is mandatory while the core should be
> relied upon to decide which correction to handle.
>
> nand-ecc-mode was already inacurate, but it becomes totally
> problematic with setups where there are several hardware engines.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> Documentation/devicetree/bindings/mtd/nand-controller.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> index 0969d2e6720b..a3750978ebb8 100644
> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> @@ -68,6 +68,12 @@ patternProperties:
> 3/ The ECC engine is external, in this case the phandle should
> reference the specific ECC engine node.
>
> + nand-use-soft-ecc-engine: true
> + description: Use a software ECC engine.
Humm, I'm surprised this is valid YAML. nand-use-soft-ecc-engine can't
be both a boolean and a map (aka schema, aka dict).
nand-use-soft-ecc-engine:
type: boolean
description: ...
> +
> + nand-no-ecc-engine: true
> + description: Do not use any ECC correction.
> +
> nand-ecc-placement:
> allOf:
> - $ref: /schemas/types.yaml#/definitions/string
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v26 04/15] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
From: Rob Herring @ 2020-06-04 22:59 UTC (permalink / raw)
To: Dan Murphy; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604120504.32425-5-dmurphy@ti.com>
On Thu, Jun 04, 2020 at 07:04:53AM -0500, Dan Murphy wrote:
> Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
> LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
> can control RGB LEDs individually or as part of a control bank group.
> These devices have the ability to adjust the mixing control for the RGB
> LEDs to obtain different colors independent of the overall brightness of
> the LED grouping.
>
> Datasheet:
> http://www.ti.com/lit/ds/symlink/lp5012.pdf
> http://www.ti.com/lit/ds/symlink/lp5024.pdf
> http://www.ti.com/lit/ds/symlink/lp5036.pdf
>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../devicetree/bindings/leds/leds-lp50xx.yaml | 136 ++++++++++++++++++
> 1 file changed, 136 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> new file mode 100644
> index 000000000000..02fcdc13262f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LED driver for LP50XX RGB LED from Texas Instruments.
> +
> +maintainers:
> + - Dan Murphy <dmurphy@ti.com>
> +
> +description: |
> + The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
> + a LED group or control them individually.
> +
> + The difference in these RGB LED drivers is the number of supported RGB
> + modules.
> +
> + For more product information please see the link below:
> + http://www.ti.com/lit/ds/symlink/lp5012.pdf
> + http://www.ti.com/lit/ds/symlink/lp5024.pdf
> + http://www.ti.com/lit/ds/symlink/lp5036.pdf
> +
> +properties:
> + #allOf:
> + #- $ref: "common.yaml#"
> + #- $ref: "leds-class-multicolor.yaml#"
These describe properties in the 'multi-led' nodes, so the $ref goes
there. And you only need the 2nd one because it already references the
1st one (or it should once you fix patch 1).
> +
> + compatible:
> + enum:
> + - ti,lp5009
> + - ti,lp5012
> + - ti,lp5018
> + - ti,lp5024
> + - ti,lp5030
> + - ti,lp5036
> +
> + reg:
> + maxItems: 1
> + description:
> + I2C slave address
> + lp5009/12 - 0x14, 0x15, 0x16, 0x17
> + lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
> + lp5030/36 - 0x30, 0x31, 0x32, 0x33
> +
> + enable-gpios:
> + maxItems: 1
> + description: GPIO pin to enable/disable the device.
> +
> + vled-supply:
> + description: LED supply.
> +
> + child-node:
I guess you didn't understand what I said on this. What you need is:
patternProperties:
'^multi-led@[0-9]$':
type: object
$ref: leds-class-multicolor.yaml#
properties:
...
patternProperties:
'^led@[0-9]$':
type: object
$ref: common.yaml#
Adjust '[0-9]' based on how many possible child addresses there can be.
It's hex if more than 10.
> + properties:
> + ti,led-bank:
> + description:
> + This property denotes the LED module numbers that will be controlled as
> + a single RGB cluster. Each LED module number will be controlled by a
> + single LED class instance.
> + There can only be one instance of the ti,led-bank
> + property for each device node. This is a required node if the LED
> + modules are to be banked.
> + $ref: /schemas/types.yaml#definitions/uint32-array
> +
> +required:
> + - compatible
> + - reg
additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/leds/common.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@14 {
> + compatible = "ti,lp5009";
> + reg = <0x14>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + enable-gpios = <&gpio1 16>;
> +
> + multi-led@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + color = <LED_COLOR_ID_MULTI>;
> + function = LED_FUNCTION_CHARGING;
> +
> + led@0 {
> + reg = <0>;
> + color = <LED_COLOR_ID_RED>;
> + };
> +
> + led@1 {
> + reg = <1>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + led@2 {
> + reg = <2>;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> + };
> +
> + multi-led@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> + color = <LED_COLOR_ID_MULTI>;
> + function = LED_FUNCTION_STANDBY;
> + ti,led-bank = <2 3 5>;
I still don't understand why 'reg = <2 3 5>;' with the 1st entry being
the control bank. Is '2' in reg not the same thing as '2' here?
> +
> + led@6 {
> + reg = <0x6>;
> + color = <LED_COLOR_ID_RED>;
> + led-sources = <6 9 15>;
> + };
> +
> + led@7 {
> + reg = <0x7>;
> + color = <LED_COLOR_ID_GREEN>;
> + led-sources = <7 10 16>;
> + };
> +
> + led@8 {
> + reg = <0x8>;
> + color = <LED_COLOR_ID_BLUE>;
> + led-sources = <8 11 17>;
> + };
> + };
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [Freedreno] [PATCH v7 6/6] arm6: dts: qcom: sm845: Set the compatible string for the GPU SMMU
From: Jordan Crouse @ 2020-06-04 22:47 UTC (permalink / raw)
To: Rob Clark
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Linux Kernel Mailing List, Rob Herring,
Bjorn Andersson, Andy Gross, freedreno
In-Reply-To: <CAF6AEGssC5ZJKh3oMR6fFRJwZvWLy4YjE2anvq5sDmPB_ikv0Q@mail.gmail.com>
On Thu, Jun 04, 2020 at 03:38:28PM -0700, Rob Clark wrote:
> On Thu, Jun 4, 2020 at 3:02 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> >
> > On Thu, Jun 04, 2020 at 02:27:21PM -0700, Rob Clark wrote:
> > > On Thu, Jun 4, 2020 at 1:57 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> > > >
> > > > Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
> > > > split pagetables.
> > > >
> > > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > > ---
> > > >
> > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > index 8eb5a31346d2..8b15cd74e9ba 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > @@ -3556,7 +3556,7 @@
> > > > };
> > > >
> > > > adreno_smmu: iommu@5040000 {
> > > > - compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> > > > + compatible = "qcom,adreno-smmu", "qcom,smmu-v2";
> > >
> > > Should this be something like:
> > >
> > > compatible = "qcom,adreno-smmu", "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> > >
> > > so that new dtb still works with old kernel?
> >
> > As far as I know qcom,sdm845-smmu-v2 never was actually used unless we were
> > doing the parsing trick somewhere.
>
> I *think* it has a use queued up for v5.8 for the
> select-direct-mapping stuff? I'm not 100% sure of the status of that
> off the top of my head.
That uses the compatible string of the consumer device. I can add
it back in but I didn't think we needed to complicate the bindings any more if
we didn't have to.
Jordan
> BR,
> -R
>
> > Jordan
> >
> > > > reg = <0 0x5040000 0 0x10000>;
> > > > #iommu-cells = <1>;
> > > > #global-interrupts = <2>;
> > > > --
> > > > 2.17.1
> > > >
> > > > _______________________________________________
> > > > Freedreno mailing list
> > > > Freedreno@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> > > _______________________________________________
> > > Freedreno mailing list
> > > Freedreno@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> >
> > --
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v26 01/15] dt: bindings: Add multicolor class dt bindings documention
From: Rob Herring @ 2020-06-04 22:40 UTC (permalink / raw)
To: Dan Murphy; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200604120504.32425-2-dmurphy@ti.com>
On Thu, Jun 04, 2020 at 07:04:50AM -0500, Dan Murphy wrote:
> Add DT bindings for the LEDs multicolor class framework.
> Add multicolor ID to the color ID list for device tree bindings.
>
> CC: Rob Herring <robh@kernel.org>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../bindings/leds/leds-class-multicolor.yaml | 39 +++++++++++++++++++
> include/dt-bindings/leds/common.h | 3 +-
> 2 files changed, 41 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
> new file mode 100644
> index 000000000000..6cab2a1405e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common properties for the multicolor LED class.
> +
> +maintainers:
> + - Dan Murphy <dmurphy@ti.com>
> +
> +description: |
> + Bindings for multi color LEDs show how to describe current outputs of
> + either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV
> + etc.) or standalone LEDs, to achieve logically grouped multi-color LED
> + modules. This is achieved by adding multi-led nodes layer to the
> + monochrome LED bindings.
> + The nodes and properties defined in this document are unique to the multicolor
> + LED class. Common LED nodes and properties are inherited from the common.txt
> + within this documentation directory.
> +
> +patternProperties:
> + "^multi-led@([0-9a-f])$":
> + type: object
> + description: Represents the LEDs that are to be grouped.
> + properties:
> + #allOf:
> + #- $ref: "common.yaml#"
Why is this commented out? Other than it is wrong. Uncommented, this
would be defining a DT property called 'allOf'.
You can drop 'allOf' now. '$ref' should be at the level of 'properties'.
> +
> + color:
> + $ref: /schemas/types.yaml#definitions/uint32
common.yaml already defines the type, so drop this.
> + const: 8 # LED_COLOR_ID_MULTI
> + description: |
> + For multicolor LED support this property should be defined as
> + LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h.
> +
> + required:
> + - color
> +...
> diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
> index 0ce7dfc00dcb..a463ce6a8794 100644
> --- a/include/dt-bindings/leds/common.h
> +++ b/include/dt-bindings/leds/common.h
> @@ -30,7 +30,8 @@
> #define LED_COLOR_ID_VIOLET 5
> #define LED_COLOR_ID_YELLOW 6
> #define LED_COLOR_ID_IR 7
> -#define LED_COLOR_ID_MAX 8
> +#define LED_COLOR_ID_MULTI 8
> +#define LED_COLOR_ID_MAX 9
>
> /* Standard LED functions */
> /* Keyboard LEDs, usually it would be input4::capslock etc. */
> --
> 2.26.2
>
^ permalink raw reply
* Re: [Freedreno] [PATCH v7 6/6] arm6: dts: qcom: sm845: Set the compatible string for the GPU SMMU
From: Rob Clark @ 2020-06-04 22:38 UTC (permalink / raw)
To: Rob Clark,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Linux Kernel Mailing List, Rob Herring,
Bjorn Andersson, Andy Gross, freedreno
In-Reply-To: <20200604220216.GA12322@jcrouse1-lnx.qualcomm.com>
On Thu, Jun 4, 2020 at 3:02 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> On Thu, Jun 04, 2020 at 02:27:21PM -0700, Rob Clark wrote:
> > On Thu, Jun 4, 2020 at 1:57 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> > >
> > > Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
> > > split pagetables.
> > >
> > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > ---
> > >
> > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index 8eb5a31346d2..8b15cd74e9ba 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -3556,7 +3556,7 @@
> > > };
> > >
> > > adreno_smmu: iommu@5040000 {
> > > - compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> > > + compatible = "qcom,adreno-smmu", "qcom,smmu-v2";
> >
> > Should this be something like:
> >
> > compatible = "qcom,adreno-smmu", "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> >
> > so that new dtb still works with old kernel?
>
> As far as I know qcom,sdm845-smmu-v2 never was actually used unless we were
> doing the parsing trick somewhere.
I *think* it has a use queued up for v5.8 for the
select-direct-mapping stuff? I'm not 100% sure of the status of that
off the top of my head.
BR,
-R
> Jordan
>
> > > reg = <0 0x5040000 0 0x10000>;
> > > #iommu-cells = <1>;
> > > #global-interrupts = <2>;
> > > --
> > > 2.17.1
> > >
> > > _______________________________________________
> > > Freedreno mailing list
> > > Freedreno@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> > _______________________________________________
> > Freedreno mailing list
> > Freedreno@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Rob Herring @ 2020-06-04 22:35 UTC (permalink / raw)
To: Pavel Machek
Cc: Dan Murphy, Jacek Anaszewski, devicetree, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <20200604125111.GA7222@duo.ucw.cz>
On Thu, Jun 4, 2020 at 6:51 AM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Tue 2020-06-02 15:44:32, Rob Herring wrote:
> > On Tue, Jun 2, 2020 at 2:04 PM Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > On Wed 2020-05-27 08:35:06, Rob Herring wrote:
> > > > On Wed, May 27, 2020 at 7:39 AM Pavel Machek <pavel@ucw.cz> wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > Thanks for reviews!
> > > > >
> > > > > > > +additionalProperties: false
> > > > > > > +...
> > > > > > > diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> > > > > >
> > > > > > This isn't a binding file. Belongs in another patch.
> > > > >
> > > > > These constants are directly related to the binding. It makes sense to
> > > > > go in one patch...
> > > >
> > > > Yes, the header does go in this patch, but kernel subsystem files do not.
> > > >
> > > > Part of the reason for separating is we generate a DT only repository
> > > > which filters out all the kernel code. Ideally this is just filtering
> > > > out commits and the commit messages still make sens
> > >
> > > Well, but the patch can't be split like that. Otherwise we risk null
> > > pointer dereferences when one part is applied but not the second one.
> >
> > There's no risk because you are supposed to apply both patches. I
> > don't apply binding patches that are a part of a series like this.
>
> Yes, this is always guaranteed to happen, because "git bisect"
> understand patch series. Oh, wait.
What!? If the binding patch with the header comes first, how would
bisect build the driver change without the header?
> Patches are supposed to be correct on their own. If your repository
> filtering can not handle that, you need to fix that...
I'm just asking you to follow the process that *everyone* else is
following and works. It's not really about the repository filtering.
That doesn't care. A binding ABI is defined by the schema and any
defines it has. That is the logical unit that stands on its own.
Rob
^ permalink raw reply
* Re: [PATCH v12 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
From: Rob Herring @ 2020-06-04 22:24 UTC (permalink / raw)
To: Xin Ji
Cc: Neil Armstrong, Pi-Hsun Shih, Jonas Karlman, devel, linux-kernel,
devicetree, Nicolas Boichat, dri-devel, Laurent Pinchart,
Dan Carpenter, Hsin-Yi Wang, Sheng Pan, Andrzej Hajda,
Sam Ravnborg, Nicolas Boichat, Daniel Vetter, Jernej Skrabec,
David Airlie
In-Reply-To: <eb82c52574bf41b5edad488e14c27cabad39b922.1591253353.git.xji@analogixsemi.com>
On Thu, 04 Jun 2020 15:56:36 +0800, Xin Ji wrote:
> anx7625: MIPI to DP transmitter DT schema
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
^ permalink raw reply
* Re: [PATCH v3 10/10] net: eth: altera: update devicetree bindings documentation
From: Rob Herring @ 2020-06-04 22:23 UTC (permalink / raw)
To: Ooi, Joyce
Cc: David S . Miller, Jakub Kicinski, Thor Thayer, netdev,
Rob Herring, See Chin Liang, linux-kernel, Dinh Nguyen,
Dalon Westergreen, devicetree, Dalon Westergreen, Tan Ley Foon
In-Reply-To: <20200604073256.25702-11-joyce.ooi@intel.com>
On Thu, 04 Jun 2020 15:32:56 +0800, Ooi, Joyce wrote:
> From: Dalon Westergreen <dalon.westergreen@intel.com>
>
> Update devicetree bindings documentation to include msgdma
> prefetcher and ptp bindings.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Dalon Westergreen <dalon.westergreen@intel.com>
> Signed-off-by: Joyce Ooi <joyce.ooi@intel.com>
> ---
> v2: no change
> v3: no change
> ---
> .../devicetree/bindings/net/altera_tse.txt | 103 +++++++++++++++++----
> 1 file changed, 84 insertions(+), 19 deletions(-)
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
^ permalink raw reply
* [GIT PULL] Devicetree updates for v5.8
From: Rob Herring @ 2020-06-04 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, devicetree, Frank Rowand
Hi Linus,
Please pull DT updates for v5.8.
There's a couple of conflicts with your tree. renesas,wdt.txt can just
be deleted, my tree already has the necessary changes. For
qcom,ipa.yaml, take 'reg' property from my tree and 'iommus' from
yours(net). linux-next has the correct resolutions. Note that there's a
couple of other similar conflicts you can expect in linux-next.
Rob
The following changes since commit 4bc77b2d211e107fa54b1f39cd0d7dac5537b8cb:
dt-bindings: phy: qcom-qusb2: Fix defaults (2020-04-24 17:53:57 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-for-5.8
for you to fetch changes up to 8211d1e83aded34631aa87fa37f97d7bb712e925:
dt-bindings: clock: Add documentation for X1830 bindings. (2020-06-03 15:59:40 -0600)
----------------------------------------------------------------
Devicetree updates for v5.8:
- Convert various DT (non-binding) doc files to ReST
- Various improvements to device link code
- Fix __of_attach_node_sysfs refcounting bug
- Add support for 'memory-region-names' with reserved-memory binding
- Vendor prefixes for Protonic Holland, BeagleBoard.org, Alps, Check
Point, Würth Elektronik, U-Boot, Vaisala, Baikal Electronics, Shanghai
Awinic Technology Co., MikroTik, Silex Insight
- A bunch more binding conversions to DT schema. Only 3K to go.
- Add a minimum version check for schema tools
- Treewide dropping of 'allOf' usage with schema references. Not needed
in new json-schema spec.
- Some formatting clean-ups of schemas
----------------------------------------------------------------
Akash Asthana (3):
dt-bindings: geni-se: Convert QUP geni-se bindings to YAML
dt-bindings: geni-se: Add interconnect binding for GENI QUP
dt-bindings: serial: Add binding for UART pin swap
Alain Volmat (1):
dt-bindings: i2c: i2c-stm32f7: add st,stm32mp15-i2c compatible
Andre Przywara (11):
dt-bindings: clock: Convert Calxeda clock bindings to json-schema
dt-bindings: sata: Convert Calxeda SATA controller to json-schema
dt-bindings: net: Convert Calxeda Ethernet binding to json-schema
dt-bindings: phy: Convert Calxeda ComboPHY binding to json-schema
dt-bindings: arm: Convert Calxeda L2 cache controller to json-schema
dt-bindings: memory-controllers: Convert Calxeda DDR to json-schema
dt-bindings: ipmi: Convert IPMI-SMIC bindings to json-schema
dt-bindings: arm: Add Calxeda system registers json-schema binding
dt-bindings: arm: gic: Allow combining arm,gic-400 compatible strings
dt-bindings: mali-midgard: Allow dma-coherent
dt-bindings: ehci/ohci: Allow iommus property
Anson Huang (37):
dt-bindings: thermal: Convert i.MX8MM to json-schema
dt-bindings: gpio: Convert i.MX to json-schema
dt-bindings: nvmem: Convert i.MX OCOTP to json-schema
dt-bindings: nvmem: Convert i.MX IIM to json-schema
dt-bindings: nvmem: Convert MXS OCOTP to json-schema
dt-bindings: watchdog: Convert i.MX to json-schema
dt-bindings: watchdog: Convert i.MX7ULP to json-schema
dt-bindings: clock: Convert i.MX6Q clock to json-schema
dt-bindings: clock: Convert i.MX6SX clock to json-schema
dt-bindings: clock: Convert i.MX6SL clock to json-schema
dt-bindings: clock: Convert i.MX6SLL clock to json-schema
dt-bindings: clock: Convert i.MX6UL clock to json-schema
dt-bindings: rtc: Convert MXC RTC to json-schema
dt-bindings: rtc: Convert MXC RTC V2 to json-schema
dt-bindings: pwm: Convert imx pwm to json-schema
dt-bindings: pwm: Convert imx tpm pwm to json-schema
dt-bindings: pwm: Convert mxs pwm to json-schema
dt-bindings: interrupt-controller: Convert imx irqsteer to json-schema
dt-bindings: clock: Convert i.MX7D clock to json-schema
dt-bindings: timer: Convert i.MX TPM to json-schema
dt-bindings: timer: Convert i.MX SYSCTR to json-schema
dt-bindings: gpio: Convert mxs to json-schema
dt-bindings: thermal: Convert i.MX to json-schema
dt-bindings: clock: Convert i.MX5 clock to json-schema
dt-bindings: clock: Convert i.MX35 clock to json-schema
dt-bindings: clock: Convert i.MX31 clock to json-schema
dt-bindings: clock: Convert i.MX28 clock to json-schema
dt-bindings: clock: Convert i.MX23 clock to json-schema
dt-bindings: clock: Convert i.MX27 clock to json-schema
dt-bindings: clock: Convert i.MX25 clock to json-schema
dt-bindings: clock: Convert i.MX21 clock to json-schema
dt-bindings: clock: Convert i.MX1 clock to json-schema
dt-bindings: timer: Convert i.MX GPT to json-schema
dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
dt-bindings: power: Convert imx gpc to json-schema
dt-bindings: power: Convert imx gpcv2 to json-schema
dt-bindings: mailbox: Convert imx mu to json-schema
Charles Keepax (12):
hwmon: lochnagar: Move binding over to dtschema
ASoC: lochnagar: Move binding over to dtschema
pinctrl: lochnagar: Move binding over to dtschema
clk: lochnagar: Move binding over to dtschema
mfd: lochnagar: Move binding over to dtschema
regulator: arizona-regulator: Move binding over to dtschema
extcon: arizona: Move binding over to dtschema
ASoC: arizona: Move binding over to dtschema
mfd: arizona: Move binding over to dtschema
ASoC: madera: Move binding over to dtschema
pinctrl: madera: Move binding over to dtschema
mfd: madera: Move binding over to dtschema
Christophe Roullier (2):
dt-bindings: net: dwmac: increase 'maxItems' for 'clocks', 'clock-names' properties
dt-bindings: net: dwmac: Convert stm32 dwmac to DT schema
Dan Carpenter (1):
of: Fix a refcounting bug in __of_attach_node_sysfs()
Ding Xiang (1):
of: of_detach_node() remove unneeded local return variable
Drew Fustini (1):
dt-bindings: Add vendor prefix for BeagleBoard.org
Etienne Carriere (1):
dt-bindings: nvmem: stm32: new property for data access
Frank Rowand (1):
of: Documentation: change overlay example to use current syntax
Geert Uytterhoeven (16):
dt-bindings: usb: generic-ehci: Document power-domains property
dt-bindings: usb: generic-ohci: Document power-domains property
dt-bindings: gpio: rcar: Convert to json-schema
dt-bindings: watchdog: renesas-wdt: Convert to json-schema
dt-bindings: timer: renesas: ostm: Convert to json-schema
dt-bindings: eeprom: at24: Fix list of page sizes for writing
dt-bindings: auxdisplay: hd44780: Convert to json-schema
dt-bindings: serial: renesas,scifa: Remove part numbers from comments
dt-bindings: media: Add missing clock domain description
dt-bindings: rtc: rtc-sh: Add missing power-domains property
ASoC: fsi: Add missing properties to DT bindings
dt-bindings: interrupt-controller: arm,gic: Document resets property
dt-bindings: memory-controllers: renesas,dbsc: Convert to json-schema
dt-bindings: serial: Add renesas,em-uart bindings
dt-bindings: timer: renesas: mtu2: Convert to json-schema
dt-bindings: timer: renesas: cmt: Convert to json-schema
Johan Jonker (4):
dt-bindings: sram: convert rockchip-pmu-sram bindings to yaml
dt-bindings: gpu: add power-domains #cooling-cells to arm,mali-bifrost.yaml
dt-bindings: usb: dwc2: add power-domains property
dt-bindings: input: touchscreen: edt-ft5x06: change reg property
Jonathan Albrieux (1):
dt-bindings: iio: imu: bmi160: convert format to yaml, add maintainer
Jonathan McDowell (1):
dt-bindings: vendor-prefixes: Add MikroTik
Joseph Lo (1):
dt-bindings: memory: tegra: Add external memory controller binding for Tegra210
Kangmin Park (1):
docs/devicetree/i2c: brcm,bcm2835: fix node id in example
Krzysztof Kozlowski (1):
dt-bindings: memory-controllers: exynos-srom: Remove unneeded type for reg-io-width
Kunihiko Hayashi (5):
dt-bindings: phy: Convert UniPhier PCIe-PHY controller to json-schema
dt-bindings: phy: Convert UniPhier USB2-PHY controller to json-schema
dt-bindings: phy: Convert UniPhier USB3-PHY conroller to json-schema
dt-bindings: thermal: Convert UniPhier thermal monitor to json-schema
dt-bindings: watchdog: Convert UniPhier watchdog timer to json-schema
Lad Prabhakar (19):
dt-bindings: sh_eth: Sort compatible string in increasing number of the SoC
dt-bindings: irqchip: renesas-irqc: Document r8a7742 bindings
dt-bindings: serial: renesas,scif: Document r8a7742 bindings
dt-bindings: serial: renesas,scifb: Document r8a7742 bindings
dt-bindings: serial: renesas,hscif: Document r8a7742 bindings
dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
dt-bindings: serial: renesas,scifa: Document r8a7742 bindings
dt-bindings: i2c: renesas, i2c: Document r8a7742 support
dt-bindings: i2c: renesas, iic: Document r8a7742 support
dt-bindings: ata: renesas,rcar-sata: Add r8a7742 support
dt-bindings: net: renesas, ravb: Add support for r8a7742 SoC
dt-bindings: net: renesas,ether: Document R8A7742 SoC
dt-bindings: power: renesas,apmu: Document r8a7742 support
dt-bindings: gpio: renesas, rcar-gpio: Add r8a7742 (RZ/G1H) support
dt-bindings: phy: rcar-gen2: Add r8a7742 support
dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
dt-bindings: usb: renesas,usbhs: Add support for r8a7742
dt-bindings: usb: usb-xhci: Document r8a7742 support
dt-bindings: thermal: rcar-thermal: Add device tree support for r8a7742
Lubomir Rintel (5):
dt-bindings: serial: Move Marvell compatible string to 8250 binding doc
dt-bindings: serial: Convert 8250 to json-schema
dt-bindings: media: Convert marvell,mmp2-ccic to json-schema
dt-bindings: spi: Convert spi-pxa2xx to json-schema
dt-bindings: usb: Convert ehci-mv to json-schema
Martin Blumenstingl (1):
dt-bindings: gpu: mali-utgard: Add the #cooling-cells property
Masahiro Yamada (1):
dt-bindings: at24: add microchip, 24lc[0-9]+ to the compatible pattern
Matthias Brugger (1):
dt-bindings: dma: uart: mtk: fix example
Mauro Carvalho Chehab (10):
docs: dt: add an index.rst file for devicetree
docs: dt: convert usage-model.txt to ReST
docs: dt: usage_model.rst: fix link for DT usage
docs: dt: convert changesets to ReST
docs: dt: convert dynamic-resolution-notes.txt to ReST
docs: dt: convert of_unittest.txt to ReST
docs: dt: convert overlay-notes.txt to ReST format
docs: dt: convert ABI.txt to ReST format
docs: dt: convert submitting-patches.txt to ReST format
docs: dt: convert writing-bindings.txt to ReST
Michal Simek (1):
dt-bindings: vendor-prefixes: Add U-Boot bootloader prefix
Neil Armstrong (1):
dt-bindings: sram: Add Amlogic SCP SRAM compatibles
Nick Reitemeyer (1):
dt-bindings: vendor-prefixes: Add Alps
Nicolas Saenz Julienne (2):
of: property: Fix create device links for all child-supplier dependencies
of: property: Do not link to disabled devices
Nikita Travkin (1):
dt-bindings: vendor-prefixes: Add Shanghai Awinic Technology Co., Ltd.
Niklas Söderlund (1):
dt-bindings: thermal: rcar-gen3-thermal: Convert bindings to json-schema
Nobuhiro Iwamatsu (3):
dt-bindings: i2c: cadence: Migrate i2c-cadence documentation to YAML
dt-bindings: i2c: xiic: Migrate i2c-xiic documentation to YAML
dt-bindings: timer: cadence_ttc: Migrate timer-cadence-ttc documentation to YAML
Oleksij Rempel (2):
dt-bindings: vendor-prefixes: Add an entry for Protonic Holland
dt-bindings: serial: qca,ar9330-uart: Convert to json-schema
Olivier Sobrie (1):
dt-bindings: vendor-prefixes: Add Silex Insight vendor prefix
Paul Cercueil (11):
dt-bindings: timer: Convert ingenic,tcu.txt to YAML
dt-bindings: mmc: Convert jz4740-mmc doc to YAML
dt-bindings: dma: Convert jz4740-dma doc to YAML
dt-bindings: usb: ingenic,musb: Add usb-role-switch property
dt-bindings: MIPS: Require SoC compatible string after board string
dt-bindings: clock: Convert ingenic,cgu.txt to YAML
dt-bindings: intc: Convert ingenic,intc.txt to YAML
dt-bindings: i2c: Convert i2c-jz4780.txt to YAML
dt-bindings: serial: Convert ingenic,uart.txt to YAML
dt-bindings: memory: Convert ingenic,jz4780-nemc.txt to YAML
dt-bindings: mtd: Convert ingenic,jz4780-nand.txt to YAML
Pawel Dembicki (1):
dt-bindings: vendor-prefixes: Add Check Point
Peng Fan (1):
dt-bindings: mailbox: imx-mu: correct example
Qi Zheng (2):
dt/platform: Fix comment in of_dev_lookup()
of/fdt: Remove redundant kbasename function call
Ricardo Cañuelo (2):
dt-bindings: nvmem: Convert rockchip-efuse bindings to yaml
dt-bindings: display: anx7814.txt: convert to yaml
Rob Herring (12):
dt-bindings: input: Convert gpio-keys bindings to schema
dt-bindings: Clean-up schema indentation formatting
Merge branch 'dt/linus' into dt/next
dt-bindings: iio: adi,ltc2983: Add missing quotes on dependencies
Merge branch 'dt/linus' into 'dt/next'
dt-bindings: Add a minimum version check for dtschema
dt-bindings: Remove cases of 'allOf' containing a '$ref'
spi: dt-bindings: sifive: Add missing 2nd register region
dt-bindings: usb: ehci: Add missing 2nd register region
dt-bindings: ufs: ti: Fix address properties handling
dt-bindings: ufs: ti: Add missing 'additionalProperties: false'
dt-bindings: Fix incorrect 'reg' property sizes
Samuel Holland (1):
dt-bindings: timer: Document allwinner,erratum-unknown1 property
Sandeep Maheswaram (3):
dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
dt-bindings: usb: qcom,dwc3: Add compatible for SC7180
dt-bindings: usb: qcom,dwc3: Introduce interconnect properties for Qualcomm DWC3 driver
Saravana Kannan (2):
of: property: Add device link support for extcon
of: property: Don't retry device_link_add() upon failure
Saravanan Sekar (1):
dt-bindings: Add an entry for Würth Elektronik, we
Serge Semin (1):
dt-bindings: Add vendor prefix for Baikal Electronics, JSC
Thierry Reding (2):
dt-bindings: reserved-memory: Introduce memory-region-names
dt-bindings: Merge gpio-usb-b-connector with usb-connector
Vesa Jääskeläinen (1):
dt-bindings: vendor-prefixes: Add Vaisala
Yoshihiro Kaneko (1):
dt-bindings: irqchip: renesas-intc-irqpin: Convert to json-schema
Yoshihiro Shimoda (1):
dt-bindings: iommu: renesas,ipmmu-vmsa: convert to json-schema
chenqiwu (1):
drivers/of: keep description of function consistent with function name
tangjianqiang (1):
of: fix the warnings from command line.
周琰杰 (Zhou Yanjie) (1):
dt-bindings: clock: Add documentation for X1830 bindings.
Documentation/arm/microchip.rst | 2 +-
.../devicetree/bindings/{ABI.txt => ABI.rst} | 5 +-
Documentation/devicetree/bindings/Makefile | 14 +-
Documentation/devicetree/bindings/arm/altera.yaml | 6 +-
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 +-
.../arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 +-
.../devicetree/bindings/arm/arm,vexpress-juno.yaml | 34 +-
Documentation/devicetree/bindings/arm/bitmain.yaml | 2 +-
.../devicetree/bindings/arm/calxeda/hb-sregs.yaml | 49 +++
.../devicetree/bindings/arm/calxeda/l2ecc.txt | 15 -
.../devicetree/bindings/arm/calxeda/l2ecc.yaml | 42 +++
.../devicetree/bindings/arm/coresight-cti.yaml | 20 +-
Documentation/devicetree/bindings/arm/cpus.yaml | 85 +++--
Documentation/devicetree/bindings/arm/l2c2x0.yaml | 87 +++--
.../devicetree/bindings/arm/nxp/lpc32xx.yaml | 9 +-
Documentation/devicetree/bindings/arm/psci.yaml | 16 +-
.../devicetree/bindings/arm/renesas,prr.yaml | 2 +-
.../bindings/arm/samsung/exynos-chipid.yaml | 5 +-
.../bindings/arm/socionext/uniphier.yaml | 26 +-
.../devicetree/bindings/arm/stm32/st,mlahb.yaml | 2 +-
.../bindings/arm/stm32/st,stm32-syscon.yaml | 6 +-
Documentation/devicetree/bindings/arm/syna.txt | 2 +-
.../bindings/arm/tegra/nvidia,tegra20-pmc.yaml | 2 +-
.../devicetree/bindings/ata/faraday,ftide010.yaml | 4 +-
.../devicetree/bindings/ata/renesas,rcar-sata.yaml | 1 +
.../devicetree/bindings/ata/sata_highbank.txt | 44 ---
.../devicetree/bindings/ata/sata_highbank.yaml | 95 ++++++
.../devicetree/bindings/auxdisplay/hit,hd44780.txt | 45 ---
.../bindings/auxdisplay/hit,hd44780.yaml | 96 ++++++
.../bindings/bus/allwinner,sun50i-a64-de2.yaml | 5 +-
.../bindings/bus/allwinner,sun8i-a23-rsb.yaml | 4 +-
.../clock/allwinner,sun4i-a10-gates-clk.yaml | 8 +-
.../bindings/clock/bitmain,bm1880-clk.yaml | 2 +-
.../devicetree/bindings/clock/calxeda.txt | 17 -
.../devicetree/bindings/clock/calxeda.yaml | 82 +++++
.../devicetree/bindings/clock/cirrus,lochnagar.txt | 94 ------
.../bindings/clock/cirrus,lochnagar.yaml | 78 +++++
.../bindings/clock/fixed-factor-clock.yaml | 5 +-
.../devicetree/bindings/clock/fsl,plldig.yaml | 19 +-
.../devicetree/bindings/clock/imx1-clock.txt | 26 --
.../devicetree/bindings/clock/imx1-clock.yaml | 51 +++
.../devicetree/bindings/clock/imx21-clock.txt | 27 --
.../devicetree/bindings/clock/imx21-clock.yaml | 51 +++
.../devicetree/bindings/clock/imx23-clock.txt | 70 ----
.../devicetree/bindings/clock/imx23-clock.yaml | 92 ++++++
.../devicetree/bindings/clock/imx25-clock.txt | 160 ----------
.../devicetree/bindings/clock/imx25-clock.yaml | 186 +++++++++++
.../devicetree/bindings/clock/imx27-clock.txt | 27 --
.../devicetree/bindings/clock/imx27-clock.yaml | 55 ++++
.../devicetree/bindings/clock/imx28-clock.txt | 93 ------
.../devicetree/bindings/clock/imx28-clock.yaml | 115 +++++++
.../devicetree/bindings/clock/imx31-clock.txt | 90 ------
.../devicetree/bindings/clock/imx31-clock.yaml | 120 +++++++
.../devicetree/bindings/clock/imx35-clock.txt | 114 -------
.../devicetree/bindings/clock/imx35-clock.yaml | 139 ++++++++
.../devicetree/bindings/clock/imx5-clock.txt | 28 --
.../devicetree/bindings/clock/imx5-clock.yaml | 65 ++++
.../devicetree/bindings/clock/imx6q-clock.txt | 41 ---
.../devicetree/bindings/clock/imx6q-clock.yaml | 72 +++++
.../devicetree/bindings/clock/imx6sl-clock.txt | 10 -
.../devicetree/bindings/clock/imx6sl-clock.yaml | 48 +++
.../devicetree/bindings/clock/imx6sll-clock.txt | 36 ---
.../devicetree/bindings/clock/imx6sll-clock.yaml | 66 ++++
.../devicetree/bindings/clock/imx6sx-clock.txt | 13 -
.../devicetree/bindings/clock/imx6sx-clock.yaml | 70 ++++
.../devicetree/bindings/clock/imx6ul-clock.txt | 13 -
.../devicetree/bindings/clock/imx6ul-clock.yaml | 66 ++++
.../devicetree/bindings/clock/imx7d-clock.txt | 13 -
.../devicetree/bindings/clock/imx7d-clock.yaml | 65 ++++
.../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---
.../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 73 +++++
.../devicetree/bindings/clock/ingenic,cgu.txt | 57 ----
.../devicetree/bindings/clock/ingenic,cgu.yaml | 124 ++++++++
.../devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sm8250.yaml | 2 +-
.../devicetree/bindings/clock/qcom,mmcc.yaml | 16 +-
.../bindings/clock/qcom,sc7180-dispcc.yaml | 2 +-
.../bindings/clock/qcom,sc7180-gpucc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc7180-mss.yaml | 2 +-
.../bindings/clock/qcom,sc7180-videocc.yaml | 2 +-
.../bindings/clock/qcom,sdm845-dispcc.yaml | 2 +-
.../bindings/clock/qcom,sdm845-gpucc.yaml | 2 +-
.../bindings/clock/qcom,sdm845-videocc.yaml | 2 +-
.../bindings/clock/sprd,sc9863a-clk.yaml | 29 +-
.../bindings/connector/usb-connector.yaml | 73 +++--
.../crypto/allwinner,sun4i-a10-crypto.yaml | 14 +-
.../bindings/crypto/allwinner,sun8i-ce.yaml | 16 +-
.../bindings/crypto/amlogic,gxl-crypto.yaml | 4 +-
.../devicetree/bindings/crypto/st,stm32-hash.yaml | 9 +-
.../allwinner,sun4i-a10-display-engine.yaml | 7 +-
.../bindings/display/allwinner,sun4i-a10-hdmi.yaml | 40 +--
.../bindings/display/allwinner,sun4i-a10-tcon.yaml | 63 ++--
.../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 +-
.../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 10 +-
.../bindings/display/bridge/analogix,anx7814.yaml | 119 +++++++
.../devicetree/bindings/display/bridge/anx7814.txt | 42 ---
.../bindings/display/bridge/lvds-codec.yaml | 18 +-
.../bindings/display/panel/panel-common.yaml | 11 +-
.../bindings/display/panel/panel-timing.yaml | 120 ++++---
.../bindings/display/panel/sony,acx424akp.yaml | 2 +-
.../bindings/display/panel/xinpeng,xpp055c272.yaml | 4 +-
.../devicetree/bindings/display/renesas,cmm.yaml | 18 +-
.../bindings/display/ti/ti,am65x-dss.yaml | 19 +-
.../bindings/display/ti/ti,j721e-dss.yaml | 34 +-
.../devicetree/bindings/dma/dma-common.yaml | 3 +-
.../devicetree/bindings/dma/ingenic,dma.yaml | 80 +++++
.../devicetree/bindings/dma/jz4780-dma.txt | 64 ----
.../devicetree/bindings/dma/mtk-uart-apdma.txt | 3 +-
.../bindings/dma/sifive,fu540-c000-pdma.yaml | 2 +-
.../devicetree/bindings/dma/ti/k3-udma.yaml | 29 +-
Documentation/devicetree/bindings/eeprom/at24.yaml | 13 +-
.../devicetree/bindings/example-schema.yaml | 17 +-
.../devicetree/bindings/extcon/extcon-arizona.txt | 76 -----
.../bindings/extcon/extcon-usbc-cros-ec.yaml | 3 +-
.../devicetree/bindings/extcon/wlf,arizona.yaml | 125 ++++++++
.../bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 +-
.../devicetree/bindings/gpio/fsl-imx-gpio.txt | 35 --
.../devicetree/bindings/gpio/fsl-imx-gpio.yaml | 68 ++++
.../devicetree/bindings/gpio/gpio-mxs.txt | 88 ------
.../devicetree/bindings/gpio/gpio-mxs.yaml | 136 ++++++++
.../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 94 ------
.../bindings/gpio/renesas,rcar-gpio.yaml | 144 +++++++++
.../devicetree/bindings/gpio/sifive,gpio.yaml | 2 +-
.../devicetree/bindings/gpu/arm,mali-bifrost.yaml | 6 +
.../devicetree/bindings/gpu/arm,mali-midgard.yaml | 20 +-
.../devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 +
.../devicetree/bindings/gpu/vivante,gc.yaml | 2 +-
.../bindings/hwmon/adi,axi-fan-control.yaml | 3 +-
.../devicetree/bindings/hwmon/adi,ltc2947.yaml | 32 +-
.../devicetree/bindings/hwmon/adt7475.yaml | 18 +-
.../devicetree/bindings/hwmon/cirrus,lochnagar.txt | 26 --
.../bindings/hwmon/cirrus,lochnagar.yaml | 35 ++
.../devicetree/bindings/hwmon/ti,tmp513.yaml | 21 +-
.../devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 2 +-
.../devicetree/bindings/i2c/cdns,i2c-r1p10.yaml | 58 ++++
.../devicetree/bindings/i2c/i2c-cadence.txt | 28 --
.../devicetree/bindings/i2c/i2c-jz4780.txt | 33 --
.../devicetree/bindings/i2c/i2c-rk3x.yaml | 10 +-
Documentation/devicetree/bindings/i2c/i2c-xiic.txt | 25 --
.../devicetree/bindings/i2c/ingenic,i2c.yaml | 88 ++++++
.../devicetree/bindings/i2c/renesas,i2c.txt | 1 +
.../devicetree/bindings/i2c/renesas,iic.txt | 1 +
.../devicetree/bindings/i2c/st,stm32-i2c.yaml | 15 +-
.../bindings/i2c/xlnx,xps-iic-2.00.a.yaml | 49 +++
.../devicetree/bindings/iio/adc/adi,ad7124.yaml | 9 +-
.../devicetree/bindings/iio/adc/lltc,ltc2496.yaml | 9 +-
.../bindings/iio/adc/microchip,mcp3911.yaml | 7 +-
.../devicetree/bindings/iio/adc/st,stm32-adc.yaml | 35 +-
.../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 27 +-
.../devicetree/bindings/iio/imu/bmi160.txt | 37 ---
.../devicetree/bindings/iio/imu/bosch,bmi160.yaml | 75 +++++
.../devicetree/bindings/iio/light/tsl2772.yaml | 13 +-
.../bindings/iio/temperature/adi,ltc2983.yaml | 60 ++--
Documentation/devicetree/bindings/index.rst | 12 +
.../input/allwinner,sun4i-a10-lradc-keys.yaml | 9 +-
.../devicetree/bindings/input/gpio-keys-polled.txt | 45 ---
.../devicetree/bindings/input/gpio-keys.txt | 58 ----
.../devicetree/bindings/input/gpio-keys.yaml | 149 +++++++++
Documentation/devicetree/bindings/input/input.yaml | 9 +-
.../devicetree/bindings/input/iqs62x-keys.yaml | 7 +-
.../bindings/input/touchscreen/edt-ft5x06.yaml | 30 +-
.../bindings/input/touchscreen/goodix.yaml | 2 +-
.../bindings/interconnect/qcom,msm8916.yaml | 4 +-
.../bindings/interconnect/qcom,msm8974.yaml | 4 +-
.../bindings/interconnect/qcom,qcs404.yaml | 4 +-
.../bindings/interconnect/qcom,sc7180.yaml | 6 +-
.../bindings/interconnect/qcom,sdm845.yaml | 4 +-
.../allwinner,sun7i-a20-sc-nmi.yaml | 12 +-
.../bindings/interrupt-controller/arm,gic-v3.yaml | 39 +--
.../bindings/interrupt-controller/arm,gic.yaml | 9 +
.../bindings/interrupt-controller/fsl,irqsteer.txt | 35 --
.../interrupt-controller/fsl,irqsteer.yaml | 89 ++++++
.../bindings/interrupt-controller/ingenic,intc.txt | 28 --
.../interrupt-controller/ingenic,intc.yaml | 63 ++++
.../intel,ixp4xx-interrupt.yaml | 8 +-
.../interrupt-controller/loongson,liointc.yaml | 8 +-
.../interrupt-controller/renesas,intc-irqpin.txt | 62 ----
.../interrupt-controller/renesas,intc-irqpin.yaml | 107 +++++++
.../interrupt-controller/renesas,irqc.yaml | 3 +-
.../interrupt-controller/st,stm32-exti.yaml | 12 +-
.../devicetree/bindings/iommu/arm,smmu.yaml | 3 +-
.../bindings/iommu/renesas,ipmmu-vmsa.txt | 73 -----
.../bindings/iommu/renesas,ipmmu-vmsa.yaml | 98 ++++++
.../devicetree/bindings/iommu/samsung,sysmmu.yaml | 10 +-
.../devicetree/bindings/ipmi/ipmi-smic.txt | 25 --
.../devicetree/bindings/ipmi/ipmi-smic.yaml | 63 ++++
Documentation/devicetree/bindings/leds/common.yaml | 13 +-
.../devicetree/bindings/leds/leds-gpio.yaml | 3 +-
.../bindings/leds/rohm,bd71828-leds.yaml | 9 +-
.../devicetree/bindings/mailbox/fsl,mu.txt | 58 ----
.../devicetree/bindings/mailbox/fsl,mu.yaml | 91 ++++++
.../devicetree/bindings/mailbox/st,stm32-ipcc.yaml | 7 +-
.../bindings/media/allwinner,sun4i-a10-csi.yaml | 28 +-
.../devicetree/bindings/media/amlogic,gx-vdec.yaml | 20 +-
.../bindings/media/amlogic,meson-gx-ao-cec.yaml | 5 +-
.../devicetree/bindings/media/i2c/imx219.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.txt | 50 ---
.../bindings/media/marvell,mmp2-ccic.yaml | 99 ++++++
.../bindings/media/qcom,sc7180-venus.yaml | 2 +-
.../bindings/media/qcom,sdm845-venus-v2.yaml | 2 +-
.../bindings/media/qcom,sdm845-venus.yaml | 2 +-
Documentation/devicetree/bindings/media/rc.yaml | 265 ++++++++--------
.../devicetree/bindings/media/renesas,ceu.yaml | 39 ++-
.../devicetree/bindings/media/renesas,csi2.yaml | 2 +-
.../devicetree/bindings/media/renesas,vin.yaml | 21 +-
.../devicetree/bindings/media/ti,vpe.yaml | 2 +-
.../memory-controllers/calxeda-ddr-ctrlr.txt | 16 -
.../memory-controllers/calxeda-ddr-ctrlr.yaml | 42 +++
.../bindings/memory-controllers/exynos-srom.yaml | 13 +-
.../memory-controllers/fsl/imx8m-ddrc.yaml | 6 +-
.../memory-controllers/ingenic,jz4780-nemc.txt | 76 -----
.../bindings/memory-controllers/ingenic,nemc.yaml | 126 ++++++++
.../memory-controllers/nvidia,tegra124-emc.yaml | 13 +-
.../memory-controllers/nvidia,tegra124-mc.yaml | 5 +-
.../memory-controllers/nvidia,tegra210-emc.yaml | 82 +++++
.../memory-controllers/nvidia,tegra30-emc.yaml | 9 +-
.../memory-controllers/nvidia,tegra30-mc.yaml | 3 +-
.../bindings/memory-controllers/renesas,dbsc.txt | 44 ---
.../bindings/memory-controllers/renesas,dbsc.yaml | 56 ++++
.../bindings/mfd/allwinner,sun4i-a10-ts.yaml | 20 +-
Documentation/devicetree/bindings/mfd/arizona.txt | 101 ------
.../devicetree/bindings/mfd/cirrus,lochnagar.txt | 85 -----
.../devicetree/bindings/mfd/cirrus,lochnagar.yaml | 352 +++++++++++++++++++++
.../devicetree/bindings/mfd/cirrus,madera.yaml | 299 +++++++++++++++++
Documentation/devicetree/bindings/mfd/madera.txt | 114 -------
.../devicetree/bindings/mfd/st,stm32-lptimer.yaml | 4 +-
.../devicetree/bindings/mfd/st,stm32-timers.yaml | 37 ++-
.../devicetree/bindings/mfd/st,stpmic1.yaml | 9 +-
Documentation/devicetree/bindings/mfd/syscon.yaml | 17 +-
.../devicetree/bindings/mfd/wlf,arizona.yaml | 280 ++++++++++++++++
.../devicetree/bindings/mips/ingenic/devices.yaml | 4 +
.../devicetree/bindings/mmc/aspeed,sdhci.yaml | 4 +-
.../devicetree/bindings/mmc/cdns,sdhci.yaml | 79 ++---
.../devicetree/bindings/mmc/ingenic,mmc.yaml | 79 +++++
Documentation/devicetree/bindings/mmc/jz4740.txt | 41 ---
.../devicetree/bindings/mmc/mmc-controller.yaml | 37 +--
Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 2 +-
.../devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 24 +-
.../bindings/mmc/socionext,uniphier-sd.yaml | 14 +-
.../bindings/mmc/synopsys-dw-mshc-common.yaml | 14 +-
.../bindings/mtd/allwinner,sun4i-a10-nand.yaml | 13 +-
.../devicetree/bindings/mtd/denali,nand.yaml | 4 +-
.../bindings/mtd/ingenic,jz4780-nand.txt | 92 ------
.../devicetree/bindings/mtd/ingenic,nand.yaml | 132 ++++++++
.../devicetree/bindings/mtd/nand-controller.yaml | 27 +-
.../bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 +-
.../devicetree/bindings/net/calxeda-xgmac.txt | 18 --
.../devicetree/bindings/net/calxeda-xgmac.yaml | 49 +++
.../devicetree/bindings/net/can/bosch,m_can.yaml | 111 ++++---
.../bindings/net/ethernet-controller.yaml | 34 +-
.../devicetree/bindings/net/qca,ar803x.yaml | 17 +-
.../devicetree/bindings/net/qcom,ipa.yaml | 12 +-
.../devicetree/bindings/net/renesas,ether.yaml | 9 +-
.../devicetree/bindings/net/renesas,ravb.txt | 1 +
.../devicetree/bindings/net/snps,dwmac.yaml | 30 +-
.../devicetree/bindings/net/stm32-dwmac.txt | 44 ---
.../devicetree/bindings/net/stm32-dwmac.yaml | 148 +++++++++
.../devicetree/bindings/net/ti,cpsw-switch.yaml | 18 +-
.../devicetree/bindings/net/ti,davinci-mdio.yaml | 34 +-
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 98 +++---
.../devicetree/bindings/nvmem/imx-iim.txt | 22 --
.../devicetree/bindings/nvmem/imx-iim.yaml | 57 ++++
.../devicetree/bindings/nvmem/imx-ocotp.txt | 50 ---
.../devicetree/bindings/nvmem/imx-ocotp.yaml | 95 ++++++
.../devicetree/bindings/nvmem/mxs-ocotp.txt | 24 --
.../devicetree/bindings/nvmem/mxs-ocotp.yaml | 50 +++
Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 -
.../devicetree/bindings/nvmem/rockchip-efuse.txt | 54 ----
.../devicetree/bindings/nvmem/rockchip-efuse.yaml | 70 ++++
.../devicetree/bindings/nvmem/st,stm32-romem.yaml | 17 +
.../devicetree/bindings/pci/cdns-pcie-host.yaml | 3 +-
.../devicetree/bindings/pci/cdns-pcie.yaml | 3 +-
.../devicetree/bindings/pci/intel-gw-pcie.yaml | 7 +-
Documentation/devicetree/bindings/pci/pci-ep.yaml | 9 +-
.../devicetree/bindings/pci/pci-rcar-gen2.txt | 3 +-
.../phy/amlogic,meson-axg-mipi-pcie-analog.yaml | 2 +-
.../bindings/phy/amlogic,meson-axg-pcie.yaml | 2 +-
.../devicetree/bindings/phy/calxeda-combophy.txt | 17 -
.../devicetree/bindings/phy/calxeda-combophy.yaml | 51 +++
.../bindings/phy/intel,lgm-emmc-phy.yaml | 2 +-
.../bindings/phy/phy-cadence-torrent.yaml | 59 ++--
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 65 ++--
.../devicetree/bindings/phy/rcar-gen2-phy.txt | 3 +-
.../bindings/phy/rockchip,px30-dsi-dphy.yaml | 2 +-
.../bindings/phy/socionext,uniphier-pcie-phy.yaml | 77 +++++
.../bindings/phy/socionext,uniphier-usb2-phy.yaml | 85 +++++
.../phy/socionext,uniphier-usb3hs-phy.yaml | 103 ++++++
.../phy/socionext,uniphier-usb3ss-phy.yaml | 96 ++++++
.../devicetree/bindings/phy/uniphier-pcie-phy.txt | 36 ---
.../devicetree/bindings/phy/uniphier-usb2-phy.txt | 45 ---
.../bindings/phy/uniphier-usb3-hsphy.txt | 69 ----
.../bindings/phy/uniphier-usb3-ssphy.txt | 58 ----
.../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 12 +-
.../bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 37 +--
.../bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 46 ++-
.../bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 108 +++----
.../bindings/pinctrl/cirrus,lochnagar.txt | 141 ---------
.../bindings/pinctrl/cirrus,lochnagar.yaml | 190 +++++++++++
.../bindings/pinctrl/cirrus,madera-pinctrl.txt | 99 ------
.../devicetree/bindings/pinctrl/cirrus,madera.yaml | 122 +++++++
.../bindings/pinctrl/fsl,imx8mm-pinctrl.yaml | 31 +-
.../bindings/pinctrl/fsl,imx8mn-pinctrl.yaml | 31 +-
.../bindings/pinctrl/fsl,imx8mp-pinctrl.yaml | 31 +-
.../bindings/pinctrl/fsl,imx8mq-pinctrl.yaml | 31 +-
.../devicetree/bindings/pinctrl/intel,lgm-io.yaml | 4 +-
.../devicetree/bindings/pinctrl/pinmux-node.yaml | 3 +-
.../bindings/pinctrl/qcom,ipq6018-pinctrl.yaml | 3 +-
.../bindings/pinctrl/st,stm32-pinctrl.yaml | 54 ++--
.../bindings/power/amlogic,meson-ee-pwrc.yaml | 3 +-
.../devicetree/bindings/power/fsl,imx-gpc.txt | 91 ------
.../devicetree/bindings/power/fsl,imx-gpc.yaml | 124 ++++++++
.../devicetree/bindings/power/fsl,imx-gpcv2.txt | 77 -----
.../devicetree/bindings/power/fsl,imx-gpcv2.yaml | 108 +++++++
.../devicetree/bindings/power/renesas,apmu.yaml | 1 +
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 27 --
Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 66 ++++
.../devicetree/bindings/pwm/imx-tpm-pwm.txt | 22 --
.../devicetree/bindings/pwm/imx-tpm-pwm.yaml | 55 ++++
Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 17 -
Documentation/devicetree/bindings/pwm/mxs-pwm.yaml | 43 +++
.../devicetree/bindings/pwm/pwm-samsung.yaml | 27 +-
.../devicetree/bindings/pwm/renesas,pwm-rcar.yaml | 2 +-
.../bindings/regulator/arizona-regulator.txt | 18 --
.../bindings/regulator/cirrus,lochnagar.txt | 82 -----
.../bindings/regulator/gpio-regulator.yaml | 35 +-
.../devicetree/bindings/regulator/mps,mp5416.yaml | 6 +-
.../devicetree/bindings/regulator/mps,mpq7920.yaml | 28 +-
.../devicetree/bindings/regulator/regulator.yaml | 5 +-
.../bindings/regulator/rohm,bd71828-regulator.yaml | 34 +-
.../bindings/regulator/rohm,bd71837-regulator.yaml | 27 +-
.../bindings/regulator/st,stm32-booster.yaml | 3 +-
.../bindings/regulator/st,stm32mp1-pwr-reg.yaml | 3 +-
.../devicetree/bindings/regulator/wlf,arizona.yaml | 37 +++
.../bindings/remoteproc/st,stm32-rproc.yaml | 11 +-
.../bindings/reserved-memory/reserved-memory.txt | 2 +
.../reset/brcm,bcm7216-pcie-sata-rescal.yaml | 4 +-
.../devicetree/bindings/reset/intel,rcu-gw.yaml | 3 +-
Documentation/devicetree/bindings/riscv/cpus.yaml | 20 +-
.../devicetree/bindings/rtc/renesas,sh-rtc.yaml | 5 +
Documentation/devicetree/bindings/rtc/rtc-mxc.txt | 26 --
Documentation/devicetree/bindings/rtc/rtc-mxc.yaml | 57 ++++
.../devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 -
.../devicetree/bindings/rtc/rtc-mxc_v2.yaml | 46 +++
.../devicetree/bindings/rtc/st,stm32-rtc.yaml | 47 ++-
Documentation/devicetree/bindings/serial/8250.txt | 100 ------
Documentation/devicetree/bindings/serial/8250.yaml | 233 ++++++++++++++
.../bindings/serial/amlogic,meson-uart.yaml | 16 +-
.../devicetree/bindings/serial/ingenic,uart.txt | 28 --
.../devicetree/bindings/serial/ingenic,uart.yaml | 94 ++++++
.../devicetree/bindings/serial/mrvl-serial.txt | 4 -
.../devicetree/bindings/serial/pl011.yaml | 10 +-
.../devicetree/bindings/serial/qca,ar9330-uart.txt | 31 --
.../bindings/serial/qca,ar9330-uart.yaml | 50 +++
.../bindings/serial/renesas,em-uart.yaml | 49 +++
.../devicetree/bindings/serial/renesas,hscif.yaml | 1 +
.../devicetree/bindings/serial/renesas,scif.yaml | 1 +
.../devicetree/bindings/serial/renesas,scifa.yaml | 15 +-
.../devicetree/bindings/serial/renesas,scifb.yaml | 1 +
.../devicetree/bindings/serial/rs485.yaml | 43 ++-
.../devicetree/bindings/serial/samsung_uart.yaml | 5 +-
.../devicetree/bindings/serial/serial.yaml | 8 +
.../devicetree/bindings/serial/sifive-serial.yaml | 2 +-
.../bindings/soc/amlogic/amlogic,canvas.yaml | 10 +-
.../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 94 ------
.../devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 225 +++++++++++++
.../devicetree/bindings/sound/adi,adau7118.yaml | 20 +-
.../bindings/sound/allwinner,sun4i-a10-codec.yaml | 51 ++-
.../devicetree/bindings/sound/amlogic,aiu.yaml | 3 +-
.../bindings/sound/amlogic,g12a-toacodec.yaml | 2 +-
.../devicetree/bindings/sound/amlogic,t9015.yaml | 3 +-
.../devicetree/bindings/sound/cirrus,lochnagar.txt | 39 ---
.../bindings/sound/cirrus,lochnagar.yaml | 52 +++
.../devicetree/bindings/sound/cirrus,madera.yaml | 113 +++++++
Documentation/devicetree/bindings/sound/madera.txt | 67 ----
.../devicetree/bindings/sound/qcom,wcd934x.yaml | 3 +-
.../devicetree/bindings/sound/renesas,fsi.yaml | 41 ++-
.../devicetree/bindings/sound/rockchip-i2s.yaml | 6 +-
.../devicetree/bindings/sound/tlv320adcx140.yaml | 10 +-
.../devicetree/bindings/sound/wlf,arizona.txt | 53 ----
.../devicetree/bindings/sound/wlf,arizona.yaml | 114 +++++++
.../devicetree/bindings/spi/marvell,mmp2-ssp.yaml | 58 ++++
.../bindings/spi/qcom,spi-qcom-qspi.yaml | 10 +-
.../devicetree/bindings/spi/renesas,hspi.yaml | 4 +-
.../devicetree/bindings/spi/renesas,sh-msiof.yaml | 44 ++-
.../devicetree/bindings/spi/spi-controller.yaml | 14 +-
.../devicetree/bindings/spi/spi-pl022.yaml | 57 ++--
.../devicetree/bindings/spi/spi-pxa2xx.txt | 27 --
.../devicetree/bindings/spi/spi-sifive.yaml | 25 +-
.../devicetree/bindings/spi/st,stm32-qspi.yaml | 4 +-
.../sram/allwinner,sun4i-a10-system-control.yaml | 64 ++--
.../devicetree/bindings/sram/rockchip-pmu-sram.txt | 16 -
Documentation/devicetree/bindings/sram/sram.yaml | 28 +-
...bmitting-patches.txt => submitting-patches.rst} | 12 +-
.../bindings/thermal/amlogic,thermal.yaml | 10 +-
.../devicetree/bindings/thermal/imx-thermal.txt | 61 ----
.../devicetree/bindings/thermal/imx-thermal.yaml | 102 ++++++
.../devicetree/bindings/thermal/imx8mm-thermal.txt | 15 -
.../bindings/thermal/imx8mm-thermal.yaml | 58 ++++
.../devicetree/bindings/thermal/qcom-tsens.yaml | 7 +-
.../bindings/thermal/rcar-gen3-thermal.txt | 60 ----
.../bindings/thermal/rcar-gen3-thermal.yaml | 99 ++++++
.../devicetree/bindings/thermal/rcar-thermal.yaml | 7 +-
.../thermal/socionext,uniphier-thermal.yaml | 59 ++++
.../devicetree/bindings/thermal/sprd-thermal.yaml | 2 +-
.../bindings/thermal/uniphier-thermal.txt | 65 ----
.../devicetree/bindings/timer/arm,arch_timer.yaml | 10 +-
.../bindings/timer/arm,arch_timer_mmio.yaml | 11 +-
.../bindings/timer/cadence,ttc-timer.txt | 21 --
.../devicetree/bindings/timer/cdns,ttc.yaml | 48 +++
.../devicetree/bindings/timer/fsl,imxgpt.txt | 45 ---
.../devicetree/bindings/timer/fsl,imxgpt.yaml | 72 +++++
.../devicetree/bindings/timer/ingenic,tcu.txt | 138 --------
.../devicetree/bindings/timer/ingenic,tcu.yaml | 280 ++++++++++++++++
.../devicetree/bindings/timer/nxp,sysctr-timer.txt | 25 --
.../bindings/timer/nxp,sysctr-timer.yaml | 54 ++++
.../devicetree/bindings/timer/nxp,tpm-timer.txt | 28 --
.../devicetree/bindings/timer/nxp,tpm-timer.yaml | 61 ++++
.../devicetree/bindings/timer/renesas,cmt.txt | 110 -------
.../devicetree/bindings/timer/renesas,cmt.yaml | 182 +++++++++++
.../devicetree/bindings/timer/renesas,mtu2.txt | 42 ---
.../devicetree/bindings/timer/renesas,mtu2.yaml | 76 +++++
.../devicetree/bindings/timer/renesas,ostm.txt | 31 --
.../devicetree/bindings/timer/renesas,ostm.yaml | 59 ++++
.../devicetree/bindings/ufs/ti,j721e-ufs.yaml | 65 ++--
.../bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 3 +-
.../devicetree/bindings/usb/aspeed,usb-vhub.yaml | 18 +-
Documentation/devicetree/bindings/usb/dwc2.yaml | 11 +-
Documentation/devicetree/bindings/usb/ehci-mv.txt | 23 --
.../devicetree/bindings/usb/generic-ehci.yaml | 27 +-
.../devicetree/bindings/usb/generic-ohci.yaml | 6 +
.../devicetree/bindings/usb/ingenic,musb.yaml | 3 +
.../bindings/usb/marvell,pxau2o-ehci.yaml | 62 ++++
.../devicetree/bindings/usb/nvidia,tegra-xudc.yaml | 6 +-
.../devicetree/bindings/usb/qcom,dwc3.txt | 104 ------
.../devicetree/bindings/usb/qcom,dwc3.yaml | 174 ++++++++++
.../devicetree/bindings/usb/renesas,usb3-peri.yaml | 2 +-
.../devicetree/bindings/usb/renesas,usbhs.yaml | 3 +-
.../devicetree/bindings/usb/ti,j721e-usb.yaml | 54 ++--
.../devicetree/bindings/usb/usb-conn-gpio.txt | 30 --
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 22 ++
.../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 24 --
.../devicetree/bindings/watchdog/fsl-imx-wdt.yaml | 54 ++++
.../bindings/watchdog/fsl-imx7ulp-wdt.txt | 22 --
.../bindings/watchdog/fsl-imx7ulp-wdt.yaml | 60 ++++
.../devicetree/bindings/watchdog/renesas,wdt.txt | 50 ---
.../devicetree/bindings/watchdog/renesas,wdt.yaml | 101 ++++++
.../bindings/watchdog/socionext,uniphier-wdt.yaml | 36 +++
.../devicetree/bindings/watchdog/ti,rti-wdt.yaml | 2 +-
.../devicetree/bindings/watchdog/uniphier-wdt.txt | 20 --
.../{writing-bindings.txt => writing-bindings.rst} | 9 +-
.../devicetree/{changesets.txt => changesets.rst} | 24 +-
...tion-notes.txt => dynamic-resolution-notes.rst} | 5 +-
Documentation/devicetree/index.rst | 17 +
.../{of_unittest.txt => of_unittest.rst} | 192 +++++------
.../{overlay-notes.txt => overlay-notes.rst} | 119 ++++---
.../{usage-model.txt => usage-model.rst} | 35 +-
Documentation/index.rst | 3 +
Documentation/process/submitting-patches.rst | 2 +-
.../it_IT/process/submitting-patches.rst | 2 +-
MAINTAINERS | 33 +-
drivers/of/dynamic.c | 3 +-
drivers/of/fdt.c | 8 +-
drivers/of/kobj.c | 3 +-
drivers/of/of_reserved_mem.c | 10 +-
drivers/of/platform.c | 2 +-
drivers/of/property.c | 20 +-
include/linux/mfd/core.h | 2 +-
scripts/checkpatch.pl | 2 +-
470 files changed, 11822 insertions(+), 7433 deletions(-)
rename Documentation/devicetree/bindings/{ABI.txt => ABI.rst} (94%)
create mode 100644 Documentation/devicetree/bindings/arm/calxeda/hb-sregs.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt
create mode 100644 Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml
delete mode 100644 Documentation/devicetree/bindings/ata/sata_highbank.txt
create mode 100644 Documentation/devicetree/bindings/ata/sata_highbank.yaml
delete mode 100644 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
create mode 100644 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/calxeda.txt
create mode 100644 Documentation/devicetree/bindings/clock/calxeda.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx23-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx25-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx27-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx28-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx28-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx31-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx31-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx35-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx35-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx5-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx5-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6q-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/ingenic,cgu.txt
create mode 100644 Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
delete mode 100644 Documentation/devicetree/bindings/display/bridge/anx7814.txt
create mode 100644 Documentation/devicetree/bindings/dma/ingenic,dma.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt
delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt
create mode 100644 Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
delete mode 100644 Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt
create mode 100644 Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
delete mode 100644 Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
create mode 100644 Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml
delete mode 100644 Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
create mode 100644 Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-cadence.txt
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-jz4780.txt
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-xiic.txt
create mode 100644 Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
create mode 100644 Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
delete mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
create mode 100644 Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
create mode 100644 Documentation/devicetree/bindings/index.rst
delete mode 100644 Documentation/devicetree/bindings/input/gpio-keys-polled.txt
delete mode 100644 Documentation/devicetree/bindings/input/gpio-keys.txt
create mode 100644 Documentation/devicetree/bindings/input/gpio-keys.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.yaml
delete mode 100644 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
create mode 100644 Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
delete mode 100644 Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
create mode 100644 Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/fsl,mu.txt
create mode 100644 Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
delete mode 100644 Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
create mode 100644 Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
delete mode 100644 Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml
delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
delete mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/arizona.txt
delete mode 100644 Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/cirrus,madera.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
create mode 100644 Documentation/devicetree/bindings/mfd/wlf,arizona.yaml
create mode 100644 Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/jz4740.txt
delete mode 100644 Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
delete mode 100644 Documentation/devicetree/bindings/net/calxeda-xgmac.txt
create mode 100644 Documentation/devicetree/bindings/net/calxeda-xgmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/nvmem/imx-iim.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/imx-iim.yaml
delete mode 100644 Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
delete mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
delete mode 100644 Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/calxeda-combophy.txt
create mode 100644 Documentation/devicetree/bindings/phy/calxeda-combophy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/uniphier-pcie-phy.txt
delete mode 100644 Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt
delete mode 100644 Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt
delete mode 100644 Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt
delete mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml
delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.txt
create mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/mxs-pwm.txt
create mode 100644 Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/arizona-regulator.txt
delete mode 100644 Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc.yaml
delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/8250.txt
create mode 100644 Documentation/devicetree/bindings/serial/8250.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/ingenic,uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/ingenic,uart.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/mrvl-serial.txt
delete mode 100644 Documentation/devicetree/bindings/serial/qca,ar9330-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml
create mode 100644 Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
delete mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt
create mode 100644 Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
create mode 100644 Documentation/devicetree/bindings/sound/cirrus,madera.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/madera.txt
delete mode 100644 Documentation/devicetree/bindings/sound/wlf,arizona.txt
create mode 100644 Documentation/devicetree/bindings/sound/wlf,arizona.yaml
create mode 100644 Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-pxa2xx.txt
delete mode 100644 Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
rename Documentation/devicetree/bindings/{submitting-patches.txt => submitting-patches.rst} (92%)
delete mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.yaml
delete mode 100644 Documentation/devicetree/bindings/thermal/imx8mm-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
delete mode 100644 Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
create mode 100644 Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
delete mode 100644 Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
delete mode 100644 Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/cdns,ttc.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/renesas,cmt.txt
create mode 100644 Documentation/devicetree/bindings/timer/renesas,cmt.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/renesas,mtu2.txt
create mode 100644 Documentation/devicetree/bindings/timer/renesas,mtu2.yaml
delete mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/ehci-mv.txt
create mode 100644 Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.txt
create mode 100644 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
delete mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
create mode 100644 Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt
rename Documentation/devicetree/bindings/{writing-bindings.txt => writing-bindings.rst} (89%)
rename Documentation/devicetree/{changesets.txt => changesets.rst} (59%)
rename Documentation/devicetree/{dynamic-resolution-notes.txt => dynamic-resolution-notes.rst} (90%)
create mode 100644 Documentation/devicetree/index.rst
rename Documentation/devicetree/{of_unittest.txt => of_unittest.rst} (54%)
rename Documentation/devicetree/{overlay-notes.txt => overlay-notes.rst} (50%)
rename Documentation/devicetree/{usage-model.txt => usage-model.rst} (97%)
^ permalink raw reply
* Re: [Freedreno] [PATCH v7 6/6] arm6: dts: qcom: sm845: Set the compatible string for the GPU SMMU
From: Jordan Crouse @ 2020-06-04 22:02 UTC (permalink / raw)
To: Rob Clark
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Linux Kernel Mailing List, Rob Herring,
Bjorn Andersson, Andy Gross, freedreno
In-Reply-To: <CAF6AEGt4N5+0h0fkrO7m6KD3VMXkdoFyhN5Nz72DcMjoHX6XWA@mail.gmail.com>
On Thu, Jun 04, 2020 at 02:27:21PM -0700, Rob Clark wrote:
> On Thu, Jun 4, 2020 at 1:57 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> >
> > Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
> > split pagetables.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> >
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 8eb5a31346d2..8b15cd74e9ba 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -3556,7 +3556,7 @@
> > };
> >
> > adreno_smmu: iommu@5040000 {
> > - compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> > + compatible = "qcom,adreno-smmu", "qcom,smmu-v2";
>
> Should this be something like:
>
> compatible = "qcom,adreno-smmu", "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
>
> so that new dtb still works with old kernel?
As far as I know qcom,sdm845-smmu-v2 never was actually used unless we were
doing the parsing trick somewhere.
Jordan
> > reg = <0 0x5040000 0 0x10000>;
> > #iommu-cells = <1>;
> > #global-interrupts = <2>;
> > --
> > 2.17.1
> >
> > _______________________________________________
> > Freedreno mailing list
> > Freedreno@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-06-04 21:28 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Mark Brown, Rob Herring, Nicolas Saenz Julienne,
Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:SPI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl, lukas
The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
For the BCM2835 case which is deemed performance critical, we would like
to continue using an interrupt handler which does not have the extra
comparison on BCM2835_SPI_CS_INTR.
To support that requirement the common interrupt handling code between
the shared and non-shared interrupt paths is split into a
bcm2835_spi_interrupt_common() and both bcm2835_spi_interrupt() as well
as bcm2835_spi_shared_interrupt() make use of it.
During probe, we determine if there is at least another instance of this
SPI controller, and if there is, then we install a shared interrupt
handler.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- identify other available SPI nodes to determine if we need to set-up
interrupt sharing. This needs to happen for the very first instance
since we cannot know for the first instance whether interrupt sharing
is needed or not.
drivers/spi/spi-bcm2835.c | 61 ++++++++++++++++++++++++++++++++-------
1 file changed, 50 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 237bd306c268..0288b5b3de1e 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -361,11 +361,10 @@ static void bcm2835_spi_reset_hw(struct spi_controller *ctlr)
bcm2835_wr(bs, BCM2835_SPI_DLEN, 0);
}
-static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+static inline irqreturn_t bcm2835_spi_interrupt_common(struct spi_controller *ctlr,
+ u32 cs)
{
- struct spi_controller *ctlr = dev_id;
struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
- u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
/*
* An interrupt is signaled either if DONE is set (TX FIFO empty)
@@ -394,6 +393,27 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctlr = dev_id;
+ struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+ u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+ return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
+static irqreturn_t bcm2835_spi_shared_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctlr = dev_id;
+ struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+ u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+ if (!(cs & BCM2835_SPI_CS_INTR))
+ return IRQ_NONE;
+
+ return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
static int bcm2835_spi_transfer_one_irq(struct spi_controller *ctlr,
struct spi_device *spi,
struct spi_transfer *tfr,
@@ -1287,12 +1307,37 @@ static int bcm2835_spi_setup(struct spi_device *spi)
return 0;
}
+static const struct of_device_id bcm2835_spi_match[] = {
+ { .compatible = "brcm,bcm2835-spi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
+
static int bcm2835_spi_probe(struct platform_device *pdev)
{
+ irq_handler_t bcm2835_spi_isr_func = bcm2835_spi_interrupt;
struct spi_controller *ctlr;
+ unsigned long flags = 0;
+ struct device_node *dn;
struct bcm2835_spi *bs;
int err;
+ /* On BCM2711 there can be multiple SPI controllers enabled sharing the
+ * same interrupt line, but we also want to minimize the overhead if
+ * there is no need to support interrupt sharing. If we find at least
+ * another available instane (not counting the one we are probed from),
+ * then we assume that interrupt sharing is necessary.
+ */
+ for_each_compatible_node(dn, NULL, bcm2835_spi_match[0].compatible) {
+ err = of_device_is_available(dn) && dn != pdev->dev.of_node;
+ of_node_put(dn);
+ if (err) {
+ flags = IRQF_SHARED;
+ bcm2835_spi_isr_func = bcm2835_spi_shared_interrupt;
+ break;
+ }
+ }
+
ctlr = spi_alloc_master(&pdev->dev, ALIGN(sizeof(*bs),
dma_get_cache_alignment()));
if (!ctlr)
@@ -1344,8 +1389,8 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
bcm2835_wr(bs, BCM2835_SPI_CS,
BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
- err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt, 0,
- dev_name(&pdev->dev), ctlr);
+ err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_isr_func,
+ flags, dev_name(&pdev->dev), ctlr);
if (err) {
dev_err(&pdev->dev, "could not request IRQ: %d\n", err);
goto out_dma_release;
@@ -1400,12 +1445,6 @@ static void bcm2835_spi_shutdown(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to shutdown\n");
}
-static const struct of_device_id bcm2835_spi_match[] = {
- { .compatible = "brcm,bcm2835-spi", },
- {}
-};
-MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
-
static struct platform_driver bcm2835_spi_driver = {
.driver = {
.name = DRV_NAME,
--
2.17.1
^ permalink raw reply related
* Re: [Freedreno] [PATCH v7 6/6] arm6: dts: qcom: sm845: Set the compatible string for the GPU SMMU
From: Rob Clark @ 2020-06-04 21:27 UTC (permalink / raw)
To: Jordan Crouse
Cc: linux-arm-msm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Rob Herring, Bjorn Andersson,
Andy Gross, freedreno
In-Reply-To: <20200604205710.3167-7-jcrouse@codeaurora.org>
On Thu, Jun 4, 2020 at 1:57 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
> split pagetables.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 8eb5a31346d2..8b15cd74e9ba 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3556,7 +3556,7 @@
> };
>
> adreno_smmu: iommu@5040000 {
> - compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> + compatible = "qcom,adreno-smmu", "qcom,smmu-v2";
Should this be something like:
compatible = "qcom,adreno-smmu", "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
so that new dtb still works with old kernel?
BR,
-R
> reg = <0 0x5040000 0 0x10000>;
> #iommu-cells = <1>;
> #global-interrupts = <2>;
> --
> 2.17.1
>
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
^ 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