* Re: [PATCH V6 05/12] SPEAr: misc: Add binding information
From: Mark Rutland @ 2014-02-12 18:21 UTC (permalink / raw)
To: Mohit Kumar
Cc: arnd-r2nGTMty4D4@public.gmane.org, Pratyush Anand, Viresh Kumar,
spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <bfddafffd103bef179fef717793bf94652742b85.1392109054.git.mohit.kumar-qxv4g6HH51o@public.gmane.org>
On Tue, Feb 11, 2014 at 09:30:01AM +0000, Mohit Kumar wrote:
> From: Pratyush Anand <pratyush.anand-qxv4g6HH51o@public.gmane.org>
>
> SPEAr SOCs have some miscellaneous registers which are used to configure
> few properties of different peripheral controllers.
>
> Signed-off-by: Pratyush Anand <pratyush.anand-qxv4g6HH51o@public.gmane.org>
> Cc: Mohit Kumar <mohit.kumar-qxv4g6HH51o@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Viresh Kumar <viresh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../devicetree/bindings/arm/spear-misc.txt | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/spear-misc.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/spear-misc.txt b/Documentation/devicetree/bindings/arm/spear-misc.txt
> new file mode 100644
> index 0000000..ab324e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/spear-misc.txt
> @@ -0,0 +1,9 @@
> +SPEAr Misc configuration
> +===========================
> +SPEAr SOCs have some miscellaneous registers which are used to configure
> +few properties of different peripheral controllers.
> +
> +misc node required properties:
> +
> +- compatible Should be "st,spear1340-misc", "syscon".
> +- reg: Address range of misc space
Is there no better name than misc?
How big is this expected to be?
Mark.
--
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 V6 03/12] phy: st-miphy40lp: Add binding information
From: Mark Rutland @ 2014-02-12 18:20 UTC (permalink / raw)
To: Mohit Kumar
Cc: arnd-r2nGTMty4D4@public.gmane.org, Pratyush Anand, Viresh Kumar,
Kishon Vijay Abraham I,
spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <af50da74226a244dfc05aed3dc9d28b896d166a4.1392109054.git.mohit.kumar-qxv4g6HH51o@public.gmane.org>
On Tue, Feb 11, 2014 at 09:29:59AM +0000, Mohit Kumar wrote:
> From: Pratyush Anand <pratyush.anand-qxv4g6HH51o@public.gmane.org>
>
> ST miphy40lp can be used with PCIe, SATA and Super Speed USB
> controllers. SPEAr13XX SoCs use this phy for PCIe and SATA.
>
> Signed-off-by: Pratyush Anand <pratyush.anand-qxv4g6HH51o@public.gmane.org>
> Cc: Mohit Kumar <mohit.kumar-qxv4g6HH51o@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Viresh Kumar <viresh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> Cc: spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../devicetree/bindings/phy/st-miphy40lp.txt | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/st-miphy40lp.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/st-miphy40lp.txt b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> new file mode 100644
> index 0000000..1c8d04c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> @@ -0,0 +1,18 @@
> +ST miphy40lp DT detail
> +===================================
> +
> +miphy40lp is a phy controller from ST Microelectronics which supports PCIe,
> +SATA and Super Speed USB host and devices. It has been used in SPEAr13xx SOCs.
> +
> +Required properties:
> +- compatible : should be "st,miphy40lp-phy"
> + Other supported soc specific compatible:
> + "st,spear1310-miphy"
> + "st,spear1340-miphy"
> +- reg : offset and length of the PHY register set.
> +- misc: phandle for the syscon node to access misc registers
This is very vague. What is this used for?
> +- phy-id: Instance id of the phy.
> +- #phy-cells : from the generic PHY bindings, must be 1.
> + - 1st cell: phandle to the phy node.
> + - 2nd cell: 0 if phy (in 1st cell) is to be used for SATA, 1 for PCIe
> + and 2 for Super Speed USB.
One cell or two?
Thanks,
Mark.
--
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: [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Jason Gunthorpe @ 2014-02-12 18:20 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, keescook-F7+t8E8rja9g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Grant Likely, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140212174554.GM27395-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
Sure is a neat idea, but I think in general it would probably be smart
to include the entire FDT blob in the early random pool, that way you
get MACs and other machine unique data too.
>From there it is a small step to encourage bootloaders to include
boot-time-variable data in the DT like like 'boot time of day', 'cycle
counter', 'random blob', etc.
Then you just need the bootloader to dump the random-seed file into a
DT property.
Or have the bootloader fetch randomness from any HWRNG it has a driver
for. (eg a TPM)
Jason
--
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: [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Arnd Bergmann @ 2014-02-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Laura Abbott, Jason Cooper, linux-kernel, Rob Herring,
Kumar Gala, Grant Likely, keescook
In-Reply-To: <20140212174554.GM27395@titan.lakedaemon.net>
On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
I like the idea, but wouldn't it be easier to pass actual random data
using DT, rather than the address/size? That way we could even
use the same DT binding for passing randomness from the bootloader,
whereever it may have found that.
If the bootloader has internet connectivity, it could even mix in
some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
;-)
Arnd
^ permalink raw reply
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Olof Johansson @ 2014-02-12 18:13 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, Kees Cook, Laura Abbott, Grant Likely, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Kumar Gala
In-Reply-To: <20140212174554.GM27395-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
>
> While not ideal, it works in absence of an HRNG, and is no worse than
> the current situation of storing the seed in /var/lib/misc/random-seed.
> It also doesn't require modification of the bootloaders. Just an
> updated kernel, and update the bootloader environment to load the
> seed.
Hmm. There are some drawbacks with this -- it assumes you can "just
update the bootloader environment" which in general isn't easy to do.
Also, you can't assume that /boot is writable or exists on all
embedded systems.
In general, taking both runtime and system-dependend data and using
that to see entropy is a good idea. For example, device trees that
contain serial numbers and mac addresses for the individual system. I
think x86 feeds the DMI table in for similar purposes.
If that can be amended on some systems with a runtime seed (from
/boot), that's good but we can't rely on it.
-Olof
--
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 3/3] Documentation: mfd: Add binding document for S2MPA01
From: Mark Rutland @ 2014-02-12 18:10 UTC (permalink / raw)
To: Sachin Kamat
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
sbkim73@samsung.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, patches@linaro.org
In-Reply-To: <1389266554-23463-3-git-send-email-sachin.kamat@linaro.org>
Hi Sachin,
Apologies for the delay on this.
On Thu, Jan 09, 2014 at 11:22:34AM +0000, Sachin Kamat wrote:
> Added initial binding documentation for S2MPA01 MFD.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> * Re-organised as suggested by Mark Rutland.
> ---
> Documentation/devicetree/bindings/mfd/s2mpa01.txt | 86 +++++++++++++++++++++
> 1 file changed, 86 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> new file mode 100644
> index 000000000000..70879b92b24b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> @@ -0,0 +1,86 @@
> +
> +* Samsung S2MPA01 Voltage and Current Regulator
> +
> +The Samsung S2MPA01 is a multi-function device which includes high
> +efficiency buck converters including Dual-Phase buck converter, various LDOs,
> +and an RTC. It is interfaced to the host controller using an I2C interface.
> +Each sub-block is addressed by the host system using different I2C slave
> +addresses.
> +
> +Required properties:
> +- compatible: Should be "samsung,s2mpa01-pmic".
> +- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
Is the slave address not per-instance in I2C? If not why must is be 0x66?
> +
> +Optional properties:
> +- interrupt-parent: Specifies the phandle of the interrupt controller to which
> + the interrupts from s2mpa01 are delivered to.
> +- interrupts: Interrupt specifier for interrupt source (connected to SoC).
The part in brackets can go. Assuming this is a single interrupt:
- interrupts: An interrupt-specifier for the sole interrupt generated by
the device.
If the interrupt has a name it would be nice to mention that. If there
are more than one you should describe them.
> +
> +Optional nodes:
> +- regulators: The regulators of s2mpa01 that have to be instantiated should be
> + included in a sub-node named 'regulators'. Regulator nodes and constraints
> + included in this sub-node use the standard regulator bindings which are
> + documented elsewhere.
> +
> +Properties for BUCK regulator nodes:
> + regulator-ramp-delay for BUCKs = [6250/12500(default)/25000/50000] uV/us
This could be made easier to read:
- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
(default), 250000, or 50000. May be 0 for disabling the ramp delay on
BUCK{1,2,3,4}.
> +
> + BUCK[1/2/3/4] supports disabling ramp delay on hardware, so explictly
> + regulator-ramp-delay = <0> can be used for them to disable ramp delay.
> + In the absence of the regulator-ramp-delay property, the default ramp
> + delay will be used.
Can be folded into the above, as in my example.
> +
> + NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
> + for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
Missing '=' before <value>?
> + Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
> + BUCK[2, 4], and BUCK[8, 9, 10]
The following BUCKs share ramp settings:
* 1 and 6
* 2 and 4
* 8, 9, and 10
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 2/3] regulator: Add support for S2MPA01 regulator
From: Mark Rutland @ 2014-02-12 18:02 UTC (permalink / raw)
To: Sachin Kamat
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
sbkim73@samsung.com, lee.jones@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, patches@linaro.org
In-Reply-To: <1389266554-23463-2-git-send-email-sachin.kamat@linaro.org>
On Thu, Jan 09, 2014 at 11:22:33AM +0000, Sachin Kamat wrote:
> Add support for S2MPA01 voltage and current regulator.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> * Addressed comments from Mark Brown
> - Used module_platform_driver instead of subsys init call
> ---
> drivers/regulator/Kconfig | 7 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/s2mpa01.c | 482 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 490 insertions(+)
> create mode 100644 drivers/regulator/s2mpa01.c
[...]
> +static int s2mpa01_pmic_probe(struct platform_device *pdev)
> +{
> + struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> + struct sec_platform_data *pdata = dev_get_platdata(iodev->dev);
> + struct of_regulator_match rdata[S2MPA01_REGULATOR_MAX];
> + struct device_node *reg_np = NULL;
> + struct regulator_config config = { };
> + struct s2mpa01_info *s2mpa01;
> + int i, ret;
> +
> + s2mpa01 = devm_kzalloc(&pdev->dev, sizeof(*s2mpa01), GFP_KERNEL);
> + if (!s2mpa01)
> + return -ENOMEM;
> +
> + for (i = 0; i < S2MPA01_REGULATOR_CNT; i++)
> + rdata[i].name = regulators[i].name;
> +
> + if (iodev->dev->of_node) {
> + reg_np = of_find_node_by_name(iodev->dev->of_node,
> + "regulators");
This walks the allnodes list, and can thus walk outside of the parent
node.
Use of_get_child_by_name instead.
> + if (!reg_np) {
> + dev_err(&pdev->dev,
> + "could not find regulators sub-node\n");
> + return -EINVAL;
> + }
> +
> + of_regulator_match(&pdev->dev, reg_np, rdata,
> + S2MPA01_REGULATOR_MAX);
Is a reference to reg_np held beyond this? Do you need an
of_node_put(reg_np)?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-12 18:00 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com, Alexandre Courbot,
Sekhar Nori, Rob Herring, Santosh Shilimkar,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdbrs==tpUBs=WLWkt0frBcSMRDRokOn2tvP-1gt7Qq3+w@mail.gmail.com>
Hi Linus,
On 02/12/2014 05:03 PM, Linus Walleij wrote:
> On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>
>> The similar GPIO HW block is used by keystone SoCs as
>> in Davinci SoCs.
>> Hence, reuse Davinci GPIO driver for Keystone taking into
>> account that Keystone contains ARM GIC IRQ controller which
>> is implemented using IRQ Chip.
>>
>> Documentation:
>> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> Changes in v4:
>> - rebased on top of v3.14 +
>> [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
>
> I tried applying this and it does not apply on the "devel" branch
> in the GPIO tree. Since I haven't touched one line of code in the
> DaVinci driver since v3.14-rc1 I seriously doubt that this is
> rebased on v3.14[-rc].
>
> Can you please rebase the patch onto v3.14-rc1 for real and
> resend it?
Sorry, But I've to clarify that this patch is based on:
http://www.spinics.net/lists/linux-kernel-janitors/msg18017.html
[patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
And I did it to avoid merge conflicts between these two patches.
Is it possible to apply above one first? It's not in any of your
branches.
Of Course, I can re-base this patch on clean v3.14-rc1, but then merge
conflict will happen with "gpio: davinci: signedness.." patch.
Regards,
- grygorii
^ permalink raw reply
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Jason Cooper @ 2014-02-12 17:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Laura Abbott, Grant Likely, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kumar Gala,
Kees Cook
In-Reply-To: <201402121251.06280.arnd-r2nGTMty4D4@public.gmane.org>
Laura,
Sorry to hijack the thread (sort of). :)
+ Kees Cook
On Wed, Feb 12, 2014 at 12:51:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Laura Abbott wrote:
> > This is an RFC to seed the random number pool earlier when using devicetree.
> > The big issue this is trying to solve is the fact that the stack canary for
> > ARM tends to be the same across bootups of the same device. This is because
> > the random number pools do not get initialized until after the canary has
> > been set up. The canary can be moved later, but in general there is still
> > no way to reliably get random numbers early for other features (e.g. vector
> > randomization).
>
> Implementation-wise this looks reasonable, and it obviously addresses a
> very real problem.
>
> > The goal here is to allow devices to add to the random pools via
> > add_device_randomness or some other method of their chosing at FDT time.
> > I realize that ARCH_RANDOM is already available but this didn't work because
> > 1) ARCH_RANDOM is not multi-platform compatible without added
> > infrastructure to ARM
>
> That could certainly be done, but I agree that a more generic
> approach like you did is nicer. One thing that might be useful
> would be to wire up your OF_RANDOM infrastructure as a generic
> implementation of ARCH_RANDOM, and merge your header file into
> include/asm-generic/archrandom.h, with an added way to call
> arch_get_random_long() for the devices you add.
>
> > The big reason to skip ARCH_RANDOM though is that the random number generation
> > we have would be reasonable if only seeded earlier.
>
> Yes, makes sense.
>
> I also wonder if we should add a 'trivial' implementation that just
> reads a DT property full of random numbers to use as either an initial
> seed, or to feed into arch_get_random_long(). This would allow the
> boot loader to pass any entropy it has already gathered into the kernel,
> but leaves the danger that people might pass static not-so-random data
> through a precompiled dtb file ;-). If we get the boot loaders to be
> smart enough, doing only this would be a much simpler kernel implementation
> than your suggestion, but I'm not sure how far I want to trust boot loaders.
I brought this up at last weeks devicetree irc meeting. My goal is to
provide early randomness for kaslr on ARM. Currently, my idea is modify
the init script to save an additional random seed from /dev/urandom to
/boot/random-seed.
The bootloader would then load this file into ram, and pass the
address/size to the kernel either via dt, or commandline. kaslr (run in
the decompressor) would consume some of this randomness, and then
random.c would consume the rest in a non-crediting initialization.
While not ideal, it works in absence of an HRNG, and is no worse than
the current situation of storing the seed in /var/lib/misc/random-seed.
It also doesn't require modification of the bootloaders. Just an
updated kernel, and update the bootloader environment to load the
seed.
Unfortunately, it's an idea so far. I have one project to get off of my
plate, then this is next :)
thx,
Jason.
--
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] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
From: Philipp Zabel @ 2014-02-12 17:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Russell King - ARM Linux, Grant Likely, Rob Herring,
Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
Kyungmin Park, linux-kernel, linux-media, devicetree,
Guennadi Liakhovetski, Philipp Zabel
In-Reply-To: <20140212223515.71a445f4.m.chehab@samsung.com>
Hi Mauro,
Am Mittwoch, den 12.02.2014, 22:35 +0900 schrieb Mauro Carvalho Chehab:
> Em Wed, 12 Feb 2014 10:11:54 +0100
> Philipp Zabel <p.zabel@pengutronix.de> escreveu:
>
> > Hi Mauro,
> >
> > Am Mittwoch, den 12.02.2014, 06:53 +0900 schrieb Mauro Carvalho Chehab:
> > [...]
> > > > diff --git a/include/media/of_graph.h b/include/media/of_graph.h
> > > > new file mode 100644
> > > > index 0000000..3bbeb60
> > > > --- /dev/null
> > > > +++ b/include/media/of_graph.h
> > > > @@ -0,0 +1,46 @@
> > > > +/*
> > > > + * OF graph binding parsing helpers
> > > > + *
> > > > + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
> > > > + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > > > + *
> > > > + * Copyright (C) 2012 Renesas Electronics Corp.
> > > > + * Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of version 2 of the GNU General Public License as
> > > > + * published by the Free Software Foundation.
> > > > + */
> > > > +#ifndef __LINUX_OF_GRAPH_H
> > > > +#define __LINUX_OF_GRAPH_H
> > > > +
> > > > +#ifdef CONFIG_OF
> > >
> > > As a matter of consistency, it would be better to test here for
> > > CONFIG_OF_GRAPH instead, to reflect the same symbol that enables such
> > > functions as used on Kconfig/Makefile.
> >
> > Maybe I'm trying to be too clever for my own good, but my reasoning was
> > as follows:
> >
> > Suppose I newly use the of_graph_ helpers in a subsystem that does not
> > yet select OF_GRAPH. In that case I'd rather get linking errors earlier
> > rather than stubbed out functions that silently fail to parse the DT
> > later.
>
> I see your point, but, imagining that someone pushed a patch using those
> symbols upstream, that would break compilation and git bisection, with
> will hurt everyone, and not only the very few of us that would actually
> need the OF_GRAPH symbol for an specific driver.
>
> Also, such push would mean that someone forgot to do his homework and
> to test if the committed functionality is actually working.
>
> So, it seems more fair that the one that did the mistake will be the one
> that will suffer the consequences for his errors instead of applying a
> penalty to everybody's else ;)
point taken.
> > Since there is
> > config VIDEO_DEV
> > select OF_GRAPH if OF
> > already and the same should be added for other users of device tree
> > graphs, I think stubbing out the functions only if OF is disabled should
> > be enough.
>
> Well, if you want to be sure that the graph will always be there if OF, then
> you could do, instead:
>
> config OF_GRAPH
> bool
> default OF
>
> (that would actually make OF_GRAPH just an alias to OF - so we could just
> use OF instead).
>
> In any case, I think that we should use the same config name at Makefile,
> Kconfig and of_graph.h (either OF_GRAPH or just OF).
If nobody states a strong preference, I'll just get rid of the
CONFIG_OF_GRAPH option altogether and use CONFIG_OF directly.
regards
Philipp
^ permalink raw reply
* [PATCH] export of_irq_count
From: delicious quinoa @ 2014-02-12 17:34 UTC (permalink / raw)
To: Rob Herring
Cc: Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dinh Nguyen, Yves Vandervennet, atull-EIB2kfCEclfQT0dZR+AlfA
From: Alan Tull <atull-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
export of_irq_count so it can be used in drivers that are built
as modules.
Signed-off-by: Alan Tull <atull-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
---
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9bcf2cf..5ed19f3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -393,6 +393,7 @@ int of_irq_count(struct device_node *dev)
return nr;
}
+EXPORT_SYMBOL_GPL(of_irq_count);
/**
* of_irq_to_resource_table - Fill in resource table with node's IRQ info
--
1.7.9.5
--
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: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step sizeç
From: Ezequiel Garcia @ 2014-02-12 17:32 UTC (permalink / raw)
To: Brian Norris
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Pekon Gupta, Thomas Petazzoni, Gregory Clement, Seif Mazareeb,
Lior Amsalem
In-Reply-To: <20140212080014.GC3500@norris-Latitude-E6410>
On Wed, Feb 12, 2014 at 12:00:14AM -0800, Brian Norris wrote:
> Hi Ezequiel,
>
> On Fri, Jan 17, 2014 at 09:13:40AM -0300, Ezequiel Garcia wrote:
> > Some flashes can only be properly accessed when the ECC mode is
> > specified, and a way to describe such mode is required.
> >
> > Such ECC mode is completely driver-specific so instead of having one binding
> > per compatible-string, let's add generic ECC strength and ECC step size.
> > Driver's can choose the appropriate ECC mode, based on this specification.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> > index 03855c8..683a310 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> > @@ -3,5 +3,9 @@
> > - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> > "soft_bch".
> > +- nand-ecc-strength : integer ECC required strength.
> > +- nand-ecc-size : integer step size associated to the ECC strength.
>
> Probably should be nand-ecc-step-size, to be clearer.
>
No problem.
> > + The exact meaning of the ECC strength and ECC size parameters is completely
> > + driver-specific.
>
> I think we can be much more specific than this. We need to at least
> describe how the strength and size are related, and we need to mention
> how this represents the ECC scheme to use, rather than the minimum
> requirement of the flash.
>
> I'd say something like this. Feel free to improve it, but it covers the
> gist of what I think we can say in a generic document:
>
> - nand-ecc-strength: integer representing the number of bits to correct
> per ECC step
> - nand-ecc-step-size: integer representing the number of data bytes
> that are covered by a single ECC step
>
> Together, the ECC strength and step size define the correction
> capability, so that we say we will correct "X bit errors per Y
> bytes". The interpretation of these parameters is
> implementation-defined, but they often have ramifications on the
> formation, interpretation, and placement of correction metadata on
> the flash. Not all implementations must support all possible
> combinations. Implementations are encouraged to further define the
> value(s) they support.
>
Much better, thanks!
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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 v3 0/2] ASoC: atmel_ssc_dai: add option to choose clock
From: Mark Brown @ 2014-02-12 17:23 UTC (permalink / raw)
To: Bo Shen
Cc: Mark Rutland, alsa-devel, Stephen Warren, linux-doc, Takashi Iwai,
nicolas.ferre, Liam Girdwood, Chas Williams, Lars-Peter Clausen,
Arnd Bergmann, linux-atm-general, plagnioj, devicetree,
Pawel Moll, Ian Campbell, linux-sound, Rob Herring,
linux-arm-kernel, Richard Genoud, Greg Kroah-Hartman,
linux-kernel, Rob Landley, netdev
In-Reply-To: <1392012586-30790-1-git-send-email-voice.shen@atmel.com>
[-- Attachment #1.1: Type: text/plain, Size: 259 bytes --]
On Mon, Feb 10, 2014 at 02:09:44PM +0800, Bo Shen wrote:
> When SSC work in slave mode, the clock can come from TK pin and also
> can come from RK pin, this is hardware design decided. So, make it
> available to choose where the clock from.
Applied, thanks.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Fabio Estevam @ 2014-02-12 17:22 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <20140212152050.GA28749-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
On Wed, Feb 12, 2014 at 1:20 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Feb 12, 2014 at 01:57:36PM +0000, Mark Rutland wrote:
>> As it stands, the dts are buggy. I can appreciate that you don't feel
>> this is important, but I do. It's not just an IMX issue, there is
>> widespread misunderstanding and abuse of simple-bus.
>>
>> Said abuse is relying on current Linux implementation details, and that
>> can and will create problems if and when probing code is changed.
>
> The reality is the code already gets no chance to change on this regard,
> considering the requirement that we need to maintain the interface
> between kernel and DT as ABI. The dts have been there like this for
> 10 kernel releases or so.
What breakage do you see with this patch?
--
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: [RFC/PATCH 2/3] arm: Add ARCH_WANT_OF_RANDOMNESS
From: Grant Likely @ 2014-02-12 16:49 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann
Cc: Laura Abbott, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kumar Gala,
Kees Cook
In-Reply-To: <1392168805-14200-3-git-send-email-lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, 11 Feb 2014 17:33:24 -0800, Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> The stack canary for ARM is currently the same across reboots
> due to lack of randomness early enough. Add ARCH_WANT_OF_RANDOMNESS
> to allow devices to add whatever randomness they need.
>
> Signed-off-by: Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Do you have a draft patch for a user of this yet?
g.
> ---
> arch/arm/Kconfig | 3 +++
> arch/arm/kernel/vmlinux.lds.S | 1 +
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e254198..7ab0db1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -222,6 +222,9 @@ config NEED_RET_TO_USER
> config ARCH_MTD_XIP
> bool
>
> +config ARCH_WANT_OF_RANDOMNESS
> + def_bool n
> +
> config VECTORS_BASE
> hex
> default 0xffff0000 if MMU || CPU_HIGH_VECTOR
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 7bcee5c..2198258 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -202,6 +202,7 @@ SECTIONS
> INIT_SETUP(16)
> INIT_CALLS
> CON_INITCALL
> + EARLY_RANDOM_FUNCS
> SECURITY_INITCALL
> INIT_RAM_FS
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
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: [RFC/PATCH 1/3] of: Add early randomness hooks
From: Grant Likely @ 2014-02-12 16:47 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann
Cc: Laura Abbott, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kumar Gala,
Kees Cook
In-Reply-To: <1392168805-14200-2-git-send-email-lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, 11 Feb 2014 17:33:23 -0800, Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> Until randomness is added to the kernel's pools, random
> numbers returned may not be truly 'random'. Randomness comes
> from a variety of sources in the kernel but much of the
> randomness comes from device related initialization. This
> means that any random numbers that are needed before drivers
> are initialized (e.g. stack canary) may not be truely random.
> Fix this by build a list of functions that can be used to add
> randomness to the kernel's pools very early. The functions are
> tied to particular compatible strings of devicetree nodes. The
> flattened devicetree is scanned and if the node is present the
> function is called. Note that this must happen on the flattened
> devicetree to ensure the randomness gets added to the pool
> early enough to make a difference.
>
> Signed-off-by: Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Intriguing solution. Looks good to me, but some comments below...
> ---
> drivers/of/Kconfig | 7 ++++++
> drivers/of/Makefile | 1 +
> drivers/of/fdt.c | 7 ++++++
> drivers/of/of_randomness.c | 43 +++++++++++++++++++++++++++++++++++++
> include/asm-generic/vmlinux.lds.h | 5 ++++
> include/linux/of_randomness.h | 42 ++++++++++++++++++++++++++++++++++++
> 6 files changed, 105 insertions(+), 0 deletions(-)
> create mode 100644 drivers/of/of_randomness.c
> create mode 100644 include/linux/of_randomness.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index c6973f1..6ae4a38 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -75,4 +75,11 @@ config OF_MTD
> depends on MTD
> def_bool y
>
> +config OF_RANDOMNESS
> + def_bool n
There should be the option to turn this off, particularly if it turns
out to be expensive in terms of boot time.
> + depends on OF_FLATTREE && ARCH_WANT_OF_RANDOMNESS
> + help
> + OpenFirmware hooks to scan for device randomness
> + via flat devicetree
Inconsistent whitespace
> +
> endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index efd0510..0ce02d1 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_MTD) += of_mtd.o
> +obj-$(CONFIG_OF_RANDOMNESS) += of_randomness.o
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 758b4f8..c25960e 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/of_randomness.h>
> #include <linux/string.h>
> #include <linux/errno.h>
> #include <linux/slab.h>
> @@ -889,6 +890,12 @@ bool __init early_init_dt_scan(void *params)
> /* Setup memory, calling early_init_dt_add_memory_arch */
> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>
> +#ifdef CONFIG_OF_RANDOMNESS
> + /* Add device randomness */
> + of_scan_flat_dt(early_init_dt_scan_early_randomness, NULL);
> +#endif
Drop the #ifdef in fdt.c and use static inlines in the header file. One
that does the of_scan_flat_dt() call, and one empty stub for the
!CONFIG_OF_RANDOMNESS case.
I would also bypass the of_scan_flat_dt call entirely if the
__early_random_funcs list is empty.
> +
> +
> return true;
> }
>
> diff --git a/drivers/of/of_randomness.c b/drivers/of/of_randomness.c
> new file mode 100644
> index 0000000..9d23624
> --- /dev/null
> +++ b/drivers/of/of_randomness.c
> @@ -0,0 +1,43 @@
> +/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/random.h>
> +#include <linux/string.h>
> +#include <linux/of_randomness.h>
> +#include <linux/of_fdt.h>
> +
> +int __init early_init_dt_scan_early_randomness(unsigned long node,
> + const char *uname,
> + int depth, void *data)
> +{
> + struct early_random_func *f;
> + void *prop;
> + unsigned long len;
> +
> + prop = of_get_flat_dt_prop(node, "compatible", &len);
> +
> + if (!prop)
> + return 0;
> +
> + for (f = __early_random_funcs_start;
> + f < __early_random_funcs_end;
> + f++) {
> + pr_debug("Check compat %s addr %p against %s\n",
> + f->compat_string, f->add_randomness, (char *)prop);
> + if (strcmp(prop, f->compat_string) == 0)
> + f->add_randomness(node);
> + }
> +
> + return 0;
> +}
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bc2121f..e5b8be9 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -645,6 +645,11 @@
> *(.security_initcall.init) \
> VMLINUX_SYMBOL(__security_initcall_end) = .;
>
> +#define EARLY_RANDOM_FUNCS \
> + VMLINUX_SYMBOL(__early_random_funcs_start) = .; \
> + *(.earlyrandom.init) \
> + VMLINUX_SYMBOL(__early_random_funcs_end) = .;
> +
> #ifdef CONFIG_BLK_DEV_INITRD
> #define INIT_RAM_FS \
> . = ALIGN(4); \
> diff --git a/include/linux/of_randomness.h b/include/linux/of_randomness.h
> new file mode 100644
> index 0000000..b8b4532
> --- /dev/null
> +++ b/include/linux/of_randomness.h
> @@ -0,0 +1,42 @@
> +/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#ifndef LINUX_OF_RANDOMNESS_H
> +#define LINUX_OF_RANDOMNESS_H
> +
> +extern int early_init_dt_scan_early_randomness(unsigned long node,
> + const char *uname,
> + int depth, void *data);
> +
> +#ifdef CONFIG_OF_RANDOMNESS
> +
> +struct early_random_func {
> + char *compat_string;
> + void (*add_randomness)(unsigned long fdt_node);
> +};
> +
> +extern struct early_random_func __early_random_funcs_start[];
> +extern struct early_random_func __early_random_funcs_end[];
> +
> +#define EARLY_RANDOM_FUNC(c, f) \
> +static struct early_random_func __early_rand##f __used \
> + __attribute((__section__(".earlyrandom.init"))) = { \
> + .compat_string = c, \
> + .add_randomness = f\
> + } \
> +
> +#else
> +
> +#define EARLY_RANDOM_FUNC(f, e)
> +#endif
> +
> +#endif
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
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] bus: imx-weim: support weim-cs-gpr for imx6q-weim
From: Philippe De Muyter @ 2014-02-12 16:43 UTC (permalink / raw)
To: Shawn Guo; +Cc: Huang Shijie, kernel, linux-arm-kernel, devicetree
In-Reply-To: <1392087011-31629-1-git-send-email-shawn.guo@linaro.org>
Thanks Shawn.
On Tue, Feb 11, 2014 at 10:50:11AM +0800, Shawn Guo wrote:
> For imx6q-weim type of device, there might a WEIM CS space configuration
> register in General Purpose Register controller, e.g. IOMUXC_GPR1 on
> i.MX6Q.
>
> Depending on which configuration of the following 4 is chosen for given
> system, IOMUXC_GPR1[11:0] should be set up as 0x5, 0x1b, 0x4b or 0x249
As the bits are actually grouped by 3, one could write:
... as 05, 033, 0113, or 01111
> correspondingly.
>
> CS0(128M) CS1(0M) CS2(0M) CS3(0M)
> CS0(64M) CS1(64M) CS2(0M) CS3(0M)
> CS0(64M) CS1(32M) CS2(32M) CS3(0M)
> CS0(32M) CS1(32M) CS2(32M) CS3(32M)
>
> The patch creates a table in the driver for above configurations, and
> detects which one is being used for the booting system by looking at
> 'ranges' property of WEIM node. Thus the WEIM CS GPR can be set up
> automatically at boot time.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> Documentation/devicetree/bindings/bus/imx-weim.txt | 6 ++
> drivers/bus/imx-weim.c | 83 ++++++++++++++++++++
> 2 files changed, 89 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
> index 0fd76c4..d114460f 100644
> --- a/Documentation/devicetree/bindings/bus/imx-weim.txt
> +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
> @@ -19,6 +19,12 @@ Required properties:
>
> <cs-number> 0 <physical address of mapping> <size>
>
> +Optional properties:
> +
> + - fsl,weim-cs-gpr: Should be the phandle to the General Purpose Register
> + controller that contains WEIM CS GPR register, e.g.
> + IOMUXC_GPR1 on i.MX6Q.
> +
Why require that new property ? It makes things harder to use.
And you could add the body of your commit log here.
> Timing property for child nodes. It is mandatory, not optional.
>
> - fsl,weim-cs-timing: The timing array, contains timing values for the
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 3ef58c8..9c8a522 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -11,6 +11,9 @@
> #include <linux/clk.h>
> #include <linux/io.h>
> #include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include <linux/regmap.h>
>
> struct imx_weim_devtype {
> unsigned int cs_count;
> @@ -56,6 +59,83 @@ static const struct of_device_id weim_id_table[] = {
> };
> MODULE_DEVICE_TABLE(of, weim_id_table);
>
> +struct imx6q_weim_gpr {
> + u32 cssize[4];
> + u32 gprval;
> +};
> +
> +static const struct imx6q_weim_gpr imx6q_weim_gpr_data[] __initconst = {
> + {
> + /* CS0(128M) CS1(0M) CS2(0M) CS3(0M) */
> + .cssize = { 128, 0, 0, 0 },
> + .gprval = 0x5,
05
> + }, {
> + /* CS0(64M) CS1(64M) CS2(0M) CS3(0M) */
> + .cssize = { 64, 64, 0, 0 },
> + .gprval = 0x1b,
033
> + }, {
> + /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
> + .cssize = { 64, 32, 32, 0 },
> + .gprval = 0x4b,
0113
> + }, {
> + /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
/* CS0(32M) CS1(32M) CS2(32M) CS3(32M) */
> + .cssize = { 32, 32, 32, 32 },
> + .gprval = 0x249,
01111
> + },
> +};
> +
> +static int __init imx6q_weim_gpr_setup(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + const struct property *prop;
> + struct regmap *gpr;
> + u32 cssize[4] = { 0, 0, 0, 0 };
> + int len;
> + int ret;
> + int i;
> +
> + gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (IS_ERR(gpr)) {
> + dev_dbg(&pdev->dev, "No weim-cs-gpr to set up\n");
> + return 0;
> + }
> +
> + prop = of_find_property(np, "ranges", &len);
> + if (prop == NULL)
> + return -ENOENT;
> + if (len % (sizeof(u32) * 4))
> + return -EINVAL;
> +
> + for (i = 0; i < len / (sizeof(u32) * 4); i++) {
> + int cs;
> + /* read cs index */
> + ret = of_property_read_u32_index(np, "ranges", i * 4, &cs);
> + if (ret)
> + return ret;
> + /* read cs size */
> + ret = of_property_read_u32_index(np, "ranges", i * 4 + 3,
> + &cssize[cs]);
> + if (ret)
> + return ret;
> + /* turn to MB */
> + cssize[cs] >>= 20;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(imx6q_weim_gpr_data); i++) {
> + ret = memcmp(cssize, imx6q_weim_gpr_data[i].cssize,
> + sizeof(cssize));
> + if (ret == 0) {
> + /* Find it. Set up IOMUXC_GPR1[11:0] with the gprval. */
Found it
> + regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff,
> + imx6q_weim_gpr_data[i].gprval);
> + return 0;
> + }
> + }
> +
> + dev_err(&pdev->dev, "Invalid 'ranges' configuration\n");
> + return -EINVAL;
> +}
> +
> /* Parse and set the timing for this device. */
> static int __init weim_timing_setup(struct device_node *np, void __iomem *base,
> const struct imx_weim_devtype *devtype)
> @@ -92,6 +172,9 @@ static int __init weim_parse_dt(struct platform_device *pdev,
> struct device_node *child;
> int ret;
>
> + if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6q-weim"))
> + imx6q_weim_gpr_setup(pdev);
> +
> for_each_child_of_node(pdev->dev.of_node, child) {
> if (!child->name)
> continue;
> --
> 1.7.9.5
>
Now the most important : it works. I have tested it successfully for the
4 combinations.
Code could probably be made shorter by using 'of_prop_next_u32' and building
the gprval incrementally, then checking it against the four possible values,
though.
But, again, thanks, Shawn
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Mark Rutland @ 2014-02-12 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree@vger.kernel.org, Srinivas Kandagatla,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, alexandre.torgue@st.com
In-Reply-To: <1392220985-28189-1-git-send-email-lee.jones@linaro.org>
On Wed, Feb 12, 2014 at 04:03:02PM +0000, Lee Jones wrote:
> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> devices. It has 2 ports which it can use for either; both SATA, both
> PCIe or one of each in any configuration.
>
> Cc: devicetree@vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> new file mode 100644
> index 0000000..fdfa7ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,43 @@
> +STMicroelectronics STi MIPHY365x PHY binding
> +============================================
> +
> +This binding describes a miphy device that is used to control PHY hardware
> +for SATA and PCIe.
> +
> +Required properties:
> +- compatible: Should be "st,miphy365x-phy"
> +- #phy-cells: Should be 2 (See example)
The first example has #phy-cells = <1>.
What do the cells mean? What are the expected values?
> +- reg: Address and length of the register set for the device
> +- reg-names: The names of the register addresses corresponding to the
> + registers filled in "reg".
Whenever there is a ${PROP}-names property, there should be a list of
explicit values, and a description of how it relates to ${PROP}. Without
that it's a bit useless.
Please provide an explicit list of expected names here.
I assume here what you want is something like:
- reg: a list of address + length pairs, one for each entry in reg-names
- reg-names: should contain:
* "sata0" for the sata0 control registers...
* "sata1" ...
* "pcie0" ...
* "pcie1" ...
> +- st,syscfg : Should be a phandle of the syscfg node.
What's this used for?
Cheers,
Mark.
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-12 16:31 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll,
Linus Walleij, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Mark Brown
In-Reply-To: <20140212161206.GD25957-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Wednesday 12 February 2014 16:12:06 Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 01:03:26PM +0000, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014 11:47:40 Mark Rutland wrote:
> From a quick grep, for pl022's SSPCLK we currently have the strings:
>
> * ssp{0,1}clk
> * spi_clk
> * spi{0,1,2,3}clk
>
> Though I may have missed a string or two where nodes get amended in more
> specific files. A grep for apb_clk to find neighbours didn't highlight
> any obvious ones.
Ok. Both ssp{0,1}clk and spi{0,1,2,3}clk /only/ appear in
arch/arm/boot/dts/ste-dbx5x0.dtsi and are clearly a bug, so unless
Linus Walleij has objections, I'd declare those to be bugs that
should be fixed by changing the DT file to spi_clk.
> > I noticed that ux500 has uses four different strings, one for each
> > instance, which is obviously a bug and should just be fixed. There is
> > no way this was intentional, and we can just rely on teh fallback
> > if you want to have that anyway.
>
> Sure, I'll fix those up once we have a preferred name. I guess this
> would be SSPCLK by Russell's comments, I wasn't able to find a prior use
> in the git history, but it would be in keeping with KMIREFCLK as used by
> the pl050 driver.
We do have a few cases of spi_clk, so I'd use that one. Ideally it
should be the string given in the data sheet for the IP block of course,
possibly with capital letters and underscores turned converted to
more regular strings.
> > > I assume that for the non-dt case it's possible to name clock inputs to
> > > a device without the clock being associated with the name globally? If
> > > so we could get rid of the index usage entirely in this case.
> >
> > Sorry, I don't understand the question.
>
> I thought one of the issues before dt was that clocks were in a global
> namespace. Mark's reply implies that's not necessarily the case, so I'll
> take a tour through clkdev to educate myself.
The whole point of clkdev is to create a local per-device namespace
so drivers don't need to care about the global names, as far as I understand
it.
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 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Brown @ 2014-02-12 16:22 UTC (permalink / raw)
To: Mark Rutland
Cc: Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll,
Linus Walleij, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <20140212161206.GD25957-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Wed, Feb 12, 2014 at 04:12:06PM +0000, Mark Rutland wrote:
> I thought one of the issues before dt was that clocks were in a global
> namespace. Mark's reply implies that's not necessarily the case, so I'll
> take a tour through clkdev to educate myself.
There's both a global namespace and a device local namespace, the most
exact match is used - see the comment on clk_find(). Remember that in
the past clock implementations didn't have to use clkdev at all so the
implementations varied a lot (which is half the problem with drivers
now). Lots of implementations just used global clock names and didn't
pay any attention to dev.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v11] gpio: add a driver for the Synopsys DesignWare APB GPIO block
From: delicious quinoa @ 2014-02-12 16:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org, Jamie Iles,
devicetree@vger.kernel.org, Mark Rutland, Grant Likely,
Rob Herring, Steffen Trumtrar, Sebastian Hesselbarth,
Heiko Stuebner, Alan Tull, Dinh Nguyen, Yves Vandervennet
In-Reply-To: <CACRpkdYiC=nzVG4_nQuRVSNP9TB4W=3VL9QhBQjmqvLvmP6McA@mail.gmail.com>
On Mon, Feb 10, 2014 at 5:06 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hi Alan, this is starting to look good. I's like an ACK from a DT
> maintainer on the bindings but can't see anything really controversial
> about them.
>
> On Thu, Feb 6, 2014 at 11:06 PM, Alan Tull <delicious.quinoa@gmail.com> wrote:
>
>> +static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
>> +{
>> + struct bgpio_chip *bgc = to_bgpio_chip(gc);
>> + struct dwapb_gpio_port *port = container_of(bgc, struct
>> + dwapb_gpio_port, bgc);
>> + struct dwapb_gpio *gpio = port->gpio;
>> +
>> + return irq_create_mapping(gpio->domain, offset);
>> +}
>
> I think you want to call irq_find_mapping() here. irq_create_mapping()
> should be called for all valid IRQs on probe() instead.
>
>> + ct = irq_gc->chip_types;
>> + ct->chip.irq_ack = irq_gc_ack_set_bit;
>> + ct->chip.irq_mask = irq_gc_mask_set_bit;
>> + ct->chip.irq_unmask = irq_gc_mask_clr_bit;
>> + ct->chip.irq_set_type = dwapb_irq_set_type;
>> + ct->chip.irq_enable = dwapb_irq_enable;
>> + ct->chip.irq_disable = dwapb_irq_disable;
>> + ct->regs.ack = GPIO_PORTA_EOI;
>> + ct->regs.mask = GPIO_INTMASK;
>
> Please add .startup() and .shutdown() callbacks marking the
> respective lines as IRQs, compare to recent patches in the
> GPIO subsystem such as this:
> http://marc.info/?l=linux-gpio&m=138546100215235&w=2
>
> You probably want to call irq_create_mapping() for each
> valid IRQ after registering the chip in this function.
Hi Linus,
Thanks for the feedback. I am working on making these changes. The
startup/shutdown were easy to add.
I am wondering about the change in usage of
irq_find_mapping/irq_create_mapping. It seems like all the GPIO
drivers that use irq domains do it the way I was doing it (that's
where I got the idea in the first place): irq_create_mapping is used
in the to_irq() function. I guess this is a general direction all the
other drivers will be encouraged to go in also?
Regards,
Alan
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-12 16:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll,
Linus Walleij, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Mark Brown
In-Reply-To: <1786282.mNUF0ZaUg2@wuerfel>
On Wed, Feb 12, 2014 at 01:03:26PM +0000, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 11:47:40 Mark Rutland wrote:
> > On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> > > On Wednesday 12 February 2014, Mark Rutland wrote:
> > > > To me it feels odd to require the last clock in the list (apb_pclk) to
> > > > be named, and the rest to be in a particular order. For the dt case it
> > > > seems saner to add new clocks with names as it allows arbitrary subsets
> > > > of clocks to be wired up and described (though obviously in this case a
> > > > missing sspclk would be problematic).
> > >
> > > Yes, good point about the missing clocks, and I also agree mixing ordered
> > > and named clocks in one device is rather odd and can lead to trouble.
> > >
> > > I guess there isn't really a good way out here, and I certainly won't
> > > ask for it to be done one way or the other if someone else has a
> > > good argument which way it should be implemented.
> >
> > Having thought about it, all dts that for the ssp_pclk must have some
> > name for the sspclk (though the specific name is arbitrary). I could get
> > the driver to try each of those before falling back to the index
> > (perhaps with a helper that takes a list of known aliases), so all
> > existing dts (that we are aware of) would work with the clock requested
> > by name.
>
> Strange. Why do the even have names in there? What are those strings?
I guess they're there as spacers to allow the AMBA bus code to get the
right clock when it calls clk_get(&pcdev->dev, "apb_pclk"). Everyone
seems to have worked around the binding rather than reporting the issue
or fixing it.
>From a quick grep, for pl022's SSPCLK we currently have the strings:
* ssp{0,1}clk
* spi_clk
* spi{0,1,2,3}clk
Though I may have missed a string or two where nodes get amended in more
specific files. A grep for apb_clk to find neighbours didn't highlight
any obvious ones.
>
> I noticed that ux500 has uses four different strings, one for each
> instance, which is obviously a bug and should just be fixed. There is
> no way this was intentional, and we can just rely on teh fallback
> if you want to have that anyway.
Sure, I'll fix those up once we have a preferred name. I guess this
would be SSPCLK by Russell's comments, I wasn't able to find a prior use
in the git history, but it would be in keeping with KMIREFCLK as used by
the pl050 driver.
Given the general policy of trying to not break support for existing
DTBs we'll need some fallback, either using the first clock or getting
the driver to try the names above.
>
> > I assume that for the non-dt case it's possible to name clock inputs to
> > a device without the clock being associated with the name globally? If
> > so we could get rid of the index usage entirely in this case.
>
> Sorry, I don't understand the question.
I thought one of the issues before dt was that clocks were in a global
namespace. Mark's reply implies that's not necessarily the case, so I'll
take a tour through clkdev to educate myself.
Cheers,
Mark.
--
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 3/4] ARM: DT: STi: Add DT node for MiPHY365x
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
In-Reply-To: <1392220985-28189-1-git-send-email-lee.jones@linaro.org>
The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.
Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
arch/arm/boot/dts/stih416-b2020-revE.dts | 6 +++++-
arch/arm/boot/dts/stih416-b2020.dts | 6 ++++++
arch/arm/boot/dts/stih416.dtsi | 13 +++++++++++++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts b/arch/arm/boot/dts/stih416-b2020-revE.dts
index a874570..dbe67fa 100644
--- a/arch/arm/boot/dts/stih416-b2020-revE.dts
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -32,6 +32,10 @@
ethernet1: ethernet@fef08000 {
snps,reset-gpio = <&PIO0 7>;
};
- };
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..fd9cbad 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";
+ soc {
+ miphy365x_phy: miphy365x@0 {
+ st,pcie_tx_pol_inv = <1>;
+ st,sata_gen = "gen3";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 85b8063..9fd8efb 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -9,6 +9,8 @@
#include "stih41x.dtsi"
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
+
+#include <dt-bindings/phy/phy-miphy365x.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset-controller/stih416-resets.h>
/ {
@@ -140,5 +142,16 @@
clocks = <&CLK_S_ICN_REG_0>;
};
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+
+ #phy-cells = <2>;
+ st,syscfg = <&syscfg_rear>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
In-Reply-To: <1392220985-28189-1-git-send-email-lee.jones@linaro.org>
This provides the shared header file which will be reference from both
the MiPHY365x driver and its associated Device Tree node(s).
Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
include/dt-bindings/phy/phy-miphy365x.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-miphy365x.h
diff --git a/include/dt-bindings/phy/phy-miphy365x.h b/include/dt-bindings/phy/phy-miphy365x.h
new file mode 100644
index 0000000..8757c02
--- /dev/null
+++ b/include/dt-bindings/phy/phy-miphy365x.h
@@ -0,0 +1,25 @@
+/*
+ * This header provides constants for the phy framework
+ * based on the STMicroelectronics miphy365x.
+ */
+#ifndef _DT_BINDINGS_PHY_MIPHY
+#define _DT_BINDINGS_PHY_MIPHY
+
+/* Supports 16 ports without a datatype change (u8 & 0xF0). */
+#define MIPHY_PORT_0 0
+#define MIPHY_PORT_1 1
+#define MIPHY_PORT_2 2
+#define MIPHY_PORT_3 3
+
+/* Supports 16 types without a datatype change (u8 & 0x0F). */
+#define MIPHY_TYPE_SHIFT 4
+#define MIPHY_TYPE_SATA (0 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_PCIE (1 << MIPHY_TYPE_SHIFT)
+#define MIPHY_TYPE_USB (2 << MIPHY_TYPE_SHIFT)
+
+#define MIPHY_SATA_PORT0 (MIPHY_TYPE_SATA) | (MIPHY_PORT_0)
+#define MIPHY_SATA_PORT1 (MIPHY_TYPE_SATA) | (MIPHY_PORT_1)
+#define MIPHY_PCIE_PORT0 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_0)
+#define MIPHY_PCIE_PORT1 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_1)
+
+#endif /* _DT_BINDINGS_PHY_MIPHY */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Lee Jones @ 2014-02-12 16:03 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, Lee Jones, devicetree, Srinivas Kandagatla
The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.
Cc: devicetree@vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
new file mode 100644
index 0000000..fdfa7ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -0,0 +1,43 @@
+STMicroelectronics STi MIPHY365x PHY binding
+============================================
+
+This binding describes a miphy device that is used to control PHY hardware
+for SATA and PCIe.
+
+Required properties:
+- compatible: Should be "st,miphy365x-phy"
+- #phy-cells: Should be 2 (See example)
+- reg: Address and length of the register set for the device
+- reg-names: The names of the register addresses corresponding to the
+ registers filled in "reg".
+- st,syscfg : Should be a phandle of the syscfg node.
+
+Example:
+
+ miphy365x_phy: miphy365x@0 {
+ compatible = "st,miphy365x-phy";
+ #phy-cells = <1>;
+ reg = <0xfe382000 0x100>,
+ <0xfe38a000 0x100>,
+ <0xfe394000 0x100>,
+ <0xfe804000 0x100>;
+ reg-names = "sata0", "sata1", "pcie0", "pcie1";
+ st,syscfg= <&syscfg_rear>;
+ };
+
+Specifying phy control of devices
+=================================
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the miphy device node, a port number
+and a device type.
+
+Example:
+
+#include <dt-bindings/phy/phy-miphy365x.h>
+
+ sata0: sata@fe380000 {
+ ...
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ ...
+ };
--
1.8.3.2
^ 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