* Re: [PATCH v3 000/105] drm/vc4: Support BCM2711 Display Pipeline
From: Stefan Wahren @ 2020-06-02 20:12 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne, Eric Anholt
Cc: devicetree, Tim Gover, Dave Stevenson, Stephen Boyd,
Michael Turquette, Kamal Dasu, linux-kernel, dri-devel, linux-clk,
Rob Herring, bcm-kernel-feedback-list, linux-rpi-kernel,
Philipp Zabel, Phil Elwell, linux-arm-kernel
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
Hi Maxime,
Am 27.05.20 um 17:47 schrieb Maxime Ripard:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
>
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
>
> Only the HDMI support is enabled for now (even though the DPI output has
> been tested too).
>
> This is based on the firmware clocks series sent separately:
> https://lore.kernel.org/lkml/cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.maxime@cerno.tech/
>
> Let me know if you have any comments
> Maxime
>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Cc: devicetree@vger.kernel.org
> Cc: Kamal Dasu <kdasu.kdev@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
>
> Changes from v2:
> - Rebased on top of next-20200526
i assume this is the reason why this series doesn't completely apply
against drm-misc-next.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Julius Werner @ 2020-06-02 20:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Lukas Bulwahn, Julius Werner, Evan Benn, Wim Van Sebroeck,
LINUX-WATCHDOG, Rob Herring, devicetree, Joe Perches,
kernel-janitors, LKML
In-Reply-To: <828311d2-61ea-42cb-1449-a53f3772543d@roeck-us.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 3/4] remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
From: Mathieu Poirier @ 2020-06-02 20:53 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200521001006.2725-4-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:05PM -0500, Suman Anna wrote:
> The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN
> voltage domain that are based on the TI's standard TMS320C66x DSP CorePac
> module. Each subsystem has a Fixed/Floating-Point DSP CPU, with 32 KB each
> of L1P & L1D SRAMs that can be configured and partitioned as either RAM
> and/or Cache, and 288 KB of L2 SRAM with 256 KB of memory configurable as
> either RAM and/or Cache. The CorePac also includes an Internal DMA (IDMA),
> External Memory Controller (EMC), Extended Memory Controller (XMC) with a
> Region Address Translator (RAT) unit for 32-bit to 48-bit address
> extension/translations, an Interrupt Controller (INTC) and a Powerdown
> Controller (PDC).
>
> A new remoteproc module is added to perform the device management of
> these DSP devices. The support is limited to images using only external
> DDR memory at the moment, the loading support to internal memories and
> any on-chip RAM memories will be added in a subsequent patch. RAT support
> is also left for a future patch, and as such the reserved memory carveout
> regions are all expected to be using memory regions within the first 2 GB.
> Error Recovery and Power Management features are not currently supported.
>
> The C66x remote processors do not have an MMU, and so require fixed memory
> carveout regions matching the firmware image addresses. Support for this
> is provided by mandating multiple memory regions to be attached to the
> remoteproc device. The first memory region will be used to serve as the
> DMA pool for all dynamic allocations like the vrings and vring buffers.
> The remaining memory regions are mapped into the kernel at device probe
> time, and are used to provide address translations for firmware image
> segments without the need for any RSC_CARVEOUT entries. Any firmware
> image using memory outside of the supplied reserved memory carveout
> regions will be errored out.
>
> The driver uses various TI-SCI interfaces to talk to the System Controller
> (DMSC) for managing configuration, power and reset management of these
> cores. IPC between the A72 cores and the DSP cores is supported through
> the virtio rpmsg stack using shared memory and OMAP Mailboxes.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Dropped the pm_runtime usage
> - Replaced the private k3_dsp_rproc_get_firmware() with the newly introduced
> rproc_of_parse_firmware()
> - Addressed other minor comments from Mathieu - Revised help on Kconfig, reordered
> header files, whitespace indentation fixes, remove the stale memset comment on
> internal memories, renamed struct k3_dsp_rproc_mem to struct k3_dsp_mem.
> v1: https://patchwork.kernel.org/patch/11458577/
>
> drivers/remoteproc/Kconfig | 13 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 701 ++++++++++++++++++++++
> 3 files changed, 715 insertions(+)
> create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 2c9fb870a276..ef787774b52b 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -265,6 +265,19 @@ config TI_K3_R5_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> a slave processor
>
> +config TI_K3_DSP_REMOTEPROC
> + tristate "TI K3 DSP remoteproc support"
> + depends on ARCH_K3
> + select MAILBOX
> + select OMAP2PLUS_MBOX
> + help
> + Say m here to support TI's C66x and C71x DSP remote processor
> + subsystems on various TI K3 family of SoCs through the remote
> + processor framework.
> +
> + It's safe to say N here if you're not interested in utilizing
> + the DSP slave processors.
> +
> endif # REMOTEPROC
>
> endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index ea0c6812e4fc..9f87d222744c 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> +obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> new file mode 100644
> index 000000000000..e4036f5992fe
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -0,0 +1,701 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 DSP Remote Processor(s) driver
> + *
> + * Copyright (C) 2018-2020 Texas Instruments Incorporated - http://www.ti.com/
> + * Suman Anna <s-anna@ti.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/omap-mailbox.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define KEYSTONE_RPROC_LOCAL_ADDRESS_MASK (SZ_16M - 1)
> +
> +/**
> + * struct k3_dsp_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from DSP view
> + * @size: Size of the memory region
> + */
> +struct k3_dsp_mem {
> + void __iomem *cpu_addr;
> + phys_addr_t bus_addr;
> + u32 dev_addr;
> + size_t size;
> +};
> +
> +/**
> + * struct k3_dsp_mem_data - memory definitions for a DSP
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_dsp_mem_data {
> + const char *name;
> + const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_dsp_dev_data - device data structure for a DSP
> + * @mems: pointer to memory definitions for a DSP
> + * @num_mems: number of memory regions in @mems
> + * @boot_align_addr: boot vector address alignment granularity
> + * @uses_lreset: flag to denote the need for local reset management
> + */
> +struct k3_dsp_dev_data {
> + const struct k3_dsp_mem_data *mems;
> + u32 num_mems;
> + u32 boot_align_addr;
> + bool uses_lreset;
> +};
> +
> +/**
> + * struct k3_dsp_rproc - k3 DSP remote processor driver structure
> + * @dev: cached device pointer
> + * @rproc: remoteproc device handle
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control handle
> + * @data: pointer to DSP-specific device data
> + * @tsp: TI-SCI processor control handle
> + * @ti_sci: TI-SCI handle
> + * @ti_sci_id: TI-SCI device identifier
> + * @mbox: mailbox channel handle
> + * @client: mailbox client to request the mailbox channel
> + */
> +struct k3_dsp_rproc {
> + struct device *dev;
> + struct rproc *rproc;
> + struct k3_dsp_mem *mem;
> + int num_mems;
> + struct k3_dsp_mem *rmem;
> + int num_rmems;
> + struct reset_control *reset;
> + const struct k3_dsp_dev_data *data;
> + struct ti_sci_proc *tsp;
> + const struct ti_sci_handle *ti_sci;
> + u32 ti_sci_id;
> + struct mbox_chan *mbox;
> + struct mbox_client client;
> +};
> +
> +/**
> + * k3_dsp_rproc_mbox_callback() - inbound mailbox message handler
> + * @client: mailbox client pointer used for requesting the mailbox channel
> + * @data: mailbox payload
> + *
> + * This handler is invoked by the OMAP mailbox driver whenever a mailbox
> + * message is received. Usually, the mailbox payload simply contains
> + * the index of the virtqueue that is kicked by the remote processor,
> + * and we let remoteproc core handle it.
> + *
> + * In addition to virtqueue indices, we also have some out-of-band values
> + * that indicate different events. Those values are deliberately very
> + * large so they don't coincide with virtqueue indices.
> + */
> +static void k3_dsp_rproc_mbox_callback(struct mbox_client *client, void *data)
> +{
> + struct k3_dsp_rproc *kproc = container_of(client, struct k3_dsp_rproc,
> + client);
> + struct device *dev = kproc->rproc->dev.parent;
> + const char *name = kproc->rproc->name;
> + u32 msg = omap_mbox_message(data);
> +
> + dev_dbg(dev, "mbox msg: 0x%x\n", msg);
> +
> + switch (msg) {
> + case RP_MBOX_CRASH:
> + /*
> + * remoteproc detected an exception, but error recovery is not
> + * supported. So, just log this for now
> + */
> + dev_err(dev, "K3 DSP rproc %s crashed\n", name);
> + break;
> + case RP_MBOX_ECHO_REPLY:
> + dev_info(dev, "received echo reply from %s\n", name);
> + break;
> + default:
> + /* silently handle all other valid messages */
> + if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
> + return;
> + if (msg > kproc->rproc->max_notifyid) {
> + dev_dbg(dev, "dropping unknown message 0x%x", msg);
> + return;
> + }
> + /* msg contains the index of the triggered vring */
> + if (rproc_vq_interrupt(kproc->rproc, msg) == IRQ_NONE)
> + dev_dbg(dev, "no message was found in vqid %d\n", msg);
> + }
> +}
> +
> +/*
> + * Kick the remote processor to notify about pending unprocessed messages.
> + * The vqid usage is not used and is inconsequential, as the kick is performed
> + * through a simulated GPIO (a bit in an IPC interrupt-triggering register),
> + * the remote processor is expected to process both its Tx and Rx virtqueues.
> + */
> +static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = rproc->dev.parent;
> + mbox_msg_t msg = (mbox_msg_t)vqid;
> + int ret;
> +
> + /* send the index of the triggered virtqueue in the mailbox payload */
> + ret = mbox_send_message(kproc->mbox, (void *)msg);
> + if (ret < 0)
> + dev_err(dev, "failed to send mailbox message, status = %d\n",
> + ret);
> +}
> +
> +/* Put the DSP processor into reset */
> +static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = reset_control_assert(kproc->reset);
> + if (ret) {
> + dev_err(dev, "local-reset assert failed, ret = %d\n", ret);
> + return ret;
> + }
> +
> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
> + if (reset_control_deassert(kproc->reset))
> + dev_warn(dev, "local-reset deassert back failed\n");
> + }
> +
> + return ret;
> +}
> +
> +/* Release the DSP processor from reset */
> +static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "module-reset deassert failed, ret = %d\n", ret);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(kproc->reset);
> + if (ret) {
> + dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> + if (kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id))
> + dev_warn(dev, "module-reset assert back failed\n");
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * Power up the DSP remote processor.
> + *
> + * This function will be invoked only after the firmware for this rproc
> + * was loaded, parsed successfully, and all of its resource requirements
> + * were met.
> + */
> +static int k3_dsp_rproc_start(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct mbox_client *client = &kproc->client;
> + struct device *dev = kproc->dev;
> + u32 boot_addr;
> + int ret;
> +
> + client->dev = dev;
> + client->tx_done = NULL;
> + client->rx_callback = k3_dsp_rproc_mbox_callback;
> + client->tx_block = false;
> + client->knows_txdone = false;
> +
> + kproc->mbox = mbox_request_channel(client, 0);
> + if (IS_ERR(kproc->mbox)) {
> + ret = -EBUSY;
> + dev_err(dev, "mbox_request_channel failed: %ld\n",
> + PTR_ERR(kproc->mbox));
> + return ret;
> + }
> +
> + /*
> + * Ping the remote processor, this is only for sanity-sake for now;
> + * there is no functional effect whatsoever.
> + *
> + * Note that the reply will _not_ arrive immediately: this message
> + * will wait in the mailbox fifo until the remote processor is booted.
> + */
> + ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_ECHO_REQUEST);
> + if (ret < 0) {
> + dev_err(dev, "mbox_send_message failed: %d\n", ret);
> + goto put_mbox;
> + }
> +
> + boot_addr = rproc->bootaddr;
> + if (boot_addr & (kproc->data->boot_align_addr - 1)) {
> + dev_err(dev, "invalid boot address 0x%x, must be aligned on a 0x%x boundary\n",
> + boot_addr, kproc->data->boot_align_addr);
> + ret = -EINVAL;
> + goto put_mbox;
> + }
> +
> + dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr);
> + ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0);
> + if (ret)
> + goto put_mbox;
> +
> + ret = k3_dsp_rproc_release(kproc);
> + if (ret)
> + goto put_mbox;
> +
> + return 0;
> +
> +put_mbox:
> + mbox_free_channel(kproc->mbox);
> + return ret;
> +}
> +
> +/*
> + * Stop the DSP remote processor.
> + *
> + * This function puts the DSP processor into reset, and finishes processing
> + * of any pending messages.
> + */
> +static int k3_dsp_rproc_stop(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> +
> + mbox_free_channel(kproc->mbox);
> +
> + k3_dsp_rproc_reset(kproc);
> +
> + return 0;
> +}
> +
> +/*
> + * Custom function to translate a DSP device address (internal RAMs only) to a
> + * kernel virtual address. The DSPs can access their RAMs at either an internal
> + * address visible only from a DSP, or at the SoC-level bus address. Both these
> + * addresses need to be looked through for translation. The translated addresses
> + * can be used either by the remoteproc core for loading (when using kernel
> + * remoteproc loader), or by any rpmsg bus drivers.
> + */
> +static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + void __iomem *va = NULL;
> + phys_addr_t bus_addr;
> + u32 dev_addr, offset;
> + size_t size;
> + int i;
> +
> + if (len == 0)
> + return NULL;
> +
> + for (i = 0; i < kproc->num_mems; i++) {
> + bus_addr = kproc->mem[i].bus_addr;
> + dev_addr = kproc->mem[i].dev_addr;
> + size = kproc->mem[i].size;
> +
> + if (da < KEYSTONE_RPROC_LOCAL_ADDRESS_MASK) {
> + /* handle DSP-view addresses */
> + if (da >= dev_addr &&
> + ((da + len) <= (dev_addr + size))) {
> + offset = da - dev_addr;
> + va = kproc->mem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + } else {
> + /* handle SoC-view addresses */
> + if (da >= bus_addr &&
> + (da + len) <= (bus_addr + size)) {
> + offset = da - bus_addr;
> + va = kproc->mem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + }
> + }
> +
> + /* handle static DDR reserved memory regions */
> + for (i = 0; i < kproc->num_rmems; i++) {
> + dev_addr = kproc->rmem[i].dev_addr;
> + size = kproc->rmem[i].size;
> +
> + if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
> + offset = da - dev_addr;
> + va = kproc->rmem[i].cpu_addr + offset;
> + return (__force void *)va;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +static const struct rproc_ops k3_dsp_rproc_ops = {
> + .start = k3_dsp_rproc_start,
> + .stop = k3_dsp_rproc_stop,
> + .kick = k3_dsp_rproc_kick,
> + .da_to_va = k3_dsp_rproc_da_to_va,
> +};
> +
> +static int k3_dsp_rproc_of_get_memories(struct platform_device *pdev,
> + struct k3_dsp_rproc *kproc)
> +{
> + const struct k3_dsp_dev_data *data = kproc->data;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int num_mems = 0;
> + int i;
> +
> + num_mems = kproc->data->num_mems;
> + kproc->mem = devm_kcalloc(kproc->dev, num_mems,
> + sizeof(*kproc->mem), GFP_KERNEL);
> + if (!kproc->mem)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_mems; i++) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + data->mems[i].name);
> + if (!res) {
> + dev_err(dev, "found no memory resource for %s\n",
> + data->mems[i].name);
> + return -EINVAL;
> + }
> + if (!devm_request_mem_region(dev, res->start,
> + resource_size(res),
> + dev_name(dev))) {
> + dev_err(dev, "could not request %s region for resource\n",
> + data->mems[i].name);
> + return -EBUSY;
> + }
> +
> + kproc->mem[i].cpu_addr = devm_ioremap_wc(dev, res->start,
> + resource_size(res));
> + if (IS_ERR(kproc->mem[i].cpu_addr)) {
> + dev_err(dev, "failed to map %s memory\n",
> + data->mems[i].name);
> + return PTR_ERR(kproc->mem[i].cpu_addr);
> + }
> + kproc->mem[i].bus_addr = res->start;
> + kproc->mem[i].dev_addr = data->mems[i].dev_addr;
> + kproc->mem[i].size = resource_size(res);
> +
> + dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> + data->mems[i].name, &kproc->mem[i].bus_addr,
> + kproc->mem[i].size, kproc->mem[i].cpu_addr,
> + kproc->mem[i].dev_addr);
> + }
> + kproc->num_mems = num_mems;
> +
> + return 0;
> +}
> +
> +static int k3_dsp_reserved_mem_init(struct k3_dsp_rproc *kproc)
> +{
> + struct device *dev = kproc->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *rmem_np;
> + struct reserved_mem *rmem;
> + int num_rmems;
> + int ret, i;
> +
> + num_rmems = of_property_count_elems_of_size(np, "memory-region",
> + sizeof(phandle));
> + if (num_rmems <= 0) {
> + dev_err(dev, "device does not reserved memory regions, ret = %d\n",
> + num_rmems);
> + return -EINVAL;
> + }
> + if (num_rmems < 2) {
> + dev_err(dev, "device needs atleast two memory regions to be defined, num = %d\n",
> + num_rmems);
> + return -EINVAL;
> + }
> +
> + /* use reserved memory region 0 for vring DMA allocations */
> + ret = of_reserved_mem_device_init_by_idx(dev, np, 0);
> + if (ret) {
> + dev_err(dev, "device cannot initialize DMA pool, ret = %d\n",
> + ret);
> + return ret;
> + }
> +
> + num_rmems--;
> + kproc->rmem = kcalloc(num_rmems, sizeof(*kproc->rmem), GFP_KERNEL);
> + if (!kproc->rmem) {
> + ret = -ENOMEM;
> + goto release_rmem;
> + }
> +
> + /* use remaining reserved memory regions for static carveouts */
> + for (i = 0; i < num_rmems; i++) {
> + rmem_np = of_parse_phandle(np, "memory-region", i + 1);
> + if (!rmem_np) {
> + ret = -EINVAL;
> + goto unmap_rmem;
> + }
> +
> + rmem = of_reserved_mem_lookup(rmem_np);
> + if (!rmem) {
> + of_node_put(rmem_np);
> + ret = -EINVAL;
> + goto unmap_rmem;
> + }
> + of_node_put(rmem_np);
> +
> + kproc->rmem[i].bus_addr = rmem->base;
> + /* 64-bit address regions currently not supported */
> + kproc->rmem[i].dev_addr = (u32)rmem->base;
> + kproc->rmem[i].size = rmem->size;
> + kproc->rmem[i].cpu_addr = ioremap_wc(rmem->base, rmem->size);
> + if (!kproc->rmem[i].cpu_addr) {
> + dev_err(dev, "failed to map reserved memory#%d at %pa of size %pa\n",
> + i + 1, &rmem->base, &rmem->size);
> + ret = -ENOMEM;
> + goto unmap_rmem;
> + }
> +
> + dev_dbg(dev, "reserved memory%d: bus addr %pa size 0x%zx va %pK da 0x%x\n",
> + i + 1, &kproc->rmem[i].bus_addr,
> + kproc->rmem[i].size, kproc->rmem[i].cpu_addr,
> + kproc->rmem[i].dev_addr);
> + }
> + kproc->num_rmems = num_rmems;
> +
> + return 0;
> +
> +unmap_rmem:
> + for (i--; i >= 0; i--) {
> + if (kproc->rmem[i].cpu_addr)
> + iounmap(kproc->rmem[i].cpu_addr);
> + }
> + kfree(kproc->rmem);
> +release_rmem:
> + of_reserved_mem_device_release(kproc->dev);
> + return ret;
> +}
> +
> +static void k3_dsp_reserved_mem_exit(struct k3_dsp_rproc *kproc)
> +{
> + int i;
> +
> + for (i = 0; i < kproc->num_rmems; i++)
> + iounmap(kproc->rmem[i].cpu_addr);
> + kfree(kproc->rmem);
> +
> + of_reserved_mem_device_release(kproc->dev);
> +}
> +
> +static
> +struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
> + const struct ti_sci_handle *sci)
> +{
> + struct ti_sci_proc *tsp;
> + u32 temp[2];
> + int ret;
> +
> + ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
> + temp, 2);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + tsp = kzalloc(sizeof(*tsp), GFP_KERNEL);
> + if (!tsp)
> + return ERR_PTR(-ENOMEM);
> +
> + tsp->dev = dev;
> + tsp->sci = sci;
> + tsp->ops = &sci->ops.proc_ops;
> + tsp->proc_id = temp[0];
> + tsp->host_id = temp[1];
> +
> + return tsp;
> +}
> +
> +static int k3_dsp_rproc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + const struct k3_dsp_dev_data *data;
> + struct k3_dsp_rproc *kproc;
> + struct rproc *rproc;
> + const char *fw_name;
> + int ret = 0;
> + int ret1;
> +
> + data = of_device_get_match_data(dev);
> + if (!data)
> + return -ENODEV;
> +
> + ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> + if (ret) {
> + dev_err(dev, "failed to parse firmware-name property, ret = %d\n",
> + ret);
> + return ret;
> + }
> +
> + rproc = rproc_alloc(dev, dev_name(dev), &k3_dsp_rproc_ops, fw_name,
> + sizeof(*kproc));
> + if (!rproc)
> + return -ENOMEM;
> +
> + rproc->has_iommu = false;
> + rproc->recovery_disabled = true;
> + kproc = rproc->priv;
> + kproc->rproc = rproc;
> + kproc->dev = dev;
> + kproc->data = data;
> +
> + kproc->ti_sci = ti_sci_get_by_phandle(np, "ti,sci");
> + if (IS_ERR(kproc->ti_sci)) {
> + ret = PTR_ERR(kproc->ti_sci);
> + if (ret != -EPROBE_DEFER) {
> + dev_err(dev, "failed to get ti-sci handle, ret = %d\n",
> + ret);
> + }
> + kproc->ti_sci = NULL;
> + goto free_rproc;
> + }
> +
> + ret = of_property_read_u32(np, "ti,sci-dev-id", &kproc->ti_sci_id);
> + if (ret) {
> + dev_err(dev, "missing 'ti,sci-dev-id' property\n");
> + goto put_sci;
> + }
> +
> + kproc->reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(kproc->reset)) {
> + ret = PTR_ERR(kproc->reset);
> + dev_err(dev, "failed to get reset, status = %d\n", ret);
> + goto put_sci;
> + }
> +
> + kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
> + if (IS_ERR(kproc->tsp)) {
> + dev_err(dev, "failed to construct ti-sci proc control, ret = %d\n",
> + ret);
> + ret = PTR_ERR(kproc->tsp);
> + goto put_sci;
> + }
> +
> + ret = ti_sci_proc_request(kproc->tsp);
> + if (ret < 0) {
> + dev_err(dev, "ti_sci_proc_request failed, ret = %d\n", ret);
> + goto free_tsp;
> + }
> +
> + ret = k3_dsp_rproc_of_get_memories(pdev, kproc);
> + if (ret)
> + goto release_tsp;
> +
> + ret = k3_dsp_reserved_mem_init(kproc);
> + if (ret) {
> + dev_err(dev, "reserved memory init failed, ret = %d\n", ret);
> + goto release_tsp;
> + }
> +
> + ret = rproc_add(rproc);
> + if (ret) {
> + dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
> + ret);
> + goto release_mem;
> + }
> +
> + platform_set_drvdata(pdev, kproc);
> +
> + return 0;
> +
> +release_mem:
> + k3_dsp_reserved_mem_exit(kproc);
> +release_tsp:
> + ret1 = ti_sci_proc_release(kproc->tsp);
> + if (ret1)
> + dev_err(dev, "failed to release proc, ret = %d\n", ret1);
> +free_tsp:
> + kfree(kproc->tsp);
> +put_sci:
> + ret1 = ti_sci_put_handle(kproc->ti_sci);
> + if (ret1)
> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret1);
> +free_rproc:
> + rproc_free(rproc);
> + return ret;
> +}
> +
> +static int k3_dsp_rproc_remove(struct platform_device *pdev)
> +{
> + struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + rproc_del(kproc->rproc);
> +
> + ret = ti_sci_proc_release(kproc->tsp);
> + if (ret)
> + dev_err(dev, "failed to release proc, ret = %d\n", ret);
> +
> + kfree(kproc->tsp);
> +
> + ret = ti_sci_put_handle(kproc->ti_sci);
> + if (ret)
> + dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret);
> +
> + k3_dsp_reserved_mem_exit(kproc);
> + rproc_free(kproc->rproc);
> +
> + return 0;
> +}
> +
> +static const struct k3_dsp_mem_data c66_mems[] = {
> + { .name = "l2sram", .dev_addr = 0x800000 },
> + { .name = "l1pram", .dev_addr = 0xe00000 },
> + { .name = "l1dram", .dev_addr = 0xf00000 },
> +};
> +
> +static const struct k3_dsp_dev_data c66_data = {
> + .mems = c66_mems,
> + .num_mems = ARRAY_SIZE(c66_mems),
> + .boot_align_addr = SZ_1K,
> + .uses_lreset = true,
> +};
> +
> +static const struct of_device_id k3_dsp_of_match[] = {
> + { .compatible = "ti,j721e-c66-dsp", .data = &c66_data, },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, k3_dsp_of_match);
> +
> +static struct platform_driver k3_dsp_rproc_driver = {
> + .probe = k3_dsp_rproc_probe,
> + .remove = k3_dsp_rproc_remove,
> + .driver = {
> + .name = "k3-dsp-rproc",
> + .of_match_table = k3_dsp_of_match,
> + },
> +};
> +
> +module_platform_driver(k3_dsp_rproc_driver);
> +
> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("TI K3 DSP Remoteproc driver");
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-02 20:53 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200529174634.GA2630216@bogus>
On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > 7211 (STB version of RPi4).
> > - add new property 'brcm,scb-sizes'
> > - add new property 'resets'
> > - add new property 'reset-names'
> > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > the example to show this.
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > 1 file changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index 8680a0f86c5a..66a7df45983d 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -14,7 +14,13 @@ allOf:
> >
> > properties:
> > compatible:
> > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > + items:
> > + - enum:
>
> Don't need items here. Just change the const to enum.
>
> > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> >
> > reg:
> > maxItems: 1
> > @@ -34,10 +40,12 @@ properties:
> > - const: msi
> >
> > ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 4
> >
> > dma-ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 6
> >
> > clocks:
> > maxItems: 1
> > @@ -58,8 +66,30 @@ properties:
> >
> > aspm-no-l0s: true
> >
> > + resets:
> > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > + phandle pointing to the RESCAL reset controller provider node.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + reset-names:
> > + items:
> > + - const: rescal
>
> These are going to need to be an if/then schema if they only apply to
> certain compatible(s).
Why is that -- the code is general enough to handle its presence or
not (it is an optional compatibility)>
>
>
> > +
> > + brcm,scb-sizes:
> > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > + viewport size of a memory controller. There may be up to
> > + three controllers, and each size must be a power of two
> > + with a size greater or equal to the amount of memory the
> > + controller supports.
>
> This sounds like what dma-ranges should express?
There is some overlap but this contains information that is not in the
dma-ranges. Believe me I tried.
>
> If not, we do have 64-bit size if that what you need.
IIRC I tried the 64-bit size but the YAML validator did not like it;
it wanted numbers like <0x1122334455667788> while dtc wanted <
0x11223344 0x55667788>. I gave up trying and switched to u32.
Thanks,
Jim
>
>
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32-array
> > + - items:
> > + minItems: 2
> > + maxItems: 6
> > +
> > required:
> > - reg
> > + - ranges
> > - dma-ranges
> > - "#interrupt-cells"
> > - interrupts
> > @@ -93,7 +123,9 @@ examples:
> > msi-parent = <&pcie0>;
> > msi-controller;
> > ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> > - dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> > + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
> > + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
> > brcm,enable-ssc;
> > + brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
> > };
> > };
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
From: Sam Ravnborg @ 2020-06-02 20:56 UTC (permalink / raw)
To: Emil Velikov
Cc: Liu Ying, ML dri-devel, devicetree, Thierry Reding,
NXP Linux Team
In-Reply-To: <CACvgo50UOby-xV_OYmM55VUXUbwLxK-q6bs2FoS_FuwB9ChYJg@mail.gmail.com>
Hi Emil.
On Tue, Jun 02, 2020 at 01:46:19PM +0100, Emil Velikov wrote:
> On Tue, 2 Jun 2020 at 08:17, Liu Ying <victor.liu@nxp.com> wrote:
> >
> > This patch adds support for Kaohsiung Opto-Electronics Inc.
> > 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface.
> > The panel has dual LVDS channels.
> >
> > My panel is manufactured by US Micro Products(USMP). There is a tag at
> > the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
> > and it's made by KOE in Taiwan.
> >
> > The panel spec from USMP can be found at:
> > https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
> >
> > The below panel spec from KOE is basically the same to the one from USMP.
> > However, the panel type 'TX26D202VM0BAA' is a little bit different.
> > It looks that the two types of panel are compatible with each other.
> > http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
> >
> > Cc: Thierry Reding <thierry.reding@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index b6ecd15..7c222ec 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2200,6 +2200,37 @@ static const struct panel_desc koe_tx14d24vm1bpa = {
> > },
> > };
> >
> > +static const struct display_timing koe_tx26d202vm0bwa_timing = {
> > + .pixelclock = { 151820000, 156720000, 159780000 },
> > + .hactive = { 1920, 1920, 1920 },
> > + .hfront_porch = { 105, 130, 142 },
> > + .hback_porch = { 45, 70, 82 },
> > + .hsync_len = { 30, 30, 30 },
> > + .vactive = { 1200, 1200, 1200},
> > + .vfront_porch = { 3, 5, 10 },
> > + .vback_porch = { 2, 5, 10 },
> > + .vsync_len = { 5, 5, 5 },
> > +};
> > +
> > +static const struct panel_desc koe_tx26d202vm0bwa = {
> > + .timings = &koe_tx26d202vm0bwa_timing,
> > + .num_timings = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 217,
> > + .height = 136,
> > + },
> > + .delay = {
> > + .prepare = 1000,
> > + .enable = 1000,
> > + .unprepare = 1000,
> > + .disable = 1000,
> Ouch 1s for each delay is huge. Nevertheless it matches the specs so,
> the series is:
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>
> Sam, Thierry I assume you'll merge the series. Let me know if I should
> pick it up.
I am quite busy with non-linux stuff these days so fine if you can pick
them up. I like that simple panel patches are processed fast.
I expect to have some hours for linux work friday or saturday, but no
promises...
Sam
>
> -Emil
^ permalink raw reply
* Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
From: Serge Semin @ 2020-06-02 21:12 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, SoC Team, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200519120519.GE24801@soft-dev15.microsemi.net>
On Tue, May 19, 2020 at 02:05:19PM +0200, Lars Povlsen wrote:
> On 13/05/20 16:18, Mark Brown wrote:
> > Date: Wed, 13 May 2020 16:18:11 +0100
> > From: Mark Brown <broonie@kernel.org>
> > To: Lars Povlsen <lars.povlsen@microchip.com>
> > Cc: SoC Team <soc@kernel.org>, Microchip Linux Driver Support
> > <UNGLinuxDriver@microchip.com>, linux-spi@vger.kernel.org,
> > devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> > linux-arm-kernel@lists.infradead.org, Alexandre Belloni
> > <alexandre.belloni@bootlin.com>
> > Subject: Re: [PATCH 05/10] spi: spi-dw-mmio: Spin off MSCC platforms into
> > spi-dw-mchp
> > User-Agent: Mutt/1.10.1 (2018-07-13)
> >
> > On Wed, May 13, 2020 at 04:00:26PM +0200, Lars Povlsen wrote:
> >
> > > +config SPI_DW_MCHP
> > > + tristate "Memory-mapped io interface driver using DW SPI core of MSCC SoCs"
> > > + default y if ARCH_SPARX5
> > > + default y if SOC_VCOREIII
> >
> > Why the default ys?
>
> The SoC will typically boot from SPI... But its not a requirement per
> se. I will remove it.
>
> >
> > > +++ b/drivers/spi/Makefile
> > > @@ -37,6 +37,7 @@ obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
> > > obj-$(CONFIG_SPI_DLN2) += spi-dln2.o
> > > obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
> > > obj-$(CONFIG_SPI_DW_MMIO) += spi-dw-mmio.o
> > > +obj-$(CONFIG_SPI_DW_MCHP) += spi-dw-mchp.o
> > > obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o
> > > spi-dw-midpci-objs := spi-dw-pci.o spi-dw-mid.o
> > > obj-$(CONFIG_SPI_EFM32) += spi-efm32.o
> >
> > Please keep the file alphabetically sorted.
> >
>
> Noted.
>
> > > +++ b/drivers/spi/spi-dw-mchp.c
> > > @@ -0,0 +1,232 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Memory-mapped interface driver for MSCC SoCs
> > > + *
> >
> > Please make the entire comment a C++ one so things look more
> > intentional.
>
> Sure, I can do that. The presented form matches that of the other
> spi-dw-* drivers, but I can see other using // blocks. Ack.
>
> >
> > > +#define MAX_CS 4
> >
> > This should be namespaced.
>
> Ack.
>
> >
> > > + rx_sample_dly = 0;
> > > + device_property_read_u32(&pdev->dev, "spi-rx-delay-us", &rx_sample_dly);
> > > + dws->rx_sample_dly = DIV_ROUND_UP(rx_sample_dly,
> > > + (dws->max_freq / 1000000));
Perhaps 100000 is better to be replace with macro USEC_PER_SEC...
Moreover are you sure the formulae is correct?
dws->rx_sample_dly - a number of ssi_clk periods/cycles to delay the Rx-data sample,
dws->max_freq - ssi_clk frequency (not period).
In real math the formulae would look like:
S = d * P [s], where d - number of delay cycles, P - ssi_clk period in seconds,
S - requested delay in seconds.
In the driver notation: d = dws->rx_sample_dly, P = 1 / dws->max_freq,
S = rx_sample_dly ("spi-rx-delay-us" property value).
dws->rx_sample_dly * (1 / dws->max_freq) = rx_sample_dly <=>
dws->rx_sample_dly = rx_sample_dly * dws->max_freq.
Though that's represented in seconds, so if rx_sample_dly is specified in usec,
then you'd need to scale it down dividing by USEC_PER_SEC.
For example, imagine we need a delay of 1 usec with ssi_clk of 50MHz.
By your formulae we'd have: 1 / (50000000 / 1000000) = 0 cycles (actually 1 due
to DIV_ROUND_UP, but incorrect anyway),
By mine: 1 * (500000000 / 1000000) = 50 cycles. Seems closer to reality.
Am I missing something?
> >
> > If this is a standard feature of the DesignWare IP why parse it here and
> > not in the generic code?
>
> This is a standard feature of the DesignWare IP, so good suggestion. I
> will arrange with Serge.
Regarding "spi-rx-delay-us" and the sampling delay the IP supports. Here is what
documentation says regarding the register, which is then initialized with this
parameter "This register controls the number of ssi_clk cycles that are
delayed from the default sample time before the actual sample of the rxd input
signal occurs." While the "spi-rx-delay-us" property is described as: "Delay, in
microseconds, after a read transfer." I may misunderstand something, but IMO
these descriptions don't refer to the same values. The only real use of the
"spi-rx-delay-us" property I've found in "./drivers/input/rmi4/rmi_spi.c".
That driver gets the value of the property and just sets the delay_usecs
of some transfers, which isn't even close to the functionality the RX_SAMPLE_DLY
register provides.
To be clear the RX_SAMPLE_DLY register can be used to delay the RX-bits sample
with respect to the normal Rx sampling timing. The delay is measured in the
numbers of the ssi_clk periods. (Note also that the maximum delay is limited
with a constant parameter pre-initialized at the IP-core synthesis stage. It can
be defined within a range [4, 255]. In our IP it's limited with just 4 periods.)
As I see it, a better way would be to either define a new vendor-specific
property like "snps,rx-sample-delay-ns" (note NS here, since normally the
ssi_clk is much higher than 1MHz), or define a new generic SPI property.
Mark, Andy?
-Sergey
>
> Thank you for your comments!
>
> ---Lars
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Rob Herring @ 2020-06-02 21:41 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CA+-6iNwWBFYHVKiwwJ95DYQ5zmc5uBo1cgZzd6rpD++aQWgGpw@mail.gmail.com>
On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > From: Jim Quinlan <jquinlan@broadcom.com>
> > >
> > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > 7211 (STB version of RPi4).
> > > - add new property 'brcm,scb-sizes'
> > > - add new property 'resets'
> > > - add new property 'reset-names'
> > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > the example to show this.
> > >
> > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > ---
> > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > index 8680a0f86c5a..66a7df45983d 100644
> > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > @@ -14,7 +14,13 @@ allOf:
> > >
> > > properties:
> > > compatible:
> > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + items:
> > > + - enum:
> >
> > Don't need items here. Just change the const to enum.
> >
> > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > >
> > > reg:
> > > maxItems: 1
> > > @@ -34,10 +40,12 @@ properties:
> > > - const: msi
> > >
> > > ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 4
> > >
> > > dma-ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 6
> > >
> > > clocks:
> > > maxItems: 1
> > > @@ -58,8 +66,30 @@ properties:
> > >
> > > aspm-no-l0s: true
> > >
> > > + resets:
> > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > + phandle pointing to the RESCAL reset controller provider node.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: rescal
> >
> > These are going to need to be an if/then schema if they only apply to
> > certain compatible(s).
>
> Why is that -- the code is general enough to handle its presence or
> not (it is an optional compatibility)>
Because an if/then schema expresses in a parse-able form what your
'description' does in free form text.
Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
we should check that. The schema shouldn't be just what some driver
happens to currently allow. Also, it's not a driver's job to validate
DT, so it shouldn't check any of this.
> > > + brcm,scb-sizes:
> > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > + viewport size of a memory controller. There may be up to
> > > + three controllers, and each size must be a power of two
> > > + with a size greater or equal to the amount of memory the
> > > + controller supports.
> >
> > This sounds like what dma-ranges should express?
>
> There is some overlap but this contains information that is not in the
> dma-ranges. Believe me I tried.
I don't understand. If you had 3 dma-ranges entries, you'd have 3
sizes. Can you expand or show me what you tried?
> > If not, we do have 64-bit size if that what you need.
>
> IIRC I tried the 64-bit size but the YAML validator did not like it;
> it wanted numbers like <0x1122334455667788> while dtc wanted <
> 0x11223344 0x55667788>. I gave up trying and switched to u32.
You used the /bits/ annotation for dtc?:
/bits/ 64 <0x1122334455667788>
I also made a recent fix to dt-schema around handling of 64-bit sizes,
so update if you have problems still.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/4] remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
From: Mathieu Poirier @ 2020-06-02 21:42 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Rob Herring, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200521001006.2725-5-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:06PM -0500, Suman Anna wrote:
> The resets for the DSP processors on K3 SoCs are managed through the
> Power and Sleep Controller (PSC) module. Each DSP typically has two
> resets - a global module reset for powering on the device, and a local
> reset that affects only the CPU while allowing access to the other
> sub-modules within the DSP processor sub-systems.
>
> The C66x DSPs have two levels of internal RAMs that can be used to
> boot from, and the firmware loading into these RAMs require the
> local reset to be asserted with the device powered on/enabled using
> the module reset. Enhance the K3 DSP remoteproc driver to add support
> for loading into the internal RAMs. The local reset is deasserted on
> SoC power-on-reset, so logic has to be added in probe in remoteproc
> mode to balance the remoteproc state-machine.
>
> Note that the local resets are a no-op on C71x cores, and the hardware
> does not supporting loading into its internal RAMs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Dropped the local-reset no-op checks from k3_dsp_rproc_prepare/unprepare()
> callbacks. The logic will be adjusted back in the C71 patch series.
> - The C71 local reset references are also removed from the comments for the
> k3_dsp_rproc_prepare() function.
> v1: https://patchwork.kernel.org/patch/11458579/
>
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 72 +++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> index e4036f5992fe..610fbbf85ee6 100644
> --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
> @@ -174,6 +174,9 @@ static int k3_dsp_rproc_reset(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> + if (kproc->data->uses_lreset)
> + return ret;
> +
> ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> kproc->ti_sci_id);
> if (ret) {
> @@ -191,6 +194,9 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> struct device *dev = kproc->dev;
> int ret;
>
> + if (kproc->data->uses_lreset)
> + goto lreset;
> +
> ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> kproc->ti_sci_id);
> if (ret) {
> @@ -198,6 +204,7 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> +lreset:
> ret = reset_control_deassert(kproc->reset);
> if (ret) {
> dev_err(dev, "local-reset deassert failed, ret = %d\n", ret);
> @@ -209,6 +216,53 @@ static int k3_dsp_rproc_release(struct k3_dsp_rproc *kproc)
> return ret;
> }
>
> +/*
> + * The C66x DSP cores have a local reset that affects only the CPU, and a
> + * generic module reset that powers on the device and allows the DSP internal
> + * memories to be accessed while the local reset is asserted. This function is
> + * used to release the global reset on C66x DSPs to allow loading into the DSP
> + * internal RAMs. The .prepare() ops is invoked by remoteproc core before any
> + * firmware loading, and is followed by the .start() ops after loading to
> + * actually let the C66x DSP cores run.
> + */
> +static int k3_dsp_rproc_prepare(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.get_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret)
> + dev_err(dev, "module-reset deassert failed, cannot enable internal RAM loading, ret = %d\n",
> + ret);
> +
> + return ret;
> +}
> +
> +/*
> + * This function implements the .unprepare() ops and performs the complimentary
> + * operations to that of the .prepare() ops. The function is used to assert the
> + * global reset on applicable C66x cores. This completes the second portion of
> + * powering down the C66x DSP cores. The cores themselves are only halted in the
> + * .stop() callback through the local reset, and the .unprepare() ops is invoked
> + * by the remoteproc core after the remoteproc is stopped to balance the global
> + * reset.
> + */
> +static int k3_dsp_rproc_unprepare(struct rproc *rproc)
> +{
> + struct k3_dsp_rproc *kproc = rproc->priv;
> + struct device *dev = kproc->dev;
> + int ret;
> +
> + ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> + kproc->ti_sci_id);
> + if (ret)
> + dev_err(dev, "module-reset assert failed, ret = %d\n", ret);
> +
> + return ret;
> +}
> +
> /*
> * Power up the DSP remote processor.
> *
> @@ -352,6 +406,8 @@ static void *k3_dsp_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
> }
>
> static const struct rproc_ops k3_dsp_rproc_ops = {
> + .prepare = k3_dsp_rproc_prepare,
> + .unprepare = k3_dsp_rproc_unprepare,
> .start = k3_dsp_rproc_start,
> .stop = k3_dsp_rproc_stop,
> .kick = k3_dsp_rproc_kick,
> @@ -614,6 +670,22 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
> goto release_tsp;
> }
>
> + /*
> + * ensure the DSP local reset is asserted to ensure the DSP doesn't
> + * execute bogus code in .prepare() when the module reset is released.
> + */
> + if (data->uses_lreset) {
> + ret = reset_control_status(kproc->reset);
> + if (ret < 0) {
> + dev_err(dev, "failed to get reset status, status = %d\n",
> + ret);
> + goto release_mem;
> + } else if (ret == 0) {
> + dev_warn(dev, "local reset is deasserted for device\n");
> + k3_dsp_rproc_reset(kproc);
> + }
> + }
> +
> ret = rproc_add(rproc);
> if (ret) {
> dev_err(dev, "failed to add register device with remoteproc core, status = %d\n",
> --
> 2.26.0
>
^ permalink raw reply
* Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Rob Herring @ 2020-06-02 21:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Dan Murphy, Jacek Anaszewski, devicetree, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <20200602200436.GA6535@amd>
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.
Rob
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: NSP: Add support for Cisco Meraki NSP devices
From: Florian Fainelli @ 2020-06-02 21:55 UTC (permalink / raw)
To: Matthew Hagan
Cc: Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
devicetree, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Hi Matthew,
On 6/2/2020 9:11 AM, Matthew Hagan wrote:
> This patch set adds support for the Meraki MX64(W) and MX65(W) security
> devices. There are four devices in total, all using the same basic hardware.
>
> The MX64 series has five ethernet ports connected to the BCM SRAB. The MX65
> series has two ports conected to the SRAB, and two QCA8337 switches connected
> by SGMII to SRAB ports 4 and 5, each providing five additional ports.
>
> The W variants of these devices have two BCM43520s on the PCIe bus. On the
> non-wireless variants PCIe is inactive, hence separate dts files.
>
> 1/3 contains common bindings for both Meraki devices.
> 2/3 contains MX64 specific bindings.
> 3/3 contains MX65 specific bindings.
Glad to see those patches being submitted upstream to support those
devices, don't we need a change to arch/arm/boot/dts/Makefile to add
those DTS files to be built when ARCH_BCM_NSP is enabled?
>
> Note that Chris Packham's "[PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe
> deferrals" is also necessary.
Humm, I am not sure this patch is really the way to go, but I have to
look at it again.
>
> Thanks,
> Matthew
>
> Matthew Hagan (3):
> ARM: dts: NSP: Add common bindings for Meraki MX64/65
> ARM: dts: NSP: Add support for Cisco Meraki MX64(W)
> ARM: dts: NSP: Add support for Cisco Meraki MX65(W)
>
> arch/arm/boot/dts/bcm958625-mx64.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx64w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx64x.dtsi | 136 ++++++++
> arch/arm/boot/dts/bcm958625-mx65.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx65w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx65x.dtsi | 321 +++++++++++++++++++
> arch/arm/boot/dts/bcm958625-mx6x-common.dtsi | 172 ++++++++++
> 7 files changed, 705 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
>
--
Florian
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-02 21:55 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CAL_JsqKtASTzACSNn8BgmEBqf0eyR8RB_tjY7aUnvK+2GYXTbg@mail.gmail.com>
On Tue, Jun 2, 2020 at 5:41 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> >
> > On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > > From: Jim Quinlan <jquinlan@broadcom.com>
> > > >
> > > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > > 7211 (STB version of RPi4).
> > > > - add new property 'brcm,scb-sizes'
> > > > - add new property 'resets'
> > > > - add new property 'reset-names'
> > > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > > the example to show this.
> > > >
> > > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > > ---
> > > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > index 8680a0f86c5a..66a7df45983d 100644
> > > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > @@ -14,7 +14,13 @@ allOf:
> > > >
> > > > properties:
> > > > compatible:
> > > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + items:
> > > > + - enum:
> > >
> > > Don't need items here. Just change the const to enum.
> > >
> > > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -34,10 +40,12 @@ properties:
> > > > - const: msi
> > > >
> > > > ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 4
> > > >
> > > > dma-ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 6
> > > >
> > > > clocks:
> > > > maxItems: 1
> > > > @@ -58,8 +66,30 @@ properties:
> > > >
> > > > aspm-no-l0s: true
> > > >
> > > > + resets:
> > > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > > + phandle pointing to the RESCAL reset controller provider node.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: rescal
> > >
> > > These are going to need to be an if/then schema if they only apply to
> > > certain compatible(s).
> >
> > Why is that -- the code is general enough to handle its presence or
> > not (it is an optional compatibility)>
>
> Because an if/then schema expresses in a parse-able form what your
> 'description' does in free form text.
>
> Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
> we should check that. The schema shouldn't be just what some driver
> happens to currently allow. Also, it's not a driver's job to validate
> DT, so it shouldn't check any of this.
Got it, will fix.
>
> > > > + brcm,scb-sizes:
> > > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > > + viewport size of a memory controller. There may be up to
> > > > + three controllers, and each size must be a power of two
> > > > + with a size greater or equal to the amount of memory the
> > > > + controller supports.
> > >
> > > This sounds like what dma-ranges should express?
> >
> > There is some overlap but this contains information that is not in the
> > dma-ranges. Believe me I tried.
>
> I don't understand. If you had 3 dma-ranges entries, you'd have 3
> sizes. Can you expand or show me what you tried?
Here is a simple example: suppose you have two dma-ranges. This could
be from one of two cases:
- Both dma-ranges are from the same memory controller (the second
range is the "extended" region).
- One dma-range can be from memc0 and the other can be from memc1; the
extensions are not used.
The driver has to determine (a) how many memory controllers there are
and (b) what the size should be for each of them. It is impossible to
do this with the case above.
>
> > > If not, we do have 64-bit size if that what you need.
> >
> > IIRC I tried the 64-bit size but the YAML validator did not like it;
> > it wanted numbers like <0x1122334455667788> while dtc wanted <
> > 0x11223344 0x55667788>. I gave up trying and switched to u32.
>
> You used the /bits/ annotation for dtc?:
>
> /bits/ 64 <0x1122334455667788>
>
> I also made a recent fix to dt-schema around handling of 64-bit sizes,
> so update if you have problems still.
I didn't try the /bits/ so I'll pursue this.
Thanks,
Jim
>
> Rob
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Florian Fainelli @ 2020-06-02 22:33 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <20200602164522.3276-5-dmurphy@ti.com>
On 6/2/2020 9:45 AM, Dan Murphy wrote:
> Add RGMII internal delay configuration for Rx and Tx.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
[snip]
> +
> enum {
> DP83869_PORT_MIRRORING_KEEP,
> DP83869_PORT_MIRRORING_EN,
> @@ -108,6 +113,8 @@ enum {
> struct dp83869_private {
> int tx_fifo_depth;
> int rx_fifo_depth;
> + s32 rx_id_delay;
> + s32 tx_id_delay;
> int io_impedance;
> int port_mirroring;
> bool rxctrl_strap_quirk;
> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
> &dp83869->tx_fifo_depth))
> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>
> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
> + &dp83869->rx_id_delay);
> + if (ret) {
> + dp83869->rx_id_delay =
> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
> + ret = 0;
> + }
> +
> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
> + &dp83869->tx_id_delay);
> + if (ret) {
> + dp83869->tx_id_delay =
> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
> + ret = 0;
> + }
It is still not clear to me why is not the parsing being done by the PHY
library helper directly?
--
Florian
^ permalink raw reply
* Re: [PATCH 06/10] dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
From: Serge Semin @ 2020-06-02 23:07 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, Rob Herring, devicetree,
Alexandre Belloni, linux-kernel, linux-spi,
Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-7-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:27PM +0200, Lars Povlsen wrote:
> This add DT bindings for the Sparx5 SPI driver.
This whole file can be easily merged in to the generic DW APB SSI DT
binding file. Just use "if: properties: compatible: const: ..." construction
to distinguish ocelot, jaguar, sparx5 and non-sparx5 nodes.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../bindings/spi/mscc,ocelot-spi.yaml | 49 +++++++++++++++----
> 1 file changed, 39 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> index a3ac0fa576553..8beecde4b0880 100644
> --- a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> +++ b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> @@ -23,15 +23,23 @@ properties:
> enum:
> - mscc,ocelot-spi
> - mscc,jaguar2-spi
> + - microchip,sparx5-spi
>
> interrupts:
> maxItems: 1
>
> reg:
> minItems: 2
> - items:
> - - description: Designware SPI registers
> - - description: CS override registers
> + maxItems: 3
> + oneOf:
> + - items:
> + - description: Designware SPI registers
> + - description: CS override registers (Not sparx5).
> + - items:
> + - description: Designware SPI registers
> + - description: CS override registers (Not sparx5).
> + - description: Direct mapped SPI read area. If provided, the
> + driver will register spi_mem_op's to take advantage of it.
>
> clocks:
> maxItems: 1
> @@ -43,6 +51,23 @@ properties:
> enum: [ 2, 4 ]
> maxItems: 1
>
> + spi-rx-delay-us:
> + description: |
> + The delay (in usec) of the RX signal sample position. This can
> + be used to tne the RX timing in order to acheive higher
> + speeds. This is used for all devices on the bus.
> + default: 0
> + maxItems: 1
spi-rx-delay-us is defined for a particular SPI-slave. Please see the
DT binding file: Documentation/devicetree/bindings/spi/spi-controller.yaml .
Although as I suggested before this delay isn't what the Dw APB SSI RX sample
delay functionality does. Probably a vendor-specific property would be better
here. But I'd also define it on a SPI-slave basis, not for all devices on the
bus.
> +
> + interface-mapping-mask:
> + description: |
> + On the Sparx5 variant, two different busses are connected to the
> + controller. This property is a mask per chip-select, indicating
> + whether the CS should go to one or the other interface.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + maxItems: 1
As Mark rightfully suggested this seems like an SPI-slave related property, then
most likely it should be defined on the SPI-slave basis (probably as a bool
property). Additionally it's vendor-specific, so the property name should be
accordingly prefixed.
> +
> required:
> - compatible
> - reg
> @@ -50,11 +75,15 @@ required:
>
> examples:
> - |
> - spi0: spi@101000 {
> - compatible = "mscc,ocelot-spi";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x101000 0x100>, <0x3c 0x18>;
> - interrupts = <9>;
> - clocks = <&ahb_clk>;
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + spi0: spi@600104000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "microchip,sparx5-spi";
> + reg = <0x00104000 0x40>, <0 0>, <0x3000000 0x4000000>;
I have a doubt that defining an empty reg region is a good idea, since you can
detect the reg requirements by the node compatible string.
-Sergey
> + num-cs = <16>;
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + clocks = <&ahb_clk>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> };
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:10 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <c3c68dcd-ccf1-25fd-fc4c-4c30608a1cc8@gmail.com>
Florian
On 6/2/20 5:33 PM, Florian Fainelli wrote:
>
> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>> Add RGMII internal delay configuration for Rx and Tx.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
> [snip]
>
>> +
>> enum {
>> DP83869_PORT_MIRRORING_KEEP,
>> DP83869_PORT_MIRRORING_EN,
>> @@ -108,6 +113,8 @@ enum {
>> struct dp83869_private {
>> int tx_fifo_depth;
>> int rx_fifo_depth;
>> + s32 rx_id_delay;
>> + s32 tx_id_delay;
>> int io_impedance;
>> int port_mirroring;
>> bool rxctrl_strap_quirk;
>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
>> &dp83869->tx_fifo_depth))
>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>
>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>> + &dp83869->rx_id_delay);
>> + if (ret) {
>> + dp83869->rx_id_delay =
>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>> + ret = 0;
>> + }
>> +
>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>> + &dp83869->tx_id_delay);
>> + if (ret) {
>> + dp83869->tx_id_delay =
>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>> + ret = 0;
>> + }
> It is still not clear to me why is not the parsing being done by the PHY
> library helper directly?
Why would we do that for these properties and not any other?
Unless there is a new precedence being set here by having the PHY
framework do all the dt node parsing for common properties.
Dan
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Florian Fainelli @ 2020-06-02 23:13 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <61888788-041f-7b93-9d99-7dad4c148021@ti.com>
On 6/2/2020 4:10 PM, Dan Murphy wrote:
> Florian
>
> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>
>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>> Add RGMII internal delay configuration for Rx and Tx.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>> [snip]
>>
>>> +
>>> enum {
>>> DP83869_PORT_MIRRORING_KEEP,
>>> DP83869_PORT_MIRRORING_EN,
>>> @@ -108,6 +113,8 @@ enum {
>>> struct dp83869_private {
>>> int tx_fifo_depth;
>>> int rx_fifo_depth;
>>> + s32 rx_id_delay;
>>> + s32 tx_id_delay;
>>> int io_impedance;
>>> int port_mirroring;
>>> bool rxctrl_strap_quirk;
>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>> *phydev)
>>> &dp83869->tx_fifo_depth))
>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>> + &dp83869->rx_id_delay);
>>> + if (ret) {
>>> + dp83869->rx_id_delay =
>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>> + ret = 0;
>>> + }
>>> +
>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>> + &dp83869->tx_id_delay);
>>> + if (ret) {
>>> + dp83869->tx_id_delay =
>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>> + ret = 0;
>>> + }
>> It is still not clear to me why is not the parsing being done by the PHY
>> library helper directly?
>
> Why would we do that for these properties and not any other?
Those properties have a standard name, which makes them suitable for
parsing by the core PHY library.
>
> Unless there is a new precedence being set here by having the PHY
> framework do all the dt node parsing for common properties.
You could parse the vendor properties through the driver, let the PHY
library parse the standard properties, and resolve any ordering
precedence within the driver. In general, I would favor standard
properties over vendor properties.
Does this help?
--
Florian
^ permalink raw reply
* Re: [PATCH 07/10] spi: spi-dw-mchp: Add Sparx5 support
From: Serge Semin @ 2020-06-02 23:22 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200513140031.25633-8-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:28PM +0200, Lars Povlsen wrote:
> This adds support for the Sparx5 SoC in the spi-dw-mchp SPI controller.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> drivers/spi/spi-dw-mchp.c | 211 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 189 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/spi/spi-dw-mchp.c b/drivers/spi/spi-dw-mchp.c
> index 0828a7616d9ab..3abdd44a550ea 100644
> --- a/drivers/spi/spi-dw-mchp.c
> +++ b/drivers/spi/spi-dw-mchp.c
> @@ -28,21 +28,22 @@
>
> #define MAX_CS 4
>
> -#define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL 0x24
> -#define OCELOT_IF_SI_OWNER_OFFSET 4
> -#define JAGUAR2_IF_SI_OWNER_OFFSET 6
> #define MSCC_IF_SI_OWNER_MASK GENMASK(1, 0)
> #define MSCC_IF_SI_OWNER_SISL 0
> #define MSCC_IF_SI_OWNER_SIBM 1
> #define MSCC_IF_SI_OWNER_SIMC 2
>
> #define MSCC_SPI_MST_SW_MODE 0x14
> -#define MSCC_SPI_MST_SW_MODE_SW_PIN_CTRL_MODE BIT(13)
> -#define MSCC_SPI_MST_SW_MODE_SW_SPI_CS(x) (x << 5)
>
> struct dw_spi_mchp_props {
> const char *syscon_name;
> - u32 si_owner_bit;
> + u32 general_ctrl_off;
> + u32 si_owner_bit, si_owner2_bit;
> + u32 pinctrl_bit_off;
> + u32 cs_bit_off;
> + u32 ss_force_ena_off;
> + u32 ss_force_val_off;
> + u32 bootmaster_cs;
> };
>
> struct dw_spi_mchp {
> @@ -53,44 +54,176 @@ struct dw_spi_mchp {
> void __iomem *spi_mst;
> const struct dw_spi_mchp_props *props;
> u32 gen_owner;
> + u32 if2mask;
> };
>
> static const struct dw_spi_mchp_props dw_spi_mchp_props_ocelot = {
> .syscon_name = "mscc,ocelot-cpu-syscon",
> + .general_ctrl_off = 0x24,
> .si_owner_bit = 4,
> + .pinctrl_bit_off = 13,
> + .cs_bit_off = 5,
> + .bootmaster_cs = 0,
> };
>
> static const struct dw_spi_mchp_props dw_spi_mchp_props_jaguar2 = {
> .syscon_name = "mscc,ocelot-cpu-syscon",
> + .general_ctrl_off = 0x24,
> .si_owner_bit = 6,
> + .pinctrl_bit_off = 13,
> + .cs_bit_off = 5,
> + .bootmaster_cs = 0,
> +};
> +
> +static const struct dw_spi_mchp_props dw_spi_mchp_props_sparx5 = {
> + .syscon_name = "microchip,sparx5-cpu-syscon",
> + .general_ctrl_off = 0x88,
> + .si_owner_bit = 6,
> + .si_owner2_bit = 4,
> + .ss_force_ena_off = 0xa4,
> + .ss_force_val_off = 0xa8,
> + .bootmaster_cs = 0,
> };
>
> /*
> - * The Designware SPI controller (referred to as master in the documentation)
> - * automatically deasserts chip select when the tx fifo is empty. The chip
> - * selects then needs to be either driven as GPIOs or, for the first 4 using the
> - * the SPI boot controller registers. the final chip select is an OR gate
> - * between the Designware SPI controller and the SPI boot controller.
> + * Set the owner of the SPI interface
> */
> -static void dw_spi_mchp_set_cs(struct spi_device *spi, bool enable)
> +static void dw_spi_mchp_set_owner(struct dw_spi_mchp *dwsmchp,
> + const struct dw_spi_mchp_props *props,
> + u8 owner, u8 owner2)
> +{
> + u32 val, msk;
> +
> + val = (owner << props->si_owner_bit);
> + msk = (MSCC_IF_SI_OWNER_MASK << props->si_owner_bit);
> + if (props->si_owner2_bit) {
> + val |= owner2 << props->si_owner2_bit;
> + msk |= (MSCC_IF_SI_OWNER_MASK << props->si_owner2_bit);
> + }
> + if (dwsmchp->gen_owner != val) {
> + regmap_update_bits(dwsmchp->syscon, props->general_ctrl_off,
> + msk, val);
> + dwsmchp->gen_owner = val;
> + }
> +}
> +
> +static void dw_spi_mchp_set_cs_owner(struct dw_spi_mchp *dwsmchp,
> + const struct dw_spi_mchp_props *props,
> + u8 cs, u8 owner)
> {
> + u8 dummy = (owner == MSCC_IF_SI_OWNER_SIBM ?
> + MSCC_IF_SI_OWNER_SIMC : MSCC_IF_SI_OWNER_SIBM);
> + if (props->si_owner2_bit && (dwsmchp->if2mask & BIT(cs))) {
> + /* SPI2 */
> + dw_spi_mchp_set_owner(dwsmchp, props, dummy, owner);
> + } else {
> + /* SPI1 */
> + dw_spi_mchp_set_owner(dwsmchp, props, owner, dummy);
> + }
> +}
> +
> +/*
> + * The Designware SPI controller (referred to as master in the
> + * documentation) automatically deasserts chip select when the tx fifo
> + * is empty. The chip selects then needs to be either driven as GPIOs
> + * or, for the first 4 using the the SPI boot controller
> + * registers. the final chip select is an OR gate between the
> + * Designware SPI controller and the SPI boot controller. nselect is
> + * an active low signal
> + */
> +static void dw_spi_mchp_set_cs(struct spi_device *spi, bool nEnable)
> +{
> + bool enable = !nEnable; /* This keeps changing in the API... */
> struct dw_spi *dws = spi_master_get_devdata(spi->master);
> struct dw_spi_mchp *dwsmchp = container_of(dws, struct dw_spi_mchp,
> dws);
> - u32 cs = spi->chip_select;
> + const struct dw_spi_mchp_props *props = dwsmchp->props;
> + u8 cs = spi->chip_select;
>
> - if (cs < 4) {
> - u32 sw_mode = MSCC_SPI_MST_SW_MODE_SW_PIN_CTRL_MODE;
> + if (enable)
> + dw_spi_mchp_set_cs_owner(dwsmchp, props, cs,
> + MSCC_IF_SI_OWNER_SIMC);
>
> - if (!enable)
> - sw_mode |= MSCC_SPI_MST_SW_MODE_SW_SPI_CS(BIT(cs));
> + if (dwsmchp->spi_mst && (cs < MAX_CS)) {
> + u32 sw_mode;
>
> + if (enable)
> + sw_mode = BIT(props->pinctrl_bit_off) |
> + (BIT(cs) << props->cs_bit_off);
> + else
> + sw_mode = 0;
> writel(sw_mode, dwsmchp->spi_mst + MSCC_SPI_MST_SW_MODE);
> + } else if (props->ss_force_ena_off) {
> + if (enable) {
> + /* Ensure CS toggles, so start off all disabled */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~0);
> + /* CS override drive enable */
> + regmap_write(dwsmchp->syscon, props->ss_force_ena_off,
> + 1);
> + /* Allow settle */
> + udelay(1);
> + /* Now set CSx enabled */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~BIT(cs));
> + } else {
> + /* CS value */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~0);
> + /* CS override drive disable */
> + regmap_write(dwsmchp->syscon, props->ss_force_ena_off,
> + 0);
> + }
> }
>
> - dw_spi_set_cs(spi, enable);
> + dw_spi_set_cs(spi, nEnable);
> +}
> +
> +static int dw_mchp_bootmaster_exec_mem_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct spi_device *spi = mem->spi;
> + int ret = -ENOTSUPP;
> +
> + /* Only reads, addrsize 1..4 */
> + if (!op->data.nbytes || !op->addr.nbytes || op->addr.nbytes > 4 ||
> + op->data.dir != SPI_MEM_DATA_IN)
> + return ret;
> +
> + /* Only handle (normal+fast) 3/4 bytes read */
> + if (op->cmd.opcode != SPINOR_OP_READ &&
> + op->cmd.opcode != SPINOR_OP_READ_FAST &&
> + op->cmd.opcode != SPINOR_OP_READ_4B &&
> + op->cmd.opcode != SPINOR_OP_READ_FAST_4B)
> + return ret;
Hm, this part most like belongs to supports_op() callback.
> +
> + /* CS0..3, only 16M reach */
> + if ((spi->chip_select < MAX_CS) &&
> + (op->addr.val + op->data.nbytes) < SZ_16M) {
The driver shouldn't return a failure if more than available data requested.
Just return the length the driver managed to read.
> + struct dw_spi *dws = spi_master_get_devdata(spi->master);
> + struct dw_spi_mchp *dwsmchp = container_of(dws,
> + struct dw_spi_mchp,
> + dws);
> + const struct dw_spi_mchp_props *props = dwsmchp->props;
> + u8 __iomem *src = dwsmchp->read_map +
> + (spi->chip_select * SZ_16M) + op->addr.val;
> +
> + if (props->bootmaster_cs != spi->chip_select)
> + return ret;
> +
> + /* Make boot master owner of SI interface */
> + dw_spi_mchp_set_cs_owner(dwsmchp, props, spi->chip_select,
> + MSCC_IF_SI_OWNER_SIBM);
> + memcpy(op->data.buf.in, src, op->data.nbytes);
So after all it's just memcpy from the directly mapped SPI-flash memory, right?
Then it's not mem_op, but I supposed it should be implemented by means of the
dirmap_{create,read,destroy}.
-Sergey
> + ret = op->data.nbytes;
> + }
> + return ret;
> }
>
> +static const struct spi_controller_mem_ops dw_mchp_bootmaster_mem_ops = {
> + .exec_op = dw_mchp_bootmaster_exec_mem_op,
> +};
> +
> static int dw_spi_mchp_init(struct platform_device *pdev,
> struct dw_spi *dws,
> struct dw_spi_mchp *dwsmchp,
> @@ -107,6 +240,18 @@ static int dw_spi_mchp_init(struct platform_device *pdev,
> }
> }
>
> + /* See if we have a direct read window */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (res && resource_size(res) >= (SZ_16M*MAX_CS)) {
> + void __iomem *ptr = devm_ioremap_resource(&pdev->dev, res);
> +
> + if (!IS_ERR(ptr)) {
> + dwsmchp->read_map = ptr;
> + dws->mem_ops = &dw_mchp_bootmaster_mem_ops;
> + dev_info(&pdev->dev, "Enabling fast memory operations\n");
> + }
> + }
> +
> dwsmchp->syscon =
> syscon_regmap_lookup_by_compatible(props->syscon_name);
> if (IS_ERR(dwsmchp->syscon)) {
> @@ -119,10 +264,9 @@ static int dw_spi_mchp_init(struct platform_device *pdev,
> if (dwsmchp->spi_mst)
> writel(0, dwsmchp->spi_mst + MSCC_SPI_MST_SW_MODE);
>
> - /* Select the owner of the SI interface */
> - regmap_update_bits(dwsmchp->syscon, MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL,
> - MSCC_IF_SI_OWNER_MASK << props->si_owner_bit,
> - MSCC_IF_SI_OWNER_SIMC << props->si_owner_bit);
> + /* SPI2 mapping bitmask */
> + device_property_read_u32(&pdev->dev, "interface-mapping-mask",
> + &dwsmchp->if2mask);
>
> dwsmchp->dws.set_cs = dw_spi_mchp_set_cs;
>
> @@ -180,6 +324,27 @@ static int dw_spi_mchp_probe(struct platform_device *pdev)
> dws->rx_sample_dly = DIV_ROUND_UP(rx_sample_dly,
> (dws->max_freq / 1000000));
>
> + if (pdev->dev.of_node) {
> + int i;
> +
> + for (i = 0; i < dws->num_cs; i++) {
> + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> + "cs-gpios", i);
> +
> + if (cs_gpio == -EPROBE_DEFER) {
> + ret = cs_gpio;
> + goto out;
> + }
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + goto out;
> + }
> + }
> + }
> +
> props = device_get_match_data(&pdev->dev);
> if (props)
> ret = dw_spi_mchp_init(pdev, dws, dwsmchp, props);
> @@ -213,6 +378,8 @@ static int dw_spi_mchp_remove(struct platform_device *pdev)
> static const struct of_device_id dw_spi_mchp_of_match[] = {
> { .compatible = "mscc,ocelot-spi", .data = &dw_spi_mchp_props_ocelot},
> { .compatible = "mscc,jaguar2-spi", .data = &dw_spi_mchp_props_jaguar2},
> + { .compatible = "microchip,sparx5-spi",
> + .data = &dw_spi_mchp_props_sparx5},
> { /* end of table */}
> };
> MODULE_DEVICE_TABLE(of, dw_spi_mchp_of_match);
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Evan Benn @ 2020-06-02 23:22 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: <CAODwPW_oxDxF_5-icRs0eaRVLgtP+bDc_OSKa=EcfeSp=c6Fag@mail.gmail.com>
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 net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:25 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <f92f70b2-6e42-5bdb-187d-ecd8533b06a6@ti.com>
Florian
On 6/2/20 6:18 PM, Dan Murphy wrote:
> Florian
>
> On 6/2/20 6:13 PM, Florian Fainelli wrote:
>>
>> On 6/2/2020 4:10 PM, Dan Murphy wrote:
>>> Florian
>>>
>>> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>>>> Add RGMII internal delay configuration for Rx and Tx.
>>>>>
>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>> ---
>>>> [snip]
>>>>
>>>>> +
>>>>> enum {
>>>>> DP83869_PORT_MIRRORING_KEEP,
>>>>> DP83869_PORT_MIRRORING_EN,
>>>>> @@ -108,6 +113,8 @@ enum {
>>>>> struct dp83869_private {
>>>>> int tx_fifo_depth;
>>>>> int rx_fifo_depth;
>>>>> + s32 rx_id_delay;
>>>>> + s32 tx_id_delay;
>>>>> int io_impedance;
>>>>> int port_mirroring;
>>>>> bool rxctrl_strap_quirk;
>>>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>>>> *phydev)
>>>>> &dp83869->tx_fifo_depth))
>>>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>>>> + &dp83869->rx_id_delay);
>>>>> + if (ret) {
>>>>> + dp83869->rx_id_delay =
>>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>>> + ret = 0;
>>>>> + }
>>>>> +
>>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>>>> + &dp83869->tx_id_delay);
>>>>> + if (ret) {
>>>>> + dp83869->tx_id_delay =
>>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>>> + ret = 0;
>>>>> + }
>>>> It is still not clear to me why is not the parsing being done by
>>>> the PHY
>>>> library helper directly?
>>> Why would we do that for these properties and not any other?
>> Those properties have a standard name, which makes them suitable for
>> parsing by the core PHY library.
>>> Unless there is a new precedence being set here by having the PHY
>>> framework do all the dt node parsing for common properties.
>> You could parse the vendor properties through the driver, let the PHY
>> library parse the standard properties, and resolve any ordering
>> precedence within the driver. In general, I would favor standard
>> properties over vendor properties.
>>
>> Does this help?
>
> Ok so new precedence then.
>
> Because there are common properties like tx-fifo-depth, rx-fifo-depth,
> enet-phy-lane-swap and max_speed that the PHY framework should parse
> as well.
>
I am assuming that the retrieval of the property and getting the index
should be 2 separate APIs?
One API to get the property value and one API to find the index value.
Dan
> Dan
>
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:18 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <6981527b-f155-a46b-574a-2e6621589ca4@gmail.com>
Florian
On 6/2/20 6:13 PM, Florian Fainelli wrote:
>
> On 6/2/2020 4:10 PM, Dan Murphy wrote:
>> Florian
>>
>> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>>> Add RGMII internal delay configuration for Rx and Tx.
>>>>
>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>> ---
>>> [snip]
>>>
>>>> +
>>>> enum {
>>>> DP83869_PORT_MIRRORING_KEEP,
>>>> DP83869_PORT_MIRRORING_EN,
>>>> @@ -108,6 +113,8 @@ enum {
>>>> struct dp83869_private {
>>>> int tx_fifo_depth;
>>>> int rx_fifo_depth;
>>>> + s32 rx_id_delay;
>>>> + s32 tx_id_delay;
>>>> int io_impedance;
>>>> int port_mirroring;
>>>> bool rxctrl_strap_quirk;
>>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>>> *phydev)
>>>> &dp83869->tx_fifo_depth))
>>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>>> + &dp83869->rx_id_delay);
>>>> + if (ret) {
>>>> + dp83869->rx_id_delay =
>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>> + ret = 0;
>>>> + }
>>>> +
>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>>> + &dp83869->tx_id_delay);
>>>> + if (ret) {
>>>> + dp83869->tx_id_delay =
>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>> + ret = 0;
>>>> + }
>>> It is still not clear to me why is not the parsing being done by the PHY
>>> library helper directly?
>> Why would we do that for these properties and not any other?
> Those properties have a standard name, which makes them suitable for
> parsing by the core PHY library.
>> Unless there is a new precedence being set here by having the PHY
>> framework do all the dt node parsing for common properties.
> You could parse the vendor properties through the driver, let the PHY
> library parse the standard properties, and resolve any ordering
> precedence within the driver. In general, I would favor standard
> properties over vendor properties.
>
> Does this help?
Ok so new precedence then.
Because there are common properties like tx-fifo-depth, rx-fifo-depth,
enet-phy-lane-swap and max_speed that the PHY framework should parse as
well.
Dan
^ permalink raw reply
* Re: [PATCH 1/4] drivers: clk: qcom: Add msm8992 GCC driver
From: Bryan O'Donoghue @ 2020-06-02 23:33 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andy Gross, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Philipp Zabel, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20200531174612.260113-2-konradybcio@gmail.com>
On 31/05/2020 18:46, Konrad Dybcio wrote:
> +static struct clk_fixed_factor xo = {
> + .mult = 1,
> + .div = 1,
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "xo",
> + .parent_names = (const char *[]) { "xo_board" },
> + .num_parents = 1,
> + .ops = &clk_fixed_factor_ops,
> + },
> +};
I think you can drop that, and use the DTS definition.
xo_board: xo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
};
sleep_clk: sleep_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};
clock_gcc: clock-controller@fc400000 {
compatible = "qcom,gcc-msm8994";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
reg = <0xfc400000 0x2000>;
+ clock-names = "xo",
+ "sleep_clk";
+ clocks = <&xo_board>,
+ <&sleep_clk>;
};
> +static int gcc_msm8992_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct clk *clk;
> +
> + clk = devm_clk_register(dev, &xo.hw);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
You should drop this too.
> +MODULE_ALIAS("platform:gcc-msm8992");
and that.
---
bod
^ permalink raw reply
* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-06-02 23:44 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, linux-kernel,
linux-spi, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <87img9q3sb.fsf@soft-dev15.microsemi.net>
On Tue, Jun 02, 2020 at 10:18:28AM +0200, Lars Povlsen wrote:
>
> Serge Semin writes:
>
> > Hello Lars,
> >
> > On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> >> This is an add-on series to the main SoC Sparx5 series
> >> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
> >>
> >> The series add support for Sparx5 on top of the existing
> >> ocelot/jaguar2 spi driver.
> >>
> >> It spins off the existing support for the MSCC platforms into a
> >> separate driver, as adding new platforms from the MSCC/Microchip
> >> product lines will further complicate (clutter) the original driver.
> >>
> >> New YAML dt-bindings are provided for the resulting driver.
> >>
> >> It is expected that the DT patches are to be taken directly by the arm-soc
> >> maintainers.
> >
> > Regarding our cooperation. It can be implemented as follows. Since your patchset
> > is less cumbersome than mine and is more ready to be integrated into the generic DW
> > APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> > to be further merged into the kernel version of the driver. After that I'll have
> > my code altered so it could be applied on top of your patches. When everything
> > is done we'll have a more comprehensive DW APB SSI driver with poll-based
> > PIO operations support, new features like rx-delay, etc.
> >
>
> Hi Serge!
>
> I think I would be able to work on the SPI patches this week. Should I
> base it on the current spi-next or 5.7? Then address the comments and
> send out a new revision?
Finally I've done a part of review. It must be enough for v2. As Mark said the
new version is supposed to be based on the spi-next, since that branch's got
all recent DW APB SSI patches applied.
-Sergey
>
> Thanks for reaching out.
>
> ---Lars
>
> > Thank you one more time for the series you've shared with us. Let's see what can
> > be done to improve it...
> >
> > -Sergey
> >
> >>
> >> Lars Povlsen (10):
> >> spi: dw: Add support for polled operation via no IRQ specified in DT
> >> spi: dw: Add support for RX sample delay register
> >> spi: dw: Add support for client driver memory operations
> >> dt-bindings: spi: Add bindings for spi-dw-mchp
> >> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> >> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> >> spi: spi-dw-mchp: Add Sparx5 support
> >> arm64: dts: sparx5: Add SPI controller
> >> arm64: dts: sparx5: Add spi-nor support
> >> arm64: dts: sparx5: Add spi-nand devices
> >>
> >> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> >> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> >> MAINTAINERS | 2 +
> >> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> >> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> >> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> >> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> >> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> >> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> >> arch/mips/configs/generic/board-ocelot.config | 2 +-
> >> drivers/spi/Kconfig | 7 +
> >> drivers/spi/Makefile | 1 +
> >> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> >> drivers/spi/spi-dw-mmio.c | 93 ----
> >> drivers/spi/spi-dw.c | 31 +-
> >> drivers/spi/spi-dw.h | 4 +
> >> 16 files changed, 644 insertions(+), 107 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> >> create mode 100644 drivers/spi/spi-dw-mchp.c
> >>
> >> --
> >> 2.26.2
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Lars Povlsen,
> Microchip
^ permalink raw reply
* Re: [PATCH v8 04/10] drm: bridge: dw_mipi_dsi: allow bridge daisy chaining
From: Laurent Pinchart @ 2020-06-02 23:51 UTC (permalink / raw)
To: Adrian Ratiu
Cc: linux-arm-kernel, devicetree, linux-rockchip, Andrzej Hajda,
Jonas Karlman, Jernej Skrabec, Heiko Stuebner, linux-kernel,
dri-devel, linux-imx, kernel, linux-stm32
In-Reply-To: <20200427081952.3536741-5-adrian.ratiu@collabora.com>
Hi Adrian,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
> Up until now the assumption was that the synopsis dsi bridge will
> directly connect to an encoder provided by the platform driver, but
> the current practice for drivers is to leave the encoder empty via
> the simple encoder API and add their logic to their own drm_bridge.
>
> Thus we need an ablility to connect the DSI bridge to another bridge
> provided by the platform driver, so we extend the dw_mipi_dsi bind()
> API with a new "previous bridge" arg instead of just hardcoding NULL.
>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> New in v8.
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++++--
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
> include/drm/bridge/dw_mipi_dsi.h | 5 ++++-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 16fd87055e7b7..140ff40fa1b62 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -1456,11 +1456,13 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
> /*
> * Bind/unbind API, used from platforms based on the component framework.
> */
> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder)
> +int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
> + struct drm_encoder *encoder,
> + struct drm_bridge *prev_bridge)
> {
> int ret;
>
> - ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, 0);
> + ret = drm_bridge_attach(encoder, &dsi->bridge, prev_bridge, 0);
Please note that chaining of bridges doesn't work well if multiple
bridges in the chain try to create a connector. This is why a
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag has been added, with a helper to
create a connector for a chain of bridges (drm_bridge_connector_init()).
This won't play well with the component framework. I would recommend
using the of_drm_find_bridge() instead in the rockchip driver, and
deprecating dw_mipi_dsi_bind().
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> return ret;
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 3feff0c45b3f7..83ef43be78135 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -929,7 +929,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> return ret;
> }
>
> - ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
> + ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder, NULL);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
> return ret;
> diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
> index b0e390b3288e8..699b3531f5b36 100644
> --- a/include/drm/bridge/dw_mipi_dsi.h
> +++ b/include/drm/bridge/dw_mipi_dsi.h
> @@ -14,6 +14,7 @@
> #include <drm/drm_modes.h>
>
> struct drm_display_mode;
> +struct drm_bridge;
> struct drm_encoder;
> struct dw_mipi_dsi;
> struct mipi_dsi_device;
> @@ -62,7 +63,9 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device *pdev,
> const struct dw_mipi_dsi_plat_data
> *plat_data);
> void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
> +int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
> + struct drm_encoder *encoder,
> + struct drm_bridge *prev_bridge);
> void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi *slave);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: dts: stm32: make hdmi-transmitter node compliant with DT bindings
From: Laurent Pinchart @ 2020-06-02 23:55 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-4-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Mon, Jun 01, 2020 at 08:33:07AM +0200, Ricardo Cañuelo wrote:
> Reorder the I2C slave addresses of the hdmi-transmitter node and remove
> the adi,input-style and adi,input-justification properties to meet the
> adi,adv7513 binding requirements.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> index 930202742a3f..b67a21a8698a 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> @@ -185,8 +185,8 @@
> &i2c4 {
> hdmi-transmitter@3d {
> compatible = "adi,adv7513";
> - reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x3d>, <0x4d>, <0x2d> , <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
> clocks = <&cec_clock>;
> clock-names = "cec";
>
> @@ -204,8 +204,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Serge Semin @ 2020-06-03 0:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Rafael J. Wysocki, Daniel Lezcano,
James Hogan, linux-mips, devicetree, linux-kernel
In-Reply-To: <61afd4bd10ac644fa623e218f947328e@kernel.org>
On Tue, Jun 02, 2020 at 11:12:31AM +0100, Marc Zyngier wrote:
> On 2020-06-02 11:09, Serge Semin wrote:
> > Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip,
> > MIPS
> > GIC timer and MIPS CPS CPUidle drivers.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> >
> > ---
> >
> > Changelog v3:
> > - Keep the files list alphabetically ordered.
> > - Add Thomas as the co-maintainer of the designated drivers.
> > ---
> > MAINTAINERS | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2926327e4976..20532e0287d7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11278,6 +11278,17 @@
> > F: arch/mips/configs/generic/board-boston.config
> > F: drivers/clk/imgtec/clk-boston.c
> > F: include/dt-bindings/clock/boston-clock.h
> >
> > +MIPS CORE DRIVERS
> > +M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > +M: Serge Semin <fancer.lancer@gmail.com>
> > +L: linux-mips@vger.kernel.org
> > +S: Supported
> > +F: drivers/bus/mips_cdmm.c
> > +F: drivers/clocksource/mips-gic-timer.c
> > +F: drivers/cpuidle/cpuidle-cps.c
> > +F: drivers/irqchip/irq-mips-cpu.c
> > +F: drivers/irqchip/irq-mips-gic.c
> > +
> > MIPS GENERIC PLATFORM
> > M: Paul Burton <paulburton@kernel.org>
> > L: linux-mips@vger.kernel.org
>
> Acked-by: Marc Zyngier <maz@kernel.org>
>
> I assume this will go via the MIPS tree.
Yes, I also think so. Though I suppose first we have to get acks from
Rafael J. Wysocki (CPU IDLE) or Daniel Lezcano (CPU IDLE,
CLOCKSOURCE/CLOCKEVENT) or Thomas Gleixner (CLOCKSOURCE, CLOCKEVENT)
since we are going to maintain the drivers from the subsystems they
support. Am I right?
-Sergey
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 4/4] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-06-03 0:03 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-5-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Mon, Jun 01, 2020 at 08:33:08AM +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>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Great work :-)
> ---
> .../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
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> deleted file mode 100644
> index 659523f538bf..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ /dev/null
> @@ -1,143 +0,0 @@
> -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
> -------------------------------------------------
> -
> -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
> -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
> -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
> -pixels, while the others support RGB interface.
> -
> -Required properties:
> -
> -- compatible: Should be one of:
> - "adi,adv7511"
> - "adi,adv7511w"
> - "adi,adv7513"
> - "adi,adv7533"
> - "adi,adv7535"
> -
> -- reg: I2C slave addresses
> - The ADV7511 internal registers are split into four pages exposed through
> - different I2C addresses, creating four register maps. Each map has it own
> - I2C address and acts as a standard slave device on the I2C bus. The main
> - address is mandatory, others are optional and revert to defaults if not
> - specified.
> -
> -
> -The ADV7511 supports a large number of input data formats that differ by their
> -color depth, color format, clock mode, bit justification and random
> -arrangement of components on the data bus. The combination of the following
> -properties describe the input and map directly to the video input tables of the
> -ADV7511 datasheet that document all the supported combinations.
> -
> -- adi,input-depth: Number of bits per color component at the input (8, 10 or
> - 12).
> -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
> - "yuv444".
> -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
> - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
> - data driven on both edges).
> -
> -The following input format properties are required except in "rgb 1x" and
> -"yuv444 1x" modes, in which case they must not be specified.
> -
> -- adi,input-style: The input components arrangement variant (1, 2 or 3), as
> - listed in the input format tables in the datasheet.
> -- adi,input-justification: The input bit justification ("left", "evenly",
> - "right").
> -
> -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
> -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
> -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
> -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
> - on the chip.
> -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
> - needed only for ADV7511.
> -
> -The following properties are required for ADV7533 and ADV7535:
> -
> -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
> - be one of 1, 2, 3 or 4.
> -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
> -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
> -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
> - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
> -
> -Optional properties:
> -
> -- interrupts: Specifier for the ADV7511 interrupt
> -- pd-gpios: Specifier for the GPIO connected to the power down signal
> -
> -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
> - (-1200 ps .. 1600 ps). Defaults to no delay.
> -- adi,embedded-sync: The input uses synchronization signals embedded in the
> - data stream (similar to BT.656). Defaults to separate H/V synchronization
> - signals.
> -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
> - internal timing generator. The chip will rely on the sync signals in the
> - DSI data lanes, rather than generate its own timings for HDMI output.
> -- clocks: from common clock binding: reference to the CEC clock.
> -- clock-names: from common clock binding: must be "cec".
> -- reg-names : Names of maps with programmable addresses.
> - It can contain any map needing a non-default address.
> - Possible maps names are : "main", "edid", "cec", "packet"
> -
> -Required nodes:
> -
> -The ADV7511 has two video ports. Their connections are modelled using the OF
> -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> -
> -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
> - remote endpoint phandle should be a reference to a valid mipi_dsi_host device
> - node.
> -- Video port 1 for the HDMI output
> -- Audio port 2 for the HDMI audio input
> -
> -
> -Example
> --------
> -
> - adv7511w: hdmi@39 {
> - compatible = "adi,adv7511w";
> - /*
> - * The EDID page will be accessible on address 0x66 on the I2C
> - * bus. All other maps continue to use their default addresses.
> - */
> - reg = <0x39>, <0x66>;
> - reg-names = "main", "edid";
> - interrupt-parent = <&gpio3>;
> - interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> - clocks = <&cec_clock>;
> - clock-names = "cec";
> -
> - adi,input-depth = <8>;
> - adi,input-colorspace = "rgb";
> - adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - adv7511w_in: endpoint {
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - adv7511_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - codec_endpoint: endpoint {
> - remote-endpoint = <&i2s0_cpu_endpoint>;
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> new file mode 100644
> index 000000000000..71b344e812dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,231 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7511/11W/13 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> + space conversion, S/PDIF, CEC and HDCP. The transmitter input is
> + parallel RGB or YUV data.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7511
> + - adi,adv7511w
> + - adi,adv7513
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7511/11W/13 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + dvdd-3v-supply:
> + description: A 3.3V supply that powers up the DVDD_3V pin.
> +
> + bgvdd-supply:
> + description: A 1.8V supply that powers up the BGVDD pin.
> +
> + adi,input-depth:
> + description: Number of bits per color component at the input.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 8, 10, 12 ]
> +
> + adi,input-colorspace:
> + description: Input color space.
> + enum: [ rgb, yuv422, yuv444 ]
> +
> + adi,input-clock:
> + description: |
> + Input clock type.
> + "1x": one clock cycle per pixel
> + "2x": two clock cycles per pixel
> + "dd": one clock cycle per pixel, data driven on both edges
> + enum: [ 1x, 2x, dd ]
> +
> + adi,clock-delay:
> + description:
> + Video data clock delay relative to the pixel clock, in ps
> + (-1200ps .. 1600 ps).
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> +
> + adi,embedded-sync:
> + description:
> + If defined, the input uses synchronization signals embedded in the
> + data stream (similar to BT.656).
> + type: boolean
> +
> + adi,input-style:
> + description:
> + Input components arrangement variant as listed in the input
> + format tables in the datasheet.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 1, 2, 3 ]
> +
> + adi,input-justification:
> + description: Input bit justification.
> + enum: [ left, evenly, right ]
> +
> + ports:
> + description:
> + The ADV7511(W)/13 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description: Video port for the RGB or YUV input.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +# adi,input-colorspace and adi,input-clock are required except in
> +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
> +# specified.
> +if:
> + not:
> + properties:
> + adi,input-colorspace:
> + contains:
> + enum: [ rgb, yuv444 ]
> + adi,input-clock:
> + contains:
> + const: 1x
> +
> +then:
> + required:
> + - adi,input-style
> + - adi,input-justification
> +
> +else:
> + properties:
> + adi,input-style: false
> + adi,input-justification: false
> +
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,input-depth
> + - adi,input-colorspace
> + - adi,input-clock
> + - avdd-supply
> + - dvdd-supply
> + - pvdd-supply
> + - dvdd-3v-supply
> + - bgvdd-supply
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7511w: hdmi@39 {
> + compatible = "adi,adv7511w";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + avdd-supply = <&v1v8>;
> + dvdd-supply = <&v1v8>;
> + pvdd-supply = <&v1v8>;
> + dvdd-3v-supply = <&v3v3>;
> + bgvdd-supply = <&v1v8>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "yuv422";
> + adi,input-clock = "1x";
> +
> + adi,input-style = <3>;
> + adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> new file mode 100644
> index 000000000000..18761f49e5fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> @@ -0,0 +1,175 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7533/35 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> + compatible with HDMI 1.4 and DVI 1.0. They support color space
> + conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7533
> + - adi,adv7535
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7533/35 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + a2vdd-supply:
> + description: A 1.8V supply that powers up the A2VDD pin.
> +
> + v3p3-supply:
> + description: A 3.3V supply that powers up the V3P3 pin.
> +
> + v1p2-supply:
> + description:
> + A supply that powers up the V1P2 pin. It can be either 1.2V
> + or 1.8V for ADV7533 but only 1.8V for ADV7535.
> +
> + adi,disable-timing-generator:
> + description:
> + Disables the internal timing generator. The chip will rely on the
> + sync signals in the DSI data lanes, rather than generating its own
> + timings for HDMI output.
> + type: boolean
> +
> + adi,dsi-lanes:
> + description: Number of DSI data lanes connected to the DSI host.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 1, 2, 3, 4 ]
> +
> + ports:
> + description:
> + The ADV7533/35 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description:
> + Video port for the DSI input. The remote endpoint phandle
> + should be a reference to a valid mipi_dsi_host_device.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,dsi-lanes
> + - avdd-supply
> + - dvdd-supply
> + - pvdd-supply
> + - a2vdd-supply
> + - v3p3-supply
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7533: hdmi@39 {
> + compatible = "adi,adv7533";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + adi,dsi-lanes = <4>;
> + avdd-supply = <&v1v8>;
> + dvdd-supply = <&v1v8>;
> + pvdd-supply = <&v1v8>;
> + a2vdd-supply = <&v1v8>;
> + v3p3-supply = <&v3v3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7533_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7533_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> 2.18.0
>
--
Regards,
Laurent Pinchart
^ 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