* [PATCH RFC v7 1/6] dma: mpc512x: reorder mpc8308 specific instructions
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392211508-23615-1-git-send-email-a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.
Signed-off-by: Alexander Popov <a13xp0p0v88-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
Acked-by: Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>
---
drivers/dma/mpc512x_dma.c | 42 +++++++++++++++++++++++++-----------------
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 448750d..2ce248b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -52,9 +52,17 @@
#define MPC_DMA_DESCRIPTORS 64
/* Macro definitions */
-#define MPC_DMA_CHANNELS 64
#define MPC_DMA_TCD_OFFSET 0x1000
+/*
+ * Maximum channel counts for individual hardware variants
+ * and the maximum channel count over all supported controllers,
+ * used for data structure size
+ */
+#define MPC8308_DMACHAN_MAX 16
+#define MPC512x_DMACHAN_MAX 64
+#define MPC_DMA_CHANNELS 64
+
/* Arbitration mode of group and channel */
#define MPC_DMA_DMACR_EDCG (1 << 31)
#define MPC_DMA_DMACR_ERGA (1 << 3)
@@ -710,10 +718,10 @@ static int mpc_dma_probe(struct platform_device *op)
dma = &mdma->dma;
dma->dev = dev;
- if (!mdma->is_mpc8308)
- dma->chancnt = MPC_DMA_CHANNELS;
+ if (mdma->is_mpc8308)
+ dma->chancnt = MPC8308_DMACHAN_MAX;
else
- dma->chancnt = 16; /* MPC8308 DMA has only 16 channels */
+ dma->chancnt = MPC512x_DMACHAN_MAX;
dma->device_alloc_chan_resources = mpc_dma_alloc_chan_resources;
dma->device_free_chan_resources = mpc_dma_free_chan_resources;
dma->device_issue_pending = mpc_dma_issue_pending;
@@ -747,7 +755,19 @@ static int mpc_dma_probe(struct platform_device *op)
* - Round-robin group arbitration,
* - Round-robin channel arbitration.
*/
- if (!mdma->is_mpc8308) {
+ if (mdma->is_mpc8308) {
+ /* MPC8308 has 16 channels and lacks some registers */
+ out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
+
+ /* enable snooping */
+ out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
+ /* Disable error interrupts */
+ out_be32(&mdma->regs->dmaeeil, 0);
+
+ /* Clear interrupts status */
+ out_be32(&mdma->regs->dmaintl, 0xFFFF);
+ out_be32(&mdma->regs->dmaerrl, 0xFFFF);
+ } else {
out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
MPC_DMA_DMACR_ERGA | MPC_DMA_DMACR_ERCA);
@@ -768,18 +788,6 @@ static int mpc_dma_probe(struct platform_device *op)
/* Route interrupts to IPIC */
out_be32(&mdma->regs->dmaihsa, 0);
out_be32(&mdma->regs->dmailsa, 0);
- } else {
- /* MPC8308 has 16 channels and lacks some registers */
- out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
-
- /* enable snooping */
- out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
- /* Disable error interrupts */
- out_be32(&mdma->regs->dmaeeil, 0);
-
- /* Clear interrupts status */
- out_be32(&mdma->regs->dmaintl, 0xFFFF);
- out_be32(&mdma->regs->dmaerrl, 0xFFFF);
}
/* Register DMA engine */
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH RFC v7 0/6] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-02-12 13:25 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA
v2013/7/14 Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>:
> this series
> - introduces slave s/g support (that's support for DMA transfers which
> involve peripherals in contrast to mem-to-mem transfers)
> - adds device tree based lookup support for DMA channels
> - combines floating patches and related feedback which already covered
> several aspects of what the suggested LPB driver needs, to demonstrate
> how integration might be done
> - carries Q&D SD card support to enable another DMA client during test,
> while this patch needs to get dropped upon pickup
Changes in v2:
> - re-order mpc8308 related code paths for improved readability, no
> change in behaviour, introduction of symbolic channel names here
> already
> - squash 'execute() start condition' and 'terminate all' into the
> introduction of 'slave s/g prep' and 'device control' support; refuse
> s/g lists with more than one item since slave support is operational
> yet proper s/g support is missing (can get addressed later)
> - always start transfers from software on MPC8308 as there are no
> external request lines for peripheral flow control
> - drop dt-bindings header file and symbolic channel names in OF nodes
Changes in v3 and v4:
Part 1/5:
- use #define instead of enum since individual channels don't require
special handling.
Part 2/5:
- add a flag "will_access_peripheral" to DMA transfer descriptor
according recommendations of Gerhard Sittig.
This flag is set in mpc_dma_prep_memcpy() and mpc_dma_prep_slave_sg()
and is evaluated in mpc_dma_execute() to choose a type of start for
the transfer.
- prevent descriptors of transfers which involve peripherals from
being chained together;
each of such transfers needs hardware initiated start.
- add locking while working with struct mpc_dma_chan
according recommendations of Lars-Peter Clausen.
- remove default nbytes value. Client kernel modules must set
src_maxburst and dst_maxburst fields of struct dma_slave_config (dmaengine.h).
Changes in v5:
Part 2/5:
- add and improve comments;
- improve the code moving transfer descriptors from 'queued' to 'active' list
in mpc_dma_execute();
- allow mpc_dma_prep_slave_sg() to run with non-empty 'active' list;
- take 'mdesc' back to 'free' list in case of error in mpc_dma_prep_slave_sg();
- improve checks of the transfer parameters;
- provide the default value for 'maxburst' in mpc_dma_device_control().
Changes in v6:
Part 2/5:
- remove doubtful comment;
- fix coding style issues;
- set default value for 'maxburst' to 1 which applies to most cases;
Part 3/5:
- use dma_get_slave_channel() instead of dma_request_channel()
in new function of_dma_xlate_by_chan_id() according recommendations of
Arnd Bergmann;
Part 4/5:
- set DMA_PRIVATE flag for MPC512x DMA controller since its driver relies on
of_dma_xlate_by_chan_id() which doesn't use dma_request_channel()
any more; (removed in v7)
- resolve little patch conflict;
Part 5/5:
- resolve little patch conflict;
Changes in v7:
Part 2:
- improve comment;
Part 4:
- split in two separate patches. Part 4/6 contains device tree
binding document and in part 5/6 MPC512x DMA controller is registered
for device tree channel lookup;
- remove setting DMA_PRIVATE flag for MPC512x DMA controller from part 5/6;
> known issues:
> - it's yet to get confirmed whether MPC8308 can use slave support or
> whether the DMA controller's driver shall actively reject it, the
> information that's available so far suggests that peripheral transfers
> to IP bus attached I/O is useful and shall not get blocked right away
- adding support for transfers which don't increment the RAM address or
do increment the peripheral "port's" address is easy with
this implementation; but which options of the common API
should be used for specifying such transfers?
- device tree binding document for the MPC512x DMA controller needs
to be improved.
Alexander Popov (3):
dma: mpc512x: reorder mpc8308 specific instructions
dma: mpc512x: add support for peripheral transfers
dma: of: Add common xlate function for matching by channel id
Gerhard Sittig (3):
dma: mpc512x: add device tree binding document
dma: mpc512x: register for device tree channel lookup
HACK mmc: mxcmmc: enable clocks for the MPC512x
.../devicetree/bindings/dma/mpc512x-dma.txt | 55 ++++
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 293 +++++++++++++++++++--
drivers/dma/of-dma.c | 35 +++
drivers/mmc/host/mxcmmc.c | 42 ++-
include/linux/of_dma.h | 4 +
6 files changed, 391 insertions(+), 39 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pawel Moll, Linus Walleij,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Brown
In-Reply-To: <20140212114740.GE21992-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Wednesday 12 February 2014 11:47:40 Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014, Mark Rutland wrote:
> > > To me it feels odd to require the last clock in the list (apb_pclk) to
> > > be named, and the rest to be in a particular order. For the dt case it
> > > seems saner to add new clocks with names as it allows arbitrary subsets
> > > of clocks to be wired up and described (though obviously in this case a
> > > missing sspclk would be problematic).
> >
> > Yes, good point about the missing clocks, and I also agree mixing ordered
> > and named clocks in one device is rather odd and can lead to trouble.
> >
> > I guess there isn't really a good way out here, and I certainly won't
> > ask for it to be done one way or the other if someone else has a
> > good argument which way it should be implemented.
>
> Having thought about it, all dts that for the ssp_pclk must have some
> name for the sspclk (though the specific name is arbitrary). I could get
> the driver to try each of those before falling back to the index
> (perhaps with a helper that takes a list of known aliases), so all
> existing dts (that we are aware of) would work with the clock requested
> by name.
Strange. Why do the even have names in there? What are those strings?
I noticed that ux500 has uses four different strings, one for each
instance, which is obviously a bug and should just be fixed. There is
no way this was intentional, and we can just rely on teh fallback
if you want to have that anyway.
> I assume that for the non-dt case it's possible to name clock inputs to
> a device without the clock being associated with the name globally? If
> so we could get rid of the index usage entirely in this case.
Sorry, I don't understand the question.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] devicetree: ad7303: Updated documentation
From: Lars-Peter Clausen @ 2014-02-12 12:51 UTC (permalink / raw)
To: Mark Rutland
Cc: Paul Cercueil, Jonathan Cameron,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org, Pawel Moll,
Ian Campbell, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20140212122137.GA25957-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On 02/12/2014 01:21 PM, Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 12:08:23PM +0000, Paul Cercueil wrote:
>> Added documentation about the "adi,use-external-reference"
>> property.
>>
>> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/iio/dac/ad7303.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
>> index 914610f..de6b32f 100644
>> --- a/Documentation/devicetree/bindings/iio/dac/ad7303.txt
>> +++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
>> @@ -7,6 +7,9 @@ Required properties:
>> - Vdd-supply: Phandle to the Vdd power supply
>>
>> Optional properties:
>> + - adi,use-external-reference: If set, the external reference voltage
>> + supply is used. Otherwise, the internal reference voltage supply is
>> + used.
>
> As I asked for the ad5064 binding document, when would you want to do
> this, and why can't the driver decide?
Hi,
sorry my fault. I got confused with an older version of this driver and the
version that actually made it upstream. This property is not in the upstream
driver. The patch can safely be ignored and go to /dev/null. Again, sorry
for noise.
- Lars
^ permalink raw reply
* Re: [PATCH] ARM: mm: cache-l2x0: Check for status property of DT node
From: Tomasz Figa @ 2014-02-12 12:42 UTC (permalink / raw)
To: Tushar Behera, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-lFZ/pmaqli7XmaaqVzeoHQ, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Will Deacon
In-Reply-To: <1392206478-11530-1-git-send-email-tushar.behera-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[making Cc list a bit more comprehensive]
On 12.02.2014 13:01, Tushar Behera wrote:
> Currently only the DT node is checked during l2x0 cache initialization,
> but it doesn't check the status of the DT node. Thus it gets called
> even if the status of DT node for L2 controller is disabled.
>
> Add explicit check to ensure that L2 cache is initialized only for
> desired boards.
>
> Reported-by: Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Tushar Behera <tushar.behera-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/mm/cache-l2x0.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 7abde2c..f075cb1 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -978,6 +978,9 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
> if (!np)
> return -ENODEV;
>
> + if (!of_device_is_available(np))
> + return -ENODEV;
> +
> if (of_address_to_resource(np, 0, &res))
> return -ENODEV;
>
>
Reviewed-by: Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Shawn Guo @ 2014-02-12 12:28 UTC (permalink / raw)
To: Mark Rutland
Cc: Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <20140212095450.GB21992-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Wed, Feb 12, 2014 at 09:54:50AM +0000, Mark Rutland wrote:
> > I take it as an unnecessary churn, unless I see the consensus from most
> > of DT maintainers and arm-soc folks that we should make this change.
> > And see comment below ...
>
> My concern is that the simple-bus is being used in a nonsensical way,
> with a meaningless address space and reg values on children. While this
> currently works it is not correct, and it's not even necessary. I would
> like to limit the misuse of these constructs so as to prevent others
> from making the same mistakes.
Unfortunately, it's already been used quite widely. This is not IMX
specific, and you can grep arch/arm/boot/dts to get the idea. I'm not
sure if it's worth the churn to 'fix' it. In these days, arm-soc folks
are quite sensitive to the number of IMX patches and change sets. 50
LOC change for one board dts, and we now have ~70 files for IMX. That's
why I would like to get the agreement from arm-soc folks that we should
really make such change.
>
> >
> > >
> > > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 51 ++++++++++++++--------------------
> > > 1 file changed, 21 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > index 0d816d3..d7df5b2 100644
> > > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > > @@ -18,38 +18,29 @@
> > > reg = <0x10000000 0x40000000>;
> > > };
> > >
> > > - regulators {
> > > - compatible = "simple-bus";
> > > - #address-cells = <1>;
> > > - #size-cells = <0>;
> > > -
> > > - reg_usb_otg_vbus: regulator@0 {
> > > - compatible = "regulator-fixed";
> > > - reg = <0>;
> > > - regulator-name = "usb_otg_vbus";
> > > - regulator-min-microvolt = <5000000>;
> > > - regulator-max-microvolt = <5000000>;
> > > - gpio = <&gpio3 22 0>;
> > > - enable-active-high;
> > > - };
> > > + reg_usb_otg_vbus: regulator@0 {
> >
> > nodename@num should only be used for nodes that have 'reg' property.
> > Why are you dropping 'reg' property here? Right, it does not compile if
> > you do not drop it. You can take it as a reason of why I endorse
> > simple-bus regulators container.
>
> I don't think the logical jump from "it does not compile" to "I endorse
> simple-bus regulators container" makes any sense. They're two separate
> issues.
You're right :)
>
> The unit-addresses and reg values can be dropped. They are not in the
> regulator-fixed binding, and were never necessary. All that's necessary
> is a unique name, and unit-addresses (which required a reg) were misused
> to provide uniqueness. With that fixed, this will compile.
IIRC, ePAPR recommends to use generic node name and have
unit-addresses for uniqueness. That's why I sent patch [1] to follow
the way that tegra and other platforms names them. Now you're
suggesting to go back?
Shawn
[1] http://www.spinics.net/lists/arm-kernel/msg284474.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: clock: fixed-clock: Remove unsupported 'gpios' property
From: Fabio Estevam @ 2014-02-12 12:25 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: Russell King, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <1390339010-3541-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Rob,
On Tue, Jan 21, 2014 at 7:16 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>
> Remove the 'gpios' property from the documentation as this is something that the
> current fixed clock driver does not handle.
>
> Signed-off-by: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Any comment on this one?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] devicetree: ad7303: Updated documentation
From: Mark Rutland @ 2014-02-12 12:21 UTC (permalink / raw)
To: Paul Cercueil
Cc: Jonathan Cameron, Lars-Peter Clausen,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org, Pawel Moll,
Ian Campbell, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1392206903-1662-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
On Wed, Feb 12, 2014 at 12:08:23PM +0000, Paul Cercueil wrote:
> Added documentation about the "adi,use-external-reference"
> property.
>
> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/dac/ad7303.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
> index 914610f..de6b32f 100644
> --- a/Documentation/devicetree/bindings/iio/dac/ad7303.txt
> +++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
> @@ -7,6 +7,9 @@ Required properties:
> - Vdd-supply: Phandle to the Vdd power supply
>
> Optional properties:
> + - adi,use-external-reference: If set, the external reference voltage
> + supply is used. Otherwise, the internal reference voltage supply is
> + used.
As I asked for the ad5064 binding document, when would you want to do
this, and why can't the driver decide?
Cheers,
Mark.
^ permalink raw reply
* Re: [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
From: Mark Rutland @ 2014-02-12 12:18 UTC (permalink / raw)
To: Paul Cercueil
Cc: Jonathan Cameron, Lars-Peter Clausen,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org, Pawel Moll,
Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1392206518-1457-3-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
On Wed, Feb 12, 2014 at 12:01:58PM +0000, Paul Cercueil wrote:
> Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
> Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../devicetree/bindings/iio/dac/ad5064.txt | 49 ++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> new file mode 100644
> index 0000000..e5997b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
> @@ -0,0 +1,49 @@
> +Analog Devices AD5064 DAC device driver
It would be nice to have a short description here, with useful facts
(e.g. this is an SPI device).
Is there any public documentation? It might not need to go in the
document, but having a link really helps with review.
> +
> +Required properties:
> + - compatible: Must be one of:
> + * "adi,ad5024"
> + * "adi,ad5025"
> + * "adi,ad5044"
> + * "adi,ad5045"
> + * "adi,ad5064"
> + * "adi,ad5064-1"
> + * "adi,ad5065"
> + * "adi,ad5628-1"
> + * "adi,ad5628-2"
> + * "adi,ad5648-1"
> + * "adi,ad5648-2"
> + * "adi,ad5666-1"
> + * "adi,ad5666-2"
> + * "adi,ad5668-1"
> + * "adi,ad5668-2"
> + * "adi,ad5668-3"
How do these differ? Are these just different revisions of the same
chip?
Are particular strings expected to be used as fallbacks in the
compatible list?
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 30000000)
> + - vrefA-supply, vrefB-supply: phandles to external reference voltage
> + supplies for channels 0 and 1 respectively.
> + This property must be present for ad5024, ad5025, ad5044, ad5045,
> + ad5064, ad5065.
Does ad5064 also imply ad5604-1 here?
> + - vrefC-supply, vrefD-supply: phandles to external reference voltage
> + supplies for channels 2 and 3 respectively.
> + This property must be present for ad5024, ad5044, ad5064.
Likewise.
These seem oddly named given the description. Are these named A B C D in
the documentation? If not, vref-channel-X-supply would seem to be
clearer.
Why are these grouped in pairs rather than listed individually?
> +
> +Optional properties:
> + - adi,use-external-reference: If set, the external reference voltage
> + supply is used. This should only be set if there is an external
> + reference voltage connected to the vref or vref[A-D] pins.
> + If the property is not set, the internal reference voltage supply
> + is used if present, or an error is issued by the driver.
When would you want to do this, and when would you want to use the
internal reference? Could the driver not choose to do this based on
whether a supply is listed in the dt?
Strip the part about the error, that's not a description of the device
and not a matter for the binding.
> + - vref-supply: phandle to the external reference voltage supply.
> + This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
> + ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
Just to check, on some versions (e.g. ad5668-3), this can work without
any supply listed at all, yes?
Cheers,
Mark.
^ permalink raw reply
* [PATCH] devicetree: ad7303: Updated documentation
From: Paul Cercueil @ 2014-02-12 12:08 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, linux-iio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
devicetree-u79uwXL29TY76Z2rM5mHXA, Paul Cercueil
Added documentation about the "adi,use-external-reference"
property.
Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/iio/dac/ad7303.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
index 914610f..de6b32f 100644
--- a/Documentation/devicetree/bindings/iio/dac/ad7303.txt
+++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
@@ -7,6 +7,9 @@ Required properties:
- Vdd-supply: Phandle to the Vdd power supply
Optional properties:
+ - adi,use-external-reference: If set, the external reference voltage
+ supply is used. Otherwise, the internal reference voltage supply is
+ used.
- REF-supply: Phandle to the external reference voltage supply. This should
only be set if there is an external reference voltage connected to the REF
pin. If the property is not set Vdd/2 is used as the reference voltage.
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH v2 02/21] drm/exynos: delay fbdev initialization until an output is connected
From: Sachin Kamat @ 2014-02-12 12:03 UTC (permalink / raw)
To: Andrzej Hajda
Cc: dri-devel@lists.freedesktop.org, Mark Rutland,
devicetree@vger.kernel.org, linux-samsung-soc, Pawel Moll,
Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski, Inki Dae
In-Reply-To: <1392204688-4591-3-git-send-email-a.hajda@samsung.com>
+cc Inki Dae
Looks like you missed CCing Exynos DRM maintainers.
On 12 February 2014 17:01, Andrzej Hajda <a.hajda@samsung.com> wrote:
> In case fbdev is initialized before any output is connected,
> fb resolution defaults to 1024x768. After that any output with
> bigger resolution is ignored and fbdev is not displayed.
> The patch postpones fbdev initialization to avoid such situation.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
[snip]
> static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index e7c2f2d..9a5ec83 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -249,8 +249,10 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
> return 0;
>
> fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
> - if (!fbdev)
> + if (!fbdev) {
> + DRM_ERROR("failed to allocate fbdev.\n");
This message is not needed as kzalloc gives oom message.
> return -ENOMEM;
> + }
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH 3/3] devicetree: ad5064: Added devicetree bindings documentation
From: Paul Cercueil @ 2014-02-12 12:01 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, linux-iio-u79uwXL29TY76Z2rM5mHXA,
Paul Cercueil, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392206518-1457-1-git-send-email-paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Paul Cercueil <paul.cercueil-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
.../devicetree/bindings/iio/dac/ad5064.txt | 49 ++++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5064.txt
diff --git a/Documentation/devicetree/bindings/iio/dac/ad5064.txt b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
new file mode 100644
index 0000000..e5997b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad5064.txt
@@ -0,0 +1,49 @@
+Analog Devices AD5064 DAC device driver
+
+Required properties:
+ - compatible: Must be one of:
+ * "adi,ad5024"
+ * "adi,ad5025"
+ * "adi,ad5044"
+ * "adi,ad5045"
+ * "adi,ad5064"
+ * "adi,ad5064-1"
+ * "adi,ad5065"
+ * "adi,ad5628-1"
+ * "adi,ad5628-2"
+ * "adi,ad5648-1"
+ * "adi,ad5648-2"
+ * "adi,ad5666-1"
+ * "adi,ad5666-2"
+ * "adi,ad5668-1"
+ * "adi,ad5668-2"
+ * "adi,ad5668-3"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use (< 30000000)
+ - vrefA-supply, vrefB-supply: phandles to external reference voltage
+ supplies for channels 0 and 1 respectively.
+ This property must be present for ad5024, ad5025, ad5044, ad5045,
+ ad5064, ad5065.
+ - vrefC-supply, vrefD-supply: phandles to external reference voltage
+ supplies for channels 2 and 3 respectively.
+ This property must be present for ad5024, ad5044, ad5064.
+
+Optional properties:
+ - adi,use-external-reference: If set, the external reference voltage
+ supply is used. This should only be set if there is an external
+ reference voltage connected to the vref or vref[A-D] pins.
+ If the property is not set, the internal reference voltage supply
+ is used if present, or an error is issued by the driver.
+ - vref-supply: phandle to the external reference voltage supply.
+ This property can be used with ad5064-1, ad5628-1, ad5628-2, ad5648-1,
+ ad5648-2, ad5666-1, ad5666-2, ad5668-1, ad5668-2, ad5668-3.
+
+Example:
+
+ ad5668-2@4 {
+ compatible = "adi,ad5668-2";
+ reg = <4>;
+ spi-max-frequency = <10000000>;
+ adi,use-external-reference;
+ vref-supply = <&vref_supply>;
+ };
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH v2 16/21] ARM: dts: exynos5250: add display power domain node
From: Andrzej Hajda @ 2014-02-12 11:59 UTC (permalink / raw)
To: Sachin Kamat
Cc: dri-devel@lists.freedesktop.org, Mark Rutland,
devicetree@vger.kernel.org, linux-samsung-soc, Pawel Moll,
Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <CAK9yfHwikyhoV6rLgB+vHoFdjuFWSZxCtE3xth7AhF6o=oS2GQ@mail.gmail.com>
On 02/12/2014 12:51 PM, Sachin Kamat wrote:
Hi Sachin,
> Hi Andrzej,
>
> On 12 February 2014 17:01, Andrzej Hajda <a.hajda@samsung.com> wrote:
>> The patch adds power domain for display subsystem.
>>
>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index c8745a0..0935dca 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -84,6 +84,11 @@
>> reg = <0x10044040 0x20>;
>> };
>>
>> + pd_disp: mfc-power-domain@100440a0 {
> Looks like a typo here.
>
Fortunately it is harmless, but thanks for pointing it out. Will be fixed.
Regards
Andrzej
^ permalink raw reply
* Re: [RFC PATCH v2 16/21] ARM: dts: exynos5250: add display power domain node
From: Sachin Kamat @ 2014-02-12 11:51 UTC (permalink / raw)
To: Andrzej Hajda
Cc: dri-devel@lists.freedesktop.org, Mark Rutland,
devicetree@vger.kernel.org, linux-samsung-soc, Pawel Moll,
Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-17-git-send-email-a.hajda@samsung.com>
Hi Andrzej,
On 12 February 2014 17:01, Andrzej Hajda <a.hajda@samsung.com> wrote:
> The patch adds power domain for display subsystem.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index c8745a0..0935dca 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -84,6 +84,11 @@
> reg = <0x10044040 0x20>;
> };
>
> + pd_disp: mfc-power-domain@100440a0 {
Looks like a typo here.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Arnd Bergmann @ 2014-02-12 11:51 UTC (permalink / raw)
To: Laura Abbott
Cc: devicetree, Kees Cook, linux-kernel, Rob Herring, Kumar Gala,
Grant Likely, linux-arm-kernel
In-Reply-To: <1392168805-14200-1-git-send-email-lauraa@codeaurora.org>
On Wednesday 12 February 2014, Laura Abbott wrote:
> This is an RFC to seed the random number pool earlier when using devicetree.
> The big issue this is trying to solve is the fact that the stack canary for
> ARM tends to be the same across bootups of the same device. This is because
> the random number pools do not get initialized until after the canary has
> been set up. The canary can be moved later, but in general there is still
> no way to reliably get random numbers early for other features (e.g. vector
> randomization).
Implementation-wise this looks reasonable, and it obviously addresses a
very real problem.
> The goal here is to allow devices to add to the random pools via
> add_device_randomness or some other method of their chosing at FDT time.
> I realize that ARCH_RANDOM is already available but this didn't work because
> 1) ARCH_RANDOM is not multi-platform compatible without added
> infrastructure to ARM
That could certainly be done, but I agree that a more generic
approach like you did is nicer. One thing that might be useful
would be to wire up your OF_RANDOM infrastructure as a generic
implementation of ARCH_RANDOM, and merge your header file into
include/asm-generic/archrandom.h, with an added way to call
arch_get_random_long() for the devices you add.
> The big reason to skip ARCH_RANDOM though is that the random number generation
> we have would be reasonable if only seeded earlier.
Yes, makes sense.
I also wonder if we should add a 'trivial' implementation that just
reads a DT property full of random numbers to use as either an initial
seed, or to feed into arch_get_random_long(). This would allow the
boot loader to pass any entropy it has already gathered into the kernel,
but leaves the danger that people might pass static not-so-random data
through a precompiled dtb file ;-). If we get the boot loaders to be
smart enough, doing only this would be a much simpler kernel implementation
than your suggestion, but I'm not sure how far I want to trust boot loaders.
Another possibilitiy is to mix in the any contents of a "local-mac-address"
property into the entropy at early DT probing, which would still be
deterministic for a given machine and should not count as entropty,
but at least give each machine with this property a unique seed in the
absence of any other entropy source.
Arnd
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-12 11:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
Linus Walleij
In-Reply-To: <201402121221.51233.arnd-r2nGTMty4D4@public.gmane.org>
On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Mark Rutland wrote:
> > To me it feels odd to require the last clock in the list (apb_pclk) to
> > be named, and the rest to be in a particular order. For the dt case it
> > seems saner to add new clocks with names as it allows arbitrary subsets
> > of clocks to be wired up and described (though obviously in this case a
> > missing sspclk would be problematic).
>
> Yes, good point about the missing clocks, and I also agree mixing ordered
> and named clocks in one device is rather odd and can lead to trouble.
>
> I guess there isn't really a good way out here, and I certainly won't
> ask for it to be done one way or the other if someone else has a
> good argument which way it should be implemented.
Having thought about it, all dts that for the ssp_pclk must have some
name for the sspclk (though the specific name is arbitrary). I could get
the driver to try each of those before falling back to the index
(perhaps with a helper that takes a list of known aliases), so all
existing dts (that we are aware of) would work with the clock requested
by name.
I assume that for the non-dt case it's possible to name clock inputs to
a device without the clock being associated with the name globally? If
so we could get rid of the index usage entirely in this case.
Does that sound workable?
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Amit Kachhap @ 2014-02-12 11:39 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, linux-arm-kernel, linux-pm, Dave Martin, Mark Rutland,
Sudeep Holla, Charles Garcia Tobin, Nicolas Pitre, Rob Herring,
Peter De Schrijver, Grant Likely, Kumar Gala, Santosh Shilimkar,
Russell King, Mark Hambleton, Hanjun Guo, Daniel Lezcano,
Amit Kucheria, Vincent Guittot, Antti Miettinen, Stephen Boyd,
Tomasz Figa, Kevin Hilman
In-Reply-To: <1392128273-8614-4-git-send-email-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
This patch series looks nice and explains the ARM C state DT bindings clearly.
Couples of thoughts below.
On 2/11/14, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter idle states at run-time.
> The parameters defining these idle states vary on a per-platform basis
> forcing
> the OS to hardcode the state parameters in platform specific static tables
> whose size grows as the number of platforms supported in the kernel
> increases
> and hampers device drivers standardization.
>
> Therefore, this patch aims at standardizing idle state device tree bindings
> for
> ARM platforms. Bindings define idle state parameters inclusive of entry
> methods
> and state latencies, to allow operating systems to retrieve the
> configuration
> entries from the device tree and initialize the related power management
> drivers, paving the way for common code in the kernel to deal with idle
> states and removing the need for static data in current and previous kernel
> versions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
> 2 files changed, 700 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 9130435..fb7f008 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -191,6 +191,13 @@ nodes to be present and contain the properties
> described below.
> property identifying a 64-bit zero-initialised
> memory location.
>
> + - cpu-idle-states
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition:
> + # List of phandles to cpu idle state nodes supported
> + by this cpu [1].
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> @@ -382,3 +389,6 @@ cpus {
> cpu-release-addr = <0 0x20000000>;
> };
> };
> +
> +[1] ARM Linux kernel documentation - idle state bindings
> + Documentation/devicetree/bindings/arm/idle-states.txt
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
> b/Documentation/devicetree/bindings/arm/idle-states.txt
> new file mode 100644
> index 0000000..f155e70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -0,0 +1,690 @@
> +==========================================
> +ARM idle states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OSPM policies. The CPU states
> representing
> +the range of dynamic idle states that a processor can enter at run-time,
> can be
> +specified through device tree bindings representing the parameters
> required
> +to enter/exit specific idle states on a given processor.
> +
> +According to the Server Base System Architecture document (SBSA, [3]), the
> +power states an ARM CPU can be put into are identified by the following
> list:
> +
> +1 - Running
> +2 - Idle_standby
> +3 - Idle_retention
> +4 - Sleep
> +5 - Off
> +
> +ARM platforms implement the power states specified in the SBSA through
> power
> +management schemes that allow an OS PM implementation to put the processor
> in
> +different idle states (which include states 1 to 4 above; "off" state is
> not
> +an idle state since it does not have wake-up capabilities, hence it is not
> +considered in this document).
> +
> +Idle state parameters (eg entry latency) are platform specific and need to
> be
> +characterized with bindings that provide the required information to OSPM
> +code so that it can build the required tables and use them at runtime.
> +
> +The device tree binding definition for ARM idle states is the subject of
> this
> +document.
> +
> +===========================================
> +2 - cpu-idle-states node
> +===========================================
> +
> +ARM processor idle states are defined within the cpu-idle-states node,
> which is
> +a direct child of the cpus node and provides a container where the
> processor
> +states, defined as device tree nodes, are listed.
> +
> +- cpu-idle-states node
> +
> + Usage: Optional - On ARM systems, is a container of processor idle
> + states nodes. If the system does not provide CPU
> + power management capabilities or the processor just
> + supports idle_standby a cpu-idle-states node is not
> + required.
> +
> + Description: cpu-idle-states node is a container node, where its
> + subnodes describe the CPU idle states.
> +
> + Node name must be "cpu-idle-states".
> +
> + The cpu-idle-states node's parent node must be the cpus node.
> +
> + The cpu-idle-states node's child nodes can be:
> +
> + - one or more state nodes
> +
> + Any other configuration is considered invalid.
> +
> +The nodes describing the idle states (state) can only be defined within
> the
> +cpu-idle-states node.
> +
> +Any other configuration is consider invalid and therefore must be ignored.
> +
> +===========================================
> +2 - state node
> +===========================================
> +
> +A state node represents an idle state description and must be defined as
> +follows:
> +
> +- state node
> +
> + Description: must be child of either the cpu-idle-states node or
> + a state node.
> +
> + The state node name shall be "stateN", where N = {0, 1, ...} is
> + the node number; state nodes which are siblings within a single common
> + parent node must be given a unique and sequential N value, starting
> + from 0.
> +
> + A state node can contain state child nodes. A state node with
> + children represents a hierarchical state, which is a superset of
> + the child states. Hierarchical states require all CPUs on which
> + they are valid to request the state in order for it to be entered.
> +
> + A state node defines the following properties:
> +
> + - compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must be "arm,cpu-idle-state".
> +
> + - index
> + Usage: Required
> + Value type: <u32>
> + Definition: It represents an idle state index, starting from 2.
> + Index 0 represents the processor state "running"
> + and index 1 represents processor mode
> + "idle_standby", entered by executing a wfi
> + instruction (SBSA,[3]); indexes 0 and 1 are
> + standard ARM states that need not be described.
> +
> + - entry-method
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Describes the method by which a CPU enters the
> + idle state. This property is required and must be
> + one of:
> +
> + - "arm,psci-cpu-suspend"
> + ARM PSCI firmware interface, CPU suspend
> + method[2].
> +
> + - "[vendor],[method]"
> + An implementation dependent string with
> + format "vendor,method", where vendor is a string
> + denoting the name of the manufacturer and
> + method is a string specifying the mechanism
> + used to enter the idle state.
> +
> + - power-state
> + Usage: See definition.
> + Value type: <u32>
> + Definition: Depends on the entry-method property value.
> + If entry-method is "arm,psci-cpu-suspend":
> + # Property is required and represents
> + psci-power-state parameter. Please refer to
> + [2] for PSCI bindings definition.
> +
> + - entry-latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to enter the idle state.
I liked your V2 version of OPP based latency more. However in this way
also latency supplied can correspond to max OPP and based on the
current OPP, the cpuidle driver can compute the new latency
proportionately. In case of frequency this can be linear but may not
be linear for residency.
> +
> + - exit-latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to exit the idle state.
> +
> + - min-residency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing time in microseconds
> + required for the CPU to be in the idle state to
> + make up for the dynamic power consumed to
> + enter/exit the idle state in order to break even
> + in terms of power consumption compared to idle
> + state index 1 (idle_standby).
> +
> + - power-domains
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition: List of power domain specifiers ([1]) describing
> + the power domains that are affected by the idle
> + state entry.
I can see power-domains used in 2 places. First in C state definitions
and second in cpu node cache descriptions. I am not sure but if
possible than this can be put in one place.
> +
> + - cache-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present cache memory is retained on power down,
> + otherwise it is lost.
Can the DT bindings support both retained and non-retained with
different C states? The example shown does not use the retained flag.
I guess than many combinations are possible.
Processor retained, cache non-retained = C state 2
Processor non retained , cache retained = C state 3
Processor non retained, cache non retained = C state 4
> +
> + - processor-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present CPU processor logic is retained on
> + power down, otherwise it is lost.
> +
> +===========================================
> +3 - Examples
> +===========================================
> +
> +Example 1 (ARM 64-bit, 16-cpu system):
> +
> +pd_clusters: power-domain-clusters@80002000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80002000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pd_cores: power-domain-cores@80000000 {
> + compatible = "arm,power-controller";
> + reg = <0x0 0x80000000 0x0 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +};
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu-idle-states {
> +
> + STATE0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x1010000>;
> + entry-latency = <500>;
> + exit-latency = <1000>;
> + min-residency = <2500>;
> + power-domains = <&pd_clusters 0>;
> + STATE0_1: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x0010000>;
> + entry-latency = <200>;
> + exit-latency = <400>;
> + min-residency = <300>;
> + power-domains = <&pd_cores 0>,
> + <&pd_cores 1>,
> + <&pd_cores 2>,
> + <&pd_cores 3>,
> + <&pd_cores 4>,
> + <&pd_cores 5>,
> + <&pd_cores 6>,
> + <&pd_cores 7>;
> + };
> + };
> +
> + STATE1: state1 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x1010000>;
> + entry-latency = <1000>;
> + exit-latency = <3000>;
> + min-residency = <6500>;
> + power-domains = <&pd_clusters 1>;
> + STATE1_0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x0010000>;
> + entry-latency = <200>;
> + exit-latency = <400>;
> + min-residency = <500>;
> + power-domains = <&pd_cores 8>,
> + <&pd_cores 9>,
> + <&pd_cores 10>,
> + <&pd_cores 11>,
> + <&pd_cores 12>,
> + <&pd_cores 13>,
> + <&pd_cores 14>,
> + <&pd_cores 15>;
> + };
> + };
> + };
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + next-level-cache = <&L1_0>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_0: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 0>;
> + };
> + L2_0: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 0>;
> + };
> + };
> +
> + CPU1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + next-level-cache = <&L1_1>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_1: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 1>;
> + };
> + };
> +
> + CPU2: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_2>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_2: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 2>;
> + };
> + };
> +
> + CPU3: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_3>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_3: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 3>;
> + };
> + };
> +
> + CPU4: cpu@10000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10000>;
> + enable-method = "psci";
> + next-level-cache = <&L1_4>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_4: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 4>;
> + };
> + };
> +
> + CPU5: cpu@10001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10001>;
> + enable-method = "psci";
> + next-level-cache = <&L1_5>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_5: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 5>;
> + };
> + };
> +
> + CPU6: cpu@10100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_6>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_6: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 6>;
> + };
> + };
> +
> + CPU7: cpu@10101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x10101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_7>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_7: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 7>;
> + };
> + };
> +
> + CPU8: cpu@100000000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x0>;
> + enable-method = "psci";
> + next-level-cache = <&L1_8>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_8: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 8>;
> + };
> + L2_1: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 1>;
> + };
> + };
> +
> + CPU9: cpu@100000001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x1>;
> + enable-method = "psci";
> + next-level-cache = <&L1_9>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_9: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 9>;
> + };
> + };
> +
> + CPU10: cpu@100000100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_10>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_10: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 10>;
> + };
> + };
> +
> + CPU11: cpu@100000101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_11>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_11: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 11>;
> + };
> + };
> +
> + CPU12: cpu@100010000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10000>;
> + enable-method = "psci";
> + next-level-cache = <&L1_12>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_12: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 12>;
> + };
> + };
> +
> + CPU13: cpu@100010001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10001>;
> + enable-method = "psci";
> + next-level-cache = <&L1_13>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_13: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 13>;
> + };
> + };
> +
> + CPU14: cpu@100010100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10100>;
> + enable-method = "psci";
> + next-level-cache = <&L1_14>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_14: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 14>;
> + };
> + };
> +
> + CPU15: cpu@100010101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1 0x10101>;
> + enable-method = "psci";
> + next-level-cache = <&L1_15>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_15: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 15>;
> + };
> + };
> +};
> +
> +Example 2 (ARM 32-bit, 8-cpu system, two clusters):
> +
> +pd_clusters: power-domain-clusters@80002000 {
> + compatible = "arm,power-controller";
> + reg = <0x80002000 0x1000>;
> + #power-domain-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pd_cores: power-domain-cores@80000000 {
> + compatible = "arm,power-controller";
> + reg = <0x80000000 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +};
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <1>;
> +
> + cpu-idle-states {
> +
> + STATE0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "psci";
> + psci-power-state = <0x1010000>;
> + entry-latency = <1000>;
> + exit-latency = <1500>;
> + min-residency = <1500>;
> + power-domains = <&pd_clusters 0>;
> + STATE0_1: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "psci";
> + psci-power-state = <0x0010000>;
> + entry-latency = <400>;
> + exit-latency = <500>;
> + min-residency = <300>;
> + power-domains = <&pd_cores 0>,
> + <&pd_cores 1>,
> + <&pd_cores 2>,
> + <&pd_cores 3>;
> + };
> + };
> +
> + STATE1: state1 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
> + entry-method = "psci";
> + psci-power-state = <0x1010000>;
> + entry-latency = <800>;
> + exit-latency = <2000>;
> + min-residency = <6500>;
> + power-domains = <&pd_clusters 1>;
> + STATE1_0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "psci";
> + psci-power-state = <0x0010000>;
> + entry-latency = <300>;
> + exit-latency = <500>;
> + min-residency = <500>;
> + power-domains = <&pd_cores 4>,
> + <&pd_cores 5>,
> + <&pd_cores 6>,
> + <&pd_cores 7>;
> + };
> + };
> + };
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x0>;
> + next-level-cache = <&L1_0>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_0: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 0>;
> + };
> + L2_0: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 0>;
> + };
> + };
> +
> + CPU1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x1>;
> + next-level-cache = <&L1_1>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_1: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 1>;
> + };
> + };
> +
> + CPU2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x2>;
> + next-level-cache = <&L1_2>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_2: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 2>;
> + };
> + };
> +
> + CPU3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x3>;
> + next-level-cache = <&L1_3>;
> + cpu-idle-states = <&STATE0_1 &STATE0>;
> + L1_3: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_0>;
> + power-domain = <&pd_cores 3>;
> + };
> + };
> +
> + CPU4: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + next-level-cache = <&L1_4>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_4: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 4>;
> + };
> + L2_1: l2-cache {
> + compatible = "arm,arch-cache";
> + power-domain = <&pd_clusters 1>;
> + };
> + };
> +
> + CPU5: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + next-level-cache = <&L1_5>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_5: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 5>;
> + };
> + };
> +
> + CPU6: cpu@102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x102>;
> + next-level-cache = <&L1_6>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_6: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 6>;
> + };
> + };
> +
> + CPU7: cpu@103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x103>;
> + next-level-cache = <&L1_7>;
> + cpu-idle-states = <&STATE1_0 &STATE1>;
> + L1_7: l1-cache {
> + compatible = "arm,arch-cache";
> + next-level-cache = <&L2_1>;
> + power-domain = <&pd_cores 7>;
> + };
> + };
> +};
> +
> +===========================================
> +4 - References
> +===========================================
> +
> +[1] ARM Linux Kernel documentation - power domain bindings
> + Documentation/devicetree/bindings/power/power_domain.txt
> +
> +[2] ARM Linux Kernel documentation - PSCI bindings
> + Documentation/devicetree/bindings/arm/psci.txt
> +
> +[3] ARM Server Base System Architecture (SBSA)
> + http://infocenter.arm.com/help/index.jsp
> --
> 1.8.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] of: give priority to the compatible match in __of_match_node()
From: Kevin Hao @ 2014-02-12 11:38 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Sebastian Hesselbarth, Stephen N Chivers, Chris Proctor,
Arnd Bergmann, Scott Wood, Grant Likely, Rob Herring
When the device node do have a compatible property, we definitely
prefer the compatible match besides the type and name. Only if
there is no such a match, we then consider the candidate which
doesn't have compatible entry but do match the type or name with
the device node.
This is based on a patch from Sebastian Hesselbarth.
http://patchwork.ozlabs.org/patch/319434/
I did some code refactoring and also fixed a bug in the original patch.
Cc: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Kevin Hao <haokexin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/of/base.c | 55 +++++++++++++++++++++++++++++++++++++------------------
1 file changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450d5683..9d655df458bd 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,32 +730,45 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static int of_match_type_or_name(const struct device_node *node,
+ const struct of_device_id *m)
+{
+ int match = 1;
+
+ if (m->name[0])
+ match &= node->name && !strcmp(m->name, node->name);
+
+ if (m->type[0])
+ match &= node->type && !strcmp(m->type, node->type);
+
+ return match;
+}
+
static
const struct of_device_id *__of_match_node(const struct of_device_id *matches,
const struct device_node *node)
{
const char *cp;
int cplen, l;
+ const struct of_device_id *m;
+ int match;
if (!matches)
return NULL;
cp = __of_get_property(node, "compatible", &cplen);
- do {
- const struct of_device_id *m = matches;
+ while (cp && (cplen > 0)) {
+ m = matches;
/* Check against matches with current compatible string */
while (m->name[0] || m->type[0] || m->compatible[0]) {
- int match = 1;
- if (m->name[0])
- match &= node->name
- && !strcmp(m->name, node->name);
- if (m->type[0])
- match &= node->type
- && !strcmp(m->type, node->type);
- if (m->compatible[0])
- match &= cp
- && !of_compat_cmp(m->compatible, cp,
+ if (!m->compatible[0]) {
+ m++;
+ continue;
+ }
+
+ match = of_match_type_or_name(node, m);
+ match &= cp && !of_compat_cmp(m->compatible, cp,
strlen(m->compatible));
if (match)
return m;
@@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
}
/* Get node's next compatible string */
- if (cp) {
- l = strlen(cp) + 1;
- cp += l;
- cplen -= l;
- }
- } while (cp && (cplen > 0));
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ m = matches;
+ /* Check against matches without compatible string */
+ while (m->name[0] || m->type[0] || m->compatible[0]) {
+ if (!m->compatible[0] && of_match_type_or_name(node, m))
+ return m;
+ m++;
+ }
return NULL;
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
From: Kevin Hao @ 2014-02-12 11:32 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Stephen N Chivers, Chris Proctor, Arnd Bergmann, devicetree,
Scott Wood, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <52FB5A56.2050402-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Wed, Feb 12, 2014 at 12:26:14PM +0100, Sebastian Hesselbarth wrote:
> You can cook it down to:
>
> m = matches;
> /* Check against matches without compatible string */
> while (m->name[0] || m->type[0] || m->compatible[0]) {
> if (!m->compatible[0] && of_match_type_or_name(node, m)
> return m;
> m++;
> }
Will do.
Thanks,
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [RFC PATCH v2 21/21] ARM: dts: exynos4412-trats2: enable exynos/fimd node
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Andrzej Hajda, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
The patch changes fimd node status to OK.
Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/exynos4412-trats2.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 0986d08..9296f86 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -545,6 +545,10 @@
};
};
+ fimd@11c00000 {
+ status = "okay";
+ };
+
camera {
pinctrl-0 = <&cam_port_b_clk_active>;
pinctrl-names = "default";
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 20/21] ARM: dts: exynos4210-trats: enable exynos/fimd node
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Andrzej Hajda, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
The patch changes fimd node status to OK.
Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/exynos4210-trats.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 5483969..f121505 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -391,6 +391,10 @@
};
};
+ fimd@11c00000 {
+ status = "okay";
+ };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel
Cc: Andrzej Hajda, Mark Rutland, devicetree, linux-samsung-soc,
Pawel Moll, Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda@samsung.com>
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 39 ++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index a0a985d..7d666b1 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -584,6 +584,45 @@
};
};
+ panel: panel {
+ compatible = "boe,hv070wsa-100";
+ power-supply = <&vcc_3v3_reg>;
+ enable-gpios = <&gpd1 3 0>;
+ port {
+ panel_ep: endpoint {
+ remote-endpoint = <&bridge_out_ep>;
+ };
+ };
+ };
+
+ dsi_0: dsi@14500000 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ samsung,pll-clock-frequency = <24000000>;
+ samsung,burst-clock-frequency = <320000000>;
+ samsung,esc-clock-frequency = <10000000>;
+ status = "okay";
+
+ bridge@0 {
+ reg = <0>;
+ compatible = "toshiba,tc358764";
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddmipi-supply = <&vcc_1v2_reg>;
+ vddlvds133-supply = <&vcc_3v3_reg>;
+ vddlvds112-supply = <&vcc_1v2_reg>;
+ reset-gpio = <&gpd1 6 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+ bridge_out_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+ };
+
fimd: fimd@14400000 {
status = "okay";
};
--
1.8.3.2
^ permalink raw reply related
* [RFC PATCH v2 18/21] ARM: dts: exynos5250-arndale: add display regulators
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel
Cc: Andrzej Hajda, Mark Rutland, devicetree, linux-samsung-soc,
Pawel Moll, Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda@samsung.com>
The patch adds fixed regulators used by DSI/LVDS bridge
and panel. Regulators are named according to schematics.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 8aa8d8c..a0a985d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -525,6 +525,30 @@
reg = <2>;
regulator-name = "hdmi-en";
};
+
+ vcc_1v2_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vcc_1v8_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vcc_3v3_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
fixed-rate-clocks {
--
1.8.3.2
^ permalink raw reply related
* [RFC PATCH v2 17/21] ARM: dts: exynos5250: add DSI node
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel
Cc: Andrzej Hajda, Mark Rutland, devicetree, linux-samsung-soc,
Pawel Moll, Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda@samsung.com>
The patch adds common part of DSI node for Exynos5250 platforms.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 0935dca..bbe8ef4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -656,6 +656,20 @@
phy-names = "dp";
};
+ dsi_0: dsi@14500000 {
+ compatible = "samsung,exynos4210-mipi-dsi";
+ reg = <0x14500000 0x10000>;
+ interrupts = <0 82 0>;
+ samsung,power-domain = <&pd_disp>;
+ phys = <&mipi_phy 3>;
+ phy-names = "dsim";
+ clocks = <&clock 341>, <&clock 134>;
+ clock-names = "bus_clk", "pll_clk";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
fimd@14400000 {
clocks = <&clock 133>, <&clock 339>;
clock-names = "sclk_fimd", "fimd";
--
1.8.3.2
^ permalink raw reply related
* [RFC PATCH v2 16/21] ARM: dts: exynos5250: add display power domain node
From: Andrzej Hajda @ 2014-02-12 11:31 UTC (permalink / raw)
To: dri-devel
Cc: Andrzej Hajda, Mark Rutland, devicetree, linux-samsung-soc,
Pawel Moll, Ian Campbell, Kyungmin Park, Rob Herring, Kumar Gala,
Grant Likely, Sean Paul, Marek Szyprowski
In-Reply-To: <1392204688-4591-1-git-send-email-a.hajda@samsung.com>
The patch adds power domain for display subsystem.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm/boot/dts/exynos5250.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index c8745a0..0935dca 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -84,6 +84,11 @@
reg = <0x10044040 0x20>;
};
+ pd_disp: mfc-power-domain@100440a0 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x100440a0 0x20>;
+ };
+
clock: clock-controller@10010000 {
compatible = "samsung,exynos5250-clock";
reg = <0x10010000 0x30000>;
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox