Devicetree
 help / color / mirror / Atom feed
* Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
From: Philippe CORNU @ 2020-05-29 15:45 UTC (permalink / raw)
  To: Adrian Ratiu, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	Laurent Pinchart
  Cc: Jernej Skrabec, Heiko Stuebner, Adrian Pop, Jonas Karlman,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda, linux-imx@nxp.com, kernel@collabora.com,
	linux-stm32@st-md-mailman.stormreply.com, Arnaud Ferraris,
	Yannick FERTRE, Benjamin GAIGNARD
In-Reply-To: <20200427081952.3536741-9-adrian.ratiu@collabora.com>

Hi Adrian,
and thank you very much for the patchset.
Thank you also for having tested it on STM32F769 and STM32MP1.
Sorry for the late response, Yannick and I will review it as soon as 
possible and we will keep you posted.
Note: Do not hesitate to put us in copy for the next version 
(philippe.cornu@st.com, yannick.fertre@st.com)
Regards,
Philippe :-)


On 4/27/20 10:19 AM, Adrian Ratiu wrote:
> The stm mipi-dsi platform driver added a version test in
> commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
> so that HW revisions other than v1.3x get rejected. The rockchip
> driver had no such check and just assumed register layouts are
> v1.3x compatible.
> 
> Having such tests was a good idea because only v130/v131 layouts
> were supported at the time, however since adding multiple layout
> support in the bridge, the version is automatically checked for
> all drivers, compatible layouts get picked and unsupported HW is
> automatically rejected by the bridge, so there's no use keeping
> the test in the stm driver.
> 
> The main reason prompting this change is that the stm driver
> test immediately disabled the peripheral clock after reading
> the version, making the bridge read version 0x0 immediately
> after in its own probe(), so we move the clock disabling after
> the bridge does the version test.
> 
> Tested on STM32F769 and STM32MP1.
> 
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Reported-by: Adrian Pop <pop.adrian61@gmail.com>
> Tested-by: Adrian Pop <pop.adrian61@gmail.com>
> Tested-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> New in v6.
> ---
>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +++---------
>   1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 2e1f2664495d0..7218e405d7e2b 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -402,15 +402,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
>   		goto err_dsi_probe;
>   	}
>   
> -	dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> -	clk_disable_unprepare(pclk);
> -
> -	if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
> -		ret = -ENODEV;
> -		DRM_ERROR("bad dsi hardware version\n");
> -		goto err_dsi_probe;
> -	}
> -
>   	dw_mipi_dsi_stm_plat_data.base = dsi->base;
>   	dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>   
> @@ -423,6 +414,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
>   		goto err_dsi_probe;
>   	}
>   
> +	dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> +	clk_disable_unprepare(pclk);
> +
>   	return 0;
>   
>   err_dsi_probe:
> 

^ permalink raw reply

* Re: [PATCH v5 09/11] dmaengine: dw: Initialize min and max burst DMA device capability
From: Andy Shevchenko @ 2020-05-29 15:48 UTC (permalink / raw)
  To: Serge Semin
  Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
	Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
	linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529144054.4251-10-Sergey.Semin@baikalelectronics.ru>

On Fri, May 29, 2020 at 05:40:52PM +0300, Serge Semin wrote:
> According to the DW APB DMAC data book the minimum burst transaction
> length is 1 and it's true for any version of the controller since
> isn't parametrised in the coreAssembler so can't be changed at the
> IP-core synthesis stage. The maximum burst transaction can vary from
> channel to channel and from controller to controller depending on a
> IP-core parameter the system engineer activated during the IP-core
> synthesis. Let's initialise both min_burst and max_burst members of the
> DMA controller descriptor with extreme values so the DMA clients could
> use them to properly optimize the DMA requests. The channels and
> controller-specific max_burst length initialization will be introduced
> by the follow-up patches.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> 
> ---
> 
> Changelog v4:
> - This is a new patch suggested by Andy.
> 
> Changelog v5:
> - Introduce macro with extreme min and max burst length supported by the
>   DW DMA controller.
> - Initialize max_burst length capability with extreme burst length supported
>   by the DW DMAC IP-core.
> ---
>  drivers/dma/dw/core.c                | 2 ++
>  include/linux/platform_data/dma-dw.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index ceded21537e2..4887aa2fc73c 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1229,6 +1229,8 @@ int do_dma_probe(struct dw_dma_chip *chip)
>  	dw->dma.device_issue_pending = dwc_issue_pending;
>  
>  	/* DMA capabilities */
> +	dw->dma.min_burst = DW_DMA_MIN_BURST;
> +	dw->dma.max_burst = DW_DMA_MAX_BURST;
>  	dw->dma.src_addr_widths = DW_DMA_BUSWIDTHS;
>  	dw->dma.dst_addr_widths = DW_DMA_BUSWIDTHS;
>  	dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
> diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
> index f3eaf9ec00a1..369e41e9dcc9 100644
> --- a/include/linux/platform_data/dma-dw.h
> +++ b/include/linux/platform_data/dma-dw.h
> @@ -12,6 +12,8 @@
>  
>  #define DW_DMA_MAX_NR_MASTERS	4
>  #define DW_DMA_MAX_NR_CHANNELS	8
> +#define DW_DMA_MIN_BURST	1
> +#define DW_DMA_MAX_BURST	256
>  
>  /**
>   * struct dw_dma_slave - Controller-specific information about a slave
> -- 
> 2.26.2
> 

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply

* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Rob Herring @ 2020-05-29 15:54 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: devicetree
In-Reply-To: <20200528132323.30288-1-geert+renesas@glider.be>

On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> When an interrupt controller has an "interrupt-map" property, an "is
> valid under each of" error is triggered.
>
> Fix this by allowing "interrupt-controller" and "interrupt-map" to
> coexist, in both the interrrupts meta-schema and the
> interrupt-controller schema.

But both should not be present. If 'interrupt-controller' is present,
the Linux irq parsing code will ignore 'interrupt-map'. Seems like
that's backwards, but this parsing code is older than dirt and we'd
probably break some 1990s machine changing it.

Rob

^ permalink raw reply

* [PATCHv4 1/2] spi: dw: add reset control
From: Dinh Nguyen @ 2020-05-29 15:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: dinguyen, devicetree, linux-spi, broonie, robh+dt, Sergey.Semin,
	fancer.lancer, andriy.shevchenko, lars.povlsen, liang.j.jin

Add mechanism to get the reset control and deassert it in order to bring
the IP out of reset.

Signed-off-by: Liang Jin J <liang.j.jin@ericsson.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v4: no change
v3: allow for other failures
    remove tab for rstc reset_control
v2: use _get_optional_exclusive
    put IP back into reset if there was an error in probe function
---
 drivers/spi/spi-dw-mmio.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 0894b4c09496..a1b87d4606ba 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -19,6 +19,7 @@
 #include <linux/acpi.h>
 #include <linux/property.h>
 #include <linux/regmap.h>
+#include <linux/reset.h>
 
 #include "spi-dw.h"
 
@@ -29,6 +30,7 @@ struct dw_spi_mmio {
 	struct clk     *clk;
 	struct clk     *pclk;
 	void           *priv;
+	struct reset_control *rstc;
 };
 
 #define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL	0x24
@@ -224,6 +226,14 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
 	if (ret)
 		goto out_clk;
 
+	/* find an optional reset controller */
+	dwsmmio->rstc = devm_reset_control_get_optional_exclusive(&pdev->dev, "spi");
+	if (IS_ERR(dwsmmio->rstc)) {
+		ret = PTR_ERR(dwsmmio->rstc);
+		goto out_clk;
+	}
+	reset_control_deassert(dwsmmio->rstc);
+
 	dws->bus_num = pdev->id;
 
 	dws->max_freq = clk_get_rate(dwsmmio->clk);
@@ -257,6 +267,8 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
 	clk_disable_unprepare(dwsmmio->pclk);
 out_clk:
 	clk_disable_unprepare(dwsmmio->clk);
+	reset_control_assert(dwsmmio->rstc);
+
 	return ret;
 }
 
@@ -268,6 +280,7 @@ static int dw_spi_mmio_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	clk_disable_unprepare(dwsmmio->pclk);
 	clk_disable_unprepare(dwsmmio->clk);
+	reset_control_assert(dwsmmio->rstc);
 
 	return 0;
 }
-- 
2.17.1


^ permalink raw reply related

* [PATCHv4 2/2] dt-bindings: snps,dw-apb-ssi: add optional reset property
From: Dinh Nguyen @ 2020-05-29 15:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: dinguyen, devicetree, linux-spi, broonie, robh+dt, Sergey.Semin,
	fancer.lancer, andriy.shevchenko, lars.povlsen, liang.j.jin
In-Reply-To: <20200529155806.16758-1-dinguyen@kernel.org>

Add optional reset property.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v4: rebased to linux-next 20200529
v3: no change
v2: actually document the "resets" and "reset-names" optional properties
---
 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
index 020e3168ee41..0f21407a7ea3 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
@@ -25,6 +25,9 @@ Optional properties:
   device.  Supported values are 2 or 4 (the default).
 - dmas : Phandle + identifiers of Tx and Rx DMA channels.
 - dma-names : Contains the names of the DMA channels. Must be "tx" and "rx".
+- resets : contains an entry for each entry in reset-names.
+	   See ../reset/reset.txt for details.
+- reset-names : must contain "spi"
 
 Child nodes as per the generic SPI binding.
 
@@ -40,5 +43,7 @@ Example:
 		num-cs = <2>;
 		cs-gpios = <&gpio0 13 0>,
 			   <&gpio0 14 0>;
+		resets = <&rst SPIM0_RST>;
+		reset-names = "spi";
 	};
 
-- 
2.17.1


^ permalink raw reply related

* Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
From: Pavel Machek @ 2020-05-29 16:02 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
	NXP Linux Team, Rob Herring, devicetree, linux-kernel, kernel,
	Ian Ray, Samu Nuutamo
In-Reply-To: <20200529140555.ozlvz4egihkvo3aw@earth.universe>

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hi!

> ping?

Well, I thought that we maybe do not need standard LEDs on medical hardware.

> On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > From: Ian Ray <ian.ray@ge.com>
> > > > 
> > > > Use kernel LED interface for the alarm LEDs.
> > > 
> > > Could we get these changes cced to LED maintainers?
> > 
> > Sorry, you are not turning up via get_maintainer.pl and usually
> > subsystem maintainers are not CC'd for every DT device instance.
> > E.g. I do not want to be always CC'd for DT board file containing
> > a battery/charger. I'm quite surprised you want to be CC'd for
> > them, just looking at ARM DT files there are over 1000 instances
> > of leds.

Well, we have mess in the naming; I'd like to clear it up.

> > > > +		alarm1 {
> > > > +			label = "alarm:red";
> > > > +			gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > +		};
> > > 
> > > So... What is function of these leds, and can we get naming more
> > > consistent with rest of the kernel?
> > 
> > The device is a medical patient monitor and these are alarm LEDs
> > informing about critical device or patient status. They are
> > referenced by their color (those are discrete LEDs, not a
> > multi-color one) basically everywhere. The only exception is
> > "silenced", which means that audible alarm is surpressed. I
> > don't think we have something comparable for any of those LEDs
> > in the mainline tree.

Actually, we have "platform:*:mute" LEDs, that could be used for
"silenced".

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply

* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Geert Uytterhoeven @ 2020-05-29 16:02 UTC (permalink / raw)
  To: Rob Herring; +Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAL_JsqJOPd2txkz298Rs12N+keJNYg2_qjCc-3vDwtL5iNXZmA@mail.gmail.com>

Hi Rob,

On Fri, May 29, 2020 at 5:54 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > When an interrupt controller has an "interrupt-map" property, an "is
> > valid under each of" error is triggered.
> >
> > Fix this by allowing "interrupt-controller" and "interrupt-map" to
> > coexist, in both the interrrupts meta-schema and the
> > interrupt-controller schema.
>
> But both should not be present. If 'interrupt-controller' is present,

Why not?

> the Linux irq parsing code will ignore 'interrupt-map'. Seems like
> that's backwards, but this parsing code is older than dirt and we'd
> probably break some 1990s machine changing it.

That's fine.  rza1_irqc_parse_map() parses the interrupt-map itself,
to map from downstream to upstream interrupts.

Cfr. the original bindings at
https://lore.kernel.org/linux-devicetree/20190502123220.3016-2-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 v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
  To: Rob Herring, chenzhou
  Cc: Thomas Gleixner, Ingo Molnar, Catalin Marinas, Will Deacon,
	dyoung, Baoquan He, Arnd Bergmann, John.p.donnelly, pkushwaha,
	Simon Horman, Hanjun Guo,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree, Linux Doc Mailing List, linux-kernel@vger.kernel.org,
	kexec
In-Reply-To: <20200526211800.GA352001@bogus>

Hi guys,

On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.

>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt

>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.

>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.

>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
> 
> 
> I don't think there's a compatibility issue here though. The current 
> kernel doesn't care if the property is longer than 1 base+size. It only 
> checks if the size is less than 1 base+size.

Aha! I missed that.


> And yes, we can rely on 
> that implementation detail. It's only an ABI if an existing user 
> notices.
> 
> Now, if the low memory is listed first, then an older kdump kernel 
> would get a different memory range. If that's a problem, then define 
> that low memory goes last. 

This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...

I'll try and look at the rest of this series on Monday,


Thanks,

James

^ permalink raw reply

* Re: [PATCH v2 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
From: Rob Herring @ 2020-05-29 16:14 UTC (permalink / raw)
  To: Maxime Chevallier
  Cc: Robin Murphy, Hans Verkuil, devicetree, Heiko Stuebner,
	Paul Kocialkowski, Thomas Petazzoni, linux-rockchip,
	Mauro Carvalho Chehab, Miquel Raynal, Rob Herring, linux-media,
	linux-arm-kernel, Mark Rutland, linux-kernel
In-Reply-To: <20200529130405.929429-2-maxime.chevallier@bootlin.com>

On Fri, 29 May 2020 15:04:03 +0200, Maxime Chevallier wrote:
> Add a documentation for the Rockchip Camera Interface controller
> binding.
> 
> This controller can be found on platforms such as the PX30 or the
> RK3288, the PX30 being the only platform supported so far.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
> 
> Changes since V1
> 
>  - Updated the clock and reset names
>  - Added missing includes in the example, so that the make dt_binding_check passes
> 
>  .../bindings/media/rockchip-cif.yaml          | 100 ++++++++++++++++++
>  1 file changed, 100 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: Additional items are not allowed ('cif_out' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:0: 'aclk' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:1: 'hclkf' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:2: 'pclkin' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: ['aclk_cif', 'hclk_cif', 'pclk_cif', 'cif_out'] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: Additional items are not allowed ([4294967295, 52] was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: [[4294967295, 179], [4294967295, 249], [4294967295, 352], [4294967295, 52]] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:0: 'axi' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:1: 'ahb' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:2: 'pclkin' was expected

See https://patchwork.ozlabs.org/patch/1300680

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.


^ permalink raw reply

* Re: [PATCH v6 4/9] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-29 16:17 UTC (permalink / raw)
  To: dillon.minfei
  Cc: robh+dt, alexandre.torgue, dillonhua, daniel, linux-spi,
	mturquette, linux-clk, sam, mcoquelin.stm32, devicetree,
	linus.walleij, linux-arm-kernel, thierry.reding, sboyd, broonie,
	noralf, airlied, dri-devel, linux-kernel, andy.shevchenko,
	p.zabel, linux-stm32
In-Reply-To: <1590564453-24499-5-git-send-email-dillon.minfei@gmail.com>

On Wed, 27 May 2020 15:27:28 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
> 
> Add documentation for "ilitek,ili9341" panel.
> 
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
>  .../bindings/display/panel/ilitek,ili9341.yaml     | 69 ++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH 1/3] dt-bindings: net: wireless: mt76: add power-limits node
From: Felix Fietkau @ 2020-05-29 16:19 UTC (permalink / raw)
  To: linux-wireless; +Cc: devicetree

This subnode can be used to set per-rate tx power limits either per
country code / regdomain or globally.
These limits are typically provided by the device manufacturers and are
used to limit sideband emissions and stay within regulatory limits

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 .../bindings/net/wireless/mediatek,mt76.txt   | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
index ab7e7a00e534..9d9ace0cfbf9 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
@@ -36,6 +36,7 @@ Optional nodes:
 - led: Properties for a connected LED
   Optional properties:
     - led-sources: See Documentation/devicetree/bindings/leds/common.txt
+- power-limits: contains per-regdomain/channel rate power limit subnodes
 
 &pcie {
 	pcie0 {
@@ -76,3 +77,49 @@ wmac: wmac@18000000 {
 
 	power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
 };
+
+
+Subnodes of power-limits:
+
+Properties:
+- country: One or more country codes, as used by the cfg80211 regdomain code
+- regdomain: "FCC", "ETSI" or "JP"
+
+If neither country, nor regdomain is specified, the power limits node is used
+as a fallback when no other subnode matches.
+
+Subnodes txpower-2g, txpower-5g:
+
+Properties:
+- channels: pairs of first and last channel number
+- cck: 4 half-dBm per-rate power limit values
+- ofdm: 8 half-dBm per-rate power limit values
+- mcs:
+	sets of per-rate power limit values for 802.11n/802.11ac rates for
+	multiple channel bandwidth settings.
+	Each set starts with the number of channel bandwidth settings for
+	which the rate set applies, followed by either 8 (MT7603/MT7628) or
+	10 (all other chips) power limit values.
+	The order of the channel bandwidth settings is: 20, 40, 80, 160 MHz.
+
+
+power-limit example:
+
+power-limits {
+	r0 {
+		regdomain = "FCC";
+		txpower-5g {
+			r1 {
+				channels = <36 48>;
+				ofdm = <23 23 23 23 23 23 23 23>;
+				mcs = <1 23 23 23 23 23 23 23 23 23 23>,
+					  <3 22 22 22 22 22 22 22 22 22 22>;
+			};
+			r2 {
+				channels = <100 181>;
+				ofdm = <14 14 14 14 14 14 14 14>;
+				mcs = <4 14 14 14 14 14 14 14 14 14 14>;
+			};
+		};
+	};
+};
-- 
2.24.0


^ permalink raw reply related

* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-05-29 16:21 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: <20200513140031.25633-1-lars.povlsen@microchip.com>

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.

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

^ permalink raw reply

* Re: [PATCHv1 00/19] Improve SBS battery support
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Sebastian Reichel, Rob Herring, Greg Kroah-Hartman,
	Rafael J . Wysocki, linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-1-sebastian.reichel@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Hi!

> This patchset improves support for SBS compliant batteries. Due to
> the changes, the battery now exposes 32 power supply properties and
> (un)plugging it generates a backtrace containing the following message
> without the first patch in this series:
> 
> ---------------------------
> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> add_uevent_var: too many keys
> ---------------------------
> 
> For references this is what an SBS battery status looks like after
> the patch series has been applied:
> 
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000

Is that correct, BTW? sounds like these should not be equal...

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [PATCH v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
  To: Ondrej Jirman
  Cc: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
	Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
	Linus Walleij, Icenowy Zheng, dri-devel, devicetree, linux-kernel,
	linux-arm-kernel, Samuel Holland, Martijn Braam, Luca Weiss,
	Bhushan Shah
In-Reply-To: <20200513212451.1919013-5-megous@megous.com>

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi!

> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
> 
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.

If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).

One day, it would be nice to have brightness settings in lux, so I
could easily set matching levels on multiple devices, for example...

Best regards,

								Pavel

> +
> +&backlight {
> +	power-supply = <&reg_ldo_io0>;
> +	/*
> +	 * PWM backlight circuit on this PinePhone revision was changed since
> +	 * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> +	 * being off is around 20%. Duty cycle for the lowest brightness level
> +	 * also varries quite a bit between individual boards, so the lowest
> +	 * value here was chosen as a safe default.
> +	 */
> +	brightness-levels = <
> +		774  793  814  842
> +		882  935  1003 1088
> +		1192 1316 1462 1633
> +		1830 2054 2309 2596
> +		2916 3271 3664 4096>;
> +	num-interpolated-steps = <50>;
> +	default-brightness-level = <400>;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Pavel Machek @ 2020-05-29 16:28 UTC (permalink / raw)
  To: Martin Kepplinger
  Cc: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
	mchehab, Anson.Huang, agx, angus, linux-kernel, devicetree,
	linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Hi!

> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
> 
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
> 
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
> 
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>


> +		blue {
> +			label = "phone:blue:front";
> +			label = "phone:green:front";
> +			label = "phone:red:front";

Droid 4 uses "status-led:{red,green,blue}". Could this use same
naming?

> +			label = "lm3560:flash";
> +			label = "lm3560:torch";

This is one LED, right? I'm pretty sure we don't want lm3560 in the
name... "main-camera:flash" would be better. Even better would be
something that's already in use.

> +			label = "white:backlight_cluster";

Make this ":backlight", please. Again, we want something that's
already used.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [RFC v3 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
From: Jack Pham @ 2020-05-29 16:28 UTC (permalink / raw)
  To: Wesley Cheng
  Cc: robh+dt, bjorn.andersson, balbi, gregkh, agross, linux-kernel,
	linux-arm-msm, devicetree, linux-usb
In-Reply-To: <1590630363-3934-2-git-send-email-wcheng@codeaurora.org>

Hi Wesley,

On Wed, May 27, 2020 at 06:46:01PM -0700, Wesley Cheng wrote:
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting.  HW defined TX FIFO sizes may not always be
> sufficient for these compositions.  By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the required FIFO depth to
> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
> a larger TX FIFO size results in better TX throughput.
> 
> Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
> the FIFO logic to prevent running out of FIFO space.
> 
> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
> ---

<snip>

> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 00746c2..9b09528 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -540,6 +540,117 @@ static int dwc3_gadget_start_config(struct dwc3_ep *dep)
>  	return 0;
>  }
>  
> +/*
> + * dwc3_gadget_resize_tx_fifos - reallocate fifo spaces for current use-case
> + * @dwc: pointer to our context structure
> + *
> + * This function will a best effort FIFO allocation in order
> + * to improve FIFO usage and throughput, while still allowing
> + * us to enable as many endpoints as possible.
> + *
> + * Keep in mind that this operation will be highly dependent
> + * on the configured size for RAM1 - which contains TxFifo -,
> + * the amount of endpoints enabled on coreConsultant tool, and
> + * the width of the Master Bus.
> + *
> + * In general, FIFO depths are represented with the following equation:
> + *
> + * fifo_size = mult * ((max_packet + mdwidth)/mdwidth + 1) + 1
> + *
> + * Conversions can be done to the equation to derive the number of packets that
> + * will fit to a particular FIFO size value.
> + */
> +static int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc, struct dwc3_ep *dep)

The 'dep' param should be sufficient; we can just get 'dwc' from
dep->dwc. That will make it more clear this function operates on each
endpoint that needs resizing.

> +{
> +	int ram1_depth, mdwidth, fifo_0_start, tmp, num_in_ep;
> +	int min_depth, remaining, fifo_size, mult = 1, fifo, max_packet = 1024;
> +
> +	if (!dwc->needs_fifo_resize)
> +		return 0;
> +
> +	/* resize IN endpoints except ep0 */
> +	if (!usb_endpoint_dir_in(dep->endpoint.desc) || dep->number <= 1)
> +		return 0;
> +
> +	/* Don't resize already resized IN endpoint */
> +	if (dep->fifo_depth)
> +		return 0;
> +
> +	ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7);
> +	mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
> +	/* MDWIDTH is represented in bits, we need it in bytes */
> +	mdwidth >>= 3;
> +
> +	if (((dep->endpoint.maxburst > 1) &&
> +			usb_endpoint_xfer_bulk(dep->endpoint.desc))
> +			|| usb_endpoint_xfer_isoc(dep->endpoint.desc))
> +		mult = 3;
> +
> +	if ((dep->endpoint.maxburst > 6) &&
> +			usb_endpoint_xfer_bulk(dep->endpoint.desc)
> +			&& dwc3_is_usb31(dwc))
> +		mult = 6;
> +
> +	/* FIFO size for a single buffer */
> +	fifo = (max_packet + mdwidth)/mdwidth;
> +	fifo++;
> +
> +	/* Calculate the number of remaining EPs w/o any FIFO */
> +	num_in_ep = dwc->num_eps/2;
> +	num_in_ep -= dwc->num_ep_resized;
> +	/* Ignore EP0 IN */
> +	num_in_ep--;
> +
> +	/* Reserve at least one FIFO for the number of IN EPs */
> +	min_depth = num_in_ep * (fifo+1);
> +	remaining = ram1_depth - min_depth - dwc->last_fifo_depth;
> +
> +	/* We've already reserved 1 FIFO per EP, so check what we can fit in
> +	 * addition to it.  If there is not enough remaining space, allocate
> +	 * all the remaining space to the EP.
> +	 */
> +	fifo_size = (mult-1) * fifo;
> +	if (remaining < fifo_size) {
> +		if (remaining > 0)
> +			fifo_size = remaining;
> +		else
> +			fifo_size = 0;
> +	}
> +
> +	fifo_size += fifo;
> +	fifo_size++;
> +	dep->fifo_depth = fifo_size;
> +
> +	/* Check if TXFIFOs start at non-zero addr */
> +	tmp = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
> +	fifo_0_start = DWC3_GTXFIFOSIZ_TXFSTADDR(tmp);
> +
> +	fifo_size |= (fifo_0_start + (dwc->last_fifo_depth << 16));
> +	if (dwc3_is_usb31(dwc))
> +		dwc->last_fifo_depth += DWC31_GTXFIFOSIZ_TXFDEP(fifo_size);
> +	else
> +		dwc->last_fifo_depth += DWC3_GTXFIFOSIZ_TXFDEP(fifo_size);
> +
> +	/* Check fifo size allocation doesn't exceed available RAM size. */
> +	if (dwc->last_fifo_depth >= ram1_depth) {
> +		dev_err(dwc->dev, "Fifosize(%d) > RAM size(%d) %s depth:%d\n",
> +				(dwc->last_fifo_depth * mdwidth), ram1_depth,
> +				dep->endpoint.name, fifo_size);

Use dev_WARN() here and eliminate the WARN_ON(1) below?

> +		if (dwc3_is_usb31(dwc))
> +			fifo_size = DWC31_GTXFIFOSIZ_TXFDEP(fifo_size);
> +		else
> +			fifo_size = DWC3_GTXFIFOSIZ_TXFDEP(fifo_size);
> +		dwc->last_fifo_depth -= fifo_size;
> +		dep->fifo_depth = 0;
> +		WARN_ON(1);
> +		return -ENOMEM;
> +	}
> +
> +	dwc3_writel(dwc->regs, DWC3_GTXFIFOSIZ(dep->number >> 1), fifo_size);
> +	dwc->num_ep_resized++;
> +	return 0;
> +}
> +
>  static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, unsigned int action)
>  {
>  	const struct usb_ss_ep_comp_descriptor *comp_desc;
> @@ -620,6 +731,10 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action)
>  	int			ret;
>  
>  	if (!(dep->flags & DWC3_EP_ENABLED)) {
> +		ret = dwc3_gadget_resize_tx_fifos(dwc, dep);
> +		if (ret)
> +			return ret;
> +
>  		ret = dwc3_gadget_start_config(dep);
>  		if (ret)
>  			return ret;

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [Patch 1/2] dt-binbings: media: ti-vpe: Document the VIP driver
From: Benoit Parrot @ 2020-05-29 16:45 UTC (permalink / raw)
  To: Rob Herring; +Cc: Hans Verkuil, linux-media, devicetree, linux-kernel
In-Reply-To: <20200528233933.GA881467@bogus>

Hi Rob,

Thanks for the review.

Rob Herring <robh@kernel.org> wrote on Thu [2020-May-28 17:39:33 -0600]:
> On Fri, May 22, 2020 at 05:54:11PM -0500, Benoit Parrot wrote:
> > Device Tree bindings for the Video Input Port (VIP) driver.
> 
> Bindings document h/w, not drivers.

I'll fix that.

> 
> > 
> > Signed-off-by: Benoit Parrot <bparrot@ti.com>
> > ---
> >  .../devicetree/bindings/media/ti,vip.yaml     | 394 ++++++++++++++++++
> >  MAINTAINERS                                   |   1 +
> >  2 files changed, 395 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/ti,vip.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/media/ti,vip.yaml b/Documentation/devicetree/bindings/media/ti,vip.yaml
> > new file mode 100644
> > index 000000000000..8a9084e42329
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/ti,vip.yaml
> > @@ -0,0 +1,394 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/ti,vip.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Texas Instruments DRA7x VIDEO INPUT PORT (VIP) Device Tree Bindings
> > +
> > +maintainers:
> > +  - Benoit Parrot <bparrot@ti.com>
> > +
> > +description: |-
> > +  The Video Input Port (VIP) is a key component for image capture
> > +  applications. The capture module provides the system interface and the
> > +  processing capability to connect parallel image-sensor as well as
> > +  BT.656/1120 capable encoder chip to DRA7x device.
> > +
> > +  Each VIP instance supports 2 independently configurable external video
> > +  input capture slices (Slice 0 and Slice 1) each providing up to two video
> > +  input ports (Port A and Port B) where Port A can be configured as
> > +  24/16/8-bit port and Port B is fixed as 8-bit port.
> > +  Here these ports a represented as follows
> > +    port@0 -> Slice 0 Port A
> > +    port@1 -> Slice 0 Port B
> > +    port@2 -> Slice 1 Port A
> > +    port@3 -> Slice 1 Port B
> > +
> > +  Each camera port nodes should contain a 'port' child node with child
> > +  'endpoint' node. Please refer to the bindings defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +
> > +properties:
> > +  compatible:
> > +    const: ti,dra7-vip
> > +
> > +  label:
> > +    description: Instance name
> 
> Kind of odd for this type of binding. Are there a define set or pattern 
> of values.

The label here are used to 'name' each H/W instance. And so far there can
be a up to 3 instances with the currently available devices, but that
doesn't mean there couldn't be more in the future. So I did not want to
limit it here.

> 
> > +
> > +  reg:
> > +    items:
> > +      - description: The VIP main register region
> > +      - description: Video Data Parser (PARSER) register region for Slice0
> > +      - description: Color Space Conversion (CSC) register region for Slice0
> > +      - description: Scaler (SC) register region for Slice0
> > +      - description: Video Data Parser (PARSER) register region for Slice1
> > +      - description: Color Space Conversion (CSC) register region for Slice1
> > +      - description: Scaler (SC) register region for Slice1
> > +      - description: Video Port Direct Memory Access (VPDMA) register region
> > +
> > +  reg-names:
> > +    items:
> > +      - const: vip
> > +      - const: parser0
> > +      - const: csc0
> > +      - const: sc0
> > +      - const: parser1
> > +      - const: csc1
> > +      - const: sc1
> > +      - const: vpdma
> > +
> > +  interrupts:
> > +    minItems: 2
> > +    description:
> > +      IRQ index 0 is used for Slice0 interrupts
> > +      IRQ index 1 is used for Slice1 interrupts
> > +
> > +  ti,vip-clk-polarity:
> > +    $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +    description:
> > +      phandle to the device control module. The 1st argument should
> > +      contain the register offset to the CTRL_CORE_SMA_SW_1 register.
> > +      2nd argument contains the bit field to slice 0 port A,
> > +      3rd argument contains the bit field to slice 0 port B,
> > +      4th argument contains the bit field to slice 1 port A,
> > +      5th argument contains the bit field to slice 1 port B.
> > +
> > +  # See ./video-interfaces.txt for details
> > +  ports:
> > +    type: object
> > +    additionalProperties: false
> > +
> > +    properties:
> > +      "#address-cells":
> > +        const: 1
> > +
> > +      "#size-cells":
> > +        const: 0
> > +
> > +      port@0:
> > +        type: object
> > +        additionalProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            const: 0
> > +            description: Slice 0 Port A
> > +
> > +          label:
> > +            description: Port name. Usually the pin group name
> > +
> > +        patternProperties:
> > +          endpoint:
> > +            type: object
> > +            additionalProperties: false
> > +
> > +            properties:
> > +              hsync-active:
> > +                maxItems: 1
> 
> Not an array. Just:
> 
> hsync-active: true

OK I'll fix all of those.

> 
> > +
> > +              vsync-active:
> > +                maxItems: 1
> > +
> > +              pclk-sample:
> > +                maxItems: 1
> > +
> > +              bus-width:
> > +                maxItems: 1
> 
> Not an array. What subset of values are allowed?

So something like oneOf with a list then?

> 
> > +
> > +              ti,vip-pixel-mux:
> > +                type: boolean
> > +                description:
> > +                  In BT656/1120 mode, this enable pixel-muxing if
> > +                  the number of channels is either 1, 2 or 4. If this
> > +                  property is present then pixel-muxing is enabled
> > +                  otherwise it will use line-muxing.
> > +
> > +              ti,vip-channels:
> > +                $ref: "/schemas/types.yaml#definitions/uint8-array"
> > +                minItems: 1
> > +                maxItems: 16
> > +                description: |-
> > +                  In BT656/1120 mode, list of channel ids to be captured.
> > +                  If the property is not present then 1 channel is assumed.
> > +
> > +              remote-endpoint: true
> > +
> > +        required:
> > +          - reg
> > +          - label
> > +
> > +      port@1:
> > +        type: object
> > +        additionalProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            const: 1
> > +            description: Slice 0 Port B
> > +
> > +          label:
> > +            description: Port name. Usually the pin group name
> > +
> > +        patternProperties:
> > +          endpoint:
> > +            type: object
> > +            additionalProperties: false
> > +
> > +            properties:
> > +              hsync-active:
> > +                maxItems: 1
> > +
> > +              vsync-active:
> > +                maxItems: 1
> > +
> > +              pclk-sample:
> > +                maxItems: 1
> > +
> > +              bus-width:
> > +                maxItems: 1
> > +
> > +              ti,vip-pixel-mux:
> > +                type: boolean
> > +                description:
> > +                  In BT656/1120 mode, this enable pixel-muxing if
> > +                  the number of channels is either 1, 2 or 4. If this
> > +                  property is present then pixel-muxing is enabled
> > +                  otherwise it will use line-muxing.
> > +
> > +              ti,vip-channels:
> > +                $ref: "/schemas/types.yaml#definitions/uint8-array"
> > +                minItems: 1
> > +                maxItems: 16
> > +                description:
> > +                  In BT656/1120 mode, list of channel ids to be captured.
> > +                  If the property is not present then 1 channel is assumed.
> > +
> > +              remote-endpoint: true
> > +
> > +        required:
> > +          - reg
> > +          - label
> > +
> > +      port@2:
> > +        type: object
> > +        additionalProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            const: 2
> > +            description: Slice 1 Port A
> > +
> > +          label:
> > +            description: Port name. Usually the pin group name
> > +
> > +        patternProperties:
> > +          endpoint:
> > +            type: object
> > +            additionalProperties: false
> > +
> > +            properties:
> > +              hsync-active:
> > +                maxItems: 1
> > +
> > +              vsync-active:
> > +                maxItems: 1
> > +
> > +              pclk-sample:
> > +                maxItems: 1
> > +
> > +              bus-width:
> > +                maxItems: 1
> > +
> > +              ti,vip-pixel-mux:
> > +                type: boolean
> > +                description:
> > +                  In BT656/1120 mode, this enable pixel-muxing if
> > +                  the number of channels is either 1, 2 or 4. If this
> > +                  property is present then pixel-muxing is enabled
> > +                  otherwise it will use line-muxing.
> > +
> > +              ti,vip-channels:
> > +                $ref: "/schemas/types.yaml#definitions/uint8-array"
> > +                minItems: 1
> > +                maxItems: 16
> > +                description:
> > +                  In BT656/1120 mode, list of channel ids to be captured.
> > +                  If the property is not present then 1 channel is assumed.
> > +
> > +              remote-endpoint: true
> > +
> > +        required:
> > +          - reg
> > +          - label
> > +
> > +      port@3:
> > +        type: object
> > +        additionalProperties: false
> > +
> > +        properties:
> > +          reg:
> > +            const: 3
> > +            description: Slice 1 Port B
> > +
> > +          label:
> > +            description: Port name. Usually the pin group name
> > +
> > +        patternProperties:
> > +          endpoint:
> > +            type: object
> > +            additionalProperties: false
> > +
> > +            properties:
> > +              hsync-active:
> > +                maxItems: 1
> > +
> > +              vsync-active:
> > +                maxItems: 1
> > +
> > +              pclk-sample:
> > +                maxItems: 1
> > +
> > +              bus-width:
> > +                maxItems: 1
> > +
> > +              ti,vip-pixel-mux:
> > +                type: boolean
> > +                description:
> > +                  In BT656/1120 mode, this enable pixel-muxing if
> > +                  the number of channels is either 1, 2 or 4. If this
> > +                  property is present then pixel-muxing is enabled
> > +                  otherwise it will use line-muxing.
> > +
> > +              ti,vip-channels:
> > +                $ref: "/schemas/types.yaml#definitions/uint8-array"
> > +                minItems: 1
> > +                maxItems: 16
> > +                description:
> > +                  In BT656/1120 mode, list of channel ids to be captured.
> > +                  If the property is not present then 1 channel is assumed.
> > +
> > +              remote-endpoint: true
> 
> If all the properties are the same across ports, then do a 
> patternProperties with '^port@' and define them there. You'll still need 
> 'port@0', etc. to define what each port is.

Yeah I had tried to define something like that but I couldn't make pass
dt-binding-check wihtout any errors/warnings.

Can you point me to a recent example using this syntax?
Last time I check I couldn't find one.

Also I am not quite clear on the mechanism, you said to create a
patterProperties and then I wouols also have to define the individual port
themselves so I would have something like this:

      port@0:
        type: object
        additionalProperties: false

        properties:
          reg:
            const: 0
            description: Slice 0 Port A

          label:
            description: Port name. Usually the pin group name

      port@1:
        type: object
        additionalProperties: false

        properties:
          reg:
            const: 1
            description: Slice 0 Port B

          label:
            description: Port name. Usually the pin group name

      port@2:
        type: object
        additionalProperties: false

        properties:
          reg:
            const: 2
            description: Slice 1 Port A

          label:
            description: Port name. Usually the pin group name

      port@3:
        type: object
        additionalProperties: false

        properties:
          reg:
            const: 3
            description: Slice 1 Port B

          label:
            description: Port name. Usually the pin group name

And then in some way reference the patternProperties?
Or just put it before the individual ports?

> 
> > +
> > +        required:
> > +          - reg
> > +          - label
> > +
> > +    required:
> > +      - "#address-cells"
> > +      - "#size-cells"
> > +      - port@0
> > +
> > +required:
> > +  - compatible
> > +  - label
> > +  - reg
> > +  - reg-names
> > +  - interrupts
> > +  - ti,vip-clk-polarity
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +    vip1: vip@48970000 {
> > +        compatible = "ti,dra7-vip";
> > +        label = "vip1";
> > +        reg = <0x48970000 0x114>,
> > +              <0x48975500 0xD8>,
> > +              <0x48975700 0x18>,
> > +              <0x48975800 0x80>,
> > +              <0x48975a00 0xD8>,
> > +              <0x48975c00 0x18>,
> > +              <0x48975d00 0x80>,
> > +              <0x4897d000 0x400>;
> > +        reg-names = "vip",
> > +                    "parser0",
> > +                    "csc0",
> > +                    "sc0",
> > +                    "parser1",
> > +                    "csc1",
> > +                    "sc1",
> > +                    "vpdma";
> > +        interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH>,
> > +                     <GIC_SPI 392 IRQ_TYPE_LEVEL_HIGH>;
> > +        ti,vip-clk-polarity = <&scm_conf 0x534 0x1 0x4 0x2 0x8>;
> > +
> > +        ports {
> > +              #address-cells = <1>;
> > +              #size-cells = <0>;
> > +
> > +              vin1a: port@0 {
> > +                    reg = <0>;
> > +                    label = "vin1a";
> > +
> > +                    vin1a_ep: endpoint {
> > +                           remote-endpoint = <&camera1>;
> > +                           hsync-active = <1>;
> > +                           vsync-active = <1>;
> > +                           pclk-sample = <0>;
> > +                           bus-width = <8>;
> > +                    };
> > +              };
> > +              vin1b: port@1 {
> > +                    reg = <1>;
> > +                    label = "vin1b";
> > +              };
> > +              vin2a: port@2 {
> > +                    reg = <2>;
> > +                    label = "vin2a";
> > +              };
> > +              vin2b: port@3 {
> > +                    reg = <3>;
> > +                    label = "vin2b";
> > +              };
> > +         };
> > +    };
> > +
> > +    i2c {
> > +        clock-frequency = <400000>;
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +         camera@37 {
> > +              compatible = "ovti,ov10633";
> > +              reg = <0x37>;
> > +
> > +              clocks = <&fixed_clock>;
> > +              clocks-names = "xvclk";
> > +
> > +              port {
> > +                   camera1: endpoint {
> > +                           remote-endpoint = <&vin1a_ep>;
> > +                           hsync-active = <1>;
> > +                           vsync-active = <1>;
> > +                           pclk-sample = <0>;
> > +                           bus-width = <8>;
> > +                   };
> > +              };
> > +         };
> > +    };
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2e9a5f6e4ff7..06856d05b53b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16947,6 +16947,7 @@ S:	Maintained
> >  W:	http://linuxtv.org/
> >  Q:	http://patchwork.linuxtv.org/project/linux-media/list/
> >  F:	Documentation/devicetree/bindings/media/ti,cal.yaml
> > +F:	Documentation/devicetree/bindings/media/ti,vip.yaml
> >  F:	Documentation/devicetree/bindings/media/ti,vpe.yaml
> >  F:	drivers/media/platform/ti-vpe/
> >  
> > -- 
> > 2.17.1
> > 

Regards,
Benoit

^ permalink raw reply

* Re: [PATCH] dt-bindings: sound: tlv320adcx140: Fix dt-binding-check issue
From: Mark Brown @ 2020-05-29 16:51 UTC (permalink / raw)
  To: Dan Murphy, lgirdwood, perex, robh, tiwai
  Cc: devicetree, alsa-devel, linux-kernel
In-Reply-To: <20200528144711.18065-1-dmurphy@ti.com>

On Thu, 28 May 2020 09:47:11 -0500, Dan Murphy wrote:
> Fix dt-binding-check issue
> 
> ti,gpi-config:0:0: 4 is greater than the maximum of 1
> ti,gpi-config:0:1: 5 is greater than the maximum of 1
> ti,gpi-config:0:2: 6 is greater than the maximum of 1
> ti,gpi-config:0:3: 7 is greater than the maximum of 1

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: tlv320adcx140: Fix dt-binding-check issue
      commit: c8b47d63ad8755780b6b70dbe57ab8333bcc4a0f

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

^ permalink raw reply

* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Rob Herring @ 2020-05-29 17:07 UTC (permalink / raw)
  To: Johan Jonker
  Cc: linux-rockchip, devicetree, linux-arm-kernel, linux-kernel, heiko,
	linux-input, dmitry.torokhov, robh+dt
In-Reply-To: <20200520073327.6016-1-jbx6244@gmail.com>

On Wed, 20 May 2020 09:33:27 +0200, Johan Jonker wrote:
> A test with the command below gives this error:
> 
> arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> touchscreen@3e: reg:0:0: 56 was expected
> 
> The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> was shipped with different addresses then the binding currently allows.
> Change the reg property that any address will pass.
> 
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> edt-ft5x06.yaml
> 
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
>  Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!

^ permalink raw reply

* Re: [PATCH v4 1/5] dt-bindings: iio: imu: bmi160: convert format to yaml, add maintainer
From: Rob Herring @ 2020-05-29 17:08 UTC (permalink / raw)
  To: Jonathan Albrieux
  Cc: Rob Herring, Hartmut Knaack, devicetree, linux-iio, daniel.baluta,
	Peter Meerwald-Stadler, ~postmarketos/upstreaming,
	Jonathan Cameron, linux-kernel, Lars-Peter Clausen
In-Reply-To: <20200525164615.14962-2-jonathan.albrieux@gmail.com>

On Mon, 25 May 2020 18:46:00 +0200, Jonathan Albrieux wrote:
> Converts documentation from txt format to yaml.
> 
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
>  .../devicetree/bindings/iio/imu/bmi160.txt    | 37 ---------
>  .../bindings/iio/imu/bosch,bmi160.yaml        | 75 +++++++++++++++++++
>  2 files changed, 75 insertions(+), 37 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
>  create mode 100644 Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v4 2/5] dt-bindings: iio: imu: bmi160: add regulators and mount-matrix
From: Rob Herring @ 2020-05-29 17:09 UTC (permalink / raw)
  To: Jonathan Albrieux
  Cc: linux-kernel, ~postmarketos/upstreaming, daniel.baluta,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Hartmut Knaack, Lars-Peter Clausen,
	open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
	Jonathan Cameron
In-Reply-To: <20200525164615.14962-3-jonathan.albrieux@gmail.com>

On Mon, May 25, 2020 at 06:46:01PM +0200, Jonathan Albrieux wrote:
> Add vdd-supply and vddio-supply support.
> Add mount-matrix support.
> 
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
>  .../bindings/iio/imu/bosch,bmi160.yaml           | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> index 0d0ef84e22b9..cfe40dbcd723 100644
> --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> @@ -37,6 +37,17 @@ properties:
>        set if the specified interrupt pin should be configured as
>        open drain. If not set, defaults to push-pull.
>  
> +  vdd-supply:
> +    maxItems: 1

Supplies are always a single item, so don't need this.

> +    description: provide VDD power to the sensor.
> +
> +  vddio-supply:
> +    maxItems: 1
> +    description: provide VDD IO power to the sensor.
> +
> +  mount-matrix:
> +    description: an optional 3x3 mounting rotation matrix
> +
>  required:
>    - compatible
>    - reg
> @@ -52,9 +63,14 @@ examples:
>          bmi160@68 {
>                  compatible = "bosch,bmi160";
>                  reg = <0x68>;
> +                vdd-supply = <&pm8916_l17>;
> +                vddio-supply = <&pm8916_l6>;
>                  interrupt-parent = <&gpio4>;
>                  interrupts = <12 IRQ_TYPE_EDGE_RISING>;
>                  interrupt-names = "INT1";
> +                mount-matrix = "0", "1", "0",
> +                               "-1", "0", "0",
> +                               "0", "0", "1";
>          };
>      };
>    - |
> -- 
> 2.17.1
> 

^ permalink raw reply

* Re: [PATCH 3/3] hwrng: ba431-rng: add support for BA431 hwrng
From: Rob Herring @ 2020-05-29 17:12 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Olivier Sobrie, Matt Mackall, Herbert Xu, Greg Kroah-Hartman,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, DTML,
	linux-kernel@vger.kernel.org, Waleed Ziad, sebastien.rabou
In-Reply-To: <CAK8P3a3=HoQZuBoqyFgyde1X7BRfcH-GFQpu=8acOi_JhVU99g@mail.gmail.com>

On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> <olivier.sobrie@silexinsight.com> wrote:
> >
> > Silex insight BA431 is an IP designed to generate random numbers that
> > can be integrated in various FPGA.
> > This driver adds support for it through the hwrng interface.
> >
> > This driver is used in Silex Insight Viper OEM boards.
> >
> > Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> > Signed-off-by: Waleed Ziad <waleed94ziad@gmail.com>
> 
> The driver looks good to me.
> 
> Acked-by: Arnd Bergmann  <arnd@arndb.de>
> 
> >  drivers/char/hw_random/Kconfig     |  10 ++
> >  drivers/char/hw_random/Makefile    |   1 +
> >  drivers/char/hw_random/ba431-rng.c | 240 +++++++++++++++++++++++++++++
> 
> I wonder if we should move drivers/char/hw_random to its own top-level drivers
> subsystem outside of drivers/char. It seems to be growing steadily and is larger
> than a lot of other subsystems with currently 34 drivers in there.
> 
> Not your problem though.
> 
> > +       /* Wait until the state changed */
> > +       for (i = 0; i < BA431_RESET_READ_STATUS_RETRIES; ++i) {
> > +               state = ba431_trng_get_state(ba431);
> > +               if (state >= BA431_STATE_STARTUP)
> > +                       break;
> > +
> > +               udelay(BA431_RESET_READ_STATUS_INTERVAL);
> > +       }
> 
> Looking for something to improve, I noticed that this loop can take over
> a millisecond to time out, and it always runs in non-atomic context.
> It may be better to use usleep_range() than udelay().

Or better yet, use the register polling helpers.

Rob

^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Silex Insight vendor prefix
From: Rob Herring @ 2020-05-29 17:12 UTC (permalink / raw)
  To: Olivier Sobrie
  Cc: Greg Kroah-Hartman, linux-crypto, Waleed Ziad, Matt Mackall,
	sebastien.rabou, Rob Herring, Arnd Bergmann, Herbert Xu,
	linux-kernel, devicetree
In-Reply-To: <20200525195606.2941649-2-olivier.sobrie@silexinsight.com>

On Mon, 25 May 2020 21:56:04 +0200, Olivier Sobrie wrote:
> Silex Insight is a microelectronic company whose headquarter is located
> in Belgium.
> Web site of the company: https://www.silexinsight.com/
> 
> Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied, thanks!

^ permalink raw reply

* Re: [PATCH 2/3] dt-bindings: rng: document Silex Insight BA431 hwrng
From: Rob Herring @ 2020-05-29 17:13 UTC (permalink / raw)
  To: Olivier Sobrie
  Cc: linux-crypto, linux-kernel, sebastien.rabou, Herbert Xu,
	devicetree, Waleed Ziad, Rob Herring, Matt Mackall, Arnd Bergmann,
	Greg Kroah-Hartman
In-Reply-To: <20200525195606.2941649-3-olivier.sobrie@silexinsight.com>

On Mon, 25 May 2020 21:56:05 +0200, Olivier Sobrie wrote:
> This patch documents the device tree bindings of the BA431 hardware
> random number generator.
> 
> This IP is for instance present in the Viper OEM boards sold by Silex
> Insight.
> 
> Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> ---
>  .../bindings/rng/silex-insight,ba431-rng.yaml | 36 +++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 1/2] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
From: Rob Herring @ 2020-05-29 17:14 UTC (permalink / raw)
  To: Wan Ahmad Zainie
  Cc: kishon, vkoul, linux-kernel, devicetree, andriy.shevchenko,
	adrian.hunter
In-Reply-To: <20200526050452.8837-2-wan.ahmad.zainie.wan.mohamad@intel.com>

On Tue, May 26, 2020 at 01:04:51PM +0800, Wan Ahmad Zainie wrote:
> Binding description for Intel Keem Bay eMMC PHY.
> 
> Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
> ---
>  .../bindings/phy/intel,keembay-emmc-phy.yaml  | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> new file mode 100644
> index 000000000000..d3e0f169eb0a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2020 Intel Corporation
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-phy.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Intel Keem Bay eMMC PHY bindings
> +
> +maintainers:
> +  - Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
> +
> +properties:
> +  compatible:
> +    const: intel,keembay-emmc-phy
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: emmcclk
> +
> +  "#phy-cells":
> +    const: 0
> +
> +required:
> +  - compatible
> +  - reg
> +  - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    phy@20290000 {
> +          compatible = "intel,keembay-emmc-phy";
> +          reg = <0x0 0x20290000 0x0 0x54>;

Examples expect a single cell for address and size.

> +          clocks = <&emmc>;
> +          clock-names = "emmcclk";
> +          #phy-cells = <0>;
> +    };
> -- 
> 2.17.1
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox