* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-18 13:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ramuthevar, Vadivel MuruganX, kbuild test robot,
Linux Kernel Mailing List, open list:MEMORY TECHNOLOGY...,
devicetree, kbuild-all, Miquel Raynal, Richard Weinberger,
Vignesh R, Brendan Higgins, Thomas Gleixner, Boris Brezillon,
Anders Roxell, masonccyang
In-Reply-To: <CAK8P3a25GbMwbtvkxgmuGss6nEfAW4_vVbOXPxOYuDOaU_zcjA@mail.gmail.com>
On Mon, May 18, 2020 at 2:57 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, May 18, 2020 at 1:43 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, May 18, 2020 at 2:39 PM Ramuthevar, Vadivel MuruganX
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> > > On 15/5/2020 10:30 pm, Arnd Bergmann wrote:
> > > > On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko
> > > > <andy.shevchenko@gmail.com> wrote:
> > > >> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
> >
> > > > iowrite_be32() is the correct way to store word into a big-endian mmio register,
> > > > if that is the intention here.
> > > Thank you for suggestions to use iowrite32be(), it suits exactly.
> >
> > Can you before doing this comment what is the real intention here?
> >
> > And note, if you are going to use iowrite*() / ioread*() in one place,
> > you will probably need to replace all of the read*() / write*() to
> > respective io* API.
>
> The way that ioread/iowrite are defined, they are required to be a superset
> of what readl/writel do and can take __iomem pointers from either
> ioremap() or ioport_map()/pci_iomap() style mappings, while readl/writel
> are only required to work with ioremap().
>
> There is no technical requirement to stick to one set or the other for
> ioremap(), but the overhead of ioread/iowrite is also small enough
> that it generally does not hurt.
Right, my suggestion is solely for consistency. It would be a bit
weird to see readl() along with ioread32() in the same driver (in case
there are no differentiated callbacks specifically for different type
of IP).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V6 3/3] dt-bindings: serial: Add binding for UART pin swap
From: Akash Asthana @ 2020-05-18 13:19 UTC (permalink / raw)
To: Rob Herring
Cc: gregkh, linux-arm-msm, devicetree, linux-kernel, mgautam, rojay,
skakit, mka
In-Reply-To: <20200515030133.GA11479@bogus>
Hi Rob,
On 5/15/2020 8:31 AM, Rob Herring wrote:
> On Thu, May 07, 2020 at 08:30:47PM +0530, Akash Asthana wrote:
>> Add documentation to support RX-TX & CTS-RTS GPIO pin swap in HW.
>>
>> Signed-off-by: Akash Asthana <akashast@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/serial/serial.yaml | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
>> index 53204d9..e657dd6 100644
>> --- a/Documentation/devicetree/bindings/serial/serial.yaml
>> +++ b/Documentation/devicetree/bindings/serial/serial.yaml
>> @@ -67,6 +67,12 @@ properties:
>> (wired and enabled by pinmux configuration). This depends on both the
>> UART hardware and the board wiring.
>>
>> + rx-tx-swap:
>> + description: RX and TX pins are swapped.
>> +
>> + cts-rts-swap:
>> + description: CTS and RTS pins are swapped.
> Need 'type: boolean' on both of these.
okay, will correct in next version
Regards,
Akash
>
>> +
>> if:
>> required:
>> - uart-has-rtscts
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 17/17] ARM: dts: r8a7742: Add RWDT node
From: Sergei Shtylyov @ 2020-05-18 13:17 UTC (permalink / raw)
To: Lad, Prabhakar, Geert Uytterhoeven
Cc: Lad Prabhakar, Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
David S. Miller, Wim Van Sebroeck, Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List
In-Reply-To: <CA+V-a8tmG1LKYqbc7feGZQO2Tj5RCpNUHi9e19vPr+bED0KOyQ@mail.gmail.com>
Hello!
On 18.05.2020 15:27, Lad, Prabhakar wrote:
>>> Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
>>> RZ/G1H (r8a7742) SoC.
>>>
>>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>>> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>>
>> Thanks for your patch!
>>
>>> --- a/arch/arm/boot/dts/r8a7742.dtsi
>>> +++ b/arch/arm/boot/dts/r8a7742.dtsi
>>> @@ -201,6 +201,16 @@
>>> #size-cells = <2>;
>>> ranges;
>>>
>>> + rwdt: watchdog@e6020000 {
>>> + compatible = "renesas,r8a7742-wdt",
>>> + "renesas,rcar-gen2-wdt";
>>> + reg = <0 0xe6020000 0 0x0c>;
>>> + clocks = <&cpg CPG_MOD 402>;
>>> + power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
>>> + resets = <&cpg 402>;
>>> + status = "disabled";
>>
>> Missing "interrupts" property.
>>
> "interrupts" property isn't used by rwdt driver and can be dropped
> from bindings file.
DT describes the hardware, not its driver's abilities.
> Cheers,
> --Prabhakar
MBR, Sergei
^ permalink raw reply
* Re: [PATCH V6 0/3] Convert QUP bindings to YAML and add ICC, pin swap doc
From: Akash Asthana @ 2020-05-18 13:16 UTC (permalink / raw)
To: Stephen Boyd, gregkh, robh+dt
Cc: linux-arm-msm, devicetree, linux-kernel, mgautam, rojay, skakit,
mka
In-Reply-To: <158942181222.215346.11981864062704009851@swboyd.mtv.corp.google.com>
Hi Stephen,
On 5/14/2020 7:33 AM, Stephen Boyd wrote:
> Quoting Akash Asthana (2020-05-07 08:00:44)
>> Changes in V6:
>> - As per Rob's suggestion moved pin swap documentation from QUP to
>> serial.yaml file[PATCH V6 3/3].
>>
>> Changes in V4:
>> - Add interconnect binding patch.
>> - Add UART pin swap binding patch.
>>
>> Akash Asthana (3):
>> dt-bindings: geni-se: Convert QUP geni-se bindings to YAML
>> dt-bindings: geni-se: Add interconnect binding for GENI QUP
>> dt-bindings: serial: Add binding for UART pin swap
>>
> Who do you intend to pick up these patches? Rob or Greg? I suppose if
> it's all in bindings then maybe Rob can pick them up.
I intended Rob to pick these patches but Greg is maintainer of
serial.yaml file so I send patches to him as well, I thought I would be
needing ack from him.
But from your reply it's clear that I should be sending to Rob only.
Regards,
Akash
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V5 6/7] spi: spi-qcom-qspi: Add interconnect support
From: Akash Asthana @ 2020-05-18 13:10 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: gregkh, agross, bjorn.andersson, wsa, broonie, mark.rutland,
robh+dt, linux-i2c, linux-spi, devicetree, swboyd, mgautam,
linux-arm-msm, linux-serial, dianders, evgreen, georgi.djakov
In-Reply-To: <20200508185310.GF4525@google.com>
Hi Matthias,
On 5/9/2020 12:23 AM, Matthias Kaehlcke wrote:
> On Fri, May 08, 2020 at 12:03:38PM +0530, Akash Asthana wrote:
>> Get the interconnect paths for QSPI device and vote according to the
>> current bus speed of the driver.
>>
>> Signed-off-by: Akash Asthana <akashast@codeaurora.org>
>> ---
>> Changes in V2:
>> - As per Bjorn's comment, introduced and using devm_of_icc_get API for getting
>> path handle
>> - As per Matthias comment, added error handling for icc_set_bw call
>>
>> Changes in V3:
>> - No Change.
>>
>> Changes in V4:
>> - As per Mark's comment move peak_bw guess as twice of avg_bw if
>> nothing mentioned explicitly to ICC core.
>>
>> Changes in V5:
>> - Add icc_enable/disable to power on/off call.
>> - Save some non-zero avg/peak value to ICC core by calling geni_icc_set_bw
>> from probe so that when resume/icc_enable is called NOC are running at
>> some non-zero value.
>>
>> drivers/spi/spi-qcom-qspi.c | 59 ++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 58 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c
>> index 3c4f83b..6e299f4 100644
>> --- a/drivers/spi/spi-qcom-qspi.c
>> +++ b/drivers/spi/spi-qcom-qspi.c
>> @@ -2,6 +2,7 @@
>> // Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
>>
>> #include <linux/clk.h>
>> +#include <linux/interconnect.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> @@ -139,7 +140,10 @@ struct qcom_qspi {
>> struct device *dev;
>> struct clk_bulk_data *clks;
>> struct qspi_xfer xfer;
>> - /* Lock to protect xfer and IRQ accessed registers */
>> + struct icc_path *icc_path_cpu_to_qspi;
>> + unsigned int avg_bw_cpu;
>> + unsigned int peak_bw_cpu;
> There is no point in having two fields, 'peak_bw_cpu' is always assigned
> to 'avg_bw_cpu' and passed to icc_set_bw(). Just make it a single field
> 'icc_bw_cpu'.
Agree that we are not using peak_bw voting as of now but probably we may
use it in future, currently we are using only avg_bw for our need but if
in future power team shares some data or ask us to reduce our power
consumption, then with help of peak_bw we can tune ICC voting where
power and performance both can be met as per requirement.
>
>> + /* Lock to protect data accessed by IRQs */
>> spinlock_t lock;
>> };
>>
>> @@ -241,6 +245,20 @@ static int qcom_qspi_transfer_one(struct spi_master *master,
>> return ret;
>> }
>>
>> + /*
>> + * Set BW quota for CPU as driver supports FIFO mode only.
>> + * We don't have explicit peak requirement so keep it equal to avg_bw.
>> + */
>> + ctrl->avg_bw_cpu = Bps_to_icc(speed_hz);
>> + ctrl->peak_bw_cpu = ctrl->avg_bw_cpu;
>> + ret = icc_set_bw(ctrl->icc_path_cpu_to_qspi, ctrl->avg_bw_cpu,
>> + ctrl->peak_bw_cpu);
>> + if (ret) {
>> + dev_err(ctrl->dev, "%s: ICC BW voting failed for cpu\n",
>> + __func__);
> the logging in this patch is inconsistent. Here the error is not printed,
> at all, in other cases it's "<error>, ret:-42" or "<error> ret:-42".
> Please stick to a common format (unless there is no error). My
> suggestion would be "<error>: -42", in my perception "ret:" just adds
> noise.
Okay.
Regards,
Akash
>
>> + return ret;
>> + }
>> +
>> spin_lock_irqsave(&ctrl->lock, flags);
>>
>> /* We are half duplex, so either rx or tx will be set */
>> @@ -458,6 +476,29 @@ static int qcom_qspi_probe(struct platform_device *pdev)
>> if (ret)
>> goto exit_probe_master_put;
>>
>> + ctrl->icc_path_cpu_to_qspi = devm_of_icc_get(dev, "qspi-config");
>> + if (IS_ERR(ctrl->icc_path_cpu_to_qspi)) {
>> + ret = PTR_ERR(ctrl->icc_path_cpu_to_qspi);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "Failed to get cpu path, ret:%d\n", ret);
>> + goto exit_probe_master_put;
>> + }
>> + /* Set BW vote for register access */
>> + ret = icc_set_bw(ctrl->icc_path_cpu_to_qspi, Bps_to_icc(1000),
>> + Bps_to_icc(1000));
>> + if (ret) {
>> + dev_err(ctrl->dev, "%s: ICC BW voting failed for cpu ret:%d\n",
>> + __func__, ret);
>> + goto exit_probe_master_put;
>> + }
>> +
>> + ret = icc_disable(ctrl->icc_path_cpu_to_qspi);
>> + if (ret) {
>> + dev_err(ctrl->dev, "%s: ICC disable failed for cpu ret:%d\n",
>> + __func__, ret);
>> + goto exit_probe_master_put;
>> + }
>> +
>> ret = platform_get_irq(pdev, 0);
>> if (ret < 0)
>> goto exit_probe_master_put;
>> @@ -511,9 +552,17 @@ static int __maybe_unused qcom_qspi_runtime_suspend(struct device *dev)
>> {
>> struct spi_master *master = dev_get_drvdata(dev);
>> struct qcom_qspi *ctrl = spi_master_get_devdata(master);
>> + int ret;
>>
>> clk_bulk_disable_unprepare(QSPI_NUM_CLKS, ctrl->clks);
>>
>> + ret = icc_disable(ctrl->icc_path_cpu_to_qspi);
>> + if (ret) {
>> + dev_err_ratelimited(ctrl->dev, "%s: ICC disable failed for cpu ret:%d\n",
>> + __func__, ret);
>> + return ret;
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -521,6 +570,14 @@ static int __maybe_unused qcom_qspi_runtime_resume(struct device *dev)
>> {
>> struct spi_master *master = dev_get_drvdata(dev);
>> struct qcom_qspi *ctrl = spi_master_get_devdata(master);
>> + int ret;
>> +
>> + ret = icc_enable(ctrl->icc_path_cpu_to_qspi);
>> + if (ret) {
>> + dev_err_ratelimited(ctrl->dev, "%s: ICC enable failed for cpu ret:%d\n",
>> + __func__, ret);
>> + return ret;
>> + }
>>
>> return clk_bulk_prepare_enable(QSPI_NUM_CLKS, ctrl->clks);
>> }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
From: Kieran Bingham @ 2020-05-18 13:09 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Sakari Ailus, linux-renesas-soc, linux-media, devicetree,
linux-kernel, Mauro Carvalho Chehab, Kieran Bingham,
Laurent Pinchart, Niklas Söderlund, Hans Verkuil, Hyun Kwon,
Manivannan Sadhasivam, Rob Herring, Jacopo Mondi,
Laurent Pinchart, Niklas Söderlund
In-Reply-To: <20200518123810.wsqg2a3lbbme36e7@uno.localdomain>
Hi Jacopo, Sakari,
On 18/05/2020 13:38, Jacopo Mondi wrote:
> Hi Kieran, Sakari
>
> On Mon, May 18, 2020 at 12:45:18PM +0100, Kieran Bingham wrote:
>> Hi Sakari,
>>
>> There are only fairly minor comments here, fix ups will be included in a
>> v10.
>>
>> Is there anything major blocking integration?
>>
>> Regards
>>
>> Kieran
>>
>>
>>
>> On 16/05/2020 22:51, Sakari Ailus wrote:
>>> Hi Kieran,
>>>
>>> Thanks for the update.
>>>
>>> On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
>>>
>>> ...
>>>
>>>> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
>>>> + struct v4l2_subdev_pad_config *cfg,
>>>> + struct v4l2_subdev_mbus_code_enum *code)
>>>> +{
>>>> + if (code->pad || code->index > 0)
>>>> + return -EINVAL;
>>>> +
>>>> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;
>>>
>>> Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
>>> variant of the format is generally used on the serial busses. This choice
>>> was made when serial busses were introduced.
>>
>> Ok - I presume this doesn't really have much effect anyway, they just
>> have to match for the transmitter/receiver?
>>
>> But it makes sense to me, so I'll update to the 1x16 variant.
>>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct v4l2_mbus_framefmt *
>>>> +max9286_get_pad_format(struct max9286_priv *priv,
>>>> + struct v4l2_subdev_pad_config *cfg,
>>>> + unsigned int pad, u32 which)
>>>> +{
>>>> + switch (which) {
>>>> + case V4L2_SUBDEV_FORMAT_TRY:
>>>> + return v4l2_subdev_get_try_format(&priv->sd, cfg, pad);
>>>> + case V4L2_SUBDEV_FORMAT_ACTIVE:
>>>> + return &priv->fmt[pad];
>>>> + default:
>>>> + return NULL;
>>>> + }
>>>> +}
>>>> +
>>>> +static int max9286_set_fmt(struct v4l2_subdev *sd,
>>>> + struct v4l2_subdev_pad_config *cfg,
>>>> + struct v4l2_subdev_format *format)
>>>> +{
>>>> + struct max9286_priv *priv = sd_to_max9286(sd);
>>>> + struct v4l2_mbus_framefmt *cfg_fmt;
>>>> +
>>>> + if (format->pad >= MAX9286_SRC_PAD)
>>>> + return -EINVAL;
>>>
>>> You can remove these checks; it's been already done by the caller.
>>>
>>
>> Ok.
>>
>
> I think this shold be kept. The core validates that the pad number is
> valid, but we're here checking that set_fmt has been called on a sink
> pad [0-3], returning -EINVAL if set_fmt (and get_ftm as well) are
> called on the source one.
>
Indeed, this is actually preventing get/set format on the intermediate
(multiplexed) stream. But it is "breaking" link validation (or
preventing it from happening maybe?), which is defaulting 'open' ...
that might be a problem we need to look at, but as we don't have a real
multiplexed stream support implementation then that's perhaps more
difficult to give a 'correct' answer.
> My question now is how does link validation work, if get_fmt() is not
> allowed on the source pad :/ ? Anyway, I would keep this check for
> set_fmt (maybe make it an == to address Sakari's comment).
Ok - so as long as we return -EINVAL for the MAX9286_SRC_PAD, then
v4l2_subdev_link_validate() will fail on
v4l2_subdev_link_validate_get_format() for that pad, which causes a return 0
(v4l2_subdev_link_validate defaulting to success if it can't get both pads)
We could convert this to:
/*
* \todo: Prevent validation of the source pad, as it represents a
* multiplexed stream, and we do not have multiplexed stream support in
* V4L2 yet.
*/
if (format->pad == MAX9286_SRC_PAD)
Or we could call this a blocker. Which will make me sad, as I really
want to be able to have a baseline for development for this driver, but
I've been calling out for "What blockers prevent this driver from being
merged" since February so if this is it - so be it...
Sakari - is this a blocking issue for you? Or can we consider this a
topic that we (already know) needs visiting as part of V4L2 Multiplexed
stream support.
We already know of course that this driver is taking liberties due to
the lack of multiplexed stream support, and requires the receiver to
assume that each camera is on a different (consecutive?) VC.
Or perhaps - to enforce validation, we could have the get_fmt call pass
on the bus format of the first camera link ?
Thoughts anyone?
>
> Thanks
> j
>
>>
>>> ...
>>>
>>>> +static int max9286_parse_dt(struct max9286_priv *priv)
>>>> +{
>>>> + struct device *dev = &priv->client->dev;
>>>> + struct device_node *i2c_mux;
>>>> + struct device_node *node = NULL;
>>>> + unsigned int i2c_mux_mask = 0;
>>>> +
>>>> + of_node_get(dev->of_node);
>>>> + i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
>>>> + if (!i2c_mux) {
>>>> + dev_err(dev, "Failed to find i2c-mux node\n");
>>>> + of_node_put(dev->of_node);
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + /* Identify which i2c-mux channels are enabled */
>>>> + for_each_child_of_node(i2c_mux, node) {
>>>> + u32 id = 0;
>>>> +
>>>> + of_property_read_u32(node, "reg", &id);
>>>> + if (id >= MAX9286_NUM_GMSL)
>>>> + continue;
>>>> +
>>>> + if (!of_device_is_available(node)) {
>>>> + dev_dbg(dev, "Skipping disabled I2C bus port %u\n", id);
>>>> + continue;
>>>> + }
>>>> +
>>>> + i2c_mux_mask |= BIT(id);
>>>> + }
>>>> + of_node_put(node);
>>>> + of_node_put(i2c_mux);
>>>> +
>>>> + /* Parse the endpoints */
>>>> + for_each_endpoint_of_node(dev->of_node, node) {
>>>> + struct max9286_source *source;
>>>> + struct of_endpoint ep;
>>>> +
>>>> + of_graph_parse_endpoint(node, &ep);
>>>> + dev_dbg(dev, "Endpoint %pOF on port %d",
>>>> + ep.local_node, ep.port);
>>>> +
>>>> + if (ep.port > MAX9286_NUM_GMSL) {
>>>> + dev_err(dev, "Invalid endpoint %s on port %d",
>>>> + of_node_full_name(ep.local_node), ep.port);
>>>> + continue;
>>>> + }
>>>> +
>>>> + /* For the source endpoint just parse the bus configuration. */
>>>> + if (ep.port == MAX9286_SRC_PAD) {
>>>> + struct v4l2_fwnode_endpoint vep = {
>>>> + .bus_type = V4L2_MBUS_CSI2_DPHY
>>>> + };
>>>> + int ret;
>>>> +
>>>> + ret = v4l2_fwnode_endpoint_parse(
>>>> + of_fwnode_handle(node), &vep);
>>>> + if (ret) {
>>>> + of_node_put(node);
>>>> + of_node_put(dev->of_node);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + if (vep.bus_type != V4L2_MBUS_CSI2_DPHY) {
>>>
>>> This won't happen, the bus type will stay if you set it to a non-zero
>>> value.
>>
>>
>> Ok - I'll remove this check.
>>
>>
>>>
>>>> + dev_err(dev,
>>>> + "Media bus %u type not supported\n",
>>>> + vep.bus_type);
>>>> + v4l2_fwnode_endpoint_free(&vep);
>>>> + of_node_put(node);
>>>> + of_node_put(dev->of_node);
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + priv->csi2_data_lanes =
>>>> + vep.bus.mipi_csi2.num_data_lanes;
>>>> + v4l2_fwnode_endpoint_free(&vep);
>>>
>>> No need to call this unless you use v4l2_fwnode_endpoint_alloc_parse().
>>>
>>> And as you don't, you also won't know which frequencies are known to be
>>> safe to use. That said, perhaps where this device is used having a random
>>> frequency on that bus could not be an issue. Perhaps.
>>
>> Does this generate a range? or a list of static supported frequencies?
>>
>> We configure the pixel clock based upon the number of cameras connected,
>> and their pixel rates etc ...
>>
>> Are you saying that the frequency of this clock should be validated to
>> be a specific range? or are you talking about a different frequency?
>>
>>
>> For now I'll remove the v4l2_fwnode_endpoint_alloc_parse().
>>
>>
>>
>>>> +
>>>> + continue;
>>>> + }
>>>> +
>>>> + /* Skip if the corresponding GMSL link is unavailable. */
>>>> + if (!(i2c_mux_mask & BIT(ep.port)))
>>>> + continue;
>>>> +
>>>> + if (priv->sources[ep.port].fwnode) {
>>>> + dev_err(dev,
>>>> + "Multiple port endpoints are not supported: %d",
>>>> + ep.port);
>>>> +
>>>> + continue;
>>>> + }
>>>> +
>>>> + source = &priv->sources[ep.port];
>>>> + source->fwnode = fwnode_graph_get_remote_endpoint(
>>>> + of_fwnode_handle(node));
>>>> + if (!source->fwnode) {
>>>> + dev_err(dev,
>>>> + "Endpoint %pOF has no remote endpoint connection\n",
>>>> + ep.local_node);
>>>> +
>>>> + continue;
>>>> + }
>>>> +
>>>> + priv->source_mask |= BIT(ep.port);
>>>> + priv->nsources++;
>>>> + }
>>>> + of_node_put(node);
>>>> + of_node_put(dev->of_node);
>>>> +
>>>> + priv->route_mask = priv->source_mask;
>>>> +
>>>> + return 0;
>>>> +}
>>>
>>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx5: make src node name generic
From: Anson Huang @ 2020-05-18 12:54 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1589806460-19592-1-git-send-email-Anson.Huang@nxp.com>
Node name should be generic, use "reset-controller" instead of "src" for
i.MX5 SoCs src nodes.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
- If failed to apply this patch series, try them to be based on
https://patchwork.kernel.org/patch/11541935/ series, I should have
sent them in same series, sorry for that.
---
arch/arm/boot/dts/imx50.dtsi | 2 +-
arch/arm/boot/dts/imx51.dtsi | 2 +-
arch/arm/boot/dts/imx53.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 567dcc5..30726bf 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -333,7 +333,7 @@
status = "disabled";
};
- src: src@53fd0000 {
+ src: reset-controller@53fd0000 {
compatible = "fsl,imx50-src", "fsl,imx51-src";
reg = <0x53fd0000 0x4000>;
interrupts = <75>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 3f1e913..d3583aa 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -439,7 +439,7 @@
status = "disabled";
};
- src: src@73fd0000 {
+ src: reset-controller@73fd0000 {
compatible = "fsl,imx51-src";
reg = <0x73fd0000 0x4000>;
interrupts = <75>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 0d06dbd..afa57bf 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -588,7 +588,7 @@
status = "disabled";
};
- src: src@53fd0000 {
+ src: reset-controller@53fd0000 {
compatible = "fsl,imx53-src", "fsl,imx51-src";
reg = <0x53fd0000 0x4000>;
interrupts = <75>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx50: Add src node interrupt
From: Anson Huang @ 2020-05-18 12:54 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Interrupt is a required property according to SRC binding, add
it for SRC node.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx50.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index d325658..567dcc5 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -336,6 +336,7 @@
src: src@53fd0000 {
compatible = "fsl,imx50-src", "fsl,imx51-src";
reg = <0x53fd0000 0x4000>;
+ interrupts = <75>;
#reset-cells = <1>;
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/7] dt-bindings: mdf: ti,j721e-syscon.yaml: Add J721e system controller
From: Roger Quadros @ 2020-05-18 13:01 UTC (permalink / raw)
To: t-kristo, robh; +Cc: kishon, nm, nsekhar, vigneshr, devicetree, linux-kernel
In-Reply-To: <20200508082937.14171-3-rogerq@ti.com>
Hi Rob,
On 08/05/2020 11:29, Roger Quadros wrote:
> Add DT binding schema for J721e system controller.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
If this can get your Ack it would be great. Thanks!
cheers,
-roger
> ---
> .../bindings/mfd/ti,j721e-syscon.yaml | 69 +++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti,j721e-syscon.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-syscon.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-syscon.yaml
> new file mode 100644
> index 000000000000..e832fb43f884
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-syscon.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,j721e-syscon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI J721e System Controller Registers R/W Device Tree Bindings
> +
> +description: |
> + This represents the Control Module registers (CTRL_MMR0) on the SoC.
> + System controller node represents a register region containing a set
> + of miscellaneous registers. The registers are not cohesive enough to
> + represent as any specific type of device. The typical use-case is
> + for some other node's driver, or platform-specific code, to acquire
> + a reference to the syscon node (e.g. by phandle, node path, or
> + search using a specific compatible value), interrogate the node (or
> + associated OS driver) to determine the location of the registers,
> + and access the registers directly.
> +
> +maintainers:
> + - Kishon Vijay Abraham I <kishon@ti.com>
> + - Roger Quadros <rogerq@ti.com
> +
> +allOf:
> + - $ref: "syscon.yaml#"
> +
> +properties:
> + compatible:
> + anyOf:
> + - items:
> + - enum:
> + - ti,j721e-system-controller
> +
> + - const: syscon
> +
> + - contains:
> + const: syscon
> + additionalItems: true
> +
> +# Optional children
> +
> + "^serdes-ln-ctrl@[0-9a-f]+$":
> + type: object
> + description: |
> + This is the SERDES lane control mux. It should follow the bindings
> + specified in
> + Documentation/devicetree/bindings/mux/reg-mux.txt
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + scm_conf: scm-conf@100000 {
> + compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
> + reg = <0x00100000 0x1c000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + serdes_ln_ctrl: serdes-ln-ctrl@4080 {
> + compatible = "mmio-mux";
> + reg = <0x00004080 0x50>;
> + };
> + };
> +...
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH v2 13/19] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver
From: Mark Brown @ 2020-05-18 13:00 UTC (permalink / raw)
To: Serge Semin
Cc: Andy Shevchenko, Georgy Vlasov, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Rob Herring,
Arnd Bergmann, Allison Randal, Gareth Williams, linux-mips,
devicetree, John Garry, Chuanhong Guo, Joe Perches,
Gregory CLEMENT, Chris Packham, Tomer Maimon, Masahisa Kojima,
Krzysztof Kozlowski, Eddie James, Thomas Gleixner,
Wan Ahmad Zainie, Jarkko Nikula, Chuhong Yuan, Felipe Balbi,
Raymond Tan, wuxu.wu, Clement Leger, linux-spi, linux-kernel
In-Reply-To: <20200518125850.jnhaqlr2ticu3ivs@mobilestation>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Mon, May 18, 2020 at 03:58:50PM +0300, Serge Semin wrote:
> On Sat, May 16, 2020 at 11:17:25PM +0300, Serge Semin wrote:
> > Only if we rename the spi-dw.c to spi-dw-core.c. Such modification will break all
> > the pending patches merging. Mark, are you ok with this?
> Mark, could give me your comment regarding this renaming? Are you ok with this?
Either way is fine for me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds
From: Serge Semin @ 2020-05-18 12:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Mark Brown, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Arnd Bergmann, Allison Randal,
Gareth Williams, Rob Herring, linux-mips, devicetree,
Georgy Vlasov, Ramil Zaripov, Jarkko Nikula, Thomas Gleixner,
Wan Ahmad Zainie, Linus Walleij, Clement Leger, linux-spi,
linux-kernel
In-Reply-To: <20200518110343.GY1634618@smile.fi.intel.com>
On Mon, May 18, 2020 at 02:03:43PM +0300, Andy Shevchenko wrote:
> On Sat, May 16, 2020 at 11:01:33PM +0300, Serge Semin wrote:
> > On Fri, May 15, 2020 at 05:38:42PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote:
> > > > Each channel of DMA controller may have a limited length of burst
> > > > transaction (number of IO operations performed at ones in a single
> > > > DMA client request). This parameter can be used to setup the most
> > > > optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer
> > > > overrun we can set the DMA Tx level to be of FIFO depth minus the
> > > > maximum burst transactions length. To prevent the Rx buffer underflow
> > > > the DMA Rx level should be set to the maximum burst transactions length.
> > > > This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels
> > > > in accordance with these rules.
>
> ...
>
> > > > /* DMA info */
> > > > struct dma_chan *txchan;
> > > > + u32 txburst;
> > > > struct dma_chan *rxchan;
> > > > + u32 rxburst;
> > >
> > > Leave u32 together, it may be optimal on 64-bit architectures where ABIs require padding.
> >
> > It's not like anyone cared about padding in this structure in the first place)
>
> I think I have been caring (to some extend).
Well, If you have then instead of asking to rearrange just two members (which
by the way finely grouped by the Tx-Rx affiliation) why not sending a
patch, which would refactor the whole structure so to be optimal for the x64
platforms? I don't really see why this gets very important for you seeing
Mark is Ok with this. My current commit follows the common driver design
including the DW SSI data members grouping. On the second thought I'll leave
it as is then.
-Sergey
>
> > Though if v3 is required I'll group these members together.
>
> From what I see v3 is what Mark and me are waiting for. Mark, are we on the
> same page here?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [PATCH] ARM: dts: imx: make src node name generic
From: Anson Huang @ 2020-05-18 12:39 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Node name should be generic, use "reset-controller" instead of "src" for
i.MX6/i.MX7 SoCs src nodes.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sl.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 2 +-
arch/arm/boot/dts/imx7s.dtsi | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1763c2b..39d4afd 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -858,7 +858,7 @@
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
};
- src: src@20d8000 {
+ src: reset-controller@20d8000 {
compatible = "fsl,imx6q-src", "fsl,imx51-src";
reg = <0x020d8000 0x4000>;
interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index fcb84fe..911d8cf 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -678,7 +678,7 @@
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
};
- src: src@20d8000 {
+ src: reset-controller@20d8000 {
compatible = "fsl,imx6sl-src", "fsl,imx51-src";
reg = <0x020d8000 0x4000>;
interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index d6f8317..e031337 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -754,7 +754,7 @@
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
};
- src: src@20d8000 {
+ src: reset-controller@20d8000 {
compatible = "fsl,imx6sx-src", "fsl,imx51-src";
reg = <0x020d8000 0x4000>;
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 2ccf67c..35e7301 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -676,7 +676,7 @@
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
};
- src: src@20d8000 {
+ src: reset-controller@20d8000 {
compatible = "fsl,imx6ul-src", "fsl,imx51-src";
reg = <0x020d8000 0x4000>;
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 76e3ffb..8bac491 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -624,7 +624,7 @@
clock-names = "ckil", "osc";
};
- src: src@30390000 {
+ src: reset-controller@30390000 {
compatible = "fsl,imx7d-src", "syscon";
reg = <0x30390000 0x10000>;
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds
From: Mark Brown @ 2020-05-18 12:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Arnd Bergmann, Allison Randal,
Gareth Williams, Rob Herring, linux-mips, devicetree,
Georgy Vlasov, Ramil Zaripov, Jarkko Nikula, Thomas Gleixner,
Wan Ahmad Zainie, Linus Walleij, Clement Leger, linux-spi,
linux-kernel
In-Reply-To: <20200518110343.GY1634618@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
On Mon, May 18, 2020 at 02:03:43PM +0300, Andy Shevchenko wrote:
> On Sat, May 16, 2020 at 11:01:33PM +0300, Serge Semin wrote:
> > Though if v3 is required I'll group these members together.
> From what I see v3 is what Mark and me are waiting for. Mark, are we on the
> same page here?
I loose track of what's going on with this specific patch, sorry - it's
patch 10 in the series so there's a good chance it has dependencies on
some of the earlier changes anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH v8 0/3] Add Intel ComboPhy driver
From: Vinod Koul @ 2020-05-18 12:41 UTC (permalink / raw)
To: Dilip Kota
Cc: linux-kernel, kishon, devicetree, robh, andriy.shevchenko,
cheol.yong.kim, chuanhua.lei, qi-ming.wu, yixin.zhu
In-Reply-To: <cover.1589530082.git.eswara.kota@linux.intel.com>
On 15-05-20, 16:13, Dilip Kota wrote:
> This patch series adds Intel ComboPhy driver, respective yaml schemas
>
> Changes on v8:
> As per PHY Maintainer's request add description in comments for doing
> register access through register map framework.
>
> Changes on v7:
> As per System control driver maintainer's inputs remove
> fwnode_to_regmap() definition and use device_node_get_regmap()
>
> Changes on v6:
> Rebase patches on the latest maintainer's branch
> https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git/?h=phy-for-5.7
Acked-By: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 09/19] spi: dw: Parameterize the DMA Rx/Tx burst length
From: Serge Semin @ 2020-05-18 12:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Mark Brown, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Thomas Gleixner, Wan Ahmad Zainie,
Jarkko Nikula, linux-spi, linux-kernel
In-Reply-To: <20200518110150.GX1634618@smile.fi.intel.com>
On Mon, May 18, 2020 at 02:01:50PM +0300, Andy Shevchenko wrote:
> On Sat, May 16, 2020 at 05:33:53PM +0300, Serge Semin wrote:
> > On Fri, May 15, 2020 at 05:01:29PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 15, 2020 at 01:47:48PM +0300, Serge Semin wrote:
> > > > It isn't good to have numeric literals in the code especially if there
> > > > are multiple of them and they are related. Moreover in current
> > > > implementation the Tx DMA transfer activation level isn't optimal,
> > > > since it's hardwired to be at 16-32 bytes level, while it's better
> > > > to keep the SPI FIFO buffer as full as possible until all available
> > > > data is submitted. So lets introduce the DMA burst level
> > > > parametrization macros with optimal values - issue Rx transfer if at
> > > > least 16 bytes are available in the buffer and execute Tx transaction
> > > > if at least 16 bytes room is opened in SPI Tx FIFO.
> > >
> > > > - dw_writel(dws, DW_SPI_DMARDLR, 0xf);
> > > > - dw_writel(dws, DW_SPI_DMATDLR, 0x10);
> > > > + dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
> > > > + dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - TX_BURST_LEVEL);
> > >
> > > ...and if FIFO length is less than TX_BURST_LEVEL?
> > >
> > > For the patch that introduces definitions, i.e. keeping the last line here as
> > >
> > > dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
> > >
> > > I'm good. You may put your tag in that case. For fifo_len case we need to
> > > discuss in separate patch, perhaps.
> >
> > It's fixed in a consequent patch anyway. Though if v3 is required I'll remove
> > this change from here.
>
> I consider that here you might have introduced a regression and actually doing
> two things in one patch. Why not to split?
Theoretically I could, but only for a hardware with FIFO smaller than 16 bytes.
So did I, seeing this module has been dedicated for the Intel Medfield/Elkhart chips
only?
Anyway as I said this change is mostly redundant, since further in this patchset I'll
replace the constants used here with burst length properly calculated based on the
fifo-length and max-burst-length specific to the DMA.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
From: Jacopo Mondi @ 2020-05-18 12:38 UTC (permalink / raw)
To: Kieran Bingham
Cc: Sakari Ailus, linux-renesas-soc, linux-media, devicetree,
linux-kernel, Mauro Carvalho Chehab, Kieran Bingham,
Laurent Pinchart, Niklas Söderlund, Hans Verkuil, Hyun Kwon,
Manivannan Sadhasivam, Rob Herring, Jacopo Mondi,
Laurent Pinchart, Niklas Söderlund
In-Reply-To: <930009cd-d887-752a-4f1f-567c795101ee@ideasonboard.com>
Hi Kieran, Sakari
On Mon, May 18, 2020 at 12:45:18PM +0100, Kieran Bingham wrote:
> Hi Sakari,
>
> There are only fairly minor comments here, fix ups will be included in a
> v10.
>
> Is there anything major blocking integration?
>
> Regards
>
> Kieran
>
>
>
> On 16/05/2020 22:51, Sakari Ailus wrote:
> > Hi Kieran,
> >
> > Thanks for the update.
> >
> > On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
> >
> > ...
> >
> >> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + struct v4l2_subdev_mbus_code_enum *code)
> >> +{
> >> + if (code->pad || code->index > 0)
> >> + return -EINVAL;
> >> +
> >> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;
> >
> > Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
> > variant of the format is generally used on the serial busses. This choice
> > was made when serial busses were introduced.
>
> Ok - I presume this doesn't really have much effect anyway, they just
> have to match for the transmitter/receiver?
>
> But it makes sense to me, so I'll update to the 1x16 variant.
>
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static struct v4l2_mbus_framefmt *
> >> +max9286_get_pad_format(struct max9286_priv *priv,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + unsigned int pad, u32 which)
> >> +{
> >> + switch (which) {
> >> + case V4L2_SUBDEV_FORMAT_TRY:
> >> + return v4l2_subdev_get_try_format(&priv->sd, cfg, pad);
> >> + case V4L2_SUBDEV_FORMAT_ACTIVE:
> >> + return &priv->fmt[pad];
> >> + default:
> >> + return NULL;
> >> + }
> >> +}
> >> +
> >> +static int max9286_set_fmt(struct v4l2_subdev *sd,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + struct v4l2_subdev_format *format)
> >> +{
> >> + struct max9286_priv *priv = sd_to_max9286(sd);
> >> + struct v4l2_mbus_framefmt *cfg_fmt;
> >> +
> >> + if (format->pad >= MAX9286_SRC_PAD)
> >> + return -EINVAL;
> >
> > You can remove these checks; it's been already done by the caller.
> >
>
> Ok.
>
I think this shold be kept. The core validates that the pad number is
valid, but we're here checking that set_fmt has been called on a sink
pad [0-3], returning -EINVAL if set_fmt (and get_ftm as well) are
called on the source one.
My question now is how does link validation work, if get_fmt() is not
allowed on the source pad :/ ? Anyway, I would keep this check for
set_fmt (maybe make it an == to address Sakari's comment).
Thanks
j
>
> > ...
> >
> >> +static int max9286_parse_dt(struct max9286_priv *priv)
> >> +{
> >> + struct device *dev = &priv->client->dev;
> >> + struct device_node *i2c_mux;
> >> + struct device_node *node = NULL;
> >> + unsigned int i2c_mux_mask = 0;
> >> +
> >> + of_node_get(dev->of_node);
> >> + i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
> >> + if (!i2c_mux) {
> >> + dev_err(dev, "Failed to find i2c-mux node\n");
> >> + of_node_put(dev->of_node);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + /* Identify which i2c-mux channels are enabled */
> >> + for_each_child_of_node(i2c_mux, node) {
> >> + u32 id = 0;
> >> +
> >> + of_property_read_u32(node, "reg", &id);
> >> + if (id >= MAX9286_NUM_GMSL)
> >> + continue;
> >> +
> >> + if (!of_device_is_available(node)) {
> >> + dev_dbg(dev, "Skipping disabled I2C bus port %u\n", id);
> >> + continue;
> >> + }
> >> +
> >> + i2c_mux_mask |= BIT(id);
> >> + }
> >> + of_node_put(node);
> >> + of_node_put(i2c_mux);
> >> +
> >> + /* Parse the endpoints */
> >> + for_each_endpoint_of_node(dev->of_node, node) {
> >> + struct max9286_source *source;
> >> + struct of_endpoint ep;
> >> +
> >> + of_graph_parse_endpoint(node, &ep);
> >> + dev_dbg(dev, "Endpoint %pOF on port %d",
> >> + ep.local_node, ep.port);
> >> +
> >> + if (ep.port > MAX9286_NUM_GMSL) {
> >> + dev_err(dev, "Invalid endpoint %s on port %d",
> >> + of_node_full_name(ep.local_node), ep.port);
> >> + continue;
> >> + }
> >> +
> >> + /* For the source endpoint just parse the bus configuration. */
> >> + if (ep.port == MAX9286_SRC_PAD) {
> >> + struct v4l2_fwnode_endpoint vep = {
> >> + .bus_type = V4L2_MBUS_CSI2_DPHY
> >> + };
> >> + int ret;
> >> +
> >> + ret = v4l2_fwnode_endpoint_parse(
> >> + of_fwnode_handle(node), &vep);
> >> + if (ret) {
> >> + of_node_put(node);
> >> + of_node_put(dev->of_node);
> >> + return ret;
> >> + }
> >> +
> >> + if (vep.bus_type != V4L2_MBUS_CSI2_DPHY) {
> >
> > This won't happen, the bus type will stay if you set it to a non-zero
> > value.
>
>
> Ok - I'll remove this check.
>
>
> >
> >> + dev_err(dev,
> >> + "Media bus %u type not supported\n",
> >> + vep.bus_type);
> >> + v4l2_fwnode_endpoint_free(&vep);
> >> + of_node_put(node);
> >> + of_node_put(dev->of_node);
> >> + return -EINVAL;
> >> + }
> >> +
> >> + priv->csi2_data_lanes =
> >> + vep.bus.mipi_csi2.num_data_lanes;
> >> + v4l2_fwnode_endpoint_free(&vep);
> >
> > No need to call this unless you use v4l2_fwnode_endpoint_alloc_parse().
> >
> > And as you don't, you also won't know which frequencies are known to be
> > safe to use. That said, perhaps where this device is used having a random
> > frequency on that bus could not be an issue. Perhaps.
>
> Does this generate a range? or a list of static supported frequencies?
>
> We configure the pixel clock based upon the number of cameras connected,
> and their pixel rates etc ...
>
> Are you saying that the frequency of this clock should be validated to
> be a specific range? or are you talking about a different frequency?
>
>
> For now I'll remove the v4l2_fwnode_endpoint_alloc_parse().
>
>
>
> >> +
> >> + continue;
> >> + }
> >> +
> >> + /* Skip if the corresponding GMSL link is unavailable. */
> >> + if (!(i2c_mux_mask & BIT(ep.port)))
> >> + continue;
> >> +
> >> + if (priv->sources[ep.port].fwnode) {
> >> + dev_err(dev,
> >> + "Multiple port endpoints are not supported: %d",
> >> + ep.port);
> >> +
> >> + continue;
> >> + }
> >> +
> >> + source = &priv->sources[ep.port];
> >> + source->fwnode = fwnode_graph_get_remote_endpoint(
> >> + of_fwnode_handle(node));
> >> + if (!source->fwnode) {
> >> + dev_err(dev,
> >> + "Endpoint %pOF has no remote endpoint connection\n",
> >> + ep.local_node);
> >> +
> >> + continue;
> >> + }
> >> +
> >> + priv->source_mask |= BIT(ep.port);
> >> + priv->nsources++;
> >> + }
> >> + of_node_put(node);
> >> + of_node_put(dev->of_node);
> >> +
> >> + priv->route_mask = priv->source_mask;
> >> +
> >> + return 0;
> >> +}
> >
>
^ permalink raw reply
* Re: [PATCH] arm: dts: am33xx-bone-common: add gpio-line-names
From: Felipe Balbi @ 2020-05-18 12:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Drew Fustini, Grygorii Strashko, Benoît Cousson,
Tony Lindgren, Rob Herring, Linux-OMAP,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jason Kridner, Robert Nelson
In-Reply-To: <CACRpkdZnnRXwv0-71t93HX42jL-muty4yJx5gW6_P3yOM-sGAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
Linus Walleij <linus.walleij@linaro.org> writes:
> On Mon, May 18, 2020 at 10:18 AM Felipe Balbi <balbi@kernel.org> wrote:
>> Linus Walleij <linus.walleij@linaro.org> writes:
>> >> gpiochip0 - 32 lines:
>> >> line 0: "ethernet" unused input active-high
>> >> line 1: "ethernet" unused input active-high
>> >
>> > Why are the ethernet lines not tagged with respective signal name
>> > when right below the SPI lines are explicitly tagged with
>> > sclk, cs0 etc?
>> >
>> > Ethernet is usually RGMII and has signal names like
>> > tx_clk, tx_d0, tx_en etc.
>> >
>> > Also some lines seem to be tagged with the pin number
>> > like P9_22, P2_21 below, it seems a bit inconsistent
>> > to have much information on some pins and very sketchy
>> > information on some.
>>
>> the pin names match the beagle bone documentation and would help users
>> figure out which pins on the expansion headers match to a gpio signal.
>
> OK if it is how it looks in the documentation I agree that is what
> users need, maybe the documentation is confusing but there is not
> much to do about that.
the board has two expansion headers, P1 and P2:
https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#531_Expansion_Headers
Pins are always the pin number on the header, hence P2_21 and P1_10 and
so on.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/4] dt-bindings: phy: add r8a77961 support
From: Kishon Vijay Abraham I @ 2020-05-18 12:29 UTC (permalink / raw)
To: Yoshihiro Shimoda, robh+dt@kernel.org
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Vinod Koul
In-Reply-To: <TY2PR01MB3692334705CC2191432F3178D8BC0@TY2PR01MB3692.jpnprd01.prod.outlook.com>
On 5/14/2020 2:56 PM, Yoshihiro Shimoda wrote:
> Hi Kishon,
>
>> From: Yoshihiro Shimoda, Sent: Friday, March 27, 2020 6:34 PM
>>
>> This patch adds USBPHY 2.0/3.0 devices support for r8a77961
>> (R-Car M3-W+).
>
> Would you apply this patch series to your repository?
> Or, should I resend?
>
> JFYI:
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=262633
merged them now, thanks!
-Kishon
>
> Best regards,
> Yoshihiro Shimoda
>
>> Changes from v3:
>> - Retain a description of #phy-cell in patch 1/4.
>> - Add Reviewed-by in patch 1/4 and 3/4.
>> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=262507
>>
>> Changes from v2:
>> - Modify json-schema files which Geert-san was pointed out.
>> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=261847
>>
>> Changes from v1:
>> - Rebase these patches on top of my patches of convert bindings to
>> json-schema.
>> - Add Reviewed-by.
>> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=261195
>>
>> Yoshihiro Shimoda (4):
>> dt-bindings: phy: renesas: usb2-phy: convert bindings to json-schema
>> dt-bindings: phy: renesas: usb2-phy: add r8a77961 support
>> dt-bindings: phy: renesas: usb3-phy: convert bindings to json-schema
>> dt-bindings: phy: renesas: usb3-phy: add r8a77961 support
>>
>> .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 70 ------------
>> .../devicetree/bindings/phy/rcar-gen3-phy-usb3.txt | 52 ---------
>> .../devicetree/bindings/phy/renesas,usb2-phy.yaml | 117 +++++++++++++++++++++
>> .../devicetree/bindings/phy/renesas,usb3-phy.yaml | 79 ++++++++++++++
>> 4 files changed, 196 insertions(+), 122 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
>> delete mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
>> create mode 100644 Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
>> create mode 100644 Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml
>>
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 17/17] ARM: dts: r8a7742: Add RWDT node
From: Lad, Prabhakar @ 2020-05-18 12:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lad Prabhakar, Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List
In-Reply-To: <CAMuHMdVV+2HsgmBytCOFg4pri4XinT_SPWT_Ac6n7FMZN3dR3w@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Mon, May 18, 2020 at 12:47 PM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
> <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > Add a device node for the Watchdog Timer (RWDT) controller on the Renesas
> > RZ/G1H (r8a7742) SoC.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm/boot/dts/r8a7742.dtsi
> > +++ b/arch/arm/boot/dts/r8a7742.dtsi
> > @@ -201,6 +201,16 @@
> > #size-cells = <2>;
> > ranges;
> >
> > + rwdt: watchdog@e6020000 {
> > + compatible = "renesas,r8a7742-wdt",
> > + "renesas,rcar-gen2-wdt";
> > + reg = <0 0xe6020000 0 0x0c>;
> > + clocks = <&cpg CPG_MOD 402>;
> > + power-domains = <&sysc R8A7742_PD_ALWAYS_ON>;
> > + resets = <&cpg 402>;
> > + status = "disabled";
>
> Missing "interrupts" property.
>
"interrupts" property isn't used by rwdt driver and can be dropped
from bindings file.
Cheers,
--Prabhakar
> > + };
> > +
> > gpio0: gpio@e6050000 {
> > compatible = "renesas,gpio-r8a7742",
> > "renesas,rcar-gen2-gpio";
>
> The rest looks fine, so with the above fixed:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V3 5/8] phy: tegra: xusb: Add soc ops API to enable UTMI PAD protection
From: Kishon Vijay Abraham I @ 2020-05-18 12:24 UTC (permalink / raw)
To: Nagarjuna Kristam, balbi, gregkh, thierry.reding, jonathanh,
mark.rutland, robh+dt
Cc: devicetree, linux-tegra, linux-usb, linux-kernel
In-Reply-To: <1589437363-16727-6-git-send-email-nkristam@nvidia.com>
Thierry,
On 5/14/2020 11:52 AM, Nagarjuna Kristam wrote:
> When USB charger is enabled, UTMI PAD needs to be protected according
> to the direction and current level. Add support for the same on Tegra210
> and Tegra186.
>
> Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Can you give your Acked by for pending patches in this series?
Thanks
Kishon
> ---
> V3:
> - Alligned function and its arguments.
> - Fixed other comments from Thierry.
> ---
> V2:
> - Commit message coorected.
> - Patch re-based.
> ---
> drivers/phy/tegra/xusb-tegra186.c | 40 +++++++++++++++++++++++++++++++++++++++
> drivers/phy/tegra/xusb-tegra210.c | 32 +++++++++++++++++++++++++++++++
> drivers/phy/tegra/xusb.h | 13 +++++++++++++
> 3 files changed, 85 insertions(+)
>
> diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
> index f862254..59b78a7 100644
> --- a/drivers/phy/tegra/xusb-tegra186.c
> +++ b/drivers/phy/tegra/xusb-tegra186.c
> @@ -68,6 +68,13 @@
> #define PORTX_SPEED_SUPPORT_MASK (0x3)
> #define PORT_SPEED_SUPPORT_GEN1 (0x0)
>
> +#define USB2_BATTERY_CHRG_OTGPADX_CTL1(x) (0x84 + (x) * 0x40)
> +#define PD_VREG (1 << 6)
> +#define VREG_LEV(x) (((x) & 0x3) << 7)
> +#define VREG_DIR(x) (((x) & 0x3) << 11)
> +#define VREG_DIR_IN VREG_DIR(1)
> +#define VREG_DIR_OUT VREG_DIR(2)
> +
> #define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x88 + (x) * 0x40)
> #define HS_CURR_LEVEL(x) ((x) & 0x3f)
> #define TERM_SEL BIT(25)
> @@ -289,6 +296,37 @@ static void tegra_phy_xusb_utmi_pad_power_down(struct phy *phy)
> usb2->powered_on = false;
> }
>
> +static void
> +tegra186_xusb_padctl_utmi_pad_set_protection(struct tegra_xusb_port *port,
> + int level,
> + enum tegra_vbus_dir dir)
> +{
> + u32 value;
> + struct tegra_xusb_padctl *padctl = port->padctl;
> + unsigned int index = port->index;
> +
> + value = padctl_readl(padctl, USB2_BATTERY_CHRG_OTGPADX_CTL1(index));
> +
> + if (level < 0) {
> + /* disable pad protection */
> + value |= PD_VREG;
> + value &= ~VREG_LEV(~0);
> + value &= ~VREG_DIR(~0);
> + } else {
> + if (dir == TEGRA_VBUS_SOURCE)
> + value |= VREG_DIR_OUT;
> + else if (dir == TEGRA_VBUS_SINK)
> + value |= VREG_DIR_IN;
> +
> + value &= ~PD_VREG;
> + value &= ~VREG_DIR(~0);
> + value &= ~VREG_LEV(~0);
> + value |= VREG_LEV(level);
> + }
> +
> + padctl_writel(padctl, value, USB2_BATTERY_CHRG_OTGPADX_CTL1(index));
> +}
> +
> static int tegra186_xusb_padctl_vbus_override(struct tegra_xusb_padctl *padctl,
> bool status)
> {
> @@ -935,6 +973,8 @@ static const struct tegra_xusb_padctl_ops tegra186_xusb_padctl_ops = {
> .vbus_override = tegra186_xusb_padctl_vbus_override,
> .utmi_pad_power_on = tegra_phy_xusb_utmi_pad_power_on,
> .utmi_pad_power_down = tegra_phy_xusb_utmi_pad_power_down,
> + .utmi_pad_set_protection =
> + tegra186_xusb_padctl_utmi_pad_set_protection,
> };
>
> #if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
> diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/xusb-tegra210.c
> index caf0890..80c4349 100644
> --- a/drivers/phy/tegra/xusb-tegra210.c
> +++ b/drivers/phy/tegra/xusb-tegra210.c
> @@ -74,6 +74,8 @@
> #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_MASK 0x3
> #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_VAL 0x1
> #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18 (1 << 6)
> +#define USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV(x) (((x) & 0x3) << 7)
> +#define USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_DIR(x) (((x) & 0x3) << 11)
>
> #define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x088 + (x) * 0x40)
> #define XUSB_PADCTL_USB2_OTG_PAD_CTL0_PD_ZI (1 << 29)
> @@ -1116,6 +1118,34 @@ void tegra210_usb2_pad_power_down(struct phy *phy)
> usb2->powered_on = false;
> }
>
> +static void
> +tegra210_xusb_padctl_utmi_pad_set_protection(struct tegra_xusb_port *port,
> + int level,
> + enum tegra_vbus_dir dir)
> +{
> + u32 value;
> + struct tegra_xusb_padctl *padctl = port->padctl;
> + unsigned int index = port->index;
> +
> + value = padctl_readl(padctl,
> + XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(index));
> +
> + if (level < 0) {
> + /* disable pad protection */
> + value |= XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18;
> + value &= USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV(~0);
> + value &= ~USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_DIR(~0);
> + } else {
> + value &= ~XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18;
> + value &= ~USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_DIR(~0);
> + value &= USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV(~0);
> + value |= USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV(level);
> + }
> +
> + padctl_writel(padctl, value,
> + XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(index));
> +}
> +
> static int tegra210_usb2_phy_set_mode(struct phy *phy, enum phy_mode mode,
> int submode)
> {
> @@ -2291,6 +2321,8 @@ static const struct tegra_xusb_padctl_ops tegra210_xusb_padctl_ops = {
> .utmi_port_reset = tegra210_utmi_port_reset,
> .utmi_pad_power_on = tegra210_usb2_pad_power_on,
> .utmi_pad_power_down = tegra210_usb2_pad_power_down,
> + .utmi_pad_set_protection =
> + tegra210_xusb_padctl_utmi_pad_set_protection,
> };
>
> static const char * const tegra210_xusb_padctl_supply_names[] = {
> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> index 6995fc4..475bcc6 100644
> --- a/drivers/phy/tegra/xusb.h
> +++ b/drivers/phy/tegra/xusb.h
> @@ -259,6 +259,17 @@ to_sata_pad(struct tegra_xusb_pad *pad)
> */
> struct tegra_xusb_port_ops;
>
> +/*
> + * Tegra OTG port VBUS direction:
> + * default (based on port capability) or
> + * as source or sink
> + */
> +enum tegra_vbus_dir {
> + TEGRA_VBUS_DEFAULT,
> + TEGRA_VBUS_SOURCE,
> + TEGRA_VBUS_SINK
> +};
> +
> struct tegra_xusb_port {
> struct tegra_xusb_padctl *padctl;
> struct tegra_xusb_lane *lane;
> @@ -398,6 +409,8 @@ struct tegra_xusb_padctl_ops {
> int (*utmi_port_reset)(struct phy *phy);
> void (*utmi_pad_power_on)(struct phy *phy);
> void (*utmi_pad_power_down)(struct phy *phy);
> + void (*utmi_pad_set_protection)(struct tegra_xusb_port *port,
> + int level, enum tegra_vbus_dir dir);
> };
>
> struct tegra_xusb_padctl_soc {
>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sc7180: Correct the pdc interrupt ranges
From: Maulik Shah @ 2020-05-18 12:20 UTC (permalink / raw)
To: agross, bjorn.andersson
Cc: linux-arm-msm, linux-kernel, rnayak, ilina, lsrao, mka, swboyd,
evgreen, dianders, Maulik Shah, devicetree
Few PDC interrupts do not map to respective parent GIC interrupt.
Fix this by correcting the pdc interrupt map.
Fixes: 22f185ee81d2 ("arm64: dts: qcom: sc7180: Add pdc interrupt controller")
Cc: devicetree@vger.kernel.org
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index f1280e0..f6b4ee8 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2308,8 +2308,7 @@
pdc: interrupt-controller@b220000 {
compatible = "qcom,sc7180-pdc", "qcom,pdc";
reg = <0 0x0b220000 0 0x30000>;
- qcom,pdc-ranges = <0 480 15>, <17 497 98>,
- <119 634 4>, <124 639 1>;
+ qcom,pdc-ranges = <0 480 94>, <94 609 31>, <125 63 1>;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupt-controller;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH v3 0/1] net: ethernet: stmmac: simplify phy modes management for stm32
From: Christophe ROULLIER @ 2020-05-18 12:02 UTC (permalink / raw)
To: robh@kernel.org, davem@davemloft.net, joabreu@synopsys.com,
mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
Peppe CAVALLARO
Cc: linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
andrew@lunn.ch
In-Reply-To: <20200427100038.19252-1-christophe.roullier@st.com>
Hi,
Just a "gentleman ping"
Regards,
Christophe.
On 27/04/2020 12:00, Christophe Roullier wrote:
> No new feature, just to simplify stm32 part to be easier to use.
> Add by default all Ethernet clocks in DT, and activate or not in function
> of phy mode, clock frequency, if property "st,ext-phyclk" is set or not.
> Keep backward compatibility
>
> version 3:
> Add acked from Alexandre Torgue
> Rebased on top of v5.7-rc2
>
> Christophe Roullier (1):
> net: ethernet: stmmac: simplify phy modes management for stm32
>
> .../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 74 +++++++++++--------
> 1 file changed, 44 insertions(+), 30 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v7 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Arnd Bergmann @ 2020-05-18 11:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ramuthevar, Vadivel MuruganX, kbuild test robot,
Linux Kernel Mailing List, open list:MEMORY TECHNOLOGY...,
devicetree, kbuild-all, Miquel Raynal, Richard Weinberger,
Vignesh R, Brendan Higgins, Thomas Gleixner, Boris Brezillon,
Anders Roxell, masonccyang
In-Reply-To: <CAHp75Ve_XjvvGBEQyhy=qVVJMFS+18j3aKxNxSQpGK5qJmzfBg@mail.gmail.com>
On Mon, May 18, 2020 at 1:43 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, May 18, 2020 at 2:39 PM Ramuthevar, Vadivel MuruganX
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> > On 15/5/2020 10:30 pm, Arnd Bergmann wrote:
> > > On Fri, May 15, 2020 at 4:25 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > >> On Fri, May 15, 2020 at 4:48 PM kbuild test robot <lkp@intel.com> wrote:
>
> > > iowrite_be32() is the correct way to store word into a big-endian mmio register,
> > > if that is the intention here.
> > Thank you for suggestions to use iowrite32be(), it suits exactly.
>
> Can you before doing this comment what is the real intention here?
>
> And note, if you are going to use iowrite*() / ioread*() in one place,
> you will probably need to replace all of the read*() / write*() to
> respective io* API.
The way that ioread/iowrite are defined, they are required to be a superset
of what readl/writel do and can take __iomem pointers from either
ioremap() or ioport_map()/pci_iomap() style mappings, while readl/writel
are only required to work with ioremap().
There is no technical requirement to stick to one set or the other for
ioremap(), but the overhead of ioread/iowrite is also small enough
that it generally does not hurt.
Arnd
^ permalink raw reply
* Re: [PATCH 13/17] ARM: dts: r8a7742: Add Ether support
From: Geert Uytterhoeven @ 2020-05-18 11:53 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-14-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Define the generic R8A7742 part of the Ether device node.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 12/17] ARM: dts: r8a7742: Add Ethernet AVB support
From: Geert Uytterhoeven @ 2020-05-18 11:53 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Jens Axboe, Rob Herring, Wolfram Sang, Ulf Hansson,
Sergei Shtylyov, David S. Miller, Wim Van Sebroeck, Guenter Roeck,
linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux I2C, Linux MMC List, netdev,
Linux-Renesas, Linux Watchdog Mailing List, Prabhakar
In-Reply-To: <1589555337-5498-13-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 5:10 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add Ethernet AVB support for R8A7742 SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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