* Re: [PATCH v3 02/10] dt-bindings: serial: add optional pinctrl states
From: Rob Herring @ 2019-07-09 14:38 UTC (permalink / raw)
To: Erwan Le Ray
Cc: Greg Kroah-Hartman, Jiri Slaby, Maxime Coquelin, Alexandre Torgue,
Mark Rutland, linux-serial, linux-stm32, linux-arm-kernel,
linux-kernel, devicetree, Fabrice Gasnier, Bich Hemon
In-Reply-To: <1560433800-12255-3-git-send-email-erwan.leray@st.com>
On Thu, Jun 13, 2019 at 03:49:52PM +0200, Erwan Le Ray wrote:
> From: Bich Hemon <bich.hemon@st.com>
>
> Add options for pinctrl states:
> - "sleep" for low power
> - "idle" for low power and wakeup capabilities enabled
> - "no_console_suspend" for enabling console messages in low power
>
> Signed-off-by: Bich Hemon <bich.hemon@st.com>
> Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
>
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> index 5ec80c1..64a5ea9 100644
> --- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
> @@ -13,7 +13,14 @@ Required properties:
> - clocks: The input clock of the USART instance
>
> Optional properties:
> -- pinctrl: The reference on the pins configuration
> +- pinctrl-names: Set to "default". An additional "sleep" state can be defined
> + to set pins in sleep state when in low power. In case the device is used as
> + a wakeup source, "idle" state is defined in order to keep RX pin active.
> + For a console device, an optional state "no_console_suspend" can be defined
> + to enable console messages during suspend. Typically, "no_console_suspend" and
> + "default" states can refer to the same pin configuration.
no_console_suspend is a linux thing and doesn't belong in DT.
Rob
^ permalink raw reply
* Re: [PATCH v3 01/10] dt-bindings: serial: stm32: add wakeup option
From: Rob Herring @ 2019-07-09 14:35 UTC (permalink / raw)
Cc: Greg Kroah-Hartman, Jiri Slaby, Maxime Coquelin, Alexandre Torgue,
Mark Rutland, linux-serial, linux-stm32, linux-arm-kernel,
linux-kernel, devicetree, Erwan Le Ray, Fabrice Gasnier,
Bich Hemon
In-Reply-To: <1560433800-12255-2-git-send-email-erwan.leray@st.com>
On Thu, 13 Jun 2019 15:49:51 +0200, Erwan Le Ray wrote:
> Add a note for enabling wakeup capabilities of usart
>
> Signed-off-by: Bich Hemon <bich.hemon@st.com>
> Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext Milbeaut HDMAC bindings
From: Rob Herring @ 2019-07-09 14:34 UTC (permalink / raw)
To: jassisinghbrar
Cc: dmaengine, devicetree, linux-kernel, vkoul, mark.rutland,
orito.takao, masami.hiramatsu, kasai.kazuhiro, Jassi Brar
In-Reply-To: <20190613005237.1996-1-jassisinghbrar@gmail.com>
On Wed, Jun 12, 2019 at 07:52:37PM -0500, jassisinghbrar@gmail.com wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
>
> Document the devicetree bindings for Socionext Milbeaut HDMAC
> controller. Controller has upto 8 floating channels, that need
> a predefined slave-id to work from a set of slaves.
>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
> .../bindings/dma/milbeaut-m10v-hdmac.txt | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> new file mode 100644
> index 000000000000..a104fcb9e73d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> @@ -0,0 +1,51 @@
> +* Milbeaut AHB DMA Controller
> +
> +Milbeaut AHB DMA controller has transfer capability bellow.
> + - memory to memory transfer
> + - device to memory transfer
> + - memory to device transfer
> +
> +Required property:
> +- compatible: Should be "socionext,milbeaut-m10v-hdmac"
> +- reg: Should contain DMA registers location and length.
> +- interrupts: Should contain all of the per-channel DMA interrupts.
How many?
> +- #dma-cells: Should be 1. Specify the ID of the slave.
> +- clocks: Phandle to the clock used by the HDMAC module.
> +
> +
> +Example:
> +
> + hdmac1: hdmac@1e110000 {
dma-controller@...
> + compatible = "socionext,milbeaut-m10v-hdmac";
> + reg = <0x1e110000 0x10000>;
> + interrupts = <0 132 4>,
> + <0 133 4>,
> + <0 134 4>,
> + <0 135 4>,
> + <0 136 4>,
> + <0 137 4>,
> + <0 138 4>,
> + <0 139 4>;
> + #dma-cells = <1>;
> + clocks = <&dummy_clk>;
> + };
> +
> +* DMA client
> +
> +Clients have to specify the DMA requests with phandles in a list.
Nothing specific to this binding here and the client side is already
documented, so drop this section.
> +
> +Required properties:
> +- dmas: List of one or more DMA request specifiers. One DMA request specifier
> + consists of a phandle to the DMA controller followed by the integer
> + specifying the request line.
> +- dma-names: List of string identifiers for the DMA requests. For the correct
> + names, have a look at the specific client driver.
> +
> +Example:
> +
> + sni_spi1: spi@1e800100 {
> + ...
> + dmas = <&hdmac1 22>, <&hdmac1 21>;
> + dma-names = "tx", "rx";
> + ...
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
From: Eugen.Hristev @ 2019-07-09 14:33 UTC (permalink / raw)
To: Luis.Oliveira, mchehab, davem, gregkh, Jonathan.Cameron, robh,
Nicolas.Ferre, paulmck, mark.rutland, kishon, devicetree,
linux-media, linux-kernel
Cc: Joao.Pinto
In-Reply-To: <1560280855-18085-2-git-send-email-luis.oliveira@synopsys.com>
On 11.06.2019 22:20, Luis Oliveira wrote:
> From: Luis Oliveira <lolivei@synopsys.com>
>
> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Changelog
> v3-v4
> - remove "plat" from the block name @rob @laurent
> - remove "phy-names" when single-entry @rob
> - remove "snps,output-type" -> went to the driver config @laurent
>
> .../devicetree/bindings/media/snps,dw-csi.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> new file mode 100644
> index 0000000..613b7f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> @@ -0,0 +1,41 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +-----------
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible : shall be "snps,dw-csi"
> +- reg : physical base address and size of the device memory
> + mapped registers;
> +- interrupts : DW CSI-2 Host interrupts
> +- phys : List of one PHY specifier (as defined in
> + Documentation/devicetree/bindings/phy/phy-bindings.txt).
> + This PHY is a MIPI DPHY working in RX mode.
> +- resets : Reference to a reset controller (optional)
> +
> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the camera as
> + described in video-interfaces.txt[1].
> +
> +Example:
> +
> + csi2: csi2@3000 {
> + compatible = "snps,dw-csi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = < 0x03000 0x7FF>;
> + phys = <&mipi_dphy_rx>;
> + resets = <&dw_rst 1>;
> + interrupts = <2>;
> +
> + port@0 {
> + reg = <0>;
> + csi_ep1: endpoint {
> + remote-endpoint = <&camera_1>;
> + data-lanes = <1 2>;
> + };
Hello Luis,
Which is the output port (endpoint) : how to connect the output of
csi2host to another node ?
I mean, the second port of this block, or, how is the data taken from
csi2host ?
Thanks,
Eugen
> + };
> + };
>
^ permalink raw reply
* Re: [RESEND, PATCH v4 2/2] dt-bindings: cpufreq: Document allwinner,sun50i-h6-operating-points
From: Rob Herring @ 2019-07-09 14:31 UTC (permalink / raw)
Cc: vireshk, nm, sboyd, robh+dt, mark.rutland, maxime.ripard, wens,
rjw, davem, mchehab+samsung, gregkh, linus.walleij, nicolas.ferre,
paulmck, linux-pm, devicetree, linux-arm-kernel, linux-kernel,
Yangtao Li
In-Reply-To: <20190612162816.31713-3-tiny.windzz@gmail.com>
On Wed, 12 Jun 2019 12:28:16 -0400, Yangtao Li wrote:
> Allwinner Process Voltage Scaling Tables defines the voltage and
> frequency value based on the speedbin blown in the efuse combination.
> The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to
> provide the OPP framework with required information.
> This is used to determine the voltage and frequency value for each
> OPP of operating-points-v2 table when it is parsed by the OPP framework.
>
> The "allwinner,sun50i-h6-operating-points" DT extends the
> "operating-points-v2"
> with following parameters:
> - nvmem-cells (NVMEM area containig the speedbin information)
> - opp-microvolt-<name>: voltage in micro Volts.
> At runtime, the platform can pick a <name> and matching
> opp-microvolt-<name> property.
> HW: <name>:
> sun50i-h6 speed0 speed1 speed2
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../bindings/opp/sun50i-nvmem-cpufreq.txt | 167 ++++++++++++++++++
> 1 file changed, 167 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/opp/sun50i-nvmem-cpufreq.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 08/10] media: dt-bindings: Document i.MX8MQ and i.MX8MM VPU bindings
From: Rob Herring @ 2019-07-09 14:25 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Boris Brezillon,
Ezequiel Garcia, Nicolas Dufresne, Jonas Karlman, devicetree,
kernel
In-Reply-To: <20190612093915.18973-9-p.zabel@pengutronix.de>
On Wed, Jun 12, 2019 at 11:39:13AM +0200, Philipp Zabel wrote:
> Add devicetree binding documentation for the Hantro G1/G2 VPU on i.MX8MQ
> and for the Hantro G1/G2/H1 VPU on i.MX8MM.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> .../devicetree/bindings/media/imx8m-vpu.txt | 56 +++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/imx8m-vpu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/imx8m-vpu.txt b/Documentation/devicetree/bindings/media/imx8m-vpu.txt
> new file mode 100644
> index 000000000000..659bd28dd002
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx8m-vpu.txt
> @@ -0,0 +1,56 @@
> +device-tree bindings for Hantro G1/G2/H1 VPU codecs implemented on i.MX8M SoCs
> +
> +Required properties:
> +- compatible: value should be one of the following
> + "nxp,imx8mq-vpu",
> + "nxp,imx8mm-vpu";
> +- regs: VPU core and control block register ranges
> +- reg-names: should be
> + "g1", "g2", "ctrl" on i.MX8MQ,
> + "g1", "g2", "h1", "ctrl" on i.MX8MM.
Would be nicer to put h1 at the end, so the indexes don't change.
> +- interrupts: encoding and decoding interrupt specifiers
> +- interrupt-names: should be
> + "g1", "g2" on i.MX8MQ,
> + "g1", "g2", "h1" on i.MX8MM.
> +- clocks: phandle to VPU core clocks and bus clock
> +- clock-names: should be
> + "g1", "g2", "bus" on i.MX8MQ,
> + "g1", "g2", "h1", "bus" on i.MX8MM.
Here too.
> +- power-domains: phandle to power domain node
> +
> +Examples:
> +
> + vpu: vpu@38300000 {
video-codec@...
> + compatible = "nxp,imx8mq-vpu";
> + reg = <0x38300000 0x10000>,
> + <0x38310000 0x10000>,
> + <0x38320000 0x10000>;
> + reg-names = "g1", "g2", "ctrl";
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "g1", "g2";
> + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
> + <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
> + <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
> + clock-names = "g1", "g2", "bus";
> + power-domains = <&pgc_vpu>;
> + };
> +
> + vpu: vpu@38300000 {
Are 2 examples really necessary?
> + compatible = "nxp,imx8mm-vpu";
> + reg = <0x38300000 0x10000>,
> + <0x38310000 0x10000>,
> + <0x38320000 0x10000>;
> + <0x38330000 0x10000>;
> + reg-names = "g1", "g2", "h1", "ctrl";
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "g1", "g2", "h1";
> + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
> + <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
> + <&clk IMX8MQ_CLK_VPU_H1_ROOT>,
> + <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
> + clock-names = "g1", "g2", "h1", "bus";
> + power-domains = <&pgc_vpu>;
> + };
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: usb: mtk-xhci: add an optional xhci_ck clock
From: Rob Herring @ 2019-07-09 14:22 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Greg Kroah-Hartman, Mark Rutland, Matthias Brugger, Mathias Nyman,
linux-usb, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Jumin Li
In-Reply-To: <9b6ad8dee142d73b56d653ecb7475c4ed28e5eb8.1560246390.git.chunfeng.yun@mediatek.com>
On Wed, Jun 12, 2019 at 01:55:19PM +0800, Chunfeng Yun wrote:
> Add a new optional clock xhci_ck
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> index 266c2d917a28..91c0704b586b 100644
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> @@ -29,6 +29,7 @@ Required properties:
> "sys_ck": controller clock used by normal mode,
> the following ones are optional:
> "ref_ck": reference clock used by low power mode etc,
> + "xhci_ck": controller clock,
> "mcu_ck": mcu_bus clock for register access,
> "dma_ck": dma_bus clock for data transfer by DMA
A new clock should go at the end to stay backwards compatible.
>
> @@ -100,7 +101,7 @@ Required properties:
> - clocks : a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
> - clock-names : must contain "sys_ck", and the following ones are optional:
> - "ref_ck", "mcu_ck" and "dma_ck"
> + "ref_ck", "xhci_ck", "mcu_ck" and "dma_ck"
>
> Optional properties:
> - vbus-supply : reference to the VBUS regulator;
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
From: Maxime Ripard @ 2019-07-09 14:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, Vasily Khoruzhick, Mark Rutland, devicetree,
Sean Paul, David Airlie, Greg Kroah-Hartman, linux-kernel,
dri-devel, Andrzej Hajda, Chen-Yu Tsai, Rob Herring, Torsten Duwe,
Laurent Pinchart, Daniel Vetter, Harald Geyer, Thierry Reding,
Thomas Gleixner
In-Reply-To: <72E7C765-3660-413A-8450-94BE4B3D1345@aosc.io>
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
> >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> >> > > Maybe instead of edp-connector one would introduce integrator's
> >specific
> >> > > connector, for example with compatible
> >"olimex,teres-edp-connector"
> >> > > which should follow edp abstract connector rules? This will be at
> >least
> >> > > consistent with below presentation[1] - eDP requirements depends
> >on
> >> > > integrator. Then if olimex has standard way of dealing with
> >panels
> >> > > present in olimex/teres platforms the driver would then create
> >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
> >guess.
> >> > > Anyway it still looks fishy for me :), maybe because I am not
> >> > > familiarized with details of these platforms.
> >> >
> >> > That makes sense yes
> >>
> >> Actually, it makes no sense at all. Current implementation for
> >anx6345
> >> driver works fine as is with any panel specified assuming panel
> >delays
> >> are long enough for connected panel. It just doesn't use panel
> >timings
> >> from the driver. Creating a platform driver for connector itself
> >looks
> >> redundant since it can't be reused, it doesn't describe actual
> >> hardware and it's just defeats purpose of DT by introducing
> >> board-specific code.
> >
> >I'm not sure where you got the idea that the purpose of DT is to not
> >have any board-specific code.
> >
> >It's perfectly fine to have some, that's even why there's a compatible
> >assigned to each and every board.
> >
> >What the DT is about is allowing us to have a generic behaviour that
> >we can detect: we can have a given behaviour for a given board, and a
> >separate one for another one, and this will be evaluated at runtime.
> >
> >This is *exactly* what this is about: we can have a compatible that
> >sets a given, more specific, behaviour (olimex,teres-edp-connector)
> >while saying that this is compatible with the generic behaviour
> >(edp-connector). That way, any OS will know what quirk to apply if
> >needed, and if not that it can use the generic behaviour.
> >
> >And we could create a generic driver, for the generic behaviour if
> >needed.
> >
> >> There's another issue: if we introduce edp-connector we'll have to
> >> specify power up delays somewhere (in dts? or in platform driver?),
> >so
> >> edp-connector doesn't really solve the issue of multiple panels with
> >> same motherboard.
> >
> >And that's what that compatible is about :)
>
> Maybe we can introduce a connector w/o any driver just like hdmi-connector?
Ironically, a driver for it has been sent yesterday :)
But yeah, we can definitely do that too.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: usb: mtu3: support force_vbus mode
From: Rob Herring @ 2019-07-09 14:21 UTC (permalink / raw)
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Matthias Brugger,
Mathias Nyman, Chunfeng Yun, linux-usb, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, Jumin Li
In-Reply-To: <65f025186332b2b44f7b27f58af893217df1adb5.1560246390.git.chunfeng.yun@mediatek.com>
On Wed, 12 Jun 2019 13:55:18 +0800, Chunfeng Yun wrote:
> Add a new property to indicate that the controller doesn't support Vbus
> detection due to non-exist Vbus PIN, and the driver should set force_vbus
> state for device mode
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: usb: mtu3: fix typo of DMA clock name
From: Rob Herring @ 2019-07-09 14:20 UTC (permalink / raw)
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Matthias Brugger,
Mathias Nyman, Chunfeng Yun, linux-usb, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, Jumin Li
In-Reply-To: <5e06482a0be15476c7b5825f155accf98275afa8.1560246390.git.chunfeng.yun@mediatek.com>
On Wed, 12 Jun 2019 13:55:17 +0800, Chunfeng Yun wrote:
> Fix typo of dma_ck
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [v4 4/6] dt-bindings: phy: Document the Synopsys MIPI DPHY Rx bindings
From: Rob Herring @ 2019-07-09 14:20 UTC (permalink / raw)
To: Luis Oliveira
Cc: mchehab, davem, gregkh, Jonathan.Cameron, nicolas.ferre, paulmck,
mark.rutland, kishon, devicetree, linux-media, linux-kernel,
Joao.Pinto
In-Reply-To: <1560280855-18085-5-git-send-email-luis.oliveira@synopsys.com>
On Tue, Jun 11, 2019 at 09:20:53PM +0200, Luis Oliveira wrote:
> Add device-tree bindings documentation for SNPS DesignWare MIPI D-PHY in
> RX mode.
>
> Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
> ---
> Changelog
> v3-v4
> - @Laurent I know I told you I could remove the snps,dphy-frequency on V3 but
> it is really useful for me here. I removed all other the proprietary
> properties except this one. Do you still think it must be removed?
> - Frequency units @Rob
Frequency units means append '-khz' to the property name. That also
makes the 'frequency' part redundant, so maybe name it more around what
the frequency is. The frequency for what?
Rob
>
> .../devicetree/bindings/phy/snps,dw-dphy-rx.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/snps,dw-dphy-rx.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/snps,dw-dphy-rx.txt b/Documentation/devicetree/bindings/phy/snps,dw-dphy-rx.txt
> new file mode 100644
> index 0000000..50603e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/snps,dw-dphy-rx.txt
> @@ -0,0 +1,29 @@
> +Synopsys DesignWare MIPI Rx D-PHY block details
> +
> +Description
> +-----------
> +
> +The Synopsys MIPI D-PHY controller supports MIPI-DPHY in receiver mode.
> +Please refer to phy-bindings.txt for more information.
> +
> +Required properties:
> +- compatible : Shall be "snps,dw-dphy-rx".
> +- #phy-cells : Must be 1.
> +- bus-width : Size of the test interface data bus (8 bits->8 or
> + 12bits->12).
> +- snps,dphy-frequency : Frequency at which D-PHY should start, configurable.
> + Check Synopsys databook. (-kHz)
> +- reg : Test interface register. This correspondes to the
> + physical base address of the controller and size of
> + the device memory mapped registers; Check Synopsys
> + databook.
> +
> +Example:
> +
> + mipi_dphy_rx1: dphy@d00003040 {
> + compatible = "snps,dw-dphy-rx";
> + #phy-cells = <1>;
> + bus-width = <12>;
> + snps,dphy-frequency = <300000>;
> + reg = <0xd0003040 0x20>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V12 01/12] PCI: Add #defines for some of PCIe spec r4.0 features
From: Bjorn Helgaas @ 2019-07-09 14:14 UTC (permalink / raw)
To: Vidya Sagar
Cc: lorenzo.pieralisi, robh+dt, mark.rutland, thierry.reding,
jonathanh, kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <20190701124010.7484-2-vidyas@nvidia.com>
On Mon, Jul 01, 2019 at 06:09:59PM +0530, Vidya Sagar wrote:
> Add #defines only for the Data Link Feature and Physical Layer 16.0 GT/s
> features.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> Reviewed-by: Thierry Reding <treding@nvidia.com>
Please include spec references in the commit log, e.g., PCIe r5.0, sec
7.7.4, for Data Link Feature and sec 7.7.5 for Physical Layer 16 GT/s.
> include/uapi/linux/pci_regs.h | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index f28e562d7ca8..1c79f6a097d2 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -713,7 +713,9 @@
> #define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port Containment */
> #define PCI_EXT_CAP_ID_L1SS 0x1E /* L1 PM Substates */
> #define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement */
> -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM
> +#define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */
> +#define PCI_EXT_CAP_ID_PL 0x26 /* Physical Layer 16.0 GT/s */
Maybe PCI_EXT_CAP_ID_PL_16GT so there's a little more hint of what
this is for?
> +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL
>
> #define PCI_EXT_CAP_DSN_SIZEOF 12
> #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
> @@ -1053,4 +1055,22 @@
> #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe0000000 /* LTR_L1.2_THRESHOLD_Scale */
> #define PCI_L1SS_CTL2 0x0c /* Control 2 Register */
>
> +/* Data Link Feature */
> +#define PCI_DLF_CAP 0x04 /* Capabilities Register */
> +#define PCI_DLF_LOCAL_DLF_SUP_MASK 0x007fffff /* Local Data Link Feature Supported */
> +#define PCI_DLF_EXCHANGE_ENABLE 0x80000000 /* Data Link Feature Exchange Enable */
> +#define PCI_DLF_STS 0x08 /* Status Register */
> +#define PCI_DLF_REMOTE_DLF_SUP_MASK 0x007fffff /* Remote Data Link Feature Supported */
> +#define PCI_DLF_REMOTE_DLF_SUP_VALID 0x80000000 /* Remote Data Link Feature Support Valid */
I'm a little bit ambivalent about adding #defines that aren't used. I
personally would probably just add the things we use, so the header
file gives a clue about what's currently implemented. But I guess
either way is fine.
> +/* Physical Layer 16.0 GT/s */
> +#define PCI_PL_16GT_CAP 0x04 /* Capabilities Register */
> +#define PCI_PL_16GT_CTRL 0x08 /* Control Register */
> +#define PCI_PL_16GT_STS 0x0c /* Status Register */
> +#define PCI_PL_16GT_LDPM_STS 0x10 /* Local Data Parity Mismatch Status Register */
> +#define PCI_PL_16GT_FRDPM_STS 0x14 /* First Retimer Data Parity Mismatch Status Register */
> +#define PCI_PL_16GT_SRDPM_STS 0x18 /* Second Retimer Data Parity Mismatch Status Register */
> +#define PCI_PL_16GT_RSVD 0x1C /* Reserved */
Use lower-case hex consistently here. There's no global consistency
in this file, but we can at least be consistent in each section. But
I'm even more hesitant about included unused #defines for "reserved"
fields, so if you drop this it would take care of both :)
> +#define PCI_PL_16GT_LE_CTRL 0x20 /* Lane Equalization Control Register */
This is the only register you actually use. You defined a local
PL16G_CAP_OFF_DSP_16G_TX_PRESET_MASK for this register. Shouldn't
that be defined here instead of in
drivers/pci/controller/dwc/pcie-tegra194.c?
> #endif /* LINUX_PCI_REGS_H */
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/5] drivers: spi: core: Add optional stall delay between cs_change transfers
From: Mark Brown @ 2019-07-09 14:12 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Alexandru Ardelean, linux-iio, linux-spi, devicetree,
linux-kernel, Michael Hennerich
In-Reply-To: <20190626193438.7248d0a9@archlinux>
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
On Wed, Jun 26, 2019 at 07:34:38PM +0100, Jonathan Cameron wrote:
> On Tue, 25 Jun 2019 16:13:25 +0300
> Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
>
> > Some devices like the ADIS16460 IMU require a stall period between
> > transfers, i.e. between when the CS is de-asserted and re-asserted. The
> > default value of 10us is not enough. This change makes the delay
> > configurable for when the next CS change goes active.
This looks like cs_change_delay.
As documented in SubmittingPatches please send patches to the
maintainers for the code you would like to change. The normal kernel
workflow is that people apply patches from their inboxes, if they aren't
copied they are likely to not see the patch at all and it is much more
difficult to apply patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/10] net: hisilicon: HI13X1_GMAX need dreq reset at first
From: Jiangfeng Xiao @ 2019-07-09 13:48 UTC (permalink / raw)
To: Sergei Shtylyov, davem, robh+dt, yisen.zhuang, salil.mehta,
mark.rutland, dingtianhong
Cc: netdev, devicetree, linux-kernel, leeyou.li, nixiaoming,
jianping.liu, xiekunxun
In-Reply-To: <890c48d1-76b8-5aea-e175-aa7d9967acd2@cogentembedded.com>
On 2019/7/9 17:35, Sergei Shtylyov wrote:
> Hello!
>
> On 09.07.2019 6:31, Jiangfeng Xiao wrote:
>
>> HI13X1_GMAC delete request for soft reset at first,
>> otherwise, the subsequent initialization will not
>> take effect.
>>
>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>> ---
>> drivers/net/ethernet/hisilicon/hip04_eth.c | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
>> index fe61b01..19d8cfd 100644
>> --- a/drivers/net/ethernet/hisilicon/hip04_eth.c
>> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
> [...]
>> @@ -853,6 +867,15 @@ static int hip04_mac_probe(struct platform_device *pdev)
>> goto init_fail;
>> }
>> +#if defined(CONFIG_HI13X1_GMAC)
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> + priv->sysctrl_base = devm_ioremap_resource(d, res);
>
> There's devm_platform_ioremap_resource() now.
Thank you for your review, Great issue, which makes my code more concise.
I will fix it in v3. Or submit a patch to modify it separately, if maintainer
applies this patch series.
^ permalink raw reply
* Re: [PATCH 0/5]Add support for mt2701 JPEG ENC support
From: Hans Verkuil @ 2019-07-09 13:46 UTC (permalink / raw)
To: Xia Jiang, Rob Herring, Matthias Brugger, Rick Chang
Cc: linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Marek Szyprowski, Tomasz Figa, srv_heupstream
In-Reply-To: <20190709032103.10291-1-xia.jiang@mediatek.com>
On 7/9/19 5:20 AM, Xia Jiang wrote:
> This patchset add support for mt2701 JPEG ENC support.
>
> This is the compliance test result for jpeg dec and enc.
>
> The JPEG dec log:
> ------------------------------------------------------------
> v4l2-compliance -d /dev/video0
> v4l2-compliance SHA: 08fed4d0edb1492b91d9d1054c36fed95c372eaa, 32 bits
Hmm, the SHA indicates that you are using an old v4l2-compliance version.
Please get the latest code from the v4l-utils git repo.
<snip>
> Buffer ioctls:
> fail: v4l2-test-buffers.cpp(713): q.create_bufs(node, 1, &fmt) != EINVAL
This should be fixed: this test tries to create a buffer of half the minimum
size, and the driver doesn't check that it is too small.
Ditto for the encoder.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH V12 01/12] PCI: Add #defines for some of PCIe spec r4.0 features
From: Vidya Sagar @ 2019-07-09 13:38 UTC (permalink / raw)
To: bhelgaas
Cc: lorenzo.pieralisi, robh+dt, mark.rutland, thierry.reding,
jonathanh, kishon, catalin.marinas, will.deacon, jingoohan1,
gustavo.pimentel, digetx, mperttunen, linux-pci, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel, kthota, mmaddireddy,
sagar.tv
In-Reply-To: <66d8af45-66f5-b597-0ea8-39e8662df5e6@nvidia.com>
On 7/5/2019 7:16 PM, Vidya Sagar wrote:
Bjorn,
Apologies for pinging again about this.
Can you please provide Ack for this change so that Lorenzo can pick up this series?
Thanks,
Vidya Sagar
> On 7/1/2019 6:09 PM, Vidya Sagar wrote:
> Bjorn,
> Can you please provide Ack for this patch?
>
> Thanks,
> Vidya Sagar
>
>> Add #defines only for the Data Link Feature and Physical Layer 16.0 GT/s
>> features.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> Reviewed-by: Thierry Reding <treding@nvidia.com>
>> ---
>> Changes since [v11]:
>> * None
>>
>> Changes since [v10]:
>> * None
>>
>> Changes since [v9]:
>> * None
>>
>> Changes since [v8]:
>> * None
>>
>> Changes since [v7]:
>> * None
>>
>> Changes since [v6]:
>> * None
>>
>> Changes since [v5]:
>> * None
>>
>> Changes since [v4]:
>> * None
>>
>> Changes since [v3]:
>> * None
>>
>> Changes since [v2]:
>> * Updated commit message and description to explicitly mention that defines are
>> added only for some of the features and not all.
>>
>> Changes since [v1]:
>> * None
>>
>> include/uapi/linux/pci_regs.h | 22 +++++++++++++++++++++-
>> 1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>> index f28e562d7ca8..1c79f6a097d2 100644
>> --- a/include/uapi/linux/pci_regs.h
>> +++ b/include/uapi/linux/pci_regs.h
>> @@ -713,7 +713,9 @@
>> #define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port Containment */
>> #define PCI_EXT_CAP_ID_L1SS 0x1E /* L1 PM Substates */
>> #define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement */
>> -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM
>> +#define PCI_EXT_CAP_ID_DLF 0x25 /* Data Link Feature */
>> +#define PCI_EXT_CAP_ID_PL 0x26 /* Physical Layer 16.0 GT/s */
>> +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL
>> #define PCI_EXT_CAP_DSN_SIZEOF 12
>> #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
>> @@ -1053,4 +1055,22 @@
>> #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe0000000 /* LTR_L1.2_THRESHOLD_Scale */
>> #define PCI_L1SS_CTL2 0x0c /* Control 2 Register */
>> +/* Data Link Feature */
>> +#define PCI_DLF_CAP 0x04 /* Capabilities Register */
>> +#define PCI_DLF_LOCAL_DLF_SUP_MASK 0x007fffff /* Local Data Link Feature Supported */
>> +#define PCI_DLF_EXCHANGE_ENABLE 0x80000000 /* Data Link Feature Exchange Enable */
>> +#define PCI_DLF_STS 0x08 /* Status Register */
>> +#define PCI_DLF_REMOTE_DLF_SUP_MASK 0x007fffff /* Remote Data Link Feature Supported */
>> +#define PCI_DLF_REMOTE_DLF_SUP_VALID 0x80000000 /* Remote Data Link Feature Support Valid */
>> +
>> +/* Physical Layer 16.0 GT/s */
>> +#define PCI_PL_16GT_CAP 0x04 /* Capabilities Register */
>> +#define PCI_PL_16GT_CTRL 0x08 /* Control Register */
>> +#define PCI_PL_16GT_STS 0x0c /* Status Register */
>> +#define PCI_PL_16GT_LDPM_STS 0x10 /* Local Data Parity Mismatch Status Register */
>> +#define PCI_PL_16GT_FRDPM_STS 0x14 /* First Retimer Data Parity Mismatch Status Register */
>> +#define PCI_PL_16GT_SRDPM_STS 0x18 /* Second Retimer Data Parity Mismatch Status Register */
>> +#define PCI_PL_16GT_RSVD 0x1C /* Reserved */
>> +#define PCI_PL_16GT_LE_CTRL 0x20 /* Lane Equalization Control Register */
>> +
>> #endif /* LINUX_PCI_REGS_H */
>>
>
^ permalink raw reply
* Re: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
From: Rob Herring @ 2019-07-09 13:31 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, jassisinghbrar@gmail.com,
sudeep.holla@arm.com, f.fainelli@gmail.com, kernel@pengutronix.de,
dl-linux-imx, shawnguo@kernel.org, festevam@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
van.freenix@gmail.com
In-Reply-To: <AM0PR04MB44816C38C43A3C8E09E8FFF588F10@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Mon, Jul 8, 2019 at 7:40 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> Hi Rob,
>
> > Subject: Re: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC
> > mailbox
> >
> > On Mon, Jun 03, 2019 at 04:30:04PM +0800, peng.fan@nxp.com wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > The ARM SMC mailbox binding describes a firmware interface to trigger
> > > actions in software layers running in the EL2 or EL3 exception levels.
> > > The term "ARM" here relates to the SMC instruction as part of the ARM
> > > instruction set, not as a standard endorsed by ARM Ltd.
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > >
> > > V2:
> > > Introduce interrupts as a property.
> > >
> > > V1:
> > > arm,func-ids is still kept as an optional property, because there is
> > > no defined SMC funciton id passed from SCMI. So in my test, I still
> > > use arm,func-ids for ARM SIP service.
> > >
> > > .../devicetree/bindings/mailbox/arm-smc.txt | 101
> > +++++++++++++++++++++
> > > 1 file changed, 101 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > > b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > > new file mode 100644
> > > index 000000000000..401887118c09
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > > @@ -0,0 +1,101 @@
> > > +ARM SMC Mailbox Interface
> > > +=========================
> > > +
> > > +This mailbox uses the ARM smc (secure monitor call) instruction to
> > > +trigger a mailbox-connected activity in firmware, executing on the
> > > +very same core as the caller. By nature this operation is synchronous
> > > +and this mailbox provides no way for asynchronous messages to be
> > > +delivered the other way round, from firmware to the OS, but
> > > +asynchronous notification could also be supported. However the value
> > > +of r0/w0/x0 the firmware returns after the smc call is delivered as a
> > > +received message to the mailbox framework, so a synchronous
> > > +communication can be established, for a asynchronous notification, no
> > > +value will be returned. The exact meaning of both the action the
> > > +mailbox triggers as well as the return value is defined by their users and is
> > not subject to this binding.
> > > +
> > > +One use case of this mailbox is the SCMI interface, which uses shared
> > > +memory to transfer commands and parameters, and a mailbox to trigger
> > > +a function call. This allows SoCs without a separate management
> > > +processor (or when such a processor is not available or used) to use
> > > +this standardized interface anyway.
> > > +
> > > +This binding describes no hardware, but establishes a firmware interface.
> > > +Upon receiving an SMC using one of the described SMC function
> > > +identifiers, the firmware is expected to trigger some mailbox connected
> > functionality.
> > > +The communication follows the ARM SMC calling convention[1].
> > > +Firmware expects an SMC function identifier in r0 or w0. The
> > > +supported identifiers are passed from consumers, or listed in the the
> > > +arm,func-ids properties as described below. The firmware can return
> > > +one value in the first SMC result register, it is expected to be an
> > > +error value, which shall be propagated to the mailbox client.
> > > +
> > > +Any core which supports the SMC or HVC instruction can be used, as
> > > +long as a firmware component running in EL3 or EL2 is handling these calls.
> > > +
> > > +Mailbox Device Node:
> > > +====================
> > > +
> > > +This node is expected to be a child of the /firmware node.
> > > +
> > > +Required properties:
> > > +--------------------
> > > +- compatible: Shall be "arm,smc-mbox"
> > > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > > +- arm,num-chans The number of channels supported.
> > > +- method: A string, either:
> > > + "hvc": if the driver shall use an HVC call, or
> > > + "smc": if the driver shall use an SMC call.
> > > +
> > > +Optional properties:
> > > +- arm,func-ids An array of 32-bit values specifying the function
> > > + IDs used by each mailbox channel. Those function IDs
> > > + follow the ARM SMC calling convention standard [1].
> > > + There is one identifier per channel and the number
> > > + of supported channels is determined by the length
> > > + of this array.
> > > +- interrupts SPI interrupts may be listed for notification,
> > > + each channel should use a dedicated interrupt
> > > + line.
> > > +
> > > +Example:
> > > +--------
> > > +
> > > + sram@910000 {
> > > + compatible = "mmio-sram";
> > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > +
> > > + cpu_scp_lpri: scp-shmem@0 {
> > > + compatible = "arm,scmi-shmem";
> > > + reg = <0x0 0x200>;
> > > + };
> > > +
> > > + cpu_scp_hpri: scp-shmem@200 {
> > > + compatible = "arm,scmi-shmem";
> > > + reg = <0x200 0x200>;
> > > + };
> > > + };
> > > +
> > > + smc_mbox: mailbox {
> >
> > This should be a child of 'firmware' node at least and really a child of the
> > firmware component that implements the feature.
>
> I checked other mbox driver, including the mbox used by ti sci, mbox used by
> i.MX8QXP. both mbox dts node not a child a firmware node,
Because those are actual h/w blocks and not implemented in firmware calls?
> I am not sure why put mbox node into a child a firmware node here.
If it is an interface provided by firmware, then it goes under /firmware.
Rob
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC
From: Rob Herring @ 2019-07-09 13:25 UTC (permalink / raw)
To: Shenhar, Talel
Cc: Nicolas Ferre, Jason Cooper, Marc Zyngier, Mark Rutland,
Mauro Carvalho Chehab, David Miller, Shawn Lin, Thomas Gleixner,
devicetree, Greg Kroah-Hartman, linux-kernel@vger.kernel.org,
dwmw, Benjamin Herrenschmidt, jonnyc, hhhawa, ronenk, hanochu,
barakw
In-Reply-To: <f1fd393d-0b8c-16f1-9ac2-0589e9cb9ea7@amazon.com>
On Tue, Jul 9, 2019 at 12:00 AM Shenhar, Talel <talel@amazon.com> wrote:
>
> Marc, should I publish those fixes as new patch that updates the
> dt-bindings or new patchset to this list?
>
> On 7/9/2019 5:23 AM, Rob Herring wrote:
> > On Mon, Jun 10, 2019 at 11:34:42AM +0300, Talel Shenhar wrote:
> >> +- #interrupt-cells: must be 2.
> >> + First cell defines the index of the interrupt within the controller.
> >> + Second cell is used to specify the trigger type and must be one of the
> >> + following:
> >> + - bits[3:0] trigger type and level flags
> >> + 1 = low-to-high edge triggered
> >> + 4 = active high level-sensitive
> > No need to define this here. Reference the standard definition.
>
> This device only support those two modes.
>
> This definition tries to capture the supported modes.
>
> Should I just state that those two modes are supported and then avoid
> the actual bits and values?
Yes.
Rob
^ permalink raw reply
* Re: [PATCH V2 2/2] dt-bindings: Document the DesignWare IP reset bindings
From: Rob Herring @ 2019-07-09 13:23 UTC (permalink / raw)
To: Luis de Oliveira
Cc: p.zabel@pengutronix.de, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Joao.Pinto@synopsys.com, Gustavo Pimentel
In-Reply-To: <MN2PR12MB371095ABA70D43398ABF982CCBF10@MN2PR12MB3710.namprd12.prod.outlook.com>
On Tue, Jul 9, 2019 at 4:33 AM Luis de Oliveira
<Luis.Oliveira@synopsys.com> wrote:
>
> Hi Rob,
>
> Thank you for the comments,
>
> From: Rob Herring <robh@kernel.org>
> Date: Tue, Jul 09, 2019 at 02:52:20
>
> > On Thu, Jun 06, 2019 at 05:36:28PM +0200, Luis Oliveira wrote:
> > > This adds documentation of device tree bindings for the
> > > DesignWare IP reset controller.
> > >
> > > Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> > > Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
> > > ---
> > > Changelog
> > > - Add active low configuration example
> > > - Fix compatible string in the active high example
> > >
> > > .../devicetree/bindings/reset/snps,dw-reset.txt | 30 ++++++++++++++++++++++
> > > 1 file changed, 30 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > > new file mode 100644
> > > index 0000000..85f3301
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > > @@ -0,0 +1,30 @@
> > > +Synopsys DesignWare Reset controller
> > > +=======================================
> > > +
> > > +Please also refer to reset.txt in this directory for common reset
> > > +controller binding usage.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible: should be one of the following.
> > > + "snps,dw-high-reset" - for active high configuration
> > > + "snps,dw-low-reset" - for active low configuration
> >
> > This is really a standalone block?
> >
> > Are there versions of IP?
> >
>
> We use this block because is is very simple. The Verilog is autogenerated
> after an simple input configuration (APB config, reset pin number, active
> high/low, etc) so it does not need versioning.
> We use it in almost all our testchips and prototyping, and it is a
> standalone block.
Okay.
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 9/9] ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add property for digital filter for i2c0 node sama5d4_xplained
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index fdfc37d..298113c 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -49,6 +49,7 @@
};
i2c0: i2c@f8014000 {
+ i2c-dig-filter;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 8/9] ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add property for analog and digital filter for i2c1 and i2c2 nodes
for sama5d2_xplained
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 808e399..965326c 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -334,6 +334,9 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flx4_default>;
atmel,fifo-size = <16>;
+ i2c-ana-filter;
+ i2c-dig-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
};
};
@@ -342,6 +345,9 @@
dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1_default>;
+ i2c-ana-filter;
+ i2c-dig-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
at24@54 {
--
2.7.4
^ permalink raw reply related
* [PATCH v3 7/9] i2c: at91: add support for analog filtering
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 18 ++++++++++++++----
drivers/i2c/busses/i2c-at91.h | 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 3bbe37c..d2840ba 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index 344fd26..4b89610 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,20 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(dev->filter_width) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr && dev->enable_ana_filt)
+ filtr |= AT91_TWI_FILTR_PADFEN;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
@@ -825,6 +833,8 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
"i2c-dig-filter");
+ dev->enable_ana_filt = of_property_read_bool(pdev->dev.of_node,
+ "i2c-ana-filter");
at91_calc_twi_clock(dev);
dev->adapter.algo = &at91_twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index d7cf01e3..977a67b 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,7 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILT BIT(0)
+#define AT91_TWI_FILTR_PADFEN BIT(1)
#define AT91_TWI_FILTR_THRES(v) ((v) << 8)
#define AT91_TWI_FILTR_THRES_MAX 7
#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
@@ -116,6 +117,7 @@ struct at91_twi_pdata {
bool has_hold_field;
bool has_dig_filtr;
bool has_adv_dig_filtr;
+ bool has_ana_filtr;
struct at_dma_slave dma_slave;
};
@@ -154,6 +156,7 @@ struct at91_twi_dev {
struct i2c_client *slave;
#endif
bool enable_dig_filt;
+ bool enable_ana_filt;
u32 filter_width;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/9] i2c: at91: add support for advanced digital filtering
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 30 +++++++++++++++++++++++++++---
drivers/i2c/busses/i2c-at91.h | 5 +++++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 62610af..3bbe37c 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index 099161a..344fd26 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
@@ -51,7 +57,7 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
*/
static void at91_calc_twi_clock(struct at91_twi_dev *dev)
{
- int ckdiv, cdiv, div, hold = 0;
+ int ckdiv, cdiv, div, hold = 0, filter_width = 0;
struct at91_twi_pdata *pdata = dev->pdata;
int offset = pdata->clk_offset;
int max_ckdiv = pdata->clk_max_div;
@@ -90,11 +96,29 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev)
}
}
+ if (pdata->has_adv_dig_filtr) {
+ /*
+ * filter width = 0 to AT91_TWI_FILTR_THRES_MAX
+ * peripheral clocks
+ */
+ filter_width = DIV_ROUND_UP(t->filter_width_ns
+ * (clk_get_rate(dev->clk) / 1000), 1000000);
+ if (filter_width > AT91_TWI_FILTR_THRES_MAX) {
+ dev_warn(dev->dev,
+ "Filter threshold set to its maximum value (%d instead of %d)\n",
+ AT91_TWI_FILTR_THRES_MAX, filter_width);
+ filter_width = AT91_TWI_FILTR_THRES_MAX;
+ }
+ }
+
dev->twi_cwgr_reg = (ckdiv << 16) | (cdiv << 8) | cdiv
| AT91_TWI_CWGR_HOLD(hold);
- dev_dbg(dev->dev, "cdiv %d ckdiv %d hold %d (%d ns)\n",
- cdiv, ckdiv, hold, t->sda_hold_ns);
+ dev->filter_width = filter_width;
+
+ dev_dbg(dev->dev, "cdiv %d ckdiv %d hold %d (%d ns), filter_width %d (%d ns)\n",
+ cdiv, ckdiv, hold, t->sda_hold_ns, filter_width,
+ t->filter_width_ns);
}
static void at91_twi_dma_cleanup(struct at91_twi_dev *dev)
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index c75447e..d7cf01e3 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -86,6 +86,9 @@
#define AT91_TWI_FILTR 0x0044
#define AT91_TWI_FILTR_FILT BIT(0)
+#define AT91_TWI_FILTR_THRES(v) ((v) << 8)
+#define AT91_TWI_FILTR_THRES_MAX 7
+#define AT91_TWI_FILTR_THRES_MASK GENMASK(10, 8)
#define AT91_TWI_FMR 0x0050 /* FIFO Mode Register */
#define AT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
@@ -112,6 +115,7 @@ struct at91_twi_pdata {
bool has_alt_cmd;
bool has_hold_field;
bool has_dig_filtr;
+ bool has_adv_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -150,6 +154,7 @@ struct at91_twi_dev {
struct i2c_client *slave;
#endif
bool enable_dig_filt;
+ u32 filter_width;
};
unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 5/9] i2c: at91: add support for digital filtering
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 9 +++++++++
drivers/i2c/busses/i2c-at91-master.c | 9 +++++++++
drivers/i2c/busses/i2c-at91.h | 5 +++++
3 files changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index a663a7a..62610af 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index e87232f..099161a 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
@@ -792,6 +798,9 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
}
+ dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
+ "i2c-dig-filter");
+
at91_calc_twi_clock(dev);
dev->adapter.algo = &at91_twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..c75447e 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#define AT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#define AT91_TWI_ACR_DIR BIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILT BIT(0)
+
#define AT91_TWI_FMR 0x0050 /* FIFO Mode Register */
#define AT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#define AT91_TWI_FMR_TXRDYM_MASK (0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -145,6 +149,7 @@ struct at91_twi_dev {
unsigned smr;
struct i2c_client *slave;
#endif
+ bool enable_dig_filt;
};
unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/9] i2c: at91: add new platform support for sam9x60
From: Eugen.Hristev @ 2019-07-09 13:19 UTC (permalink / raw)
To: wsa, peda, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
Cc: Nicolas.Ferre, Eugen.Hristev
In-Reply-To: <1562678049-17581-1-git-send-email-eugen.hristev@microchip.com>
From: Eugen Hristev <eugen.hristev@microchip.com>
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index 8d55cdd..a663a7a 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = &sama5d2_config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = &sam9x60_config,
+ }, {
/* sentinel */
}
};
--
2.7.4
^ permalink raw reply related
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