* 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
* Re: linux-next: build failure after merge of the final tree
From: Ben Myers @ 2013-08-21 15:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: cbe-oss-dev, Arnd Bergmann, Dwight Engen, linux-kernel, xfs,
linux-next, Jeremy Kerr, linuxppc-dev, Gao feng
In-Reply-To: <20130821102246.4e3c4c8fe549d8c7760da96d@canb.auug.org.au>
Hey Stephen,
On Wed, Aug 21, 2013 at 10:22:46AM +1000, Stephen Rothwell wrote:
> On Tue, 20 Aug 2013 14:28:44 -0500 Ben Myers <bpm@sgi.com> wrote:
> > I'd prefer not to break Stephen's tree two days in a row. We could just revert
> > d6970d4b726c in the xfs tree for the time being as Stephen has done, but given
> > the choice would prefer the fix. Do you have a preference between the two
> > approaches that Dwight has posted? The first seems more conservative...
>
> I will automatically revert that commit when I merge the xfs tree until
> some other solution is forthcoming (so you don't have to do the revert in
> the xfs tree).
Gah. That makes sense. ;)
> This does need to be fixed fairly soon, though.
Agreed, thanks.
-Ben
^ permalink raw reply
* Re: [PATCH V2] i2c: move of helpers into the core
From: Sylwester Nawrocki @ 2013-08-21 14:46 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree, davinci-linux-open-source, linux-samsung-soc,
linux-doc, linux-kernel, linux-acpi, linux-i2c, linux-tegra,
linux-omap, linuxppc-dev, linux-arm-kernel, linux-media
In-Reply-To: <1377092832-3417-1-git-send-email-wsa@the-dreams.de>
On 08/21/2013 03:47 PM, Wolfram Sang wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@amsung.com>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
With this patch there are still couple of of_i2c.h header file
inclusions:
$ git grep of_i2c.h
arch/powerpc/platforms/44x/warp.c:#include <linux/of_i2c.h>
drivers/gpu/drm/tilcdc/tilcdc_slave.c:#include <linux/of_i2c.h>
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:#include <linux/of_i2c.h>
drivers/gpu/host1x/drm/output.c:#include <linux/of_i2c.h>
drivers/media/platform/exynos4-is/fimc-is.c:#include <linux/of_i2c.h>
drivers/media/platform/exynos4-is/media-dev.c:#include <linux/of_i2c.h>
drivers/staging/imx-drm/imx-tve.c:#include <linux/of_i2c.h>
sound/soc/fsl/imx-sgtl5000.c:#include <linux/of_i2c.h>
sound/soc/fsl/imx-wm8962.c:#include <linux/of_i2c.h>
Please include also this chunk, without it I'm getting build errors.
--------------8<---------------------
diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
index ca07b48..e38e9dc 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
@@ -11,6 +11,7 @@
*/
#include <linux/clk.h>
+#include <linux/i2c.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c
b/drivers/media/platform/exynos4-is/fimc-is.c
index 6743ae3..63e4f1d 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -21,7 +21,6 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/of_irq.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index c10dee2..00e5f91 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -22,7 +22,6 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/types.h>
--------------8<---------------------
> ---
>
> V1 -> V2: * Add #else branch to #if CONFIG_OF
> * EXPORT_SYMBOLs got attached to wrong functions
> * cosmetic change (of -> OF)
> * properly based on 3.11-rc4
>
> Documentation/acpi/enumeration.txt | 1 -
> drivers/i2c/busses/i2c-at91.c | 3 -
> drivers/i2c/busses/i2c-cpm.c | 6 --
> drivers/i2c/busses/i2c-davinci.c | 2 -
> drivers/i2c/busses/i2c-designware-platdrv.c | 2 -
> drivers/i2c/busses/i2c-gpio.c | 3 -
> drivers/i2c/busses/i2c-i801.c | 2 -
> drivers/i2c/busses/i2c-ibm_iic.c | 4 -
> drivers/i2c/busses/i2c-imx.c | 3 -
> drivers/i2c/busses/i2c-mpc.c | 2 -
> drivers/i2c/busses/i2c-mv64xxx.c | 3 -
> drivers/i2c/busses/i2c-mxs.c | 3 -
> drivers/i2c/busses/i2c-nomadik.c | 3 -
> drivers/i2c/busses/i2c-ocores.c | 3 -
> drivers/i2c/busses/i2c-octeon.c | 3 -
> drivers/i2c/busses/i2c-omap.c | 3 -
> drivers/i2c/busses/i2c-pnx.c | 3 -
> drivers/i2c/busses/i2c-powermac.c | 9 +-
> drivers/i2c/busses/i2c-pxa.c | 2 -
> drivers/i2c/busses/i2c-s3c2410.c | 2 -
> drivers/i2c/busses/i2c-sh_mobile.c | 2 -
> drivers/i2c/busses/i2c-sirf.c | 3 -
> drivers/i2c/busses/i2c-stu300.c | 2 -
> drivers/i2c/busses/i2c-tegra.c | 3 -
> drivers/i2c/busses/i2c-versatile.c | 2 -
> drivers/i2c/busses/i2c-wmt.c | 3 -
> drivers/i2c/busses/i2c-xiic.c | 3 -
> drivers/i2c/i2c-core.c | 109 +++++++++++++++++++++-
> drivers/i2c/i2c-mux.c | 3 -
> drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 1 -
> drivers/i2c/muxes/i2c-mux-gpio.c | 1 -
> drivers/i2c/muxes/i2c-mux-pinctrl.c | 1 -
> drivers/media/platform/exynos4-is/fimc-is-i2c.c | 3 -
> drivers/of/Kconfig | 6 --
> drivers/of/Makefile | 1 -
> drivers/of/of_i2c.c | 114 -----------------------
> include/linux/i2c.h | 20 ++++
> include/linux/of_i2c.h | 46 ---------
> 38 files changed, 132 insertions(+), 253 deletions(-)
> delete mode 100644 drivers/of/of_i2c.c
> delete mode 100644 include/linux/of_i2c.h
I've tested this patch on Exynos4412 SoC based board, so this covers
i2c-s3c2410 and fimc-is-i2c. Compiled with CONFIG_OF enabled.
I guess after removing all remaining occurrences of
#include <linux/of_i2c.h> you could add:
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Thanks,
Sylwester
^ permalink raw reply related
* [PATCH V2] i2c: move of helpers into the core
From: Wolfram Sang @ 2013-08-21 13:47 UTC (permalink / raw)
To: linux-i2c
Cc: devicetree, davinci-linux-open-source, linux-samsung-soc,
linux-doc, Wolfram Sang, linux-kernel, linux-acpi, linux-tegra,
linux-omap, linuxppc-dev, linux-arm-kernel, linux-media
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver. So, fix the drivers and documentation, too.
Acked-by: Sylwester Nawrocki <s.nawrocki@amsung.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
V1 -> V2: * Add #else branch to #if CONFIG_OF
* EXPORT_SYMBOLs got attached to wrong functions
* cosmetic change (of -> OF)
* properly based on 3.11-rc4
Documentation/acpi/enumeration.txt | 1 -
drivers/i2c/busses/i2c-at91.c | 3 -
drivers/i2c/busses/i2c-cpm.c | 6 --
drivers/i2c/busses/i2c-davinci.c | 2 -
drivers/i2c/busses/i2c-designware-platdrv.c | 2 -
drivers/i2c/busses/i2c-gpio.c | 3 -
drivers/i2c/busses/i2c-i801.c | 2 -
drivers/i2c/busses/i2c-ibm_iic.c | 4 -
drivers/i2c/busses/i2c-imx.c | 3 -
drivers/i2c/busses/i2c-mpc.c | 2 -
drivers/i2c/busses/i2c-mv64xxx.c | 3 -
drivers/i2c/busses/i2c-mxs.c | 3 -
drivers/i2c/busses/i2c-nomadik.c | 3 -
drivers/i2c/busses/i2c-ocores.c | 3 -
drivers/i2c/busses/i2c-octeon.c | 3 -
drivers/i2c/busses/i2c-omap.c | 3 -
drivers/i2c/busses/i2c-pnx.c | 3 -
drivers/i2c/busses/i2c-powermac.c | 9 +-
drivers/i2c/busses/i2c-pxa.c | 2 -
drivers/i2c/busses/i2c-s3c2410.c | 2 -
drivers/i2c/busses/i2c-sh_mobile.c | 2 -
drivers/i2c/busses/i2c-sirf.c | 3 -
drivers/i2c/busses/i2c-stu300.c | 2 -
drivers/i2c/busses/i2c-tegra.c | 3 -
drivers/i2c/busses/i2c-versatile.c | 2 -
drivers/i2c/busses/i2c-wmt.c | 3 -
drivers/i2c/busses/i2c-xiic.c | 3 -
drivers/i2c/i2c-core.c | 109 +++++++++++++++++++++-
drivers/i2c/i2c-mux.c | 3 -
drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 1 -
drivers/i2c/muxes/i2c-mux-gpio.c | 1 -
drivers/i2c/muxes/i2c-mux-pinctrl.c | 1 -
drivers/media/platform/exynos4-is/fimc-is-i2c.c | 3 -
drivers/of/Kconfig | 6 --
drivers/of/Makefile | 1 -
drivers/of/of_i2c.c | 114 -----------------------
include/linux/i2c.h | 20 ++++
include/linux/of_i2c.h | 46 ---------
38 files changed, 132 insertions(+), 253 deletions(-)
delete mode 100644 drivers/of/of_i2c.c
delete mode 100644 include/linux/of_i2c.h
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index d9be7a9..958266e 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
if (ret)
/* handle error */
- of_i2c_register_devices(adapter);
/* Enumerate the slave devices behind this bus via ACPI */
acpi_i2c_register_devices(adapter);
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 6bb839b..fd05930 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -28,7 +28,6 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/platform_data/dma-atmel.h>
@@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev)
return rc;
}
- of_i2c_register_devices(&dev->adapter);
-
dev_info(dev->dev, "AT91 i2c bus driver.\n");
return 0;
}
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 2e1f7eb..b2b8aa9 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -42,7 +42,6 @@
#include <linux/dma-mapping.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include <sysdev/fsl_soc.h>
#include <asm/cpm.h>
@@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev)
dev_dbg(&ofdev->dev, "hw routines for %s registered.\n",
cpm->adap.name);
- /*
- * register OF I2C devices
- */
- of_i2c_register_devices(&cpm->adap);
-
return 0;
out_shut:
cpm_i2c_shutdown(cpm);
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index fa55605..62be3b3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,7 +38,6 @@
#include <linux/slab.h>
#include <linux/cpufreq.h>
#include <linux/gpio.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <mach/hardware.h>
@@ -728,7 +727,6 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
goto err_unuse_clocks;
}
- of_i2c_register_devices(adap);
return 0;
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 4c5fada..27ea436 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -35,7 +35,6 @@
#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/pm.h>
#include <linux/pm_runtime.h>
@@ -172,7 +171,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
return r;
}
- of_i2c_register_devices(adap);
acpi_i2c_register_devices(adap);
pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index bc6e139..e5da9fe 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
-#include <linux/of_i2c.h>
struct i2c_gpio_private_data {
struct i2c_adapter adap;
@@ -224,8 +223,6 @@ static int i2c_gpio_probe(struct platform_device *pdev)
if (ret)
goto err_add_bus;
- of_i2c_register_devices(adap);
-
platform_set_drvdata(pdev, priv);
dev_info(&pdev->dev, "using pins %u (SDA) and %u (SCL%s)\n",
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 4ebceed..4296d17 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -87,7 +87,6 @@
#include <linux/slab.h>
#include <linux/wait.h>
#include <linux/err.h>
-#include <linux/of_i2c.h>
#if (defined CONFIG_I2C_MUX_GPIO || defined CONFIG_I2C_MUX_GPIO_MODULE) && \
defined CONFIG_DMI
@@ -1230,7 +1229,6 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto exit_free_irq;
}
- of_i2c_register_devices(&priv->adapter);
i801_probe_optional_slaves(priv);
/* We ignore errors - multiplexing is optional */
i801_add_mux(priv);
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 973f516..ff3caa0 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -42,7 +42,6 @@
#include <linux/io.h>
#include <linux/i2c.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include "i2c-ibm_iic.h"
@@ -759,9 +758,6 @@ static int iic_probe(struct platform_device *ofdev)
dev_info(&ofdev->dev, "using %s mode\n",
dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
- /* Now register all the child nodes */
- of_i2c_register_devices(adap);
-
return 0;
error_cleanup:
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index e242797..bbbea6b 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -50,7 +50,6 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_data/i2c-imx.h>
/** Defines ********************************************************************
@@ -570,8 +569,6 @@ static int __init i2c_imx_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c_imx->adapter);
-
/* Set up platform driver data */
platform_set_drvdata(pdev, i2c_imx);
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..9f2513d 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -18,7 +18,6 @@
#include <linux/sched.h>
#include <linux/init.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include <linux/slab.h>
#include <linux/io.h>
@@ -691,7 +690,6 @@ static int fsl_i2c_probe(struct platform_device *op)
dev_err(i2c->dev, "failed to add adapter\n");
goto fail_add;
}
- of_i2c_register_devices(&i2c->adap);
return result;
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index b1f42bf..8220322 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -21,7 +21,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
-#include <linux/of_i2c.h>
#include <linux/clk.h>
#include <linux/err.h>
@@ -689,8 +688,6 @@ mv64xxx_i2c_probe(struct platform_device *pd)
goto exit_free_irq;
}
- of_i2c_register_devices(&drv_data->adapter);
-
return 0;
exit_free_irq:
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index df8ff5a..62ed07d 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -27,7 +27,6 @@
#include <linux/stmp_device.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
@@ -701,8 +700,6 @@ static int mxs_i2c_probe(struct platform_device *pdev)
return err;
}
- of_i2c_register_devices(adap);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 512dfe6..519df17 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -24,7 +24,6 @@
#include <linux/pm_runtime.h>
#include <linux/platform_data/i2c-nomadik.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/pinctrl/consumer.h>
#define DRIVER_NAME "nmk-i2c"
@@ -1045,8 +1044,6 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
goto err_add_adap;
}
- of_i2c_register_devices(adap);
-
pm_runtime_put(&adev->dev);
return 0;
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 0e1f824..0a52b78 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -24,7 +24,6 @@
#include <linux/i2c-ocores.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#include <linux/log2.h>
struct ocores_i2c {
@@ -435,8 +434,6 @@ static int ocores_i2c_probe(struct platform_device *pdev)
if (pdata) {
for (i = 0; i < pdata->num_devices; i++)
i2c_new_device(&i2c->adap, pdata->devices + i);
- } else {
- of_i2c_register_devices(&i2c->adap);
}
return 0;
diff --git a/drivers/i2c/busses/i2c-octeon.c b/drivers/i2c/busses/i2c-octeon.c
index 956fe32..b929ba2 100644
--- a/drivers/i2c/busses/i2c-octeon.c
+++ b/drivers/i2c/busses/i2c-octeon.c
@@ -15,7 +15,6 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/delay.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -599,8 +598,6 @@ static int octeon_i2c_probe(struct platform_device *pdev)
}
dev_info(i2c->dev, "version %s\n", DRV_VERSION);
- of_i2c_register_devices(&i2c->adap);
-
return 0;
out:
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 142b694d..a9f0f80 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,7 +38,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/i2c-omap.h>
@@ -1245,8 +1244,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr,
major, minor, dev->speed);
- of_i2c_register_devices(adap);
-
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
index 5f39c6d..7b57d67 100644
--- a/drivers/i2c/busses/i2c-pnx.c
+++ b/drivers/i2c/busses/i2c-pnx.c
@@ -23,7 +23,6 @@
#include <linux/err.h>
#include <linux/clk.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#define I2C_PNX_TIMEOUT_DEFAULT 10 /* msec */
#define I2C_PNX_SPEED_KHZ_DEFAULT 100
@@ -741,8 +740,6 @@ static int i2c_pnx_probe(struct platform_device *pdev)
goto out_irq;
}
- of_i2c_register_devices(&alg_data->adapter);
-
dev_dbg(&pdev->dev, "%s: Master at %#8x, irq %d.\n",
alg_data->adapter.name, res->start, alg_data->irq);
diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..1010f2e 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -440,7 +440,9 @@ static int i2c_powermac_probe(struct platform_device *dev)
adapter->algo = &i2c_powermac_algorithm;
i2c_set_adapdata(adapter, bus);
adapter->dev.parent = &dev->dev;
- adapter->dev.of_node = dev->dev.of_node;
+
+ /* Clear of_node to skip automatic registration of i2c child nodes */
+ adapter->dev.of_node = NULL;
rc = i2c_add_adapter(adapter);
if (rc) {
printk(KERN_ERR "i2c-powermac: Adapter %s registration "
@@ -450,9 +452,8 @@ static int i2c_powermac_probe(struct platform_device *dev)
printk(KERN_INFO "PowerMac i2c bus %s registered\n", adapter->name);
- /* Cannot use of_i2c_register_devices() due to Apple device-tree
- * funkyness
- */
+ /* Use custom child registration due to Apple device-tree funkyness */
+ adapter->dev.of_node = dev->dev.of_node;
i2c_powermac_register_devices(adapter, bus);
return rc;
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index fbafed2..bc65014 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -31,7 +31,6 @@
#include <linux/i2c-pxa.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/err.h>
#include <linux/clk.h>
@@ -1185,7 +1184,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
printk(KERN_INFO "I2C: Failed to add bus\n");
goto eadapt;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(dev, i2c);
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index cab1c91..643426e 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -36,7 +36,6 @@
#include <linux/cpufreq.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
@@ -1154,7 +1153,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(pdev, i2c);
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index debf745..aa1268f 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -27,7 +27,6 @@
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/err.h>
#include <linux/pm_runtime.h>
#include <linux/clk.h>
@@ -758,7 +757,6 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
"I2C adapter %d with bus speed %lu Hz (L/H=%x/%x)\n",
adap->nr, pd->bus_speed, pd->iccl, pd->icch);
- of_i2c_register_devices(adap);
return 0;
err_all:
diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
index a63c7d5..0ff22e2 100644
--- a/drivers/i2c/busses/i2c-sirf.c
+++ b/drivers/i2c/busses/i2c-sirf.c
@@ -12,7 +12,6 @@
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
@@ -366,8 +365,6 @@ static int i2c_sirfsoc_probe(struct platform_device *pdev)
clk_disable(clk);
- of_i2c_register_devices(adap);
-
dev_info(&pdev->dev, " I2C adapter ready to operate\n");
return 0;
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index d1a6b20..047546c 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -17,7 +17,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
/* the name of this kernel module */
#define NAME "stu300"
@@ -936,7 +935,6 @@ stu300_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
dev_info(&pdev->dev, "ST DDC I2C @ %p, irq %d\n",
dev->virtbase, dev->irq);
- of_i2c_register_devices(adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 9aa1b60..c457cb4 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -25,7 +25,6 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <linux/module.h>
#include <linux/clk/tegra.h>
@@ -802,8 +801,6 @@ static int tegra_i2c_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c_dev->adapter);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-versatile.c b/drivers/i2c/busses/i2c-versatile.c
index f3a8790..6bb3a89 100644
--- a/drivers/i2c/busses/i2c-versatile.c
+++ b/drivers/i2c/busses/i2c-versatile.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#define I2C_CONTROL 0x00
#define I2C_CONTROLS 0x00
@@ -108,7 +107,6 @@ static int i2c_versatile_probe(struct platform_device *dev)
ret = i2c_bit_add_numbered_bus(&i2c->adap);
if (ret >= 0) {
platform_set_drvdata(dev, i2c);
- of_i2c_register_devices(&i2c->adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-wmt.c b/drivers/i2c/busses/i2c-wmt.c
index baaa7d1..c65da3d 100644
--- a/drivers/i2c/busses/i2c-wmt.c
+++ b/drivers/i2c/busses/i2c-wmt.c
@@ -21,7 +21,6 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/of_i2c.h>
#include <linux/of_irq.h>
#include <linux/platform_device.h>
@@ -439,8 +438,6 @@ static int wmt_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c_dev);
- of_i2c_register_devices(adap);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index 3d0f052..8823db7 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -40,7 +40,6 @@
#include <linux/i2c-xiic.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#define DRIVER_NAME "xiic-i2c"
@@ -752,8 +751,6 @@ static int xiic_i2c_probe(struct platform_device *pdev)
i2c_new_device(&i2c->adap, pdata->devices + i);
}
- of_i2c_register_devices(&i2c->adap);
-
return 0;
add_adapter_failed:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..125f749 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -23,7 +23,11 @@
SMBus 2.0 support by Mark Studebaker <mdsxyz123@yahoo.com> and
Jean Delvare <khali@linux-fr.org>
Mux support by Rodolfo Giometti <giometti@enneenne.com> and
- Michael Lawnick <michael.lawnick.ext@nsn.com> */
+ Michael Lawnick <michael.lawnick.ext@nsn.com>
+ OF support is copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ (based on a previous patch from Jon Smirl <jonsmirl@gmail.com>) and
+ (c) 2013 Wolfram Sang <wsa@the-dreams.de>
+ */
#include <linux/module.h>
#include <linux/kernel.h>
@@ -35,7 +39,9 @@
#include <linux/init.h>
#include <linux/idr.h>
#include <linux/mutex.h>
+#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/completion.h>
#include <linux/hardirq.h>
#include <linux/irqflags.h>
@@ -954,6 +960,104 @@ static void i2c_scan_static_board_info(struct i2c_adapter *adapter)
up_read(&__i2c_board_lock);
}
+/* OF support code */
+
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+ void *result;
+ struct device_node *node;
+
+ /* Only register child devices if the adapter has a node pointer set */
+ if (!adap->dev.of_node)
+ return;
+
+ dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
+
+ for_each_available_child_of_node(adap->dev.of_node, node) {
+ struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
+ const __be32 *addr;
+ int len;
+
+ dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
+
+ if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
+ dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
+ node->full_name);
+ continue;
+ }
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || (len < sizeof(int))) {
+ dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
+ node->full_name);
+ continue;
+ }
+
+ info.addr = be32_to_cpup(addr);
+ if (info.addr > (1 << 10) - 1) {
+ dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
+ info.addr, node->full_name);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ info.of_node = of_node_get(node);
+ info.archdata = &dev_ad;
+
+ if (of_get_property(node, "wakeup-source", NULL))
+ info.flags |= I2C_CLIENT_WAKE;
+
+ request_module("%s%s", I2C_MODULE_PREFIX, info.type);
+
+ result = i2c_new_device(adap, &info);
+ if (result == NULL) {
+ dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
+ node->full_name);
+ of_node_put(node);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+/* must call put_device() when done with returned i2c_client device */
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return i2c_verify_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
+/* must call put_device() when done with returned i2c_adapter device */
+struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return i2c_verify_adapter(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
+#else
+static void of_i2c_register_devices(struct i2c_adapter *adap) { }
+#endif /* CONFIG_OF */
+
static int i2c_do_add_adapter(struct i2c_driver *driver,
struct i2c_adapter *adap)
{
@@ -1058,6 +1162,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
exit_recovery:
/* create pre-declared device nodes */
+ of_i2c_register_devices(adap);
+
if (adap->nr < __i2c_first_dynamic_bus_num)
i2c_scan_static_board_info(adap);
@@ -1282,7 +1388,6 @@ void i2c_del_adapter(struct i2c_adapter *adap)
}
EXPORT_SYMBOL(i2c_del_adapter);
-
/* ------------------------------------------------------------------------- */
int i2c_for_each_dev(void *data, int (*fn)(struct device *, void *))
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 7409ebb..797e311 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,7 +25,6 @@
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -185,8 +184,6 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
dev_info(&parent->dev, "Added multiplexed i2c bus %d\n",
i2c_adapter_id(&priv->adap));
- of_i2c_register_devices(&priv->adap);
-
return &priv->adap;
}
EXPORT_SYMBOL_GPL(i2c_add_mux_adapter);
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
index 210b6f7..b901638 100644
--- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -21,7 +21,6 @@
#include <linux/i2c-mux.h>
#include <linux/init.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
index 5a0ce00..128a981 100644
--- a/drivers/i2c/muxes/i2c-mux-gpio.c
+++ b/drivers/i2c/muxes/i2c-mux-gpio.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/gpio.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
struct gpiomux {
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index a43c0ce..859a6d2 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -20,7 +20,6 @@
#include <linux/i2c-mux.h>
#include <linux/init.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/pinctrl/consumer.h>
#include <linux/i2c-mux-pinctrl.h>
#include <linux/platform_device.h>
diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
index 617a798..c283186 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
@@ -67,8 +66,6 @@ static int fimc_is_i2c_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_enable(&i2c_adap->dev);
- of_i2c_register_devices(i2c_adap);
-
return 0;
}
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80e5c13..78cc760 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -48,12 +48,6 @@ config OF_IRQ
def_bool y
depends on !SPARC
-config OF_I2C
- def_tristate I2C
- depends on I2C
- help
- OpenFirmware I2C accessors
-
config OF_NET
depends on NETDEVICES
def_bool y
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 1f9c0c4..efd0510 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_OF_FLATTREE) += fdt.o
obj-$(CONFIG_OF_PROMTREE) += pdt.o
obj-$(CONFIG_OF_ADDRESS) += address.o
obj-$(CONFIG_OF_IRQ) += irq.o
-obj-$(CONFIG_OF_I2C) += of_i2c.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
deleted file mode 100644
index b667264..0000000
--- a/drivers/of/of_i2c.c
+++ /dev/null
@@ -1,114 +0,0 @@
-/*
- * OF helpers for the I2C API
- *
- * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
- *
- * Based on a previous patch from Jon Smirl <jonsmirl@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/i2c.h>
-#include <linux/irq.h>
-#include <linux/of.h>
-#include <linux/of_i2c.h>
-#include <linux/of_irq.h>
-#include <linux/module.h>
-
-void of_i2c_register_devices(struct i2c_adapter *adap)
-{
- void *result;
- struct device_node *node;
-
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap->dev.of_node)
- return;
-
- dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
-
- for_each_available_child_of_node(adap->dev.of_node, node) {
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr;
- int len;
-
- dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
-
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
- node->full_name);
- continue;
- }
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || (len < sizeof(int))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
- node->full_name);
- continue;
- }
-
- info.addr = be32_to_cpup(addr);
- if (info.addr > (1 << 10) - 1) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
- info.addr, node->full_name);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
-
- if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
-
- request_module("%s%s", I2C_MODULE_PREFIX, info.type);
-
- result = i2c_new_device(adap, &info);
- if (result == NULL) {
- dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
- node->full_name);
- of_node_put(node);
- irq_dispose_mapping(info.irq);
- continue;
- }
- }
-}
-EXPORT_SYMBOL(of_i2c_register_devices);
-
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
-/* must call put_device() when done with returned i2c_client device */
-struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
-{
- struct device *dev;
-
- dev = bus_find_device(&i2c_bus_type, NULL, node,
- of_dev_node_match);
- if (!dev)
- return NULL;
-
- return i2c_verify_client(dev);
-}
-EXPORT_SYMBOL(of_find_i2c_device_by_node);
-
-/* must call put_device() when done with returned i2c_adapter device */
-struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
-{
- struct device *dev;
-
- dev = bus_find_device(&i2c_bus_type, NULL, node,
- of_dev_node_match);
- if (!dev)
- return NULL;
-
- return i2c_verify_adapter(dev);
-}
-EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
-
-MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e988fa9..2189189 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -542,6 +542,26 @@ static inline int i2c_adapter_id(struct i2c_adapter *adap)
#endif /* I2C */
+#if IS_ENABLED(CONFIG_OF)
+/* must call put_device() when done with returned i2c_client device */
+extern struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
+/* must call put_device() when done with returned i2c_adapter device */
+extern struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node);
+
+#else
+
+static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ return NULL;
+}
+
+static inline struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#if IS_ENABLED(CONFIG_ACPI_I2C)
extern void acpi_i2c_register_devices(struct i2c_adapter *adap);
#else
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
deleted file mode 100644
index cfb545c..0000000
--- a/include/linux/of_i2c.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Generic I2C API implementation for PowerPC.
- *
- * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef __LINUX_OF_I2C_H
-#define __LINUX_OF_I2C_H
-
-#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE)
-#include <linux/i2c.h>
-
-extern void of_i2c_register_devices(struct i2c_adapter *adap);
-
-/* must call put_device() when done with returned i2c_client device */
-extern struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
-
-/* must call put_device() when done with returned i2c_adapter device */
-extern struct i2c_adapter *of_find_i2c_adapter_by_node(
- struct device_node *node);
-
-#else
-static inline void of_i2c_register_devices(struct i2c_adapter *adap)
-{
- return;
-}
-
-static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
-{
- return NULL;
-}
-
-/* must call put_device() when done with returned i2c_adapter device */
-static inline struct i2c_adapter *of_find_i2c_adapter_by_node(
- struct device_node *node)
-{
- return NULL;
-}
-#endif /* CONFIG_OF_I2C */
-
-#endif /* __LINUX_OF_I2C_H */
--
1.7.10.4
^ 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