* Re: [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Arnd Bergmann @ 2014-02-28 15:31 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson
In-Reply-To: <5310A5F1.9070901-l0cyMroinI0@public.gmane.org>
On Friday 28 February 2014 10:06:25 Santosh Shilimkar wrote:
> I made that LPAE specific assuming the 32 machines anyway are
> happy with default as they are today. We can keep CONFIG_ARM
> and handle the special case in machine platform notifier.
I think all other machines that support LPAE can also run with
LPAE disabled and still use coherent DMA, they may just not
support all the available RAM.
Arnd
--
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
* Re: [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Santosh Shilimkar @ 2014-02-28 15:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson
In-Reply-To: <11548178.4dQyMzBAP8@wuerfel>
On Friday 28 February 2014 10:31 AM, Arnd Bergmann wrote:
> On Friday 28 February 2014 10:06:25 Santosh Shilimkar wrote:
>> I made that LPAE specific assuming the 32 machines anyway are
>> happy with default as they are today. We can keep CONFIG_ARM
>> and handle the special case in machine platform notifier.
>
> I think all other machines that support LPAE can also run with
> LPAE disabled and still use coherent DMA, they may just not
> support all the available RAM.
>
Fair enough.
Regards,
Santosh
--
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
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Tomi Valkeinen @ 2014-02-28 15:39 UTC (permalink / raw)
To: Sebastian Hesselbarth, linux-fbdev, dri-devel, devicetree,
linux-arm-kernel
Cc: Russell King - ARM Linux, Sascha Hauer, Tomasz Figa, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel
In-Reply-To: <5310945A.9040106@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 8208 bytes --]
On 28/02/14 15:51, Sebastian Hesselbarth wrote:
>> TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
>> and CT_CP_HPD, which need to be controlled based on what the user wants
>> and the state of the HPD line. Who controls those?
>
> Strictly speaking TPD12S015 has _no_ GPIO but only buffers. It
What do you mean with that? That TPD doesn't provide GPIOs that you
could control, in the sense that SoCs do? Sure. I didn't mean that. I
meant it has gpios in the same sense that, say, a panel might have a
'enable' gpio.
Somebody needs to control the gpio state. For a panel, I would say it's
the panel driver's job. And the gpio would be present in the panel's DT
node. The same way for TDP.
> translates one voltage to another. The controlling instance is
> your "video card" that is really interested in the actual state
> of HPD signal.
Well. I think it's the driver for the respective hardware device that
handles the gpio. Of course, that driver will usually get information
from somewhere else when to use those gpios. It may be the "video card",
but really, the video card driver also gets the information if to enable
the output from somewhere else.
> Also the same for power, TPD12S015 doesn't decide to be powered up
> or down but the "video card" does. We have GPIO regulators that
> deal with that situation already.
The same here. TPD driver gets told to enable itself (or some particular
feature that it supports). It will then enable the required powers.
> Consider the same board but replace TPD12S015 with another level-
> shifter, you still want OMAP video driver work with that out-of-the-box,
Right. For this exact reason, the TPD is a separate driver. I can easily
leave it out, or replace it with any other similar chip. Or the TPD
driver can be used on some other platform.
OMAP video driver doesn't know anything about TPD, as TPD is not part of
OMAP video hardware, or even OMAP SoC.
How would this work without TPD, or with, say, TPD1234567, which instead
has 5 GPIOs that need to be set in particular order? The video card
driver would need to know the exact details of all possible level
shifters out there? Or?
> don't you? Fact is, OMAP IP requires GPIOs to sense HPD status hence
> that GPIO is a property of the corresponding OMAP node. How level-
> translation happens is irrelevant here.
No it doesn't. There are different ways to handle HPD on OMAP HDMI. It's
true that the HDMI IP supports directly handling HPD, but that's not
used as there were some issues with it (I don't remember what). The HPD
can as well be handled outside the HDMI driver.
If the HDMI IP would be handling the HPD, then, yes, HDMI node would
have HPD gpio defined.
> Thinking about it again, HPD gpio shouldn't be a property of the
> connector at all but again the controlling instance. The connector
> cannot deal with the information provided by HPD nor can it determine
> if anyone is listening to HPD events.
Well, this goes into the driver implementation details, but I disagree.
You have a video pipeline, let's say it's just SoC's HDMI encoder, and
HDMI connector. In this particular case, the HDMI encoder IP has no
support for HPD. On top of that, you have a "video card" driver,
"display subsystem" driver, or whatever you want to call it, which is in
control of the video pipeline. Let's call it controller.
The controller asks to get notified of a HPD event from the video
pipeline. It doesn't care if the HPD is handled by the HDMI encoder
driver or the connector driver. They can each handle it, in ways that
suit the particular hardware they control. Of course, handling it in
only one place usually makes sense.
When the controller is notified of a HPD, it can then decide what to do.
If the user has told it to enable video output on HPD, the controller
can command the video pipeline to be enabled.
>> Well, I think the HPD gpio should be where it's most logical to have it.
>
> Right, but this is usually the controlling instance and not the
> consuming one. E.g. to detect presence of an MMC card by GPIO, you'd
> put that into the MMC _controller_ not any card node.
I'm not familiar with MMC, so there it may be clear. With video, we can
have arbitrarily long video pipeline chains, with each component changed
to some other, differently behaving component.
Let's think of another case. SoC's DSI encoder, an external HDMI
encoder, and a HDMI connector. Who handles the HPD? Surely not the SoC's
DSI encoder, as there's no such concept as HPD in DSI? The "video card"
driver? Maybe, but from the video card's perspective, it is driving a
DSI peripheral, and again no HPD in DSI.
The logical place there is the external HDMI encoder. And again, the
HDMI encoder doesn't independently handle decisions about what to do
when HPD happens. It just catches it, and tells somebody wiser about it.
And really, what's the difference with, say, an external HDMI encoder
and TPD? Ok, lots =). But they both take video input in, output video,
and require some config/control to make the chip work.
I totally agree that TPD is on the simpler side of components. But I
think it fits right in into the model, and it works great on OMAP.
Compared to older version, where TPD support was baked into the OMAP
HDMI driver, which was a mess.
>> I mean, you could have a setup where you have the SoC HDMI encoder and
>> and the HDMI connector, and the HPD pin goes directly to the HDMI
>> encoder, which has HW support for it. In that case, the HDMI encoder
>> node should contain the HPD, and the HDMI encoder should handle it.
>
> I wonder, if in case of an dedicated HPD pin, you would ever expose that
> in DT.
Yes, if it's a dedicated pin, no configuration information needed, thus
no information needed in DT. Well, pinctrl maybe.
> Having a driver for a dumb connector seems to be a little exaggerated.
> Consider your generic HDMI connector "driver" connected to dedicated HPD
> case above. It is pretty useless then. OTOH video controllers with
> dedicated HPD know very well they can control HPD themselves, video
> controllers without dedicated HPD also know very well that they need
> GPIO for it.
Yes, I have to say I'm not 100% sure about the connectors. They could
perhaps be left out. But they make things consistent, in my opinion, as
they present a terminator for the video pipeline.
Say, you could have these two different boards:
SoC HDMI -> TPD -> HDMI connector
SoC HDMI -> TPD -> Embedded HDMI panel
In both cases, there's a component at the end, which is the end of the
pipeline (as far as we're concerned). I think it makes the driver side a
bit cleaner, and doesn't leave the TPD's output "hanging out" there.
Also I have used the connector drivers for actual work. The DVI
connector has support for reading EDID via i2c. This is again something
that you can argue that, hey, it should be the "video card" doing it.
But it fits quite well into the DVI connector, and there's no other
hardware component that has any support for the EDID.
I again see the above so that the video pipeline offers a way to read
EDID. Where exactly that's done and how it happens on the hardware
level, the controller doesn't care.
>> In OMAP's case, we have the TPD chip between the HDMI encoder and the
>> connector, and the logical place to handle HPD GPIO in that case is the
>> TPD driver, as that's where the HPD is connected to and the TPD needs to
>> be configured according to the state of the HPD.
>
> Is it really the logical place to handle HPD? I'd have put it into the
> HDMI encoder because it's the unit most interested in the state of HPD.
At least in OMAP's case, when not using the HDMI encoder's support for
HPD, the HDMI encoder is not interested at all about the HPD.
> Please, don't get me wrong, I like all this to be baked into a binding -
> just wondering if a level-shifter driver plus corresponding DT node
> is too much detail in here.
Thanks for the comments, I appreciate it. I hope I've convinced you
enough =).
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/2] Introduce AEMIF driver for Davinci/Keystone archs
From: Santosh Shilimkar @ 2014-02-28 15:43 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: Ivan Khoronzhuk, galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
rob-VoJi6FS/r0vR7s880joybQ, robherring2-Re5JQEeQqe8AvxtiuMwx3w,
linux-lFZ/pmaqli7XmaaqVzeoHQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
grygorii.strashko-l0cyMroinI0, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
nsekhar-l0cyMroinI0
In-Reply-To: <1393262772-24442-1-git-send-email-ivan.khoronzhuk-l0cyMroinI0@public.gmane.org>
Greg,
On Monday 24 February 2014 12:26 PM, Ivan Khoronzhuk wrote:
> These patches introduce Async External Memory Interface (EMIF16/AEMIF)
> controller driver for Davinci/Keystone archs.
>
> For more informations see documentation:
> Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
> OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
> Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
>
[..]
>
> v5..v6:
> - memory: ti-aemif: introduce AEMIF driver
> - memory: ti-aemif: add bindings for AEMIF driver
> changed opaque names for cs node properties
>
Can you please pick these two patches ?
Regards,
Santosh
--
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
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Russell King - ARM Linux @ 2014-02-28 15:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393590016-9361-4-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for DVI Connector.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
> new file mode 100644
> index 000000000000..6a0aff866c78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
> @@ -0,0 +1,26 @@
> +DVI Connector
> +==============
> +
> +Required properties:
> +- compatible: "dvi-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> +
> +Required nodes:
> +- Video port for DVI input
> +
> +Example
> +-------
> +
> +dvi0: connector@0 {
> + compatible = "dvi-connector";
> + label = "dvi";
> +
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> +};
This looks far too simplistic. There are different classes of DVI
connector - there is:
DVI A - analogue only
DVI D - digital only (single and dual link)
DVI I - both (single and dual digital link)
DRM at least makes a distinction between these three classes, and this
disctinction is part of the user API. How would a display system know
which kind of DVI connector is wired up on the board from this DT
description?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
* Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
From: Nishanth Menon @ 2014-02-28 15:59 UTC (permalink / raw)
To: Tero Kristo, linux-omap, paul, tony, mturquette
Cc: linux-arm-kernel, devicetree
In-Reply-To: <1393579384-23440-1-git-send-email-t-kristo@ti.com>
On 02/28/2014 03:22 AM, Tero Kristo wrote:
> Hi,
>
> This set concludes the omap2+ clock DT conversion work by creating the
> DT clock data for omap2 SoC also.
>
> I am also currently doing related work to cleanup CM/PRM codebase in
> preparation to move it into drivers/, this set is basically going to
> be a pre-requisite for that. I'll hopefully post something related
> to that early next week.
>
> This set has been boot tested on OMAP2430 only (thanks Nishanth, I don't
> have access to OMAP2 hardware myself), so any testing feedback on
> 2420 board(s) would be appreciated.
>
> Working tree:
>
> Tree: https://github.com/t-kristo/linux-pm.git
> Branch: 3.14-rc4-omap2-dt-clks
I do see checkpatch warnings in the series:
http://slexy.org/view/s20mzhlJ93
Series boot tested with:
3.14-rc4-omap2-dt-clks fc73a96 ARM: OMAP2: clock: use DT clock boot
if available
from the tree mentioned above.
Things look good other than the checkpatch violation noticed in
report, so other than that,
Tested-by: Nishanth Menon <nm@ti.com>
omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2jdV3XMCC
2: am335x-sk: Boot PASS: http://slexy.org/raw/s210nZI8Hx
3: am3517-evm: Boot PASS: http://slexy.org/raw/s21MG8kg6u
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20coVhzLt
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21XKjjwyk
6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s27PCmlDq7
7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2HX1Q3iPb
8: crane: No Image built - Missing platform support?:
9: dra7: Boot PASS: http://slexy.org/raw/s21ofDfpD2
10: ldp: Boot FAIL: http://slexy.org/raw/s2SbrpyX2p
^^ legacy behavior
11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s21n4iMUKd
12: sdp2430: Boot PASS: http://slexy.org/raw/s2CJ5hYl72
13: sdp3430: Boot PASS: http://slexy.org/raw/s20axZ1nyb
14: sdp4430: Boot PASS: http://slexy.org/raw/s21wt3C5F3
15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s208PhmCpm
TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v5 0/5] i.MX6 PU power domain support
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
The i.MX6Q can gate off the CPU and PU (GPU/VPU) power domains using the
Power Gating Controller (PGC) in the GPC register space. The CPU power
domain is already handled by wait state code, but the PU power domain can
be controlled using the generic power domain framework and power off the PU
supply regulator if all devices in the power domain are (runtime) suspended.
This patchset adds a GPC platform device initialized at subsys_initcall time
(after anatop regulators) that binds to the gpc device tree node and sets up
the PU power domain. The GPC node becomes a power-controller as defined by
Tomasz' OF power domain bindings. This series depends on his patch
"base: power: Add generic OF-based power domain look-up"
Using the power-domain bindings allows to use indexed power domains inside the
gpc node. This allows to use phandles with an index cell to select the power
domains, similarly to the reset lines provided by the SRC.
I have tested this on i.MX6S and noticed hangs if the GPU is not clocked during
domain powerup. As a consequence, the domain driver no longer collects the
reset clocks from drivers in the domain (as the GPU driver might not be
enabled, or even in mainline...), but is provided with the necessary clocks
directly from the device tree. This also allowed to get rid of the bus
notifier.
Finally, the device specific timing data has been dropped for now, since the
current generic OF power domain code doesn't support it yet.
Changes since v4:
- Use OF power domain bindings
- Provide reset clocks directly via device tree
regards
Philipp
Philipp Zabel (5):
Documentation: Add device tree bindings for Freescale i.MX GPC
ARM: imx6: gpc: Add PU power domain for GPU/VPU
ARM: dts: imx6qdl: Add power-domain information to gpc node
ARM: dts: imx6sl: Add power-domain information to gpc node
ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp
delay
.../devicetree/bindings/power/fsl,imx-gpc.txt | 54 ++++++
arch/arm/boot/dts/imx6qdl.dtsi | 7 +-
arch/arm/boot/dts/imx6sl.dtsi | 6 +-
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 182 +++++++++++++++++++++
5 files changed, 249 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
--
1.8.5.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
* [PATCH v5 1/5] Documentation: Add device tree bindings for Freescale i.MX GPC
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1393603427-6199-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The i.MX6 contains a power controller that controls power gating and
sequencing for the SoC's power domains.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since v4:
- Use OF power domain bindings
- Add reset clocks to be enabled during PU powerup.
---
.../devicetree/bindings/power/fsl,imx-gpc.txt | 54 ++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
new file mode 100644
index 0000000..eaa8c93
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -0,0 +1,54 @@
+Freescale i.MX General Power Controller
+=======================================
+
+The i.MX6Q General Power Control (GPC) block contains DVFS load tracking
+counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power
+domains.
+
+Required properties:
+- compatible: Should be "fsl,imx6q-gpc" or "fsl,imx6sl-gpc"
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain GPC interrupt request 1
+- pu-supply: Link to the LDO regulator powering the PU power domain
+- clocks: Clock phandles to devices in the PU power domain that need
+ to be enabled during domain power-up for reset propagation.
+- #power-domain-cells: Should be 1, see below:
+
+The gpc node is a power-controller as documented by the generic power domain
+bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+
+Example:
+
+ gpc: gpc@020dc000 {
+ compatible = "fsl,imx6q-gpc";
+ reg = <0x020dc000 0x4000>;
+ interrupts = <0 89 0x04 0 90 0x04>;
+ pu-supply = <®_pu>;
+ clocks = <&clks 122>, <&clks 74>, <&clks 121>,
+ <&clks 26>, <&clks 143>, <&clks 168>;
+ #power-domain-cells = <1>;
+ };
+
+
+Specifying power domain for IP modules
+======================================
+
+IP cores belonging to a power domain should contain a 'power-domain' property
+that is a phandle pointing to the gpc device node and a DOMAIN_INDEX specifying
+the power domain the device belongs to.
+
+Example of a device that is part of the PU power domain:
+
+ vpu: vpu@02040000 {
+ reg = <0x02040000 0x3c000>;
+ /* ... */
+ power-domain = <&gpc 1>;
+ /* ... */
+ };
+
+The following DOMAIN_INDEX values are valid for i.MX6Q:
+ARM_DOMAIN 0
+PU_DOMAIN 1
+The following additional DOMAIN_INDEX value is valid for i.MX6SL:
+DISPLAY_DOMAIN 2
--
1.8.5.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 v5 2/5] ARM: imx6: gpc: Add PU power domain for GPU/VPU
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1393603427-6199-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
When generic pm domain support is enabled, the PGC can be used
to completely gate power to the PU power domain containing GPU3D,
GPU2D, and VPU cores.
This code triggers the PGC powerdown sequence to disable the GPU/VPU
isolation cells and gate power and then disables the PU regulator.
To reenable, the reverse powerup sequence is triggered after the PU
regulator is enabled again.
The GPU and VPU devices in the PU power domain temporarily need
to be clocked during powerup, so that the reset machinery can work.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since v4:
- Add pu_domain struct to contain regulator and clocks
- Obtain clocks from device tree instead of from bus notifier
- Add compatible value for imx6sl (untested)
---
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 182 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 184 insertions(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 33567aa..3c58f2e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -808,6 +808,7 @@ config SOC_IMX6Q
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
select PM_OPP if PM
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 Quad processor.
@@ -827,6 +828,7 @@ config SOC_IMX6SL
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 SoloLite processor.
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 586e017..a0f587e 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -10,19 +10,40 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
+#include <linux/pm_domain.h>
+#include <linux/regulator/consumer.h>
#include <linux/irqchip/arm-gic.h>
#include "common.h"
+#include "hardware.h"
+#define GPC_CNTR 0x000
#define GPC_IMR1 0x008
+#define GPC_PGC_GPU_PDN 0x260
+#define GPC_PGC_GPU_PUPSCR 0x264
+#define GPC_PGC_GPU_PDNSCR 0x268
#define GPC_PGC_CPU_PDN 0x2a0
#define IMR_NUM 4
+#define GPU_VPU_PUP_REQ BIT(1)
+#define GPU_VPU_PDN_REQ BIT(0)
+
+struct pu_domain {
+ struct generic_pm_domain base;
+ struct regulator *reg;
+ struct clk *clk[6];
+ int num_clks;
+};
+
static void __iomem *gpc_base;
static u32 gpc_wake_irqs[IMR_NUM];
static u32 gpc_saved_imrs[IMR_NUM];
@@ -138,3 +159,164 @@ void __init imx_gpc_init(void)
gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
}
+
+#ifdef CONFIG_PM
+
+static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+ struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+ int iso, iso2sw;
+ u32 val;
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
+ iso = val & 0x3f;
+ iso2sw = (val >> 8) & 0x3f;
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Request GPC to power down GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PDN_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((iso + iso2sw) * 1000 / 66);
+
+ regulator_disable(pu->reg);
+
+ return 0;
+}
+
+static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
+{
+ struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+ int i, ret, sw, sw2iso;
+ u32 val;
+
+ ret = regulator_enable(pu->reg);
+ if (ret) {
+ pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Enable reset clocks for all devices in the PU domain */
+ for (i = 0; i < pu->num_clks; i++)
+ clk_prepare_enable(pu->clk[i]);
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
+ sw = val & 0x3f;
+ sw2iso = (val >> 8) & 0x3f;
+
+ /* Request GPC to power up GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PUP_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((sw + sw2iso) * 1000 / 66);
+
+ /* Disable reset clocks for all devices in the PU domain */
+ for (i = 0; i < pu->num_clks; i++)
+ clk_disable_unprepare(pu->clk[i]);
+
+ return 0;
+}
+
+static struct generic_pm_domain imx6q_arm_domain = {
+ .name = "ARM",
+};
+
+static struct pu_domain imx6q_pu_domain = {
+ .base = {
+ .name = "PU",
+ .power_off = imx6q_pm_pu_power_off,
+ .power_on = imx6q_pm_pu_power_on,
+ .power_off_latency_ns = 25000,
+ .power_on_latency_ns = 2000000,
+ },
+};
+
+static struct generic_pm_domain imx6sl_display_domain = {
+ .name = "DISPLAY",
+};
+
+static struct generic_pm_domain *imx_gpc_domains[] = {
+ &imx6q_arm_domain,
+ &imx6q_pu_domain.base,
+ &imx6sl_display_domain,
+};
+
+static struct genpd_onecell_data imx_gpc_onecell_data = {
+ .domains = imx_gpc_domains,
+ .domain_num = ARRAY_SIZE(imx_gpc_domains),
+};
+
+#endif /* CONFIG_PM */
+
+static int imx_gpc_probe(struct platform_device *pdev)
+{
+ struct regulator *pu_reg;
+ struct clk *clk;
+ bool is_off;
+ int ret, i;
+
+ pu_reg = devm_regulator_get(&pdev->dev, "pu");
+ if (IS_ERR(pu_reg)) {
+ ret = PTR_ERR(pu_reg);
+ dev_err(&pdev->dev, "failed to get pu regulator: %d\n", ret);
+ return ret;
+ }
+
+ /* The regulator is initially enabled */
+ ret = regulator_enable(pu_reg);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable pu regulator: %d\n", ret);
+ return ret;
+ }
+ imx6q_pu_domain.base.of_node = pdev->dev.of_node;
+ imx6q_pu_domain.reg = pu_reg;
+
+ for (i = 0; ; i++) {
+ clk = of_clk_get(pdev->dev.of_node, i);
+ if (IS_ERR(clk))
+ break;
+ imx6q_pu_domain.clk[i] = clk;
+ }
+ imx6q_pu_domain.num_clks = i;
+
+ is_off = IS_ENABLED(CONFIG_PM_RUNTIME);
+ if (is_off)
+ imx6q_pm_pu_power_off(&imx6q_pu_domain.base);
+
+ pm_genpd_init(&imx6q_pu_domain.base, NULL, is_off);
+ of_genpd_add_provider(pdev->dev.of_node, of_genpd_xlate_onecell,
+ &imx_gpc_onecell_data);
+ return 0;
+}
+
+static struct of_device_id imx_gpc_dt_ids[] = {
+ { .compatible = "fsl,imx6q-gpc" },
+ { .compatible = "fsl,imx6sl-gpc" },
+ { }
+};
+
+static struct platform_driver imx_gpc_driver = {
+ .driver = {
+ .name = "imx-gpc",
+ .owner = THIS_MODULE,
+ .of_match_table = imx_gpc_dt_ids,
+ },
+ .probe = imx_gpc_probe,
+};
+
+static int __init imx_pgc_init(void)
+{
+ return platform_driver_register(&imx_gpc_driver);
+}
+subsys_initcall(imx_pgc_init);
--
1.8.5.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 v5 3/5] ARM: dts: imx6qdl: Add power-domain information to gpc node
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1393603427-6199-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled, and a list of phandles to all clocks that must be
enabled during powerup for reset propagation.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since v4:
- Use OF power domain bindings
- Added reset clocks
---
arch/arm/boot/dts/imx6qdl.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..00f0bf0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -600,6 +600,10 @@
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04 0 90 0x04>;
+ pu-supply = <®_pu>;
+ clocks = <&clks 122>, <&clks 74>, <&clks 121>,
+ <&clks 26>, <&clks 143>, <&clks 168>;
+ #power-domain-cells = <1>;
};
gpr: iomuxc-gpr@020e0000 {
--
1.8.5.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 v5 4/5] ARM: dts: imx6sl: Add power-domain information to gpc node
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1393603427-6199-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled and a list of clocks to be enabled during powerup
for reset propagation.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since v4:
- Use OF power domain bindings
- Added reset clocks
---
arch/arm/boot/dts/imx6sl.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 28558f1..0e61262 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -529,9 +529,13 @@
};
gpc: gpc@020dc000 {
- compatible = "fsl,imx6sl-gpc", "fsl,imx6q-gpc";
+ compatible = "fsl,imx6sl-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04>;
+ pu-supply = <®_pu>;
+ clocks = <&clks IMX6SL_CLK_GPU2D_OVG>,
+ <&clks IMX6SL_CLK_GPU2D_PODF>;
+ #power-domain-cells = <1>;
};
gpr: iomuxc-gpr@020e0000 {
--
1.8.5.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 v5 5/5] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay
From: Philipp Zabel @ 2014-02-28 16:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Tomasz Figa, Rob Herring, Mark Rutland,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1393603427-6199-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The PU regulator is enabled during boot, but not necessarily always-on.
It can be disabled by the generic pm domain framework when the PU power
domain is shut down. The ramp delay of 150 us might be a bit conservative,
the value is taken from the Freescale kernel.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 00f0bf0..57e990e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -515,7 +515,8 @@
regulator-name = "vddpu";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1450000>;
- regulator-always-on;
+ regulator-enable-ramp-delay = <150>;
+ regulator-boot-on;
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
--
1.8.5.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
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Russell King - ARM Linux @ 2014-02-28 16:06 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, linux-fbdev, dri-devel, Andrzej Hajda,
Laurent Pinchart, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1393590016-9361-5-git-send-email-tomi.valkeinen@ti.com>
On Fri, Feb 28, 2014 at 02:20:11PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for HDMI Connector.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Archit Taneja <archit@ti.com>
> ---
> .../devicetree/bindings/video/hdmi-connector.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> new file mode 100644
> index 000000000000..5d25f6a432bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> @@ -0,0 +1,23 @@
> +HDMI Connector
> +==============
> +
> +Required properties:
> +- compatible: "hdmi-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +
> +Required nodes:
> +- Video port for HDMI input
> +
> +Example
> +-------
> +
> +hdmi0: connector@1 {
> + compatible = "hdmi-connector";
> + label = "hdmi";
> +
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tpd12s015_out>;
> + };
> +};
It seems rather weird to have DVI connectors having an optional I2C
property, but HDMI (which augments DVI) not having that as at least an
optional property.
I can quite well see the iMX HDMI support needing an i2c bus here.
Also, HDMI has two connector standards - type A and type B, much like
the single vs dual link of DVI. Again, DRM exposes this to userspace.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH v6 0/2] Introduce AEMIF driver for Davinci/Keystone archs
From: Greg KH @ 2014-02-28 16:06 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Ivan Khoronzhuk, galak, rob, robherring2, linux, devicetree,
pawel.moll, mark.rutland, rob.herring, swarren, ijc+devicetree,
linux-kernel, linux-arm-kernel, linux-mtd, grygorii.strashko,
dwmw2, nsekhar
In-Reply-To: <5310AEA8.1070804@ti.com>
On Fri, Feb 28, 2014 at 10:43:36AM -0500, Santosh Shilimkar wrote:
> Greg,
>
> On Monday 24 February 2014 12:26 PM, Ivan Khoronzhuk wrote:
> > These patches introduce Async External Memory Interface (EMIF16/AEMIF)
> > controller driver for Davinci/Keystone archs.
> >
> > For more informations see documentation:
> > Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
> > OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
> > Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
> >
> [..]
>
> >
> > v5..v6:
> > - memory: ti-aemif: introduce AEMIF driver
> > - memory: ti-aemif: add bindings for AEMIF driver
> > changed opaque names for cs node properties
> >
> Can you please pick these two patches ?
Asking for a response with less than a weeks time is really bold:
$ ~/bin/mdfrm -c ~/mail/todo/
521 messages in /home/gregkh/mail/todo/
Give me a chance to catch up please...
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-02-28 16:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Thierry Reding,
Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20140228155937.GQ21483@n2100.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]
On 28/02/14 17:59, Russell King - ARM Linux wrote:
>> +dvi0: connector@0 {
>> + compatible = "dvi-connector";
>> + label = "dvi";
>> +
>> + i2c-bus = <&i2c3>;
>> +
>> + dvi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> +};
>
> This looks far too simplistic. There are different classes of DVI
> connector - there is:
>
> DVI A - analogue only
> DVI D - digital only (single and dual link)
> DVI I - both (single and dual digital link)
>
> DRM at least makes a distinction between these three classes, and this
> disctinction is part of the user API. How would a display system know
> which kind of DVI connector is wired up on the board from this DT
> description?
Yes, I think that's a valid change. But do we also need to specify
single/dual link, in addition to the three types?
I guess the compatible string is the easiest way for differentation, at
least for the three main types, i.e. "dvi-d-connector" etc.
"dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
That looks a bit funny.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Russell King - ARM Linux @ 2014-02-28 16:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393590016-9361-10-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 02:20:16PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for tpd12s015 encoder
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
>
> diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
> new file mode 100644
> index 000000000000..26e6d32e3f20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
> @@ -0,0 +1,44 @@
> +TPD12S015 HDMI level shifter and ESD protection chip
> +====================================================
> +
> +Required properties:
> +- compatible: "ti,tpd12s015"
> +
> +Optional properties:
> +- gpios: CT CP HPD, LS OE and HPD gpios
If this is supposed to give people a clue about what these GPIOs are,
it completely fails to do this. CT CP? HPD is obviously the hotplug
detect signal, but why are there two - HDMI only has a single detect
pin on the connector.
While it makes sense to stick all three into one property, is it
possible that not all of these may be routed to a GPIO? If so, how
do you specify that one (or more) of these does not exist?
Another issue here is that other HDMI encoders are available - should
every encoder define its own set of bindings, or should there be a
base set of bindings which all encoders should conform to - such as
always having a HDMI output port?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
* Re: [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-02-28 16:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree, linux-fbdev, Sascha Hauer, Tomasz Figa, dri-devel,
Inki Dae, Andrzej Hajda, Rob Clark, Thierry Reding,
Laurent Pinchart, Philipp Zabel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20140228160612.GR21483@n2100.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1093 bytes --]
On 28/02/14 18:06, Russell King - ARM Linux wrote:
>> +hdmi0: connector@1 {
>> + compatible = "hdmi-connector";
>> + label = "hdmi";
>> +
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tpd12s015_out>;
>> + };
>> +};
>
> It seems rather weird to have DVI connectors having an optional I2C
> property, but HDMI (which augments DVI) not having that as at least an
> optional property.
I have added only the properties that I have used. I did think about the
i2c for HDMI also, but thought that I don't use it, and so can't test
it, and so I could well create a bad binding.
And, as I don't see any issue in adding it later, when someone uses it,
I decided to leave it out.
> I can quite well see the iMX HDMI support needing an i2c bus here.
>
> Also, HDMI has two connector standards - type A and type B, much like
> the single vs dual link of DVI. Again, DRM exposes this to userspace.
True, but isn't that just a form factor? No functional differences? But
I agree, we can add the two types here also to the compatible string.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/2] Introduce AEMIF driver for Davinci/Keystone archs
From: Santosh Shilimkar @ 2014-02-28 16:18 UTC (permalink / raw)
To: Greg KH
Cc: Ivan Khoronzhuk, galak, rob, robherring2, linux, devicetree,
pawel.moll, mark.rutland, rob.herring, swarren, ijc+devicetree,
linux-kernel, linux-arm-kernel, linux-mtd, grygorii.strashko,
dwmw2, nsekhar
In-Reply-To: <20140228160635.GA6144@kroah.com>
On Friday 28 February 2014 11:06 AM, Greg KH wrote:
> On Fri, Feb 28, 2014 at 10:43:36AM -0500, Santosh Shilimkar wrote:
>> Greg,
>>
>> On Monday 24 February 2014 12:26 PM, Ivan Khoronzhuk wrote:
>>> These patches introduce Async External Memory Interface (EMIF16/AEMIF)
>>> controller driver for Davinci/Keystone archs.
>>>
>>> For more informations see documentation:
>>> Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
>>> OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
>>> Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
>>>
>> [..]
>>
>>>
>>> v5..v6:
>>> - memory: ti-aemif: introduce AEMIF driver
>>> - memory: ti-aemif: add bindings for AEMIF driver
>>> changed opaque names for cs node properties
>>>
>> Can you please pick these two patches ?
>
> Asking for a response with less than a weeks time is really bold:
> $ ~/bin/mdfrm -c ~/mail/todo/
> 521 messages in /home/gregkh/mail/todo/
>
> Give me a chance to catch up please...
>
Sorry for that. This version was just minor update from previous
version and hence asked it.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Russell King - ARM Linux @ 2014-02-28 16:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <5310B567.7040605-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:
> On 28/02/14 17:59, Russell King - ARM Linux wrote:
>
> >> +dvi0: connector@0 {
> >> + compatible = "dvi-connector";
> >> + label = "dvi";
> >> +
> >> + i2c-bus = <&i2c3>;
> >> +
> >> + dvi_connector_in: endpoint {
> >> + remote-endpoint = <&tfp410_out>;
> >> + };
> >> +};
> >
> > This looks far too simplistic. There are different classes of DVI
> > connector - there is:
> >
> > DVI A - analogue only
> > DVI D - digital only (single and dual link)
> > DVI I - both (single and dual digital link)
> >
> > DRM at least makes a distinction between these three classes, and this
> > disctinction is part of the user API. How would a display system know
> > which kind of DVI connector is wired up on the board from this DT
> > description?
>
> Yes, I think that's a valid change. But do we also need to specify
> single/dual link, in addition to the three types?
I would argue that as it's a difference in physical hardware, then it
should be described in DT, even if we don't use it. The reasoning is
that although we may not use it today, we may need to use it in the
future, and as we're describing what the hardware actually is - and
even in this case what pins may be present or missing on the connector,
it's unlikely to be problematical (the only problem is when someone
omits it...)
> I guess the compatible string is the easiest way for differentation, at
> least for the three main types, i.e. "dvi-d-connector" etc.
>
> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
> That looks a bit funny.
I think that starts getting a tad messy:
dvi-a-connector
dvi-d-1l-connector
dvi-d-2l-connector
dvi-i-1l-connector
dvi-i-2l-connector
That's rather a lot of compatible strings. Another possibility is:
compatible = "dvi-connector";
analog;
digital;
single-link;
dual-link;
I'm debating whether "-signalling" should be on the 2nd and 3rd (or...
-signaling depending on how you prefer to spell that word.) At least
one of "analog" and/or "digital" must be specified, and if "digital"
is specified, then exactly one of "single-link" or "dual-link" should
be specified.
So, this would mean we end up with:
compatible = "dvi-connector";
analog;
digital;
dual-link;
for a DVI-I dual-link connector.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Sebastian Reichel @ 2014-02-28 16:25 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Russell King - ARM Linux, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Tomasz Figa,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Inki Dae,
Andrzej Hajda, Rob Clark, Thierry Reding, Laurent Pinchart,
Philipp Zabel, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <5310B567.7040605-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
On Fri, Feb 28, 2014 at 06:12:23PM +0200, Tomi Valkeinen wrote:
> On 28/02/14 17:59, Russell King - ARM Linux wrote:
>
> >> +dvi0: connector@0 {
> >> + compatible = "dvi-connector";
> >> + label = "dvi";
> >> +
> >> + i2c-bus = <&i2c3>;
> >> +
> >> + dvi_connector_in: endpoint {
> >> + remote-endpoint = <&tfp410_out>;
> >> + };
> >> +};
> >
> > This looks far too simplistic. There are different classes of DVI
> > connector - there is:
> >
> > DVI A - analogue only
> > DVI D - digital only (single and dual link)
> > DVI I - both (single and dual digital link)
> >
> > DRM at least makes a distinction between these three classes, and this
> > disctinction is part of the user API. How would a display system know
> > which kind of DVI connector is wired up on the board from this DT
> > description?
>
> Yes, I think that's a valid change. But do we also need to specify
> single/dual link, in addition to the three types?
>
> I guess the compatible string is the easiest way for differentation, at
> least for the three main types, i.e. "dvi-d-connector" etc.
>
> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
> That looks a bit funny.
maybe like this:
Required Properties:
- compatible: should contain one of the following:
* "dvi-d-connector"
* "dvi-a-connector"
* "dvi-i-connector"
Optional Properties:
- dual-link: Should be set for dual-link capable connectors
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Philipp Zabel @ 2014-02-28 16:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <20140228155937.GQ21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
Am Freitag, den 28.02.2014, 15:59 +0000 schrieb Russell King - ARM
Linux:
> On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
> > Add DT binding documentation for DVI Connector.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> > Reviewed-by: Archit Taneja <archit-l0cyMroinI0@public.gmane.org>
> > ---
> > .../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
> >
> > diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
> > new file mode 100644
> > index 000000000000..6a0aff866c78
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
> > @@ -0,0 +1,26 @@
> > +DVI Connector
> > +==============
> > +
> > +Required properties:
> > +- compatible: "dvi-connector"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> > +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
> > +
> > +Required nodes:
> > +- Video port for DVI input
> > +
> > +Example
> > +-------
> > +
> > +dvi0: connector@0 {
> > + compatible = "dvi-connector";
> > + label = "dvi";
> > +
> > + i2c-bus = <&i2c3>;
> > +
> > + dvi_connector_in: endpoint {
> > + remote-endpoint = <&tfp410_out>;
> > + };
> > +};
>
> This looks far too simplistic. There are different classes of DVI
> connector - there is:
>
> DVI A - analogue only
> DVI D - digital only (single and dual link)
> DVI I - both (single and dual digital link)
>
> DRM at least makes a distinction between these three classes, and this
> disctinction is part of the user API. How would a display system know
> which kind of DVI connector is wired up on the board from this DT
> description?
Maybe this could be inferred from the sources connected to it. For
example a i.MX5 board with the SoC internal TV Encoder and an external
SiI902x HDMI encoder connected to the same DVI I connector:
ipu {
port@2 {
ipu_di0_disp0: endpoint {
remote-endpoint = <&sii902x_in>;
};
};
port@3 {
ipu_di1_tve: endpoint {
remote-endpoint = <&tve_in>;
};
};
};
&sii902x {
compatible = "si,sii9022";
port@0 {
sii902x_in: endpoint {
remote-endpoint = <&ipu_di0>;
};
};
port@1 {
sii902x_out: endpoint {
remote-endpoint = <&dvi_d_in>;
};
};
};
&tve {
compatible = "fsl,imx53-tve";
port@0 {
tve_in: endpoint {
remote-endpoint = <&ipu_di1>;
};
};
port@1 {
tve_out: endpoint {
remote-endpoint = <&dvi_a_in>;
};
};
};
dvi-connector {
compatible = "dvi-connector";
ddc-i2c-bus = <&i2c3>;
port {
dvi_d_in: endpoint@0 {
remote-endpoint = <&sii902x_out>;
};
dvi_a_in: endpoint@1 {
remote-endpoint = <&tve_out>;
};
};
};
It should be possible to let the connector know that those two endpoints
are connected to a TMDS source and to a VGA source, respectively.
regards
Philipp
--
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
* [PATCH v2 0/2] checkpatch: fixes for vendor compatible check
From: Florian Vaussard @ 2014-02-28 16:25 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches; +Cc: Rob Herring, devicetree, linux-kernel
Hi,
Since v1 [1]:
- Add check for vendors with '-', as suggested by Joe Perches
Regards,
Florian
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/63770
Florian Vaussard (2):
checkpatch: check vendor compatible with dashes
checkpatch: fix spurious vendor compatible warnings
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.8.5.3
^ permalink raw reply
* [PATCH v2 1/2] checkpatch: check vendor compatible with dashes
From: Florian Vaussard @ 2014-02-28 16:25 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches; +Cc: Rob Herring, devicetree, linux-kernel
In-Reply-To: <1393604742-14317-1-git-send-email-florian.vaussard@epfl.ch>
The current vendor compatible check will not match vendors with
dashes, like:
compatible="asahi-kasei"
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 464dcef..e304e77 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2058,7 +2058,7 @@ sub process {
my $vendor = $compat;
my $vendor_path = $dt_path . "vendor-prefixes.txt";
next if (! -f $vendor_path);
- $vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
+ $vendor =~ s/^([a-zA-Z0-9\-]+)\,.*/$1/;
`grep -Eq "$vendor" $vendor_path`;
if ( $? >> 8 ) {
WARN("UNDOCUMENTED_DT_STRING",
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 2/2] checkpatch: fix spurious vendor compatible warnings
From: Florian Vaussard @ 2014-02-28 16:25 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1393604742-14317-1-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
With a compatible string like
compatible = "foo";
checkpatch will currently try to find "foo" in vendor-prefixes.txt,
which is wrong since the vendor prefix is empty in this specific case.
Skip the vendor test if the compatible is not like
compatible = "vendor,something";
Signed-off-by: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
---
scripts/checkpatch.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e304e77..7437505 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2058,6 +2058,7 @@ sub process {
my $vendor = $compat;
my $vendor_path = $dt_path . "vendor-prefixes.txt";
next if (! -f $vendor_path);
+ next if not $vendor =~ /^[a-zA-Z0-9\-]+\,.*/;
$vendor =~ s/^([a-zA-Z0-9\-]+)\,.*/$1/;
`grep -Eq "$vendor" $vendor_path`;
if ( $? >> 8 ) {
--
1.8.5.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
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Russell King - ARM Linux @ 2014-02-28 16:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Sascha Hauer, Sebastian Hesselbarth, Rob Clark,
Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393590016-9361-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
> Shortly about the display components in the series, in the order of probable
> public interest:
>
> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
> board. They don't do much, but they do mark the end of the video pipeline (from
> the board's pov), and they should also in the future offer ways to handle
> things like the +5V pin on DVI and HDMI connector and HPD pin.
The big thing which concerns me is that we're using very generic
compatible strings here - has anyone done any searches to see whether
there are any existing standards for this kind of stuff already?
Even if none can be found, if we're going to create something like
this, it should probably become a public standard not just for Linux.
If we're not willing to do that, I'd suggest prefixing the compatible
strings with "linux," as a "company" identifier so that there's no
chance that we may hit some major problem caused by a conflicting
implementation in the future.
We could alternatively take the view that Linux will only ever be used
with Linux specific DT files, but I think that's a rather broken
approach given what DT is supposed to be.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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
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