* [PATCH v3 1/8] dt-bindings: Document STM32 DCMI bindings
From: Hugues Fruchet @ 2017-04-04 15:44 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
Mauro Carvalho Chehab, Hans Verkuil
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, Benjamin Gaignard,
Yannick Fertre, Hugues Fruchet
In-Reply-To: <1491320678-17246-1-git-send-email-hugues.fruchet-qxv4g6HH51o@public.gmane.org>
This adds documentation of device tree bindings for the STM32 DCMI
(Digital Camera Memory Interface).
Signed-off-by: Hugues Fruchet <hugues.fruchet-qxv4g6HH51o@public.gmane.org>
---
.../devicetree/bindings/media/st,stm32-dcmi.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
new file mode 100644
index 0000000..c0f6f4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
+
+Required properties:
+- compatible: "st,stm32-dcmi"
+- reg: physical base address and length of the registers set for the device
+- interrupts: should contain IRQ line for the DCMI
+- resets: reference to a reset controller,
+ see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property
+- clock-names: must contain "mclk", which is the DCMI peripherial clock
+- pinctrl: the pincontrol settings to configure muxing properly
+ for pins that connect to DCMI device.
+ See Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt.
+- dmas: phandle to DMA controller node,
+ see Documentation/devicetree/bindings/dma/stm32-dma.txt
+- dma-names: must contain "tx", which is the transmit channel from DCMI to DMA
+
+DCMI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ dcmi: dcmi@50050000 {
+ compatible = "st,stm32-dcmi";
+ reg = <0x50050000 0x400>;
+ interrupts = <78>;
+ resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
+ clock-names = "mclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcmi_pins>;
+ dmas = <&dma2 1 1 0x414 0x3>;
+ dma-names = "tx";
+ port {
+ dcmi_0: endpoint@0 {
+ remote-endpoint = <...>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series
From: Hugues Fruchet @ 2017-04-04 15:44 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
Mauro Carvalho Chehab, Hans Verkuil
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-media,
Benjamin Gaignard, Yannick Fertre, Hugues Fruchet
This patchset introduces a basic support for Digital Camera Memory Interface
(DCMI) of STMicroelectronics STM32 SoC series.
This first basic support implements RGB565 & YUV frame grabbing.
Cropping and JPEG support will be added later on.
This has been tested on STM324x9I-EVAL evaluation board embedding
an OV2640 camera sensor.
This driver depends on:
- [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers http://www.spinics.net/lists/linux-media/msg113480.html
===========
= history =
===========
version 3:
- stm32-dcmi: Add "Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>"
- dt-bindings: Fix remarks from Rob Herring:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html
version 2:
- Fix a Kbuild warning in probe:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html
- Fix a warning in dcmi_queue_setup()
- dt-bindings: warn on sensor signals level inversion in board example
- Typos fixing
version 1:
- Initial submission
===================
= v4l2-compliance =
===================
Below is the v4l2-compliance report for this current version of the DCMI camera interface.
v4l2-compliance has been built from v4l-utils-1.12.3.
v4l2-compliance SHA : f5f45e17ee98a0ebad7836ade2b34ceec909d751
Driver Info:
Driver name : stm32-dcmi
Card type : STM32 Digital Camera Memory Int
Bus info : platform:dcmi
Driver version: 4.11.0
Capabilities : 0x85200001
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x05200001
Video Capture
Read/Write
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 3 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Streaming ioctls:
test read/write: OK
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total: 46, Succeeded: 46, Failed: 0, Warnings: 0
Hugues Fruchet (8):
dt-bindings: Document STM32 DCMI bindings
[media] stm32-dcmi: STM32 DCMI camera interface driver
ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL
board
ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board
ARM: configs: stm32: STMPE1600 GPIO expander
ARM: configs: stm32: DCMI + OV2640 camera support
.../devicetree/bindings/media/st,stm32-dcmi.txt | 46 +
arch/arm/boot/dts/stm32429i-eval.dts | 56 +
arch/arm/boot/dts/stm32f429.dtsi | 37 +
arch/arm/configs/stm32_defconfig | 9 +
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/stm32/Makefile | 1 +
drivers/media/platform/stm32/stm32-dcmi.c | 1419 ++++++++++++++++++++
8 files changed, 1582 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
create mode 100644 drivers/media/platform/stm32/Makefile
create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH v4 3/6] dt-bindings: soc: rockchip: grf: add support for rk3328
From: Heiko Stuebner @ 2017-04-04 15:44 UTC (permalink / raw)
To: cl
Cc: robh+dt, mark.rutland, zhengxing, andy.yan, jay.xu, matthias.bgg,
paweljarosz3691, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, wsa, linux-i2c, jic23, knaack.h, lars, pmeerw, wxt,
david.wu, linux-iio, shawn.lin, akpm, dianders, yamada.masahiro,
catalin.marinas, will.deacon, afaerber, shawnguo, khilman, arnd,
fabio.estevam, zhangqing, kever.yang
In-Reply-To: <1490607650-18650-3-git-send-email-cl@rock-chips.com>
Am Montag, 27. März 2017, 17:40:47 CEST schrieb cl@rock-chips.com:
> From: Liang Chen <cl@rock-chips.com>
>
> Signed-off-by: Liang Chen <cl@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
applied for 4.12 after rewording the subject and adding a real commit
message.
Please do not leave the actual commit message empty in future patches.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: dts: sun7i: Add can0_pins_a pinctrl settings
From: Maxime Ripard @ 2017-04-04 15:43 UTC (permalink / raw)
To: Patrick Menschel
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491238814-4888-5-git-send-email-menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
On Mon, Apr 03, 2017 at 07:00:14PM +0200, Patrick Menschel wrote:
> The A20 SoC has an on-board CAN controller. This patch adds
> the pinctrl settings for pins PH20 and PH21.
>
> This patch is adapted from the description in
> Documentation/devicetree/bindings/net/can/sun4i_can.txt
>
> Signed-off-by: Patrick Menschel <menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index c637e10..8536caf 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -1096,6 +1096,11 @@
> #interrupt-cells = <3>;
> #gpio-cells = <3>;
>
> + can0_pins_a: can0@0 {
> + pins = "PH20","PH21";
Same thing here, you need a space after that comma. I've fixed it and
applied the patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: sun4i: Add can0_pins_a pinctrl settings
From: Maxime Ripard @ 2017-04-04 15:40 UTC (permalink / raw)
To: Patrick Menschel
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel, linux-can
In-Reply-To: <1491238814-4888-3-git-send-email-menschel.p@posteo.de>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Mon, Apr 03, 2017 at 07:00:12PM +0200, Patrick Menschel wrote:
> The A10 SoC has an on-board CAN controller. This patch adds the
> pinctrl settings for pins PH20 and PH21.
>
> This patch is adapted from the description in
> Documentation/devicetree/bindings/net/can/sun4i_can.txt
>
> Signed-off-by: Patrick Menschel <menschel.p@posteo.de>
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 7c559e7..f7dced4 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -974,6 +974,11 @@
> #interrupt-cells = <3>;
> #gpio-cells = <3>;
>
> + can0_pins_a: can0@0 {
> + pins = "PH20","PH21";
You need a space after the comma here. Fixed and applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: sun4i: Add CAN node
From: Maxime Ripard @ 2017-04-04 15:40 UTC (permalink / raw)
To: Patrick Menschel
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491238814-4888-2-git-send-email-menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]
On Mon, Apr 03, 2017 at 07:00:11PM +0200, Patrick Menschel wrote:
> The A10 SoC has an on-board CAN controller.
> This patch adds the device node.
>
> This patch is adapted from the description in
> Documentation/devicetree/bindings/net/can/sun4i_can.txt
>
> Signed-off-by: Patrick Menschel <menschel.p-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> index ba20b48..7c559e7 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -1313,6 +1313,14 @@
> #size-cells = <0>;
> };
>
> + can0: can@01c2bc00 {
> + compatible = "allwinner,sun4i-a10-can";
> + reg = <0x01c2bc00 0x400>;
> + interrupts = <26>;
> + clocks = <&apb1_gates 4>;
> + status = "disabled";
> + };
> +
This wasn't ordered properly. Fixed and applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 3/5] drm/exynos: dsi: Fix the parse_dt function
From: Krzysztof Kozlowski @ 2017-04-04 15:38 UTC (permalink / raw)
To: Inki Dae
Cc: Hoegeun Kwon, jy0922.shim, Seung Woo Kim, airlied, kgene, robh+dt,
mark.rutland, catalin.marinas, will.deacon,
Javier Martinez Canillas, dri-devel, linux-arm-kernel,
linux-samsung-soc, linux-kernel, devicetree, a.hajda, Andi Shyti,
LW, Marek Szyprowski, Sylwester Nawrocki
In-Reply-To: <CAJKOXPeD4HKemKTrnC2JaON3JkuNGO9g+Hg8M7F6f2WusiYkhg@mail.gmail.com>
On Tue, Mar 28, 2017 at 11:38 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae <inki.dae@samsung.com> wrote:
>> Merged.
>
> Hi,
>
> I do not see the tag (with DT patches) merged by you which I provided
> to you before. These are essential for bisectability. Without them,
> kernel bisectability is broken. Did you merged the tag somewhere?
>
> Best regards,
> Krzysztof
>
>> Thanks,
>> Inki Dae
Inki,
I still do not see the DTS tag [1] merged in your tree but you applied
patches breaking the display. I looked at exynos-drm-next branch.
We talked already about bisectability and with Hoegeun we provided
proper solution. Hoegeun split the patchset and I sent you a stable
tag to merge. Be aware not to apply the DTS patch because you would
effectively duplicate it. Instead, deal like with any pull request -
merge the tag as dependency *before* applying DRM DSI patch.
I saw also a branch like this:
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-tm2
but this is something obviously wrong. I do not know what are your
plans to do with it, but please drop it as it brings only confusion.
Best regards,
Krzysztof
[1] https://www.spinics.net/lists/arm-kernel/msg567053.html
>> 2017년 03월 22일 10:36에 Hoegeun Kwon 이(가) 쓴 글:
>>> Hi inki,
>>>
>>> Could you check the this patch?
>>> For reference, patch 1/5 and 2/5 have already been applied to Krzysztof tree.
>>>
>>> Best regards,
>>> Hoegeun
>>>
^ permalink raw reply
* Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver
From: Marc Kleine-Budde @ 2017-04-04 15:34 UTC (permalink / raw)
To: Akshay Bhat, wg-5Yr1BZd7O62+XT7JhA+gdA
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Akshay Bhat
In-Reply-To: <32114de2-8ab7-daec-9b36-209cab0ea550-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2652 bytes --]
On 03/24/2017 06:20 PM, Akshay Bhat wrote:
> Hi Marc,
>
> On 03/17/2017 05:10 PM, Akshay Bhat wrote:
>> This patch adds support for the Holt HI-311x CAN controller. The HI311x
>> CAN controller is capable of transmitting and receiving standard data
>> frames, extended data frames and remote frames. The HI311x interfaces
>> with the host over SPI.
>>
>> Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do
>>
>> Signed-off-by: Akshay Bhat <nodeax-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>
>
> If there are no further review comments can this series be applied to
> can-next or does it need to wait for the next kernel release cycle (4.13)?
The driver doesn't check if the workqueue allocation is successfull,
I've squashed this patch:
> diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
> index ff4bb40d855e..170e8e3971b2 100644
> --- a/drivers/net/can/spi/hi311x.c
> +++ b/drivers/net/can/spi/hi311x.c
> @@ -780,20 +780,24 @@ static int hi3110_open(struct net_device *net)
>
> priv->wq = alloc_workqueue("hi3110_wq", WQ_FREEZABLE | WQ_MEM_RECLAIM,
> 0);
> + if (!priv->wq) {
> + ret = -ENOMEM;
> + goto out_free_irq;
> + }
> INIT_WORK(&priv->tx_work, hi3110_tx_work_handler);
> INIT_WORK(&priv->restart_work, hi3110_restart_work_handler);
>
> ret = hi3110_hw_reset(spi);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> ret = hi3110_setup(net);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> ret = hi3110_set_normal_mode(spi);
> if (ret)
> - goto out_free_irq;
> + goto out_free_wq;
>
> can_led_event(net, CAN_LED_EVENT_OPEN);
> netif_wake_queue(net);
> @@ -801,11 +805,12 @@ static int hi3110_open(struct net_device *net)
>
> return 0;
>
> -out_free_irq:
> + out_free_wq:
> + destroy_workqueue(priv->wq);
> + out_free_irq:
> free_irq(spi->irq, priv);
> hi3110_hw_sleep(spi);
> -
> -out_close:
> + out_close:
> hi3110_power_enable(priv->transceiver, 0);
> close_candev(net);
> mutex_unlock(&priv->hi3110_lock);
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: keystone: Add support for new K2G evm
From: Santosh Shilimkar @ 2017-04-04 15:33 UTC (permalink / raw)
To: Franklin S Cooper Jr, ssantosh, devicetree, linux-kernel,
linux-arm-kernel
Cc: robh+dt, linux
In-Reply-To: <694db3ba-cf40-790b-29e0-39f34607caf3@oracle.com>
On 4/3/2017 9:44 AM, santosh.shilimkar@oracle.com wrote:
> Hi Franklin,
>
> On 3/30/17 8:29 AM, Franklin S Cooper Jr wrote:
>> This patchset adds support for new K2G Industrial Communication Engine
>> evm. For now only a bare minimal dts which will allow ram boot.
>> Additional
>> peripherals will be added when base K2G SoC patches are upstreamed
>> allowing
>> peripherals to be enabled.
>>
>
>> ARM: keystone: Create new binding for K2G ICE evm
>> ARM: dts: keystone: Add minimum support for K2G ICE evm
>>
> Can you clarify Rob's comment on second patch and re-post the updated
> patch with his ack if you agree ? Will apply the series.
>
Just to be clear, you need to send v2 with Rob's comment addressed
for me to pick it up.
Regards,
Snatosh
^ permalink raw reply
* [PATCH v4 8/8] ARM: ux500: Add vendor prefix to tps61052 node
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Aaro Koskinen, Tony Lindgren,
Russell King, Javier Martinez Canillas, Rob Herring, Lee Jones,
linux-arm-kernel
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The tps61052 device node doesn't have a vendor prefix
in its compatible string, fix it by adding one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ste-hrefprev60.dtsi b/arch/arm/boot/dts/ste-hrefprev60.dtsi
index 5882a2606ac3..3f14b4df69b4 100644
--- a/arch/arm/boot/dts/ste-hrefprev60.dtsi
+++ b/arch/arm/boot/dts/ste-hrefprev60.dtsi
@@ -30,7 +30,7 @@
i2c@80004000 {
tps61052@33 {
- compatible = "tps61052";
+ compatible = "ti,tps61052";
reg = <0x33>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 7/8] mfd: tps6105x: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
drivers/mfd/tps6105x.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
index baa12ea666fb..187848c93779 100644
--- a/drivers/mfd/tps6105x.c
+++ b/drivers/mfd/tps6105x.c
@@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tps6105x_id);
+static const struct of_device_id tps6105x_of_match[] = {
+ { .compatible = "ti,tps61050" },
+ { .compatible = "ti,tps61052" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tps6105x_of_match);
+
static struct i2c_driver tps6105x_driver = {
.driver = {
.name = "tps6105x",
+ .of_match_table = tps6105x_of_match,
},
.probe = tps6105x_probe,
.remove = tps6105x_remove,
--
2.9.3
^ permalink raw reply related
* [PATCH v4 6/8] dt-bindings: mfd: Add TI tps6105x chip bindings
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
There are Device Tree source files defining a device node for the
tps61050/61052 I2C chip but there isn't a binding document for it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
new file mode 100644
index 000000000000..93602c7a19c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for TI TPS61050/61052 Boost Converters
+
+The TP61050/TPS61052 is a high-power "white LED driver". The
+device provides LED, GPIO and regulator functionalities.
+
+Required properties:
+- compatible: "ti,tps61050" or "ti,tps61052"
+- reg: Specifies the I2C slave address
+
+Example:
+
+i2c0 {
+ tps61052@33 {
+ compatible = "ti,tps61052";
+ reg = <0x33>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Wolfram Sang, linux-i2c, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The example contains a device node for a retu device, but
its compatible string doesn't have a vendor prefix.
While being there, drop the -mfd suffix since isn't correct.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Avoid using MFD in Device Tree (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
index 8ce9cd2855b5..c143948b2a37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -20,8 +20,8 @@ i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
- retu-mfd: retu@1 {
- compatible = "retu-mfd";
+ retu: retu@1 {
+ compatible = "nokia,retu";
reg = <0x1>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 4/8] ARM: dts: n8x0: Add vendor prefix to retu node
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Aaro Koskinen, Tony Lindgren,
Russell King, Javier Martinez Canillas, Rob Herring,
Benoît Cousson, linux-omap, Lee Jones, linux-arm-kernel
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The retu device node doesn't have a vendor prefix
in its compatible string, fix it by adding one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1b06430c8013..91886231e5a8 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -16,7 +16,7 @@
#address-cells = <1>;
#size-cells = <0>;
retu: retu@1 {
- compatible = "retu";
+ compatible = "nokia,retu";
interrupt-parent = <&gpio4>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/8] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Drop -mfd suffix in compatible string (Lee Jones).
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
drivers/mfd/retu-mfd.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 53e1d386d2c0..e7d27b7861c1 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
};
MODULE_DEVICE_TABLE(i2c, retu_id);
+static const struct of_device_id retu_of_match[] = {
+ { .compatible = "nokia,retu" },
+ { .compatible = "nokia,tahvo" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, retu_of_match);
+
static struct i2c_driver retu_driver = {
.driver = {
.name = "retu-mfd",
+ .of_match_table = retu_of_match,
},
.probe = retu_probe,
.remove = retu_remove,
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Aaro Koskinen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Tony Lindgren, Lee Jones, Javier Martinez Canillas,
Benoît Cousson, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170404153036.6651-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
It's not correct to encode the subsystem in the I2C device name, so
drop the -mfd suffix. To maintain bisect-ability, change driver and
platform code / DTS users in the same patch.
Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
arch/arm/mach-omap1/board-nokia770.c | 4 ++--
drivers/mfd/retu-mfd.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 7e5ffc583c90..1b06430c8013 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -15,8 +15,8 @@
>;
#address-cells = <1>;
#size-cells = <0>;
- retu_mfd: retu@1 {
- compatible = "retu-mfd";
+ retu: retu@1 {
+ compatible = "retu";
interrupt-parent = <&gpio4>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index ee8d9f553db4..06243c0b12d2 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
{
- I2C_BOARD_INFO("retu-mfd", 0x01),
+ I2C_BOARD_INFO("retu", 0x01),
},
{
- I2C_BOARD_INFO("tahvo-mfd", 0x02),
+ I2C_BOARD_INFO("tahvo", 0x02),
},
};
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index d4c114abeb75..53e1d386d2c0 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id retu_id[] = {
- { "retu-mfd", 0 },
- { "tahvo-mfd", 0 },
+ { "retu", 0 },
+ { "tahvo", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, retu_id);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Mark Rutland
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
There are Device Tree source files defining a device node for the
retu/tahvo I2C chip, but there isn't a DT binding document for it.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
new file mode 100644
index 000000000000..7df21a2b28ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/retu.txt
@@ -0,0 +1,21 @@
+* Device tree bindings for Nokia Retu and Tahvo multi-function device
+
+Retu and Tahvo are a multi-function devices found on Nokia Internet
+Tablets (770, N800 and N810). The Retu chip provides watchdog timer
+and power button control functionalities while Tahvo chip provides
+USB transceiver functionality.
+
+Required properties:
+- compatible: "nokia,retu" or "nokia,tahvo"
+- reg: Specifies the I2C slave address of the ASIC chip
+
+Example:
+
+i2c0 {
+ retu: retu@1 {
+ compatible = "nokia,retu";
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x1>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Javier Martinez Canillas @ 2017-04-04 15:30 UTC (permalink / raw)
To: linux-kernel
Cc: Aaro Koskinen, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Javier Martinez Canillas, Benoît Cousson, Wolfram Sang,
Mark Rutland, linux-omap, Russell King, linux-arm-kernel,
linux-i2c
Hello,
This series add OF device ID tables to mfd I2C drivers whose devices are
either used in Device Tree source files or are listed in binding docs as
a compatible string.
That's done because the plan is to change the I2C core to report proper OF
modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if
a device was registered via DT or using the legacy platform data mechanism.
So these patches will make sure that mfd I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.
Users didn't have a vendor prefix in the used compatible strings, but since
there wasn't a DT binding document for these drivers, it can be said that
were working for mere luck and so this series fixes the users and add a DT
binding doc for the drivers.
Most patches can be applied independently, with the exception of patches
2 to 4 that should be applied in the same tree to keep bisect-ability.
Best regards,
Javier
Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Drop -mfd suffix in compatible string (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
- Add a vendor prefix to the compatible string (Rob Herring).
Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
Javier Martinez Canillas (8):
dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
mfd: retu: Drop -mfd suffix from I2C device ID name
mfd: retu: Add OF device ID table
ARM: dts: n8x0: Add vendor prefix to retu node
i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
dt-bindings: mfd: Add TI tps6105x chip bindings
mfd: tps6105x: Add OF device ID table
ARM: ux500: Add vendor prefix to tps61052 node
.../devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++++++++++++++++
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
arch/arm/mach-omap1/board-nokia770.c | 4 ++--
drivers/mfd/retu-mfd.c | 12 ++++++++++--
drivers/mfd/tps6105x.c | 8 ++++++++
8 files changed, 63 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt
--
2.9.3
^ permalink raw reply
* Re: [PATCH v2 2/7] rtc: Add rtc-sh
From: Geert Uytterhoeven @ 2017-04-04 15:27 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Brandt, Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAL_JsqLLZsLzS4ONOexJADQXXXr9iquFUcVj8kX6AEVwM+x56A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Tue, Apr 4, 2017 at 4:29 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Mar 29, 2017 at 1:49 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>>>> +Example:
>>>> +rtc: rtc@fcff1000 {
>>>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>>>> + reg = <0xfcff1000 0x2e>;
>>>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>>>> + interrupt-names = "alarm", "period", "carry";
>>>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>>>> + <&rtc_x3_clk>, <&extal_clk>;
>>>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>>>> + power-domains = <&cpg_clocks>;
>>>
>>> Not documented.
>>
>> "power-domains" is a platform property.
>>
>> All hardware components need power.
>> All synchronous hardware components need a clock.
>> Most hardware components have a reset signal.
>
> And we document clocks and reset for every binding.
Then we'll have to add lots of them ;-)
Usually these are documented only if the user (the driver) cares about them,
and/or if there are multiple of the same type. E.g.
- The driver needs to know or control a clock frequency,
- The driver needs to enable/disable a clock,
- The driver needs to know or control one or more voltages,
- ...
It's not that devices without documented regulators, power-domains, or clocks
properties no longer consume power or don't run from a clock. These are just
not described in DT, as deemed unimportant. But on some platforms, they may
become important.
>> Whether these are exposed and can be controlled depends on the platform/SoC.
>> So documenting them in each and every device binding looks overkill to me.
>> I think this is something to be addressed by devicetree-specification (which
>> doesn't handle clocks, power-domains, resets yet).
>
> It's a question of validation. How do I validate power-domains is a
> valid property for a given compatible? What if it is required, but not
With platform property, I mean that it depends on the platform, not on the
compatible value of the device.
For a generic compatible value ("renesas,sh-srtc") you cannot know, as
it depends on the actual SoC the (same) RTC device is part of.
For an SoC-specific compatible value ("renesas,r7s72100-rtc"), you could know
from the compatible value (an r7s72100 SoC must have r7s72100 clocks, and the
r7s72100 clock domain, cfr.
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt).
However. the SoC-specific compatible values exist only as a workaround
for not knowing
the exact version of the IP cores.
> present? Any node can have it? So it is valid for memory and chosen
> nodes, an i2c device, an LCD panel, etc?
It's not valid for a chosen node ;-)
It can be valid for memory (or the memory-controller; oops, the memory node is
not a child of the memory-controller node), i2c devices, LCD panels, ...
depending on the platform.
Consider e.g. i2c devices. I can add a GPIO-controlled MOSFET bank to my board,
to enable power to individual i2c devices, and abstract that as a
power-controller in DT. Suddenly I have to add power-domains properties to the
individual i2c device nodes, while the i2c devices itself haven't changed, and
thus keep the same compatible values.
Should I now document the power-domains property in the i2c devices' DT binding
documents?
On Linux, the drivers won't care, as the platform-specific things are handled
transparently by Runtime PM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Icenowy Zheng @ 2017-04-04 15:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Quentin Schulz, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Lee Jones, Zhang Rui, Jonathan Cameron
In-Reply-To: <20170404144715.fa5sy427u2cz4e6z@rob-hp-laptop>
在 2017年04月04日 22:47, Rob Herring 写道:
> On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
>> Allwinner H3 features a thermal sensor like the one in A33, but has its
>> register re-arranged, the clock divider moved to CCU (originally the
>> clock divider is in ADC) and added a pair of bus clock and reset.
>>
>> Update the binding document to cover H3.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23 ++++++++++++++++++++--
>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> index badff3611a98..7753133ca0ff 100644
>> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as a thermal sensor
>> and sometimes as a touchscreen controller.
>>
>> Required properties:
>> - - compatible: "allwinner,sun8i-a33-ths",
>> + - compatible: must contain one of the following compatibles:
>> + - "allwinner,sun8i-a33-ths"
>> + - "allwinner,sun8i-h3-ths"
>> - reg: mmio address range of the chip,
>> - #thermal-sensor-cells: shall be 0,
>> - #io-channel-cells: shall be 0,
>>
>> -Example:
>> +Required properties for the following compatibles:
>> + - "allwinner,sun8i-h3-ths"
>> + - clocks: the bus clock and the input clock of the ADC,
>> + - clock-names: should be "bus" and "ths",
>> + - resets: the bus reset of the ADC,
>> +
>> +Example for A33:
>> ths: ths@01c25000 {
>> compatible = "allwinner,sun8i-a33-ths";
>> reg = <0x01c25000 0x100>;
>> @@ -17,6 +25,17 @@ Example:
>> #io-channel-cells = <0>;
>> };
>>
>> +Example for H3:
>> + ths: ths@01c25000 {
>
> adc@...
It's a thermal sensor, so I think call it THS is more appropriate
here. It's implemented as an ADC driver just because the internal
code reusing of Linux. From device tree binding view I choose to
call it ths.
>
> And drop the leading 0.
OK.
>
>> + compatible = "allwinner,sun8i-h3-ths";
>> + reg = <0x01c25000 0x100>;
>> + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
>> + clock-names = "bus", "ths";
>> + resets = <&ccu RST_BUS_THS>;
>> + #thermal-sensor-cells = <0>;
>> + #io-channel-cells = <0>;
>> + };
>> +
>> sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>>
>> sun4i resistive touchscreen controller
>> --
>> 2.12.2
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 02/14] dt/bindings: Document gpio-ingenic
From: Rob Herring @ 2017-04-04 14:52 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Alexandre Courbot, Mark Rutland, Ralf Baechle,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, james.hogan,
linux-gpio, devicetree, linux-kernel, linux-mips, linux-mmc,
linux-mtd, linux-pwm, linux-fbdev
In-Reply-To: <20170402204244.14216-3-paul@crapouillou.net>
On Sun, Apr 02, 2017 at 10:42:32PM +0200, Paul Cercueil wrote:
> This commit adds documentation for the devicetree bindings of the
> gpio-ingenic driver, which handles GPIOs of the Ingenic SoCs
> currently supported by the Linux kernel.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../devicetree/bindings/gpio/ingenic,gpio.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
>
> v2: New patch
> v3: No changes
> v4: Update for the v4 version of the gpio-ingenic driver
>
> diff --git a/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt b/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
> new file mode 100644
> index 000000000000..f54af444f7c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/ingenic,gpio.txt
> @@ -0,0 +1,48 @@
> +Ingenic jz47xx GPIO controller
> +
> +That the Ingenic GPIO driver node must be a sub-node of the Ingenic pinctrl
> +driver node.
> +
> +Required properties:
> +--------------------
> +
> + - compatible: Must contain one of:
> + - "ingenic,jz4740-gpio"
> + - "ingenic,jz4770-gpio"
> + - "ingenic,jz4780-gpio"
> + And one of:
> + - "ingenic,gpio-bank-a"
> + - "ingenic,gpio-bank-b"
> + - "ingenic,gpio-bank-c"
> + - "ingenic,gpio-bank-d"
> + - "ingenic,gpio-bank-e" (for SoC version > jz4740)
> + - "ingenic,gpio-bank-f" (for SoC version > jz4740)
This is quite strange. Why do you need the bank? Doesn't gpio-ranges
give you that info? Maybe use reg property here instead.
> + - interrupt-controller: Marks the device node as an interrupt controller.
> + - interrupts: Interrupt specifier for the controllers interrupt.
> + - #interrupt-cells: Should be 2. Refer to
> + ../interrupt-controller/interrupts.txt for more details.
> + - gpio-controller: Marks the device node as a GPIO controller.
> + - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
> + cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
> + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
> + - gpio-ranges: Range of pins managed by the GPIO controller. Refer to
> + 'gpio.txt' in this directory for more details.
> +
> +Example:
> +--------
> +
> +&pinctrl {
> + gpa: gpio-controller@0 {
gpio@...
> + compatible = "ingenic,gpio-bank-a", "ingenic,jz4740-gpio";
> +
> + gpio-controller;
> + gpio-ranges = <&pinctrl 0 0 32>;
> + #gpio-cells = <2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <28>;
> + };
> +};
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v4 01/14] dt/bindings: Document pinctrl-ingenic
From: Rob Herring @ 2017-04-04 14:48 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Alexandre Courbot, Mark Rutland, Ralf Baechle,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, james.hogan,
linux-gpio, devicetree, linux-kernel, linux-mips, linux-mmc,
linux-mtd, linux-pwm, linux-fbdev
In-Reply-To: <20170402204244.14216-2-paul@crapouillou.net>
On Sun, Apr 02, 2017 at 10:42:31PM +0200, Paul Cercueil wrote:
> This commit adds documentation for the devicetree bindings of the
> pinctrl-ingenic driver, which handles pin configuration and pin
> muxing of the Ingenic SoCs currently supported by the Linux kernel.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../bindings/pinctrl/ingenic,pinctrl.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] dt-bindings: update the Allwinner GPADC device tree binding for H3
From: Rob Herring @ 2017-04-04 14:47 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, Maxime Ripard, Chen-Yu Tsai, Jonathan Cameron,
Quentin Schulz, Zhang Rui, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170402133304.56824-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Sun, Apr 02, 2017 at 09:33:01PM +0800, Icenowy Zheng wrote:
> Allwinner H3 features a thermal sensor like the one in A33, but has its
> register re-arranged, the clock divider moved to CCU (originally the
> clock divider is in ADC) and added a pair of bus clock and reset.
>
> Update the binding document to cover H3.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 23 ++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> index badff3611a98..7753133ca0ff 100644
> --- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -4,12 +4,20 @@ The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> and sometimes as a touchscreen controller.
>
> Required properties:
> - - compatible: "allwinner,sun8i-a33-ths",
> + - compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a33-ths"
> + - "allwinner,sun8i-h3-ths"
> - reg: mmio address range of the chip,
> - #thermal-sensor-cells: shall be 0,
> - #io-channel-cells: shall be 0,
>
> -Example:
> +Required properties for the following compatibles:
> + - "allwinner,sun8i-h3-ths"
> + - clocks: the bus clock and the input clock of the ADC,
> + - clock-names: should be "bus" and "ths",
> + - resets: the bus reset of the ADC,
> +
> +Example for A33:
> ths: ths@01c25000 {
> compatible = "allwinner,sun8i-a33-ths";
> reg = <0x01c25000 0x100>;
> @@ -17,6 +25,17 @@ Example:
> #io-channel-cells = <0>;
> };
>
> +Example for H3:
> + ths: ths@01c25000 {
adc@...
And drop the leading 0.
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x100>;
> + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
> + clock-names = "bus", "ths";
> + resets = <&ccu RST_BUS_THS>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> sun4i, sun5i and sun6i SoCs are also supported via the older binding:
>
> sun4i resistive touchscreen controller
> --
> 2.12.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/7] rtc: Add rtc-sh
From: Rob Herring @ 2017-04-04 14:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Brandt, Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdVmwJYMzspVeDqToBrkfK+zGLMNhxGvEbqCA-vuCUXqoQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 29, 2017 at 1:49 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Rob,
>
> On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>>> @@ -0,0 +1,29 @@
>>> +* Real Time Clock for Renesas SH and ARM SoCs
>>> +
>>> +Required properties:
>>> +- compatible: Should be "renesas,r7s72100-rtc" and "renesas,sh-rtc" as a
>>> + fallback.
>>> +- reg: physical base address and length of memory mapped region.
>>> +- interrupts: 3 interrupts for alarm, period, and carry.
>>> +- interrupt-names: The interrupts should be labeled as "alarm", "period", and
>>> + "carry".
>>> +- clocks: The functional clock source for the RTC controller must be listed
>>> + first (if exists). Additionally, potential clock counting sources are to be
>>> + listed.
>>> +- clock-names: The functional clock must be labeled as "fck". Other clocks
>>> + may be named in accordance to the SoC hardware manuals.
>>> +
>>> +
>>> +Example:
>>> +rtc: rtc@fcff1000 {
>>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>>> + reg = <0xfcff1000 0x2e>;
>>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>>> + interrupt-names = "alarm", "period", "carry";
>>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>>> + <&rtc_x3_clk>, <&extal_clk>;
>>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>>> + power-domains = <&cpg_clocks>;
>>
>> Not documented.
>
> "power-domains" is a platform property.
>
> All hardware components need power.
> All synchronous hardware components need a clock.
> Most hardware components have a reset signal.
And we document clocks and reset for every binding.
> Whether these are exposed and can be controlled depends on the platform/SoC.
> So documenting them in each and every device binding looks overkill to me.
> I think this is something to be addressed by devicetree-specification (which
> doesn't handle clocks, power-domains, resets yet).
It's a question of validation. How do I validate power-domains is a
valid property for a given compatible? What if it is required, but not
present? Any node can have it? So it is valid for memory and chosen
nodes, an i2c device, an LCD panel, etc?
> If you prefer, the property can be removed from the example, though.
If it is valid, then I don't want it removed.
Rob
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] mmc: core: add mmc-card hardware reset enable support
From: Richard Leitner @ 2017-04-04 14:16 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
jh80.chung-Sze3O3UU22JBDgjK7y7TUQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, dev-M/VWbR8SM2SsTnJN9+BGXg,
Richard Leitner
Some eMMCs disable their hardware reset line (RST_N) by default. To enable
it the host must set the corresponding bit in ECSD. An example for such
a device is the Micron MTFCxGACAANA-4M.
This patch adds a new mmc-card devicetree property to let the host enable
this feature during card initialization.
Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
---
Documentation/devicetree/bindings/mmc/mmc-card.txt | 3 +++
drivers/mmc/core/mmc.c | 21 +++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt
index a70fcd6..8590a40 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
-broken-hpi : Use this to indicate that the mmc-card has a broken hpi
implementation, and that hpi should not be used
+-enable-hw-reset : some eMMC devices have disabled the hw reset functionality
+ (RST_N_FUNCTION) by default. By adding this property the
+ host will enable it during initialization.
Example:
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index b502601..518d0e3 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1520,9 +1520,16 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
int err;
u32 cid[4];
u32 rocr;
+ struct device_node *np;
+ bool enable_rst_n = false;
WARN_ON(!host->claimed);
+ np = mmc_of_find_child_device(host, 0);
+ if (np && of_device_is_compatible(np, "mmc-card"))
+ enable_rst_n = of_property_read_bool(np, "enable-hw-reset");
+ of_node_put(np);
+
/* Set correct bus mode for MMC before attempting init */
if (!mmc_host_is_spi(host))
mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
@@ -1810,6 +1817,20 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
}
+ /*
+ * try to enable RST_N if requested
+ * This is needed because some eMMC chips disable this function by
+ * default.
+ */
+ if (enable_rst_n) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_RST_N_FUNCTION, EXT_CSD_RST_N_ENABLED,
+ card->ext_csd.generic_cmd6_time);
+ if (err && err != -EBADMSG)
+ pr_warn("%s: Enabling RST_N feature failed\n",
+ mmc_hostname(card->host));
+ }
+
if (!oldcard)
host->card = card;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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