* Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document
From: Stephen Warren @ 2013-08-21 23:12 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree, hongbo.zhang, linux-kernel, vinod.koul, djbw,
linuxppc-dev
In-Reply-To: <1377125156.5029.40.camel@snotra.buserror.net>
On 08/21/2013 04:45 PM, Scott Wood wrote:
> On Wed, 2013-08-21 at 16:33 -0600, Stephen Warren wrote:
>> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
>>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>>
>>> This patch updates the discription of each type of DMA controller and its
>>> channels, it is preparation for adding another new DMA controller binding, it
>>> also fixes some defects of indent for text alignment at the same time.
>>
>>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>>
>>> -- compatible : compatible list, contains 2 entries, first is
>>> - "fsl,CHIP-dma", where CHIP is the processor
>>> - (mpc8349, mpc8360, etc.) and the second is
>>> - "fsl,elo-dma"
>>> +- compatible : must include "fsl,elo-dma"
>>
>> Why remove the list of supported compatible values. Lately it seems that
>> we're moving towards listing more/all the values rather than removing
>> their documentation...
>
> Previous versions had language that required fsl,CHIP-dma for 83xx (and
> maybe 85xx?) but not the new chip. I asked for it to be consistent.
> The reason that 83xx still has fsl,CHIP-dma is not because of anything
> special to 83xx, but that most other chips with this device have been
> converted to dtsi and it's much more of a pain to specify the specific
> SoC in that context. The existing language does not match actual device
> trees when it comes to 85xx.
>
> Plus, the exact SoC name is of dubious value for integrated devices. It
> doesn't uniquely identify the hardware because different versions of the
> SoC could have different versions of the subdevice. As such, on our
> chips we've been moving away from including a compatible that specifies
> the exact SoC. If it turns out we made a mistake in naming different
> versions of the device, or if there are errata, the exact SoC can still
> be determined at runtime using SVR.
OK, if there's some alternative run-time way of enabling chip-specific
quirking, it's probably fine to remove the extra compatible values.
Now, that does rather assume that this DMA IP block will only ever be
used within SoCs that have that SVR concept, but perhaps if that's ever
not the case, we can simply go back to requiring extra compatible values
in those specific cases?
^ permalink raw reply
* Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Scott Wood @ 2013-08-21 23:00 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree, hongbo.zhang, linux-kernel, vinod.koul, djbw,
linuxppc-dev
In-Reply-To: <521541EE.4010303@wwwdotorg.org>
On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:
> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
> > + - reg : <registers mapping for channel>
> > + - interrupts : <interrupt mapping for DMA channel IRQ>
>
> s/interrupts/specifier/
Do you mean s/interrupt mapping/interrupt specifier/?
And probably s/registers mapping/register specifier/ as well.
-Scott
^ permalink raw reply
* Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Scott Wood @ 2013-08-21 22:57 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree, hongbo.zhang, linux-kernel, vinod.koul, djbw,
linuxppc-dev
In-Reply-To: <521541EE.4010303@wwwdotorg.org>
On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:
> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
> > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
> > the device tree nodes for them.
>
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>
> > +** Freescale Elo3 DMA Controller
> > + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
> > + series chips, such as t1040, t4240, b4860.
> > +
> > +Required properties:
> > +
> > +- compatible : must include "fsl,elo3-dma"
>
> This should probably list all the SoC-specific compatible values too.
We're not going to specify them in the device tree (see my comment on
patch 1/3), so we probably shouldn't lie about them in the binding like
eloplus currently does. :-)
> > +- ranges : describes the mapping between the address space of the
> > + DMA channels and the address space of the DMA controller
>
> Oh, so looking at the example, this is simply about being able to write
> the reg value in the child nodes more easily without having to write out
> the full based address of the controller in each child node.
>
> I don't think the binding document should require this;
It doesn't. It just requires that there be a mapping; it doesn't have
to be any particular mapping.
> all the binding document should care about is that the child nodes have a valid reg
> value. Whether that reg value is <0x100100 0x80> without a ranges in the
> top-level DMA
Without a ranges property there is no translation and the registers
would not be memory mappable. Linux may treat the absence of ranges as
an identity mapping for compatibility with some broken OF trees, but
it's not standard.
> nor or whether that reg value is <0x0 0x80> with a ranges
> value in the top-level DMA node isn't something that the binding should
> specify. Either way will work equally without affecting a driver for the
> DMA controller; the parsing of reg with/without a ranges property is
> more of a core part of DT than anything to do with this binding.
>
> > +- DMA channel nodes:
> > + - compatible : must include "fsl,eloplus-dma-channel"
>
> Why do the channel nodes even need a compatible value? Presumably the
> driver for the top-level DMA node will scan these dma-channel nodes to
> extract the information it needs and will simply assume that all these
> nodes are DMA channel nodes rather than something else? I suppose this
> doesn't hurt, it just seems unnecessary unless you foresee other child
> nodes types existing in the future and hence a need to differentiate
> different types of nodes.
Other than "this is how the existing binding works and we're not going
to break compatibility", it allows the OS more flexibility to choose
whether to bind to controllers or directly to the channels. Sometimes a
channel will be labelled with a different compatible if it has a fixed
purpose such as being connected to audio hardware (e.g. mpc8610_hpcd.dts
where some channels are "fsl,ssi-dma-channel").
The channels are mostly independent. Only an interrupt is shared on
elo, and only an IOMMU device number on eloplus/elo3 -- plus a shared
status register that doesn't have to be used and doesn't make sense to
use without a shared interrupt.
> > + - reg : <registers mapping for channel>
> > + - interrupts : <interrupt mapping for DMA channel IRQ>
>
> s/interrupts/specifier/
>
> > +Example:
> > +dma@100300 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
>
> Those weren't mentioned in the required properties list above.
It's inherent in the existence of child nodes with reg (unless you rely
on the default of 2/1, which is discouraged). The binding should
mention it if it has particular requirements for the value of either
property, but I don't think we care here (much like we don't care what
sort of translation is used in ranges).
> Perhaps they're considered such a core part of DT functionality that it's not
> necessary, yet some other binding documents do include these properties
> in the list of required properties.
Some bindings even try to repeat the definition of standard properties
-- often incorrectly. We should avoid that.
-Scott
^ permalink raw reply
* Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document
From: Scott Wood @ 2013-08-21 22:45 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree, hongbo.zhang, linux-kernel, vinod.koul, djbw,
linuxppc-dev
In-Reply-To: <5215402E.70007@wwwdotorg.org>
On Wed, 2013-08-21 at 16:33 -0600, Stephen Warren wrote:
> On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
> > From: Hongbo Zhang <hongbo.zhang@freescale.com>
> >
> > This patch updates the discription of each type of DMA controller and its
> > channels, it is preparation for adding another new DMA controller binding, it
> > also fixes some defects of indent for text alignment at the same time.
>
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
>
> > -- compatible : compatible list, contains 2 entries, first is
> > - "fsl,CHIP-dma", where CHIP is the processor
> > - (mpc8349, mpc8360, etc.) and the second is
> > - "fsl,elo-dma"
> > +- compatible : must include "fsl,elo-dma"
>
> Why remove the list of supported compatible values. Lately it seems that
> we're moving towards listing more/all the values rather than removing
> their documentation...
Previous versions had language that required fsl,CHIP-dma for 83xx (and
maybe 85xx?) but not the new chip. I asked for it to be consistent.
The reason that 83xx still has fsl,CHIP-dma is not because of anything
special to 83xx, but that most other chips with this device have been
converted to dtsi and it's much more of a pain to specify the specific
SoC in that context. The existing language does not match actual device
trees when it comes to 85xx.
Plus, the exact SoC name is of dubious value for integrated devices. It
doesn't uniquely identify the hardware because different versions of the
SoC could have different versions of the subdevice. As such, on our
chips we've been moving away from including a compatible that specifies
the exact SoC. If it turns out we made a mistake in naming different
versions of the device, or if there are errata, the exact SoC can still
be determined at runtime using SVR.
> > -- ranges : Should be defined as specified in 1) to describe the
> > - DMA controller channels.
> > +- ranges : describes the mapping between the address space of the
> > + DMA channels and the address space of the DMA controller
>
> What is "the address space of the DMA controller". Perhaps this should
> say "the CPU-visible address space" instead?
It's translating from the addresses used in the child nodes to a CCSR
offset. It's really just a convenience for the readability and
macro-ability of the device tree that we do this translation at all,
versus having an empty ranges and using CCSR offsets in the children.
It's not about translating between the DMA controller's view and the
CPU's view or anything like that.
-Scott
^ permalink raw reply
* Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document
From: Stephen Warren @ 2013-08-21 22:33 UTC (permalink / raw)
To: hongbo.zhang
Cc: devicetree, vinod.koul, linux-kernel, djbw, scottwood,
linuxppc-dev
In-Reply-To: <1375094944-3343-2-git-send-email-hongbo.zhang@freescale.com>
On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> This patch updates the discription of each type of DMA controller and its
> channels, it is preparation for adding another new DMA controller binding, it
> also fixes some defects of indent for text alignment at the same time.
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> -- compatible : compatible list, contains 2 entries, first is
> - "fsl,CHIP-dma", where CHIP is the processor
> - (mpc8349, mpc8360, etc.) and the second is
> - "fsl,elo-dma"
> +- compatible : must include "fsl,elo-dma"
Why remove the list of supported compatible values. Lately it seems that
we're moving towards listing more/all the values rather than removing
their documentation...
> -- ranges : Should be defined as specified in 1) to describe the
> - DMA controller channels.
> +- ranges : describes the mapping between the address space of the
> + DMA channels and the address space of the DMA controller
What is "the address space of the DMA controller". Perhaps this should
say "the CPU-visible address space" instead?
^ permalink raw reply
* Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Stephen Warren @ 2013-08-21 22:40 UTC (permalink / raw)
To: hongbo.zhang
Cc: devicetree, vinod.koul, linux-kernel, djbw, scottwood,
linuxppc-dev
In-Reply-To: <1375094944-3343-3-git-send-email-hongbo.zhang@freescale.com>
On 07/29/2013 04:49 AM, hongbo.zhang@freescale.com wrote:
> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
> the device tree nodes for them.
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> +** Freescale Elo3 DMA Controller
> + This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
> + series chips, such as t1040, t4240, b4860.
> +
> +Required properties:
> +
> +- compatible : must include "fsl,elo3-dma"
This should probably list all the SoC-specific compatible values too.
> +- ranges : describes the mapping between the address space of the
> + DMA channels and the address space of the DMA controller
Oh, so looking at the example, this is simply about being able to write
the reg value in the child nodes more easily without having to write out
the full based address of the controller in each child node.
I don't think the binding document should require this; all the binding
document should care about is that the child nodes have a valid reg
value. Whether that reg value is <0x100100 0x80> without a ranges in the
top-level DMA nor or whether that reg value is <0x0 0x80> with a ranges
value in the top-level DMA node isn't something that the binding should
specify. Either way will work equally without affecting a driver for the
DMA controller; the parsing of reg with/without a ranges property is
more of a core part of DT than anything to do with this binding.
> +- DMA channel nodes:
> + - compatible : must include "fsl,eloplus-dma-channel"
Why do the channel nodes even need a compatible value? Presumably the
driver for the top-level DMA node will scan these dma-channel nodes to
extract the information it needs and will simply assume that all these
nodes are DMA channel nodes rather than something else? I suppose this
doesn't hurt, it just seems unnecessary unless you foresee other child
nodes types existing in the future and hence a need to differentiate
different types of nodes.
> + - reg : <registers mapping for channel>
> + - interrupts : <interrupt mapping for DMA channel IRQ>
s/interrupts/specifier/
> +Example:
> +dma@100300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
Those weren't mentioned in the required properties list above. Perhaps
they're considered such a core part of DT functionality that it's not
necessary, yet some other binding documents do include these properties
in the list of required properties.
^ permalink raw reply
* Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Stephen Warren @ 2013-08-21 22:14 UTC (permalink / raw)
To: Tomasz Figa
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
Nicolin Chen, timur, rob.herring, broonie, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <2125663.4przPy426h@flatron>
On 08/21/2013 12:54 PM, Tomasz Figa wrote:
> On Wednesday 21 of August 2013 12:30:59 Stephen Warren wrote:
>> On 08/20/2013 09:13 PM, Nicolin Chen wrote:
>>> This patch implements a device-tree-only machine driver for Freescale
>>> i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
>>> fsl_spdif.c drivers.
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
>>> b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
>>>
>>> +Optional properties:
>>> +
>>> + - spdif-transmitter : The phandle of the spdif-transmitter codec
>>> +
>>> + - spdif-receiver : The phandle of the spdif-receiver codec
>>> +
>>> +* Note: At least one of these two properties should be set in the DT
>>> binding.
>> I still don't think those two properties are correct.
>>
>> Exactly what node will those phandles point at?
>
> Imagine following setup:
>
> ________ ________________
> | | RX | Microphone DSP | Analog mic input
> | S/PDIF | <--------< |________________| <-------------------
> | | ________________
> | DAI | >--------> | Amplifier | >-------------------
> |________| TX |________________| Speakers output
>
> As you see in the diagram, the S/PDIF interface of the SoC can be
> connected to some external devices that can perform sound processing or
> simply handle the physical layer.
>
> I'd say that normally both RX and TX lines would be connected to a single
> codec chip that has multiple blocks inside, like sound processing,
> amplifier, mixer, etc., but nothing stops you from making a crazy setup,
> when RX and TX lines are connected to different chips.
That's much rarer with S/PDIF than I2S though right? Usually I'd expect
the S/PDIF controller to simply be routed out to a jack/connector on the
board, or perhaps to an internal HDMI encoder.
But the point of my question was more that the binding should fully
describe the type of object/node that the phandle should reference. The
type of the node would then imply what kind of operations could be
performed on that other node's driver by this node's driver. If the set
of operations is undefined, that's bad. If the set of operations is
NULL, there's probably no need to reference the node.
>> There definitely should not be a DT node for any "dummy CODEC",
>> irrespective of whether this binding calls the other node a "CODEC" or a
>> "dummy CODEC".
>
> I agree. Instead if no chip connected to particular line is specified in
> device tree, it's responsibility of Linux sound core to handle this
> properly by adding a dummy codec or whatever.
>
>> If these properties are to contain phandles, it would be acceptable for
>> the referenced node to be:
>>
>> * A node representing the physical connector/jack on the board.
>>
>> * A node representing some other IP block on the board, such as an HDMI
>> encoder/display-controller
>>
>> I think those options are unlikely in general
>
> Why? You usually codec SoC DAIs to some external chips.
It's unlikely the phandle would reference a connector/jack since we
(thus far at least) haven't created DT nodes for them. If we do put
jacks/connectors into DT, then referencing them is fine.
In the "other IP block" case, it may be worth referencing the device,
although as I mentioned above, we need to describe exactly what is
expected from that other device interface-wise.
^ permalink raw reply
* Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Tomasz Figa @ 2013-08-21 21:34 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
lars@metafoo.de, Mike Turquette, ian.campbell@citrix.com,
Pawel Moll, swarren@wwwdotorg.org, festevam@gmail.com,
Sascha Hauer, Nicolin Chen, timur@tabi.org,
rob.herring@calxeda.com, broonie@kernel.org,
p.zabel@pengutronix.de, galak@codeaurora.org,
shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130821085015.GY3719@e106331-lin.cambridge.arm.com>
On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:
> On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote:
> > Quoting Mark Rutland (2013-08-19 02:35:43)
> >
> > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote:
> > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:
> > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:
> > > > > > > > > Also I would make this option required. Use a dummy
> > > > > > > > > clock for
> > > > > > > > > mux
> > > > > > > > > inputs that are grounded for a specific SoC.
> > > > > > > >
> > > > > > > > Some clocks are not from CCM and we haven't defined in
> > > > > > > > imx6q-clk.txt,
> > > > > > > > so in most cases we can't provide a phandle for them, eg:
> > > > > > > > spdif_ext.
> > > > > > > > I think it's a bit hard to force it to be 'required'. An
> > > > > > > > 'optional'
> > > > > > > > looks more flexible to me and a default one is ensured
> > > > > > > > even if
> > > > > > > > it's
> > > > > > > > missing.
> > > > > > >
> > > > > > > <&clks 0> is the dummy clock. This can be used for all input
> > > > > > > clocks
> > > > > > > not
> > > > > > > defined by the SoC.
> > > > > >
> > > > > > Where does this assumption come from? Is it documented
> > > > > > anywhere?
> > > > >
> > > > > This is how all i.MX clock bindings currently are. See
> > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt
> > > >
> > > > OK, thanks.
> > > >
> > > > I guess we need some discussion on dummy clocks vs skipped clocks.
> > > > I think we want some consistency on this, don't we?
> > > >
> > > > If we really need a dummy clock, then we might also want a generic
> > > > way to specify it.
> > >
> > > What do we actually mean by a "dummy clock"? We already have
> > > bindings
> > > for "fixed-clock" and co friends describe relatively simple
> > > preconfigured clocks.
> >
> > Some platforms have a fake clock which defines noops callbacks and
> > basically doesn't do anything. This is analogous to the dummy
> > regulator
> > implementation. A central one could be registered by the clock core,
> > as
> > is done by the regulator core.
>
> When you say some platforms, you presumably mean the platform code in
> Linux? A dummy clock sounds like a completely Linux-specific abstraction
> rather than a description of the hardware, and I don't see why we need
> that in the DT:
>
> * If a clock is wired up and running (as presumably the dummy clock is),
> then surely it's a fixed-clock (it's running, we and we have no control
> over it, but we presumably know its rate) and can be described as such?
>
> * If no clock is wired up, then we should be able to describe that. If a
> driver believes that a clock is required when it isn't (for some level
> of functionality), then that driver should be fixed up to support the
> clock as being optional.
>
> Am I missing something?
I second that.
Moreover, I don't think that device tree should deal with dummy anything.
It should be able to describe hardware that is available on given system,
not list what hardware is not available.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v4 03/31] USB: fsl-mph-dr-of: cleanup clock API use
From: Anatolij Gustschin @ 2013-08-21 20:45 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1375821851-31609-4-git-send-email-gsi@denx.de>
On Tue, 6 Aug 2013 22:43:43 +0200
Gerhard Sittig <gsi@denx.de> wrote:
> use devm_get_clk() for automatic put upon device close, check for and
> propagate errors when enabling clocks, must prepare clocks before they
> can get enabled, unprepare after disable
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/usb/host/fsl-mph-dr-of.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
applied, thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v4 01/31] spi: mpc512x: cleanup clock API use
From: Anatolij Gustschin @ 2013-08-21 20:38 UTC (permalink / raw)
To: Mark Brown; +Cc: devicetree, Gerhard Sittig, linuxppc-dev
In-Reply-To: <20130821194817.GL26118@sirena.org.uk>
On Wed, 21 Aug 2013 20:48:17 +0100
Mark Brown <broonie@kernel.org> wrote:
> On Wed, Aug 21, 2013 at 09:22:58PM +0200, Anatolij Gustschin wrote:
>
> > Mark, are you going to apply this patch? Or should I queue it
> > in my mpc5xxx tree (I'd like to get your Acked-by then)?
>
> Has this series settled down? I'd been ignoring it since it was getting
> so many and so frequent revisions.
Patches 01 - 14 (except 09 and 11) won't change I think. I'd prefer
to queue them for v3.12, so there will be no need to resubmit again
and again. Other patches are not ready yet.
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/spufs: convert userns uid/gid mount options to kuid/kgid
From: Ben Myers @ 2013-08-21 20:24 UTC (permalink / raw)
To: Jeremy Kerr, Dwight Engen, Arnd Bergmann
Cc: cbe-oss-dev, Stephen Rothwell, linux-kernel, xfs, linux-next,
Gao feng, linuxppc-dev
In-Reply-To: <201308212205.27789.arnd@arndb.de>
On Wed, Aug 21, 2013 at 10:05:27PM +0200, Arnd Bergmann wrote:
> On Wednesday 21 August 2013, Dwight Engen wrote:
> >
> > Acked-by: Jeremy Kerr <jk@ozlabs.org>
> > Tested-by: Jeremy Kerr <jk@ozlabs.org>
> > Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Applied.
Thanks,
-Ben
^ permalink raw reply
* Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
From: Scott Wood @ 2013-08-21 20:08 UTC (permalink / raw)
To: Deepthi Dharwar
Cc: Wood Scott-B07421, daniel.lezcano@linaro.org,
Wang Dongsheng-B40534, preeti@linux.vnet.ibm.com,
linux-pm@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <521447E7.5000302@linux.vnet.ibm.com>
On Wed, 2013-08-21 at 10:23 +0530, Deepthi Dharwar wrote:
> On 08/19/2013 11:47 PM, Scott Wood wrote:
> > On Mon, 2013-08-19 at 15:48 +0530, Deepthi Dharwar wrote:
> >> Hi Dongsheng,
> >>
> >> On 08/19/2013 11:22 AM, Wang Dongsheng-B40534 wrote:
> >>> I think we should move the states and handle function to arch/power/platform*
> >>> The states and handle function is belong to backend driver, not for this, different platform have different state.
> >>> Different platforms to make their own deal with these states.
> >>>
> >>> I think we cannot put all the status of different platforms and handler in this driver.
> >>
> >> The idea here is a single powerpc back-end driver, which does a runtime
> >> detection of the platform it is running and choose the right
> >> idle states table. This was one of outcome of V2 discussion.
> >
> > I see a lot more in there than just detecting a platform and choosing a
> > driver.
> >
> >> I feel there is no harm in keeping the state information in the same
> >> file. We do have x86, which has all its variants information in one
> >> file. One place will have all the idle consolidated information of
> >> all the platform variants. If community does feel, we need to
> >> have just the states information in arch specific file, we can do so.
> >
> > What actual functionality is common to all powerpc but not common to
> > other arches?
No answer?
> >>>> +config CPU_IDLE_POWERPC
> >>>> + bool "CPU Idle driver for POWERPC platforms"
> >>>> + depends on PPC64
> >>>
> >>> Why not PPC?
> >>
> >> PPC64 seems to a good place to began the consolidation work. This
> >> patch-set has not been tested for PPC32 currently.
> >
> > PPC64 is a bad place to start if you want it to be generic, because it
> > means you'll end up growing dependencies on other things that are PPC64
> > only. There are too many arbitrary 32/64 differences as is.
>
> Hi Scott,
>
> From my understanding, PPC64 includes BOOK3E and BOOK3S archs.
> PPC includes PPC32 and PPC64.
>
> It seemed logical to start consolidating at PPC64 as
> one does not want to get into 32/64 bit differences.
I don't want to "get into" a file that claims to be generic PPC but is
loaded with 64-bit dependencies.
> From your comments above, I just wanted to clarify if PPC or PPC64 is
> bad place to start. If PPC64 is bad place to start, then whats the way
> forward ? Can you please throw some more light on it.
The way forward is to give this file a more appropriate name based on
the hardware that it actually targets -- and to refactor it so that the
answer to that question is not complicated.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/spufs: convert userns uid/gid mount options to kuid/kgid
From: Arnd Bergmann @ 2013-08-21 20:05 UTC (permalink / raw)
To: Dwight Engen
Cc: cbe-oss-dev, Stephen Rothwell, linux-kernel, xfs, Ben Myers,
linux-next, Jeremy Kerr, linuxppc-dev, Gao feng
In-Reply-To: <20130821143351.5840d556@oracle.com>
On Wednesday 21 August 2013, Dwight Engen wrote:
>
> Acked-by: Jeremy Kerr <jk@ozlabs.org>
> Tested-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v4 02/31] serial: mpc512x: cleanup clock API use
From: Anatolij Gustschin @ 2013-08-21 19:52 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1375821851-31609-3-git-send-email-gsi@denx.de>
On Tue, 6 Aug 2013 22:43:42 +0200
Gerhard Sittig <gsi@denx.de> wrote:
> cleanup the clock API use of the UART driver which is shared among the
> MPC512x and the MPC5200 platforms
> - get, prepare, and enable the MCLK during port allocation; disable,
> unprepare and put the MCLK upon port release; hold a reference to the
> clock over the period of use; check for and propagate enable errors
> - fix a buffer overflow for clock names with two digit PSC index numbers
> - stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
> switch to a fixed string later after device tree based clock lookup
> will have become available
>
> to achieve support for MPC512x which is neutral to MPC5200, the
> modification was done as follows
> - introduce "clock alloc" and "clock release" routines in addition to
> the previous "clock enable/disable" routine in the psc_ops struct
> - make the clock allocation a part of the port request (resource
> allocation), and make clock release a part of the port release, such
> that essential resources get allocated early
> - just enable/disable the clock from within the .clock() callback
> without any allocation or preparation as the former implementation
> did, since this routine is called from within the startup and shutdown
> callbacks
> - all of the above remains a NOP for the MPC5200 platform (no callbacks
> are provided on that platform)
> - implementation note: the clock gets enabled upon allocation already
> just in case the clock is not only required for bitrate generation but
> for register access as well
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/tty/serial/mpc52xx_uart.c | 98 ++++++++++++++++++++++++++++++-------
> 1 file changed, 81 insertions(+), 17 deletions(-)
applied, thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v4 01/31] spi: mpc512x: cleanup clock API use
From: Mark Brown @ 2013-08-21 19:48 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: devicetree, Gerhard Sittig, linuxppc-dev
In-Reply-To: <20130821212258.2cbc969c@crub>
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
On Wed, Aug 21, 2013 at 09:22:58PM +0200, Anatolij Gustschin wrote:
> Mark, are you going to apply this patch? Or should I queue it
> in my mpc5xxx tree (I'd like to get your Acked-by then)?
Has this series settled down? I'd been ignoring it since it was getting
so many and so frequent revisions.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] net: remove unnecessary dev_set_drvdata()
From: David Miller @ 2013-08-21 19:27 UTC (permalink / raw)
To: libo.chen
Cc: mugunthanvnm, sergei.shtylyov, netdev, jg1.han, lizefan, gregkh,
linuxppc-dev
In-Reply-To: <1377068737-48616-1-git-send-email-libo.chen@huawei.com>
From: Libo Chen <libo.chen@huawei.com>
Date: Wed, 21 Aug 2013 15:05:37 +0800
> Unnecessary dev_set_drvdata() is removed, because the driver core
> clears the driver data to NULL after device_release or on probe failure.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 01/31] spi: mpc512x: cleanup clock API use
From: Anatolij Gustschin @ 2013-08-21 19:22 UTC (permalink / raw)
To: Mark Brown; +Cc: devicetree, Gerhard Sittig, linuxppc-dev
In-Reply-To: <1375821851-31609-2-git-send-email-gsi@denx.de>
On Tue, 6 Aug 2013 22:43:41 +0200
Gerhard Sittig <gsi@denx.de> wrote:
> cleanup the MPC512x SoC's SPI master's use of the clock API
> - get, prepare, and enable the MCLK during probe; disable, unprepare and
> put the MCLK upon remove; hold a reference to the clock over the
> period of use
> - fetch MCLK rate (reference) once during probe and slightly reword BCLK
> (bitrate) determination to reduce redundancy as well as to not exceed
> the maximum text line length
> - stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
> switch to a fixed string later after device tree based clock lookup
> will have become available
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/spi/spi-mpc512x-psc.c | 48 +++++++++++++++++++++++++----------------
> 1 file changed, 30 insertions(+), 18 deletions(-)
Mark, are you going to apply this patch? Or should I queue it
in my mpc5xxx tree (I'd like to get your Acked-by then)?
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Tomasz Figa @ 2013-08-21 18:54 UTC (permalink / raw)
To: Stephen Warren
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
Nicolin Chen, timur, rob.herring, broonie, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <52150763.8020707@wwwdotorg.org>
On Wednesday 21 of August 2013 12:30:59 Stephen Warren wrote:
> On 08/20/2013 09:13 PM, Nicolin Chen wrote:
> > This patch implements a device-tree-only machine driver for Freescale
> > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
> > fsl_spdif.c drivers.
> >
> > diff --git
> > a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
> > b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
> >
> > +Optional properties:
> > +
> > + - spdif-transmitter : The phandle of the spdif-transmitter codec
> > +
> > + - spdif-receiver : The phandle of the spdif-receiver codec
> > +
> > +* Note: At least one of these two properties should be set in the DT
> > binding.
> I still don't think those two properties are correct.
>
> Exactly what node will those phandles point at?
Imagine following setup:
________ ________________
| | RX | Microphone DSP | Analog mic input
| S/PDIF | <--------< |________________| <-------------------
| | ________________
| DAI | >--------> | Amplifier | >-------------------
|________| TX |________________| Speakers output
As you see in the diagram, the S/PDIF interface of the SoC can be
connected to some external devices that can perform sound processing or
simply handle the physical layer.
I'd say that normally both RX and TX lines would be connected to a single
codec chip that has multiple blocks inside, like sound processing,
amplifier, mixer, etc., but nothing stops you from making a crazy setup,
when RX and TX lines are connected to different chips.
> There definitely should not be a DT node for any "dummy CODEC",
> irrespective of whether this binding calls the other node a "CODEC" or a
> "dummy CODEC".
I agree. Instead if no chip connected to particular line is specified in
device tree, it's responsibility of Linux sound core to handle this
properly by adding a dummy codec or whatever.
> If these properties are to contain phandles, it would be acceptable for
> the referenced node to be:
>
> * A node representing the physical connector/jack on the board.
>
> * A node representing some other IP block on the board, such as an HDMI
> encoder/display-controller
>
> I think those options are unlikely in general
Why? You usually codec SoC DAIs to some external chips.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 1/7] drivers: base: move mutex lock out of add_memory_section()
From: Greg Kroah-Hartman @ 2013-08-21 18:50 UTC (permalink / raw)
To: Seth Jennings
Cc: Dave Hansen, Lai Jiangshan, linuxppc-dev, Yinghai Lu,
Rafael J. Wysocki, linux-kernel, linux-mm, Nathan Fontenot,
Andrew Morton, Cody P Schafer, Wanpeng Li
In-Reply-To: <20130820172445.GE4151@medulla.variantweb.net>
On Tue, Aug 20, 2013 at 12:24:45PM -0500, Seth Jennings wrote:
> Gah! Forgot the cover letter.
No worries, I barely read them anyway :)
> This patchset just seeks to clean up and refactor some things in
> memory.c for better understanding and possibly better performance due do
> a decrease in mutex acquisitions and refcount churn at boot time. No
> functional change is intended by this set!
All looks good, thanks for breaking it up into reviewable patches. Now
applied.
greg k-h
^ permalink raw reply
* [PATCH] powerpc/spufs: convert userns uid/gid mount options to kuid/kgid
From: Dwight Engen @ 2013-08-21 18:33 UTC (permalink / raw)
To: Ben Myers
Cc: cbe-oss-dev, Stephen Rothwell, Arnd Bergmann, linux-kernel, xfs,
linux-next, Jeremy Kerr, linuxppc-dev, Gao feng
In-Reply-To: <20130821155654.GI5262@sgi.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Tested-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
---
arch/powerpc/platforms/cell/spufs/inode.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index f390042..87ba7cf 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -620,12 +620,16 @@ spufs_parse_options(struct super_block *sb, char *options, struct inode *root)
case Opt_uid:
if (match_int(&args[0], &option))
return 0;
- root->i_uid = option;
+ root->i_uid = make_kuid(current_user_ns(), option);
+ if (!uid_valid(root->i_uid))
+ return 0;
break;
case Opt_gid:
if (match_int(&args[0], &option))
return 0;
- root->i_gid = option;
+ root->i_gid = make_kgid(current_user_ns(), option);
+ if (!gid_valid(root->i_gid))
+ return 0;
break;
case Opt_mode:
if (match_octal(&args[0], &option))
--
1.8.1.4
On Wed, 21 Aug 2013 10:56:54 -0500
Ben Myers <bpm@sgi.com> wrote:
> Hey Dwight,
>
> On Wed, Aug 21, 2013 at 02:30:04PM +0800, Jeremy Kerr wrote:
> > > Yes, I agree. The other filesystems that take an Opt_uid as well
> > > do use current_user_ns() and not init_user_ns. They also do a
> > > uid_valid() check and fail the mount (or fallback to
> > > GLOBAL_ROOT_UID). So I think that would look like this:
> >
> > Looks good to me. Builds and mounts as expected.
> >
> > Acked-by: Jeremy Kerr <jk@ozlabs.org>
>
> Could you repost this patch with the right subject and a commit
> header? Given Jeremy's Ack I think we could proceed to pull this in.
Sure, I just wanted to make sure someone had tested it first, which it
looks like Jeremy did, thanks.
> Regards,
> Ben
^ permalink raw reply related
* Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Stephen Warren @ 2013-08-21 18:30 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
timur, rob.herring, tomasz.figa, broonie, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <e9cf5e37f858dea78319720f007f66c8c063885f.1377054540.git.b42378@freescale.com>
On 08/20/2013 09:13 PM, Nicolin Chen wrote:
> This patch implements a device-tree-only machine driver for Freescale
> i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
> fsl_spdif.c drivers.
> diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
> +Optional properties:
> +
> + - spdif-transmitter : The phandle of the spdif-transmitter codec
> +
> + - spdif-receiver : The phandle of the spdif-receiver codec
> +
> +* Note: At least one of these two properties should be set in the DT binding.
I still don't think those two properties are correct.
Exactly what node will those phandles point at?
There definitely should not be a DT node for any "dummy CODEC",
irrespective of whether this binding calls the other node a "CODEC" or a
"dummy CODEC".
If these properties are to contain phandles, it would be acceptable for
the referenced node to be:
* A node representing the physical connector/jack on the board.
* A node representing some other IP block on the board, such as an HDMI
encoder/display-controller
I think those options are unlikely in general, so I think instead these
properties should just be Boolean indicating that "something" is
connector to the S/PDIF RX/TX, without specifying what that "something"
is. It doesn't matter what at least in the connector/jack case, although
perhaps it does in the HDMI encoder/display-controller?
^ permalink raw reply
* Re: [PATCH v10 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Stephen Warren @ 2013-08-21 18:26 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
timur, rob.herring, tomasz.figa, broonie, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <03182ed7464c156ec6345194d3f7ec920f753c2f.1377054540.git.b42378@freescale.com>
On 08/20/2013 09:13 PM, Nicolin Chen wrote:
> This patch implements a device-tree-only CPU DAI driver for Freescale
> S/PDIF controller that supports stereo playback and record feature.
The DT bindings part of this patch,
Acked-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* Re: [alsa-devel] [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Stephen Warren @ 2013-08-21 16:08 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, lars, linuxppc-dev, s.hauer,
timur, rob.herring, tomasz.figa, Mark Brown, p.zabel, R65777,
shawn.guo, festevam
In-Reply-To: <20130821021801.GA6177@MrMyself>
On 08/20/2013 08:18 PM, Nicolin Chen wrote:
> On Tue, Aug 20, 2013 at 11:28:10PM +0100, Mark Brown wrote:
>> On Tue, Aug 20, 2013 at 01:53:49PM -0600, Stephen Warren wrote:
>>> On 08/20/2013 01:07 PM, Mark Brown wrote:
>>
>>>> The point is that it might turn into a more correct binding
>>>> depending on what the S/PDIF device actually is.
>>
>>> There's *never* an object on the board called a "dummy codec".
>>
>> Oh, is that what you're talking about? Yes, that makes sense. I had
>> been responding to the comments about the transceivers.
>
> I'll remove the 'dummy' words in the next version from the binding doc.
I think the word "CODEC" is also problematic in this context, since
whatever is connector to the S/PDIF output path may not be a CODEC.
That's why I suggested some more generic property names that IIRC
concentrated on enabling rx/tx rather than indicating what was actually
connected to the S/PDIF controller.
^ permalink raw reply
* [PATCH] Adding proper request of GPIO used by cpm_uart driver
From: Christophe Leroy @ 2013-08-21 15:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby; +Cc: linuxppc-dev, linux-kernel, linux-serial
cpm_uart serial driver uses GPIO for control signals. In order to be used
properly, GPIOs have to be reserved. Comment in gpiolib.c considers illegal
the use of GPIOs without requesting them. In addition, the direction of the
GPIO has to be set properly.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur linux-3.8.13/drivers/tty/serial/cpm_uart/cpm_uart_core.c linux/drivers/tty/serial/cpm_uart/cpm_uart_core.c
--- linux-3.8.13/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2013-08-21 05:34:03.000000000 +0200
+++ linux/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2013-08-21 05:30:04.000000000 +0200
@@ -1213,8 +1213,32 @@
goto out_pram;
}
- for (i = 0; i < NUM_GPIOS; i++)
- pinfo->gpios[i] = of_get_gpio(np, i);
+ for (i = 0; i < NUM_GPIOS; i++) {
+ int gpio;
+
+ pinfo->gpios[i] = -1;
+
+ gpio = of_get_gpio(np, i);
+
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, "cpm_uart");
+ if (ret) {
+ pr_err("can't request gpio #%d: %d\n", i, ret);
+ continue;
+ }
+ if (i == GPIO_RTS || i == GPIO_DTR)
+ ret = gpio_direction_output(gpio, 0);
+ else
+ ret = gpio_direction_input(gpio);
+ if (ret) {
+ pr_err("can't set direction for gpio #%d: %d\n",
+ i, ret);
+ gpio_free(gpio);
+ continue;
+ }
+ pinfo->gpios[i] = gpio;
+ }
+ }
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
udbg_putc = NULL;
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree
From: Ben Myers @ 2013-08-21 15:56 UTC (permalink / raw)
To: Jeremy Kerr
Cc: cbe-oss-dev, Stephen Rothwell, Arnd Bergmann, Dwight Engen,
linux-kernel, xfs, linux-next, Gao feng, linuxppc-dev
In-Reply-To: <52145E6C.80404@ozlabs.org>
Hey Dwight,
On Wed, Aug 21, 2013 at 02:30:04PM +0800, Jeremy Kerr wrote:
> > Yes, I agree. The other filesystems that take an Opt_uid as well do use
> > current_user_ns() and not init_user_ns. They also do a uid_valid()
> > check and fail the mount (or fallback to GLOBAL_ROOT_UID). So I think
> > that would look like this:
>
> Looks good to me. Builds and mounts as expected.
>
> Acked-by: Jeremy Kerr <jk@ozlabs.org>
Could you repost this patch with the right subject and a commit header? Given
Jeremy's Ack I think we could proceed to pull this in.
Regards,
Ben
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox