* Re: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:22 UTC (permalink / raw)
To: Antti P Miettinen
Cc: Mark Rutland, devicetree@vger.kernel.org,
daniel.lezcano@linaro.org, vincent.guittot@linaro.org,
khilman@linaro.org, linux-pm@vger.kernel.org,
pdeschrijver@nvidia.com, nico@linaro.org, sboyd@codeaurora.org,
amit.kucheria@linaro.org, t.figa@samsung.com, robh+dt@kernel.org,
santosh.shilimkar@ti.com, hanjun.guo@linaro.org,
mark.hambleton@broadcom.com, Sudeep Holla,
grant.likely@linaro.org, galak@codeaurora.org
In-Reply-To: <20140127.144815.1048814583962628826.apm@brigitte.kvy.fi>
On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > That's why I defined the worst case. How did you implemented it in your
> > idle drivers ? That would help generalize it, after all these bindings
> > are there to simplify drivers upstreaming, feedback welcome.
>
> Currently we do not handle this well downstream either. The problem
> with worst case is that the absolute worst case can be really bad and
> probability of it might be very low. Sorry - no ready answer :-)
Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.
It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.
In the meantime if you have further pieces of feedback please keep them
coming.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v3 5/6] ASoC: tlv320aic32x4: Support for master clock
From: Mark Brown @ 2014-01-27 18:17 UTC (permalink / raw)
To: Markus Pargmann
Cc: Mark Rutland, devicetree, alsa-devel, Lars-Peter Clausen,
Pawel Moll, Ian Campbell, Liam Girdwood, Rob Herring, kernel,
Kumar Gala
In-Reply-To: <1390824190-18376-6-git-send-email-mpa@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 501 bytes --]
On Mon, Jan 27, 2014 at 01:03:09PM +0100, Markus Pargmann wrote:
> case SND_SOC_BIAS_STANDBY:
> + /* Switch off master clock */
> + if (!IS_ERR(aic32x4->mclk))
> + clk_disable_unprepare(aic32x4->mclk);
> +
> /* Switch off PLL */
> snd_soc_update_bits(codec, AIC32X4_PLLPR,
> AIC32X4_PLLEN, 0);
This looks like it's disabling the MCLK before disabling the PLL - if
the two are being disabled together I would expect to see the other way
around.
Otherwise this looks good to me.
[-- 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 0/2] Replace /include/ (dtc) with #include
From: Rob Herring @ 2014-01-27 18:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: Pankaj Dubey,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Will Deacon,
Pawel Moll, Mark Rutland,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <20140127163111.GA8358-5wv7dgnIgG8@public.gmane.org>
On Mon, Jan 27, 2014 at 10:31 AM, Catalin Marinas
<catalin.marinas-5wv7dgnIgG8@public.gmane.org> wrote:
> On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
>> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
>> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
>> > based SoC dts files.
>> >
>> > Pankaj Dubey (2):
>> > arm64: dts: use #include for all AppliedMicro device tree files
>> > arm64: dts: use #include for all ARM fast model device tree file
>> >
>> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
>> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
>> > 2 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> Gentle ping.
>
> It would be good to include some rationale behind this change and I'm
> waiting for the DT guys to ack it.
Change this when you actually need it.
Rob
--
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 2/8] pci-rcar-gen2: add initial device tree documentation
From: Sergei Shtylyov @ 2014-01-27 18:13 UTC (permalink / raw)
To: Ben Dooks
Cc: Geert Uytterhoeven, linux-kernel, Linux-sh list,
devicetree@vger.kernel.org, horms+renesas
In-Reply-To: <52E6602A.8040003@codethink.co.uk>
Hello.
On 01/27/2014 04:33 PM, Ben Dooks wrote:
>>>> + - reg : A list of physical regions to access the device. The first is
>>>> + the operational registers for the OHCI/EHCI controller and the
>>>> + second region is for the bridge configuration and control
>>>> registers.
>>> You may want to add "reg-names" to use named regions, as there
>>> is more than one region.
>> I've already told Ben he can't claim EHCI/OHCI register ranges at
>> the bridge node, so there should be only one "reg" specifier.
> Well, that's going to take quite a bit of changing the driver as
> it already assumes two nodes from the platform device definition.
Ah, I failed to realize it's not your mistake, sorry.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Dave Martin @ 2014-01-27 18:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Tomasz Figa, Mark Hambleton, Lorenzo Pieralisi,
Vincent Guittot, Nicolas Pitre, Daniel Lezcano, Antti Miettinen,
Grant Likely, Charles Garcia Tobin, devicetree, Kevin Hilman,
linux-pm, Kumar Gala, Rob Herring, linux-arm-kernel,
Peter De Schrijver, Stephen Boyd, Amit Kucheria,
Santosh Shilimkar, Hanjun Guo, Sudeep Holla
On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:
> > I do have a worry that because the kernel won't normally use this
> > information, by default it will get pasted between .dts files, won't get
> > tested and will be wrong rather often. It also violates the DT principle
> > that probeable information should not be present in the DT -- ePAPR
> > obviously envisages systems where cache geometry information is not
> > probeable, but that's not the case for architected caches on ARM, except
> > in rare cases where the CLIDR is wrong.
>
> That statement is wrong. There are caches on ARM CPUs where there is no
> CLIDR register. I suggest reading the earlier DDI0100 revisions.
You're right; I should have qualified that statement with the proviso
that there _is_ a CLIDR (or some other reliably way to discover the
cache geometry directly from the hardware). In particular, this applies
to all v7-[AR] CPUs, but not to <=v5. Not sure about v6 -- it may be
a mixture.
My worry was about duplication of information; so if there is no discovery
mechanism then there is no duplication and no problem -- on those older
CPUs, the corresponding information could be placed in the DT, or where
it doesn't cause a problem it can remain hard-coded into the kernel, as
at present. If we _allow_ inclusion of that information in the DT for
pre-v7, that still raises questions about what information gets used if
there is hard-coded geometry in the kernel too.
I can't see a sufficient reason to advocate churn for pre-v7 platforms,
but other people's views may differ.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:10 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave P Martin, Mark Rutland, devicetree@vger.kernel.org,
Kevin Hilman, Vincent Guittot, Nicolas Pitre, Amit Kucheria,
Tomasz Figa, Daniel Lezcano, Stephen Boyd, Rob Herring,
Sudeep Holla, Kumar Gala, Santosh Shilimkar, Antti Miettinen,
Mark Hambleton, linux-pm@vger.kernel.org, grant.likely@linaro.org,
Hanjun Guo, Peter De Schrijver,
"linux-arm-kernel@lists.infradead.org" <linux-ar>
In-Reply-To: <20140127125839.GL15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:
> > I do have a worry that because the kernel won't normally use this
> > information, by default it will get pasted between .dts files, won't get
> > tested and will be wrong rather often. It also violates the DT principle
> > that probeable information should not be present in the DT -- ePAPR
> > obviously envisages systems where cache geometry information is not
> > probeable, but that's not the case for architected caches on ARM, except
> > in rare cases where the CLIDR is wrong.
>
> That statement is wrong. There are caches on ARM CPUs where there is no
> CLIDR register. I suggest reading the earlier DDI0100 revisions.
You are right, Dave was referring to the cache geometry properties in the
ePAPRv1.1, and the question on whether to ignore them for ARM. True, some
earlier ARM processors would need DT properties to define cache geometry owing
to the lack of cache type/id registers, but I guess we can work around that
and safely rule cache geometry properties out for ARM (better that than
having people rely on dts files containing wrong copy'n'pasted cache
geometry properties, that's the reasoning). The only reason we are defining
these bindings is to make sure we are able to detect which CPUs share what
caches, we can work around the lack of cache type/id registers to probe
geometry in earlier processors in the kernel.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH 0/9] ARM: dts: imx: remove the use of pingrp macros
From: Olof Johansson @ 2014-01-27 17:47 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Sascha Hauer, Russell King - ARM Linux,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1390668191-20289-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Shawn,
On Sat, Jan 25, 2014 at 8:43 AM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Rob,
>
> In order to solve a pinctrl data efficiency problem, we introduced
> pingrp macros [1] in this development cycle as the base of board dts
> support. The whole imx-dt-3.14 pull request has been held by Olof for
> a few weeks because he wants to get a general approval from DT folks
> on this change. But unfortunately it appears that you are not fond of
> this change.
>
> I just spent the day to create a patch series against imx-dt-3.14 to
> remove these pingrp macros. May I get your nod on this quick
> turn-around, so that we do not miss the merge window?
>
> Hi Olof,
>
> I guess we do not have to shut the door for imx-dt-3.14 if you and DT
> folks are happy with this patch series, which is a quite straight
> forward search&replace change?
The merge window is halfway over already, the time for us to pick up
large branches like these are long past.
Please rebase (since this is a partial revert of some of the earlier
patches in your dt branch, I think?), and resend after -rc1 for 3.15
inclusion.
Thanks,
-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 v5 14/20] watchdog: orion: Add support for Armada 370 and Armada XP SoC
From: Russell King - ARM Linux @ 2014-01-27 17:36 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Lior Amsalem, Andrew Lunn,
Jason Cooper, Tawfik Bayouk, Daniel Lezcano, Wim Van Sebroeck,
Arnd Bergmann, Gregory Clement, Guenter Roeck,
Sebastian Hesselbarth
In-Reply-To: <1390836440-12744-15-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, Jan 27, 2014 at 12:27:14PM -0300, Ezequiel Garcia wrote:
> +static int armada370_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Setup watchdog input clock */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT),
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT));
> +
> + dev->clk_rate = clk_get_rate(dev->clk) / WDT_A370_RATIO;
> + return 0;
> +}
> +
> +static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = of_clk_get_by_name(pdev->dev.of_node, "fixed");
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Enable the fixed watchdog clock input */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_AXP_FIXED_ENABLE_BIT,
> + WDT_AXP_FIXED_ENABLE_BIT);
> +
> + dev->clk_rate = clk_get_rate(dev->clk);
> + return 0;
> +}
Doesn't this result in dev->clk being leaked? Or at least a difference
in the way dev->clk needs to be cleaned up between these two functions?
I think it would be better in this case to use the standard clk_get() in
the first function and always use clk_put()... until there is a devm_*
version of the of_clk_get* functions.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
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] Documentation: devicetree: bindings: drm: Xylon binding
From: Davor Joja @ 2014-01-27 17:33 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20140127162255.GG16516-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
Hi Mark,
> On Mon, Jan 27, 2014 at 03:47:42PM +0000, Davor Joja wrote:
> > Hi,
>
> Hi,
>
> >
> > Can I please get comments about adding new vendor prefix "xylon", and on
> > following devicetree binding for Xylon configurable video controller (logiCVC).
> > Shown node is prepared for Xilinx Linux kernel dts file.
>
> Does this device have any publicly-accessible documentation?
Yes it has, but it does not explain the details mentioned in binding.
http://www.logicbricks.com/Documentation/Datasheets/IP/logiCVC-ML_hds.pdf
>
> It would be helpful if you could Cc this to some graphics related
> mailing lists. Not everyone on devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org is a graphics
> expert, and you'll get much better feedback with the relevant people on
> Cc.
>
Ok, CC'ed.
> It would also be nice to see some code with the binding, and for both
> the code and binding to be sent as patches. That makes it _far_ easier
> to review as it's far easier to compare with existing bindings if in a
> standard format.
>
Currently I do not have it. I only have some old binding which I want to get
rid off. That is why I want to change binding (officially) and then rewrite the
driver code for that exact binding.
> >
> >
> > logicvc_0: logicvc@40030000 {
> > compatible = "xylon,logicvc-4.00.a";
> > reg = <0x40030000 0x6000>;
> > interrupt-parent = <&ps7_scugic_0>;
> > interrupts = <0 59 4>;
> > background-layer-bits-per-pixel = <32>;
> > display-interface = <0>;
> > display-color-space = <1>;
> > is-readable-regs = <1>;
> > is-size-position = <1>;
> > layer-width = <2048>;
> > num-layers = <4>;
> > layer_0 {
> > address = <0>;
> > alpha-mode = <0>;
> > data-width = <16>;
> > type = <0>;
> > } ;
> > layer_1 {
> > address = <0>;
> > alpha-mode = <0>;
> > data-width = <32>;
> > type = <0>;
> > } ;
> > layer_2 {
> > address = <0>;
> > alpha-mode = <1>;
> > data-width = <32>;
> > type = <0>;
> > } ;
> > layer_3 {
> > address = <0>;
> > alpha-mode = <0>;
> > data-width = <16>;
> > type = <1>;
> > } ;
> > } ;
> >
> >
> > Required properties for configuring logiCVC device:
> > - compatible: value must be "xylon,logicvc-4.00.a"
> > - reg: base address and size of the logiCVC IP
>
> Presumably the address and size of the MMIO region the IP has?
Yes, MMIO region address where IP resides and size of IP registers area.
>
> Does it only have a single bank of registers?
>
Yes.
> > - interrupts-parent: the phandle for interrupt controller
> > - interrupts: the interrupt number
>
> Does the device have only a single interrupt?
Yes, in this case connected to ARM GIC.
>
> > - background-layer-bits-per-pixel: background layer color format (0, 16, 32)
> > if "0" last available layer is standard layer
>
> Why is 0 quoted, and what is a "standard layer"?
Thought that this is simple way for saying "not used".
Maybe have / not to have property?
>
> > if 16 or 32, last available layer is background layer implemented in
> > hw register and containing specified bits per pixel color value
> > - display-interface: logiCVC to display physical interface
> > (0=Parallel, 1=ITU656)
> > - display-color-space: logiCVC to display physical color space
> > (0=RGB, 1=YCbCr 4:2:2, 2=YCbCr 4:4:4)
>
> These sound like they should be properties of the display this unit is
> attached to.
To be more exact, this is output interface to whatever (LCD, encoder,
converter, ...), but it is IP property selectable when configuring.
Maybe better name for property should be "interface" and "color-space".
>
> > - is-readable-regs: all hw registers are readable by sw
>
> Which registers aren't always accessible?
IP core can be configured to disable read registers access to all except
interrupt status power control and interupt status.
>
> > - is-size-position: hw changing of layer size and position
>
> These look like booleans, but have values above.
Yes, it is boolean.
Should it be
"readable-regs;" instead "is-readable-regs = <1>;"
"size-position;" instead "is-size-position = <1>;"
>
> > - layer-width: layer width in pixels, common for all layers
> > - num-layers: supported number of layers (1-5)
>
> If you require a node for each layer, you don't need this proeprty --
> you can simply count the layer nodes.
True, I do not know what is practice in this case.
>
> > if "background-layer-bits-per-pixel != 0", "num-layers" property value is
> > decreased by 1
>
> Does that mean the author of the dt subtracts one, or this is done by
> the kernel?
>
In given example it is substracted by author, and I would like to have it like
that.
This comment should be just info for user, and maybe it is confusing.
> Why?
>
> > - layer_N
>
> Where N is?
0-4
>
> > - address: layer address hardcoded in hw (0=Unused, 0x...)
>
> The example gives all layers 0 / unused. What exactly is this address
> space?
This property is set while configuring IP, and if it is set to "0" then driver
knows that there is no dedicated address for video memory and uses its own.
>
> > - alpha-mode: layer transparency mode (0=Layer, 1=Pixel)
> > layer alpha mode contains single alpha value for all layer pixels
> > pixel alpha mode contains alpha value per pixel in video memory
> > pixel alpha mode can increase physical size of pixel in memory
> > (8 bits per pixel in pixel alpha mode uses 16 bits per pixel in
> > memory)
>
> This looks like a runtime decision rather than a property of the device.
>
> > - data-width: layer bits per pixel color format (16, 32)
> > - type: layer type (0=RGB, 1=YCbCr)
>
> Likewise why is this static?
What exactly do you mean with "runtime decision"?
All layer properties are configured in IP, and driver needs to know what they
are to properly handle pixel memory access on specific layer.
Thank you,
Davor
>
> 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: [PATCH 0/2] Replace /include/ (dtc) with #include
From: Catalin Marinas @ 2014-01-27 16:31 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Will Deacon,
Pawel Moll, Mark Rutland,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <52E63DD8.9070909-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
> > based SoC dts files.
> >
> > Pankaj Dubey (2):
> > arm64: dts: use #include for all AppliedMicro device tree files
> > arm64: dts: use #include for all ARM fast model device tree file
> >
> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> Gentle ping.
It would be good to include some rationale behind this change and I'm
waiting for the DT guys to ack it.
--
Catalin
--
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] of: Fix uninitialized child warning in for_each_child_of_node() if !OF
From: Geert Uytterhoeven @ 2014-01-27 16:23 UTC (permalink / raw)
To: Rob Herring
Cc: Grant Likely, Rob Herring, David Howells, Andrew Morton,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJyaMDkj6jE+qk6AuUNB0-TOLdqeYDBdjH+1YJFu2V0DQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 27, 2014 at 5:21 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Jan 27, 2014 at 8:52 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> On Mon, Jan 27, 2014 at 3:16 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Sun, Jan 26, 2014 at 4:21 AM, Geert Uytterhoeven
>>> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>>>> If CONFIG_OF=n:
>>>>
>>>> drivers/i2c/i2c-mux.c: In function ‘i2c_add_mux_adapter’:
>>>> drivers/i2c/i2c-mux.c:158: warning: ‘child’ is used uninitialized in this function
>>>> drivers/leds/leds-lp55xx-common.c: In function ‘lp55xx_of_populate_pdata’:
>>>> drivers/leds/leds-lp55xx-common.c:560: warning: ‘child’ is used uninitialized in this function
>>>> drivers/leds/leds-pwm.c: In function ‘led_pwm_probe’:
>>>> drivers/leds/leds-pwm.c:89: warning: ‘child’ is used uninitialized in this function
>>>> drivers/mfd/stmpe.c: In function ‘stmpe_of_probe’:
>>>> drivers/mfd/stmpe.c:1112: warning: ‘child’ is used uninitialized in this function
>>>> drivers/mfd/tc3589x.c: In function ‘tc3589x_probe’:
>>>> drivers/mfd/tc3589x.c:324: warning: ‘child’ is used uninitialized in this function
>>>> drivers/power/charger-manager.c: In function ‘of_cm_parse_desc’:
>>>> drivers/power/charger-manager.c:1606: warning: ‘child’ is used uninitialized in this function
>>>>
>>>> Introduced by commit 00b2c76a6abbe082bb5afb89ee49ec325e9cd4d2
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> ("include/linux/of.h: make for_each_child_of_node() reference its args when
>>>> CONFIG_OF=n").
>>>>
>>>> Instead of dropping the "__of_use_dn(child)" again, explicitly set child
>>>> to NULL, to protect against code using child after the loop (child == NULL
>>>> is the loop termination condition if CONFIG_OF=y).
>>>>
>>>> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>>>
>>> Just got fixed in mainline:
>>>
>>> commit 00b2c76a6abbe082bb5afb89ee49ec325e9cd4d2
>>
>> Nope, this is the one that introduced new warnings.
>
> Oh right, sorry. Read that too fast.
>
> Won't your change trigger warnings from -Wunused-but-set-variable in
> cases where child is not used? That would only be enabled for "W=1"
> though.
>
> I think the right fix here is all the for_each_X macros should not be
> conditional on CONFIG_OF and we should rely on the functions they call
> like of_get_next_child to do the right thing for !OF.
That's indeed an alternative fix. As long as of_get_next_child() and
friends return NULL, that'll work fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] Documentation: devicetree: bindings: drm: Xylon binding
From: Mark Rutland @ 2014-01-27 16:22 UTC (permalink / raw)
To: Davor Joja; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52E67F9E.20492.1406B56-l//4pz4nnF2T4XiunKkQOL/f6Pfn6aUBAL8bYrjMMd8@public.gmane.org>
On Mon, Jan 27, 2014 at 03:47:42PM +0000, Davor Joja wrote:
> Hi,
Hi,
>
> Can I please get comments about adding new vendor prefix "xylon", and on
> following devicetree binding for Xylon configurable video controller (logiCVC).
> Shown node is prepared for Xilinx Linux kernel dts file.
Does this device have any publicly-accessible documentation?
It would be helpful if you could Cc this to some graphics related
mailing lists. Not everyone on devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org is a graphics
expert, and you'll get much better feedback with the relevant people on
Cc.
It would also be nice to see some code with the binding, and for both
the code and binding to be sent as patches. That makes it _far_ easier
to review as it's far easier to compare with existing bindings if in a
standard format.
>
>
> logicvc_0: logicvc@40030000 {
> compatible = "xylon,logicvc-4.00.a";
> reg = <0x40030000 0x6000>;
> interrupt-parent = <&ps7_scugic_0>;
> interrupts = <0 59 4>;
> background-layer-bits-per-pixel = <32>;
> display-interface = <0>;
> display-color-space = <1>;
> is-readable-regs = <1>;
> is-size-position = <1>;
> layer-width = <2048>;
> num-layers = <4>;
> layer_0 {
> address = <0>;
> alpha-mode = <0>;
> data-width = <16>;
> type = <0>;
> } ;
> layer_1 {
> address = <0>;
> alpha-mode = <0>;
> data-width = <32>;
> type = <0>;
> } ;
> layer_2 {
> address = <0>;
> alpha-mode = <1>;
> data-width = <32>;
> type = <0>;
> } ;
> layer_3 {
> address = <0>;
> alpha-mode = <0>;
> data-width = <16>;
> type = <1>;
> } ;
> } ;
>
>
> Required properties for configuring logiCVC device:
> - compatible: value must be "xylon,logicvc-4.00.a"
> - reg: base address and size of the logiCVC IP
Presumably the address and size of the MMIO region the IP has?
Does it only have a single bank of registers?
> - interrupts-parent: the phandle for interrupt controller
> - interrupts: the interrupt number
Does the device have only a single interrupt?
> - background-layer-bits-per-pixel: background layer color format (0, 16, 32)
> if "0" last available layer is standard layer
Why is 0 quoted, and what is a "standard layer"?
> if 16 or 32, last available layer is background layer implemented in
> hw register and containing specified bits per pixel color value
> - display-interface: logiCVC to display physical interface
> (0=Parallel, 1=ITU656)
> - display-color-space: logiCVC to display physical color space
> (0=RGB, 1=YCbCr 4:2:2, 2=YCbCr 4:4:4)
These sound like they should be properties of the display this unit is
attached to.
> - is-readable-regs: all hw registers are readable by sw
Which registers aren't always accessible?
> - is-size-position: hw changing of layer size and position
These look like booleans, but have values above.
> - layer-width: layer width in pixels, common for all layers
> - num-layers: supported number of layers (1-5)
If you require a node for each layer, you don't need this proeprty --
you can simply count the layer nodes.
> if "background-layer-bits-per-pixel != 0", "num-layers" property value is
> decreased by 1
Does that mean the author of the dt subtracts one, or this is done by
the kernel?
Why?
> - layer_N
Where N is?
> - address: layer address hardcoded in hw (0=Unused, 0x...)
The example gives all layers 0 / unused. What exactly is this address
space?
> - alpha-mode: layer transparency mode (0=Layer, 1=Pixel)
> layer alpha mode contains single alpha value for all layer pixels
> pixel alpha mode contains alpha value per pixel in video memory
> pixel alpha mode can increase physical size of pixel in memory
> (8 bits per pixel in pixel alpha mode uses 16 bits per pixel in
> memory)
This looks like a runtime decision rather than a property of the device.
> - data-width: layer bits per pixel color format (16, 32)
> - type: layer type (0=RGB, 1=YCbCr)
Likewise why is this static?
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: [PATCH] of: Fix uninitialized child warning in for_each_child_of_node() if !OF
From: Rob Herring @ 2014-01-27 16:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Grant Likely, Rob Herring, David Howells, Andrew Morton,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdVNLYoWD=Q+utHUgEBJ1619Q5x=DsZEtmeEbogrQM2a0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 27, 2014 at 8:52 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Mon, Jan 27, 2014 at 3:16 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sun, Jan 26, 2014 at 4:21 AM, Geert Uytterhoeven
>> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>>> If CONFIG_OF=n:
>>>
>>> drivers/i2c/i2c-mux.c: In function ‘i2c_add_mux_adapter’:
>>> drivers/i2c/i2c-mux.c:158: warning: ‘child’ is used uninitialized in this function
>>> drivers/leds/leds-lp55xx-common.c: In function ‘lp55xx_of_populate_pdata’:
>>> drivers/leds/leds-lp55xx-common.c:560: warning: ‘child’ is used uninitialized in this function
>>> drivers/leds/leds-pwm.c: In function ‘led_pwm_probe’:
>>> drivers/leds/leds-pwm.c:89: warning: ‘child’ is used uninitialized in this function
>>> drivers/mfd/stmpe.c: In function ‘stmpe_of_probe’:
>>> drivers/mfd/stmpe.c:1112: warning: ‘child’ is used uninitialized in this function
>>> drivers/mfd/tc3589x.c: In function ‘tc3589x_probe’:
>>> drivers/mfd/tc3589x.c:324: warning: ‘child’ is used uninitialized in this function
>>> drivers/power/charger-manager.c: In function ‘of_cm_parse_desc’:
>>> drivers/power/charger-manager.c:1606: warning: ‘child’ is used uninitialized in this function
>>>
>>> Introduced by commit 00b2c76a6abbe082bb5afb89ee49ec325e9cd4d2
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> ("include/linux/of.h: make for_each_child_of_node() reference its args when
>>> CONFIG_OF=n").
>>>
>>> Instead of dropping the "__of_use_dn(child)" again, explicitly set child
>>> to NULL, to protect against code using child after the loop (child == NULL
>>> is the loop termination condition if CONFIG_OF=y).
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>>
>> Just got fixed in mainline:
>>
>> commit 00b2c76a6abbe082bb5afb89ee49ec325e9cd4d2
>
> Nope, this is the one that introduced new warnings.
Oh right, sorry. Read that too fast.
Won't your change trigger warnings from -Wunused-but-set-variable in
cases where child is not used? That would only be enabled for "W=1"
though.
I think the right fix here is all the for_each_X macros should not be
conditional on CONFIG_OF and we should rely on the functions they call
like of_get_next_child to do the right thing for !OF.
Rob
--
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 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Max Filippov @ 2014-01-27 16:17 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-xtensa@linux-xtensa.org, netdev, devicetree@vger.kernel.org,
LKML, Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
Rob Herring
In-Reply-To: <1390817904.2735.127.camel@deadeye.wl.decadent.org.uk>
Hi Ben,
On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>> not disable advertisement when PHY supports them. This results in
>> non-functioning network when the MAC is connected to a gigabit PHY connected
>> to a gigabit switch.
>>
>> The fix is to disable gigabit speed advertisement on attached PHY
>> unconditionally.
>>
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> drivers/net/ethernet/ethoc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>> index 4de8cfd..0aa1a05 100644
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>> netif_start_queue(dev);
>> }
>>
>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>> + ADVERTISED_1000baseT_Half);
>> phy_start(priv->phy);
>> napi_enable(&priv->napi);
>>
>
> This is not sufficient to disable gigabit speeds; the supported mask
> should also be limited. And it should be done even before the net
I tried that, but when I also limit supported mask the phy driver doesn't
touch gigabit advertising register int the genphy_config_advert at all.
That's probably right for ethtool interface, but ethoc doesn't support
ethtool.
> device is registered.
>
> Rather than poking into the phy_device structure directly from this
> driver, I think you should add a function in phylib for this purpose.
Like below?
---8<---
>From 347331f399626ecaa9a8e54252f55e0b6788772f Mon Sep 17 00:00:00 2001
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Mon, 27 Jan 2014 04:01:40 +0400
Subject: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
not disable advertisement when PHY supports them. This results in
non-functioning network when the MAC is connected to a gigabit PHY connected
to a gigabit switch.
The fix is to disable gigabit speed advertisement on attached PHY
unconditionally.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
drivers/net/ethernet/ethoc.c | 3 +++
include/linux/phy.h | 5 +++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 4de8cfd..e817d58 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -688,6 +688,9 @@ static int ethoc_mdio_probe(struct net_device *dev)
}
priv->phy = phy;
+ phy_update_adv(phy,
+ ~(ADVERTISED_1000baseT_Full |
+ ADVERTISED_1000baseT_Half), 0);
return 0;
}
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..0282a8d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
return phydev->drv->read_status(phydev);
}
+static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
+{
+ phydev->advertising = (phydev->advertising & mask) | set;
+}
+
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
--
1.8.1.4
--
Thanks.
-- Max
^ permalink raw reply related
* Re: [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Felipe Balbi @ 2014-01-27 16:05 UTC (permalink / raw)
To: Heikki Krogerus
Cc: devicetree, george.cherian, linux-doc, linux-usb, linux-kernel,
Felipe Balbi, Kishon Vijay Abraham I, linux-omap,
linux-arm-kernel, rogerq
In-Reply-To: <20140127150855.GA17928@xps8300>
[-- Attachment #1.1: Type: text/plain, Size: 2823 bytes --]
Hi,
On Mon, Jan 27, 2014 at 05:08:55PM +0200, Heikki Krogerus wrote:
> > > Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> > > do not return from probe if the USB PHY library returns -ENODEV as that
> >
> > this isn't correct, they all have PHYs, some of them might not be
> > controllable.
> >
> > > indicates the platform does not have PHY.
> >
> > not really, that indicates the current platform tried to grab a PHY and
> > the PHY doesn't exist. If there's anybody with a non-controllable PHY
> > and someone gives me a really good reason for not using the generic
> > no-op PHY, then we should add a flag and we could:
> >
> > if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
> > dwc3_grab_phys(dwc);
>
> Why would you need to know if the PHY drivers are needed or not
> explicitly in your controller driver?
because, one way or another, they all do need it. Except for quirky ones
like AM437x where a USB3 IP was hardwired into USB2-only mode, so it
really lacks a USB3 PHY.
> > But I really want to see the argument against using no-op. As far as I
> > could see, everybody needs a PHY driver one way or another, some
> > platforms just haven't sent any PHY driver upstream and have their own
> > hacked up solution to avoid using the PHY layer.
>
> Not true in our case. Platforms using Intel's SoCs and chip sets may
> or may not have controllable USB PHY. Quite often they don't. The
> Baytrails have usually ULPI PHY for USB2, but that does not mean they
> provide any vendor specific functions or any need for a driver in any
> case.
that's different from what I heard.
> Are we talking about the old USB PHY library or the new PHY framework
> with the no-op PHY driver?
>
> Well, in any case, I don't understand what is the purpose of the no-op
> PHY driver. What are you drying to achieve with that?
I'm trying to avoid supporting 500 different combinations for a single
driver. We already support old USB PHY layer and generic PHY layer, now
they both need to be made optional. The old USB PHY layer also provides
a no-op, now called phy-generic, which is actually pretty useful.
On top of all that, I'm sure you'll subscribe to the idea of preventing
dwc3 from becoming another MUSB which supports several different
configurations and none work correctly. I much prefer to take baby steps
which are well thought-out and very well exercised, so I'll be very
pedantic about proof of testing.
An invasive change such as $subject needs to be very well-tested in
different architectures with different Kconfig choices before I'd feel
comfortable applying it.
Also, the assumptions made in $subject are just plain wrong, which
gets me really iffy about applying it or not.
cheers
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 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 RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Dave Martin @ 2014-01-27 15:59 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Vincent Guittot, Mark Rutland, devicetree@vger.kernel.org,
Daniel Lezcano, Kevin Hilman, linux-pm@vger.kernel.org,
Peter De Schrijver, Nicolas Pitre, Stephen Boyd, Antti Miettinen,
Amit Kucheria, Tomasz Figa, Rob Herring, Santosh Shilimkar,
Hanjun Guo, Mark Hambleton, Sudeep Holla, grant.likely@linaro.org,
Kumar Gala, LAK, Charles Garcia-Tobin <Charles.Garcia-Tobin@
On Fri, Jan 24, 2014 at 05:58:07PM +0000, Lorenzo Pieralisi wrote:
> Hi Vincent,
>
> On Fri, Jan 24, 2014 at 08:40:40AM +0000, Vincent Guittot wrote:
>
> [...]
>
> > Hi Lorenzo,
> >
> > Sorry for the late reply,
> >
> >
> > > I had an idea. To simplify things, I think that one possibility is to
> > > add a parameter to the power domain specifier (platform specific, see
> > > Tomasz bindings):
> >
> > We can't use a simple boolean state (on/off) for defining the
> > powerdomain state associated to a c-state so your proposal of being
> > able to add a parameter that will define the power domain state is
> > interesting.
> >
> > >
> > > Documentation/devicetree/bindings/power/power_domain.txt
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224928.html
> > >
> > > to represent, when that state is entered the behavior of the power
> > > controller (ie cache RAM retention or cache shutdown or in general any
> > > substate within a power domain). Since it is platform specific, and since
> > > we are able to link caches to the power domain, the power controller will
> > > actually define what happens to the cache when that state is entered
> > > (basically we use the power domain specifier additional parameter to define
> > > a "substate" in that power domain e.g.:
> > >
> > > Example:
> > >
> > > foo_power_controller {
> > > [...]
> > > /*
> > > * first cell is register index, second one is the state index
> > > * that in turn implies the state behavior - eg cache lost or
> > > * retained
> > > */
> > > #power-domain-cells = <2>;
> > > };
> > >
> > > l1-cache {
> > > [...]
> > > /*
> > > * syntax: power-domains = list of power domain specifiers
> > > <[&power_domain_phandle register-index state],[&power_domain_phandle register-index state]>;
> > > The syntax is defined by the power controller du jour
> > > as described by Tomasz bindings
> > > */
> > > power-domains =<&foo_power_controller 0 0 &foo_power_controller 0 1>;
> >
> > Normally, power-domains describes a list of power domain specifiers
> > that are necessary for the l1-cache to at least retain its state so
> > i'm not sure understand your example above
>
> >
> > If we take the example of system that support running, retention and
> > powerdown state described as state 0, 1 and 2 for the power domain, i
> > would have set the l1-cache like:
> > power-domains =<&foo_power_controller 0 1>;
> >
> > for saying that the state is retained up to state 1
> >
> > Please look below, i have modified the rest of your example accordingly
> >
> > >
> > > }:
> > >
> > > and then
> > >
> > > state0 {
> > > index = <2>;
> > > compatible = "arm,cpu-power-state";
> > > latency = <...>;
> > > /*
> > > * This means that when the state is entered, the power
> > > * controller should use register index 0 and state 0,
> > > * whose meaning is power controller specific. Since we
> > > * know all components affected (for every component
> > > * we declare its power domain(s) and states so we
> > > * know what components are affected by the state entry.
> > > * Given the cache node above and this phandle, the state
> > > * implies that the cache is retained, register index == 0 state == 0
> > > /*
> > > power-domain =<&foo_power_controller 0 0>;
> >
> > for retention state we need to set the power domain in state 1
> > power-domain =<&foo_power_controller 0 1>;
The name "power-domain" probably needs changing if the specifier contains
state information too.
Instead, we could call it "power-state" or similar.
Key issues I see:
1) How to describe platforms where there is no "power controller" as such,
just a bunch of clocks and regulators that Linux has to poke directly.
2) Two devices might have the same power controller (in terms of IP and
revision), but integrated in different ways. So, maybe thinking of
the referenced thing as a power controller is not correct. We can
thing in terms of referring to individual power domains, or maybe
to a "power model" for the SoC.
The power domain or model becomes a container for power (domains and)
states, and refers to the IP blocks (power controllers, regulators,
clocks, clamps, whatever) required to implement it.
This change of abstraction might map more naturally onto "bunch
of clocks and regulators" situations: the power model or domain
binding can make symbolic references to clocks and regulators etc.,
so that the binding becomes less dependent on the exact content of
the rest of the DT.
3) We need to be very clear that the power state specifier needs to be
defined in terms of the actual hardware effects in the relevant SoC-
specific binding -- at the "what" level, rather than "how".
There's a fair chance of people getting lazy: they'll just stuff
indices in the DT which map to random LUTs in the Linux driver. In
that case, the DT would be describing the Linux driver, not the
hardware -- that's not what we want.
Delegating the job of defining power states to the SoC documentation
seems acceptable, though.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v2 3/4] Update bcm_defconfig with new pinctrl CONFIG
From: Christian Daudt @ 2014-01-27 15:57 UTC (permalink / raw)
To: Sherman Yin
Cc: Mark Brown, Heiko Stübner, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
Linus Walleij, Grant Likely, Matt Porter,
devicetree@vger.kernel.org, Linux Doc List,
linux-kernel@vger.kernel.org, Broadcom Kernel Feedback List,
linux-arm-kernel@lists.infradead.org, Olof Johansson
In-Reply-To: <1390509887-19278-4-git-send-email-syin@broadcom.com>
On Thu, Jan 23, 2014 at 12:44 PM, Sherman Yin <syin@broadcom.com> wrote:
> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
> driver and its related CONFIG option are renamed to bcm281xx.
>
> This commit updates the defconfig that enables the pinctrl driver.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Matt Porter <mporter@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/configs/bcm_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index bede511..53d6d47 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -126,4 +126,4 @@ CONFIG_CRC_ITU_T=y
> CONFIG_CRC7=y
> CONFIG_XZ_DEC=y
> CONFIG_AVERAGE=y
> -CONFIG_PINCTRL_CAPRI=y
> +CONFIG_PINCTRL_BCM281XX=y
> --
> 1.7.9.5
>
Acked-by: Christian Daudt <bcm@fixthebug.org>
Olof,
Can you apply this patch directly or do you want me to send a pull
request with it ?
Thanks,
csd
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Rob Herring @ 2014-01-27 15:56 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev, Tony Prisk,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rl-7uj+XXdSDtwfv37vnLkPlQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1390823503-24087-4-git-send-email-alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This should make the driver usable with VIA/WonderMedia ARM-based
> Systems-on-Chip integrated Rhine III adapters. Note that these
> are always in MMIO mode, and don't have any known EEPROM.
>
> Signed-off-by: Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Roger Luethi <rl-7uj+XXdSDtwfv37vnLkPlQ@public.gmane.org>
> ---
> .../devicetree/bindings/net/via-rhine.txt | 18 ++
> drivers/net/ethernet/via/Kconfig | 2 +-
> drivers/net/ethernet/via/via-rhine.c | 293 +++++++++++++--------
> 3 files changed, 200 insertions(+), 113 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt
>
> diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt
> new file mode 100644
> index 0000000..684dd3a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/via-rhine.txt
> @@ -0,0 +1,18 @@
> +* VIA Rhine 10/100 Network Controller
> +
> +Required properties:
> +- compatible : Should be "via,rhine"
This should be more specific rather than...
> +- reg : Address and length of the io space
> +- interrupts : Should contain the controller interrupt line
> +- rhine,revision : Rhine core revision, used to inform the
> + driver of quirks and capabilities to expect from
> + the device. Mimics the respective PCI attribute.
having this property. The OF match table can then have the quirks set
based on compatible strings.
Rob
--
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/3] net: ethoc: document OF bindings
From: Max Filippov @ 2014-01-27 15:52 UTC (permalink / raw)
To: Rob Herring
Cc: linux-xtensa@linux-xtensa.org, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Chris Zankel, Marc Gauthier,
David S. Miller, Grant Likely, Rob Herring
In-Reply-To: <CAL_JsqLjn4FXrNGLGHs639TEqmQKPx_kk9JbAd-hn7mexzAjNg@mail.gmail.com>
Hi Rob,
On Mon, Jan 27, 2014 at 6:10 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Sun, Jan 26, 2014 at 9:59 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> .../devicetree/bindings/net/opencores-ethoc.txt | 25 ++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/opencores-ethoc.txt b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>> new file mode 100644
>> index 0000000..f7c6c94
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>> @@ -0,0 +1,25 @@
>> +* OpenCores MAC 10/100 Mbps
>> +
>> +Required properties:
>> +- compatible: Should be "opencores,ethoc".
>
> There are not different versions of IP or is the version probeable?
AFAIK there's single version of this 10/100 MAC.
It doesn't have any identification registers.
>> +- reg: Address and length of the register set for the device and of its
>> + descriptor memory.
>> +- interrupts: Should contain ethoc interrupt.
>> +
>> +Optional properties:
>> +- local-mac-address: 6 bytes, mac address
>
> There's a patch in progress to move all the standard network
> properties to a common location, so you can remove this.
Will do.
>> +- clock-frequency: basic MAC frequency.
>> +- mii-mgmt-clock-frequency: frequency of MII management bus. Together
>> + with clock-frequency determines the value programmed into the CLKDIV
>> + field of MIIMODER register.
>> +
>> +Examples:
>> +
>> + enet0: ethoc@fd030000 {
>> + compatible = "opencores,ethoc";
>> + reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
>> + interrupts = <1>;
>> + local-mac-address = [00 50 c2 13 6f 00];
>> + clock-frequency = <50000000>;
>> + mii-mgmt-clock-frequency = <5000000>;
>> + };
>> --
>> 1.8.1.4
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-01-27 15:50 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Lior Amsalem, devicetree, linux-watchdog, Tawfik Bayouk,
Andrew Lunn, Daniel Lezcano, Wim Van Sebroeck, Arnd Bergmann,
Guenter Roeck, Gregory Clement, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
> This entire series depends on latest irqchip-orion fixes by Sebastian.
> Namely, this one: https://lkml.org/lkml/2014/1/23/594.
>
> How should we handle this dependency?
Sorry, I'm short on time atm. Which specific patches now depend on his
changes?
I'll be doing a topic branch for tglx for that, so it shouldn't be
rocket surgery. The big unknown is the MMIO patch currently in
Russell's patch tracker.
We may end up waiting for MMIO and Sebastian's changes to land, then
applying this during the next cycle.
thx,
Jason.
> Changes from v4 are:
>
> * Provided better commit subject and commit log for patch 7:
> "watchdog: orion: Handle the interrupt so it's properly acked".
>
> * Corrected the misnamed fuction try_rstout_ioremap().
>
> * A bunch of s/interruption/interrupt fixes
>
> * Dropped the '0' as a valid IRQ in the platform_get_irq() check, given
> it should return a positive virq-space number.
>
> Changes from v3 are:
>
> * It wasn't nice to break DT compatibility by adding a second resource
> requirement, so we provided a fallback to use the RSTOUT address.
> All in all, the solution doesn't look too bad.
>
> * Added a full watchdog stop at driver probe time, *before* the call
> to request_irq().
>
> Notice that currently the request_irq() doesn't seem to clear the
> pending interrupt. This means the BRIDGE_CAUSE clear removal is
> still not safe.
>
> This should be fixed sooner than later and, of course, before this
> gets merged.
>
> * Rework the interrupt request, to use devm_request_irq() and
> avoid dealing with IRQ releasing.
>
> * Added proper clock error handling and fixed the probe() error path.
>
> * Typos and minor issues got fixed
>
> Changes from v2:
>
> * Add proper error checking on clk_prepare_enable() and return
> PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
>
> * After the usage of the atomic I/O and considering the watchdog core
> does its own serialization, the driver's spinlock was completely
> redundant and was removed. Also suggested by Fabio.
>
> * Instead of making the driver dependent on PLAT_ORION, added a dependency
> to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
> we're working on PLAT_ORION removal.
>
> Changes from v1:
>
> * Watchdog RSTOUT enable.
> While v1 enabled the RSTOUT at each machine initialization, Jason Gunthorpe
> later pointed out [2] that such enabling might lead to a spurious watchdog
> trigger, in the event of the watchdog expired event not being cleared.
>
> Therefore, the current patchset adds RSTOUT as a second address resource
> (or 'reg' entry in devicetree words) to allow different platforms specify
> the corresponding address of the register. This change allows to build the
> driver on multiplatforms builds as helps remove a mach-specific header.
>
> The drawback of this is that the DT backwards compatibility gets broken;
> this was timely discussed but no better solution was achieved or proposed.
>
> * BRIDGE CAUSE clear removal
> The watchdog cause clear should be done by the bridge irqchip driver, so
> it's fine to remove it from the watchdog driver and instead request the
> interrupt.
>
> However, there are still a few platforms (orion5x, and legacy
> kirkwood/dove) that doesn't have this bridge irqchip support enabled.
> On these platforms the bridge cause clear is simply *not* done.
>
> If we are paranoid about this, maybe we can simply add the clear on each
> mach-xxx/irq.c, together with the other irq is initialization.
>
> Once again, thanks to everyone who helped reviewing this.
>
> Ezequiel Garcia (20):
> ARM: Introduce atomic MMIO modify
> clocksource: orion: Use atomic access for shared registers
> watchdog: orion: Add clock error handling
> watchdog: orion: Use atomic access for shared registers
> watchdog: orion: Remove unused macros
> watchdog: orion: Make sure the watchdog is initially stopped
> watchdog: orion: Handle the interrupt so it's properly acked
> watchdog: orion: Make RSTOUT register a separate resource
> watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
> watchdog: orion: Introduce an orion_watchdog device structure
> watchdog: orion: Introduce per-compatible of_device_id data
> watchdog: orion: Add per-compatible clock initialization
> watchdog: orion: Add per-compatible watchdog start implementation
> watchdog: orion: Add support for Armada 370 and Armada XP SoC
> ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
> ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
> ARM: dove: Enable Dove watchdog in the devicetree
> watchdog: orion: Enable the build on ARCH_MVEBU
> ARM: mvebu: Enable watchdog support in defconfig
> ARM: dove: Enable watchdog support in the defconfig
>
> .../devicetree/bindings/watchdog/marvel.txt | 8 +-
> arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
> arch/arm/boot/dts/armada-370.dtsi | 5 +
> arch/arm/boot/dts/armada-xp.dtsi | 6 +
> arch/arm/boot/dts/dove.dtsi | 8 +
> arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> arch/arm/configs/dove_defconfig | 2 +
> arch/arm/configs/mvebu_defconfig | 2 +
> arch/arm/include/asm/io.h | 6 +
> arch/arm/kernel/io.c | 35 ++
> arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
> arch/arm/plat-orion/common.c | 10 +-
> drivers/clocksource/time-orion.c | 28 +-
> drivers/watchdog/Kconfig | 2 +-
> drivers/watchdog/orion_wdt.c | 369 ++++++++++++++++-----
> 18 files changed, 383 insertions(+), 108 deletions(-)
>
> --
> 1.8.1.5
>
^ permalink raw reply
* [RFC] Documentation: devicetree: bindings: drm: Xylon binding
From: Davor Joja @ 2014-01-27 15:47 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Hi,
Can I please get comments about adding new vendor prefix "xylon", and on
following devicetree binding for Xylon configurable video controller (logiCVC).
Shown node is prepared for Xilinx Linux kernel dts file.
logicvc_0: logicvc@40030000 {
compatible = "xylon,logicvc-4.00.a";
reg = <0x40030000 0x6000>;
interrupt-parent = <&ps7_scugic_0>;
interrupts = <0 59 4>;
background-layer-bits-per-pixel = <32>;
display-interface = <0>;
display-color-space = <1>;
is-readable-regs = <1>;
is-size-position = <1>;
layer-width = <2048>;
num-layers = <4>;
layer_0 {
address = <0>;
alpha-mode = <0>;
data-width = <16>;
type = <0>;
} ;
layer_1 {
address = <0>;
alpha-mode = <0>;
data-width = <32>;
type = <0>;
} ;
layer_2 {
address = <0>;
alpha-mode = <1>;
data-width = <32>;
type = <0>;
} ;
layer_3 {
address = <0>;
alpha-mode = <0>;
data-width = <16>;
type = <1>;
} ;
} ;
Required properties for configuring logiCVC device:
- compatible: value must be "xylon,logicvc-4.00.a"
- reg: base address and size of the logiCVC IP
- interrupts-parent: the phandle for interrupt controller
- interrupts: the interrupt number
- background-layer-bits-per-pixel: background layer color format (0, 16, 32)
if "0" last available layer is standard layer
if 16 or 32, last available layer is background layer implemented in
hw register and containing specified bits per pixel color value
- display-interface: logiCVC to display physical interface
(0=Parallel, 1=ITU656)
- display-color-space: logiCVC to display physical color space
(0=RGB, 1=YCbCr 4:2:2, 2=YCbCr 4:4:4)
- is-readable-regs: all hw registers are readable by sw
- is-size-position: hw changing of layer size and position
- layer-width: layer width in pixels, common for all layers
- num-layers: supported number of layers (1-5)
if "background-layer-bits-per-pixel != 0", "num-layers" property value is
decreased by 1
- layer_N
- address: layer address hardcoded in hw (0=Unused, 0x...)
- alpha-mode: layer transparency mode (0=Layer, 1=Pixel)
layer alpha mode contains single alpha value for all layer pixels
pixel alpha mode contains alpha value per pixel in video memory
pixel alpha mode can increase physical size of pixel in memory
(8 bits per pixel in pixel alpha mode uses 16 bits per pixel in
memory)
- data-width: layer bits per pixel color format (16, 32)
- type: layer type (0=RGB, 1=YCbCr)
Thank you,
Davor
--
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/3] net: via-rhine: add OF bus binding
From: Alexey Charkov @ 2014-01-27 15:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Tony Prisk,
devicetree-u79uwXL29TY76Z2rM5mHXA, Roger Luethi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1390834654.2735.148.camel-nDn/Rdv9kqW9Jme8/bJn5UCKIB8iOfG2tUK59QYPAWc@public.gmane.org>
2014/1/27 Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>:
> On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
>> This should make the driver usable with VIA/WonderMedia ARM-based
>> Systems-on-Chip integrated Rhine III adapters. Note that these
>> are always in MMIO mode, and don't have any known EEPROM.
> [...]
>> --- a/drivers/net/ethernet/via/Kconfig
>> +++ b/drivers/net/ethernet/via/Kconfig
>> @@ -19,7 +19,7 @@ if NET_VENDOR_VIA
>>
>> config VIA_RHINE
>> tristate "VIA Rhine support"
>> - depends on PCI
>> + depends on (PCI || USE_OF)
>> select CRC32
>> select MII
>> ---help---
>
> This seems like the right thing to do, but it means you need to add
> #ifdef CONFIG_PCI and #ifdef CONFIG_USE_OF around the driver structures
> and related functions.
Frankly, I would like to avoid that if possible (as pointed out in the
cover email), as I believe we would get a cleaner driver without
#ifdef. This is also the way it was done in via-velocity, and it works
just fine.
> You should compile-test in configurations that have just one of those
> dependencies enabled.
This has been compile-tested and runtime-tested in OF-only
configuration on WM8950, and Roger also tested it in PCI-only
configuration, so it seems to work fine.
> [...]
>> --- a/drivers/net/ethernet/via/via-rhine.c
>> +++ b/drivers/net/ethernet/via/via-rhine.c
> [...]
>> @@ -847,7 +856,8 @@ static void rhine_hw_init(struct net_device *dev, long pioaddr)
>> msleep(5);
>>
>> /* Reload EEPROM controlled bytes cleared by soft reset */
>> - rhine_reload_eeprom(pioaddr, dev);
>> + if (!strncmp(dev->dev.parent->bus->name, "pci", 3))
>> + rhine_reload_eeprom(pioaddr, dev);
> [...]
>
> Ew. I think you should use dev_is_pci(), although you might also need
> to guard that with #ifdef CONFIG_PCI.
Oh, cool. Didn't realize it existed :) Will adjust, thanks.
I believe the #ifdef is not strictly required, though, as we include
the PCI header anyway (and the macro expands to just a simple test).
Any specific concerns why we should do that, apart from the +3.8%
module size increase?
Thanks,
Alexey
--
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] phy-rcar-usb-gen2: add device tree support
From: Felipe Balbi @ 2014-01-27 15:33 UTC (permalink / raw)
To: Ben Dooks
Cc: linux-kernel, linux-usb, linux-sh, Magnus Damm, Simon Horman,
devicetree
In-Reply-To: <1390755901-3743-1-git-send-email-ben.dooks@codethink.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3950 bytes --]
Hi,
On Sun, Jan 26, 2014 at 05:05:01PM +0000, Ben Dooks wrote:
> Add support for the phy-rcar-gen2-usb driver to be probed from device tree.
>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> Reviewed-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> Fixes from v2:
> - fix missing of_if patch
> (I clearly should not be let near git-rebase when hungry)
>
> Fixes from v1:
> - use of_property_reasd-bool()
> - remove unused of_id variable
>
> Cc: linux-usb@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: devicetree@vger.kernel.org
it's a good practice to Cc maintainers ;-)
patch looks good to me, but I'd like to get an Ack from one of DT
maintainers
> ---
> drivers/usb/phy/phy-rcar-gen2-usb.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c b/drivers/usb/phy/phy-rcar-gen2-usb.c
> index db3ab34..e4665b9 100644
> --- a/drivers/usb/phy/phy-rcar-gen2-usb.c
> +++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/platform_data/usb-rcar-gen2-phy.h>
> #include <linux/platform_device.h>
> +#include <linux/of_device.h>
> #include <linux/spinlock.h>
> #include <linux/usb/otg.h>
>
> @@ -167,6 +168,12 @@ out:
> spin_unlock_irqrestore(&priv->lock, flags);
> }
>
> +static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
> + { .compatible = "renesas,usb-phy-r8a7790", },
> + { .compatible = "renesas,rcar-gen2-usb-phy", },
> + { },
> +};
> +
> static int rcar_gen2_usb_phy_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -178,7 +185,7 @@ static int rcar_gen2_usb_phy_probe(struct platform_device *pdev)
> int retval;
>
> pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> + if (!pdata && !dev->of_node) {
> dev_err(dev, "No platform data\n");
> return -EINVAL;
> }
> @@ -203,16 +210,29 @@ static int rcar_gen2_usb_phy_probe(struct platform_device *pdev)
> spin_lock_init(&priv->lock);
> priv->clk = clk;
> priv->base = base;
> - priv->ugctrl2 = pdata->chan0_pci ?
> - USBHS_UGCTRL2_USB0_PCI : USBHS_UGCTRL2_USB0_HS;
> - priv->ugctrl2 |= pdata->chan2_pci ?
> - USBHS_UGCTRL2_USB2_PCI : USBHS_UGCTRL2_USB2_SS;
> priv->phy.dev = dev;
> priv->phy.label = dev_name(dev);
> priv->phy.init = rcar_gen2_usb_phy_init;
> priv->phy.shutdown = rcar_gen2_usb_phy_shutdown;
> priv->phy.set_suspend = rcar_gen2_usb_phy_set_suspend;
>
> + if (dev->of_node) {
> + if (of_property_read_bool(dev->of_node, "renesas,usb0-hs"))
> + priv->ugctrl2 = USBHS_UGCTRL2_USB0_HS;
> + else
> + priv->ugctrl2 = USBHS_UGCTRL2_USB0_PCI;
> +
> + if (of_property_read_bool(dev->of_node, "renesas,usb2-ss"))
> + priv->ugctrl2 |= USBHS_UGCTRL2_USB2_SS;
> + else
> + priv->ugctrl2 |= USBHS_UGCTRL2_USB2_PCI;
> + } else {
> + priv->ugctrl2 = pdata->chan0_pci ?
> + USBHS_UGCTRL2_USB0_PCI : USBHS_UGCTRL2_USB0_HS;
> + priv->ugctrl2 |= pdata->chan2_pci ?
> + USBHS_UGCTRL2_USB2_PCI : USBHS_UGCTRL2_USB2_SS;
> + }
> +
> retval = usb_add_phy(&priv->phy, USB_PHY_TYPE_USB2);
> if (retval < 0) {
> dev_err(dev, "Failed to add USB phy\n");
> @@ -236,6 +256,7 @@ static int rcar_gen2_usb_phy_remove(struct platform_device *pdev)
> static struct platform_driver rcar_gen2_usb_phy_driver = {
> .driver = {
> .name = "usb_phy_rcar_gen2",
> + .of_match_table = rcar_gen2_usb_phy_ofmatch,
> },
> .probe = rcar_gen2_usb_phy_probe,
> .remove = rcar_gen2_usb_phy_remove,
> --
> 1.8.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] net: via-rhine: switch to generic DMA functions
From: Ben Hutchings @ 2014-01-27 15:28 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Tony Prisk,
devicetree-u79uwXL29TY76Z2rM5mHXA, Roger Luethi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CABjd4Yyq_Mia=2DkC83Wpi6o1o3m5+yoMcDL4WdZmuLvRtu6qg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
On Mon, 2014-01-27 at 19:26 +0400, Alexey Charkov wrote:
> 2014/1/27 Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>:
> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
[...]
> >> @@ -1094,20 +1094,22 @@ static int alloc_ring(struct net_device* dev)
> >> void *ring;
> >> dma_addr_t ring_dma;
> >>
> >> - ring = pci_alloc_consistent(rp->pdev,
> >> + ring = dma_alloc_coherent(&rp->pdev->dev,
> >> RX_RING_SIZE * sizeof(struct rx_desc) +
> >> TX_RING_SIZE * sizeof(struct tx_desc),
> >> - &ring_dma);
> >> + &ring_dma,
> >> + GFP_ATOMIC);
> > [...]
> >
> > Indentation is messed up here (and in several other function calls
> > you're changing). You should align the function arguments so each line
> > begins in the column after the opening parenthesis.
>
> Ben, thanks for pointing out. I actually just tried to follow the
> style of surrounding code, but happy to adjust if that's the preferred
> option. From what I can see, these lines should still fit in below 80
> cols even with increased indents...
>
> Should we then also adjust other function calls within the driver with
> similar indentation (if any), that are currently not touched by this
> patch series?
There is no need to do that at the same time, but it would be a nice bit
of cleanup.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH v5 20/20] ARM: dove: Enable watchdog support in the defconfig
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Lior Amsalem, Tawfik Bayouk, Wim Van Sebroeck, Arnd Bergmann,
Daniel Lezcano, Guenter Roeck, Ezequiel Garcia
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Now that we have watchdog support, let's add it to the defconfig.
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/configs/dove_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index 1101054..a330690 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -80,6 +80,8 @@ CONFIG_SPI_ORION=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
CONFIG_DOVE_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_ORION_WATCHDOG=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
--
1.8.1.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
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