* Re: [PATCH 2/5 v2] clk: qcom: Elaborate on "active" clocks in the RPM clock bindings
From: Rob Herring @ 2017-04-28 13:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Michael Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170419091326.11226-2-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Apr 19, 2017 at 11:13:23AM +0200, Linus Walleij wrote:
> The concept of "active" clocks is just explained in a bried comment in the
> device driver, let's explain it a bit more in the device tree bindings
> so everyone understands this.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v1->v2:
> - Reword slighty in accordance with Stephens feedback.
> ---
> Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
Despite my objections, you're just documenting what is already there.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: rockchip-dw-mshc: add optional rockchip,default-num-phases
From: Rob Herring @ 2017-04-28 13:34 UTC (permalink / raw)
To: Shawn Lin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Ziyuan Xu,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Doug Anderson, Jaehoon Chung,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492592434-81312-2-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Wed, Apr 19, 2017 at 05:00:33PM +0800, Shawn Lin wrote:
> By default, dw_mmc-rockchip will execute tuning for each degree.
> So we won't miss every point of the good sample windows. However,
> probably the phases are linear inside the good sample window.
> Actually we don't need to do tuning for each degree so that we could
> save some time, for instance, probe the driver or resume from S3.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
> index 520d61d..ea47ec0 100644
> --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
> @@ -31,6 +31,10 @@ Optional Properties:
> probing, low speeds or in case where all phases work at tuning time.
> If not specified 0 deg will be used.
>
> +* rockchip,default-num-phases: The default number of times that the host
> + execute tuning when needed. If not specified, the host will do tuning
> + for 360 times, namely tuning for each degree.
How is it default when you specify it? I would think default here is
360.
Should this be common?
Rob
^ permalink raw reply
* Re: [PATCH] drivers/of_iommu: ignore SMMU DT nodes with status 'disabled'
From: Ard Biesheuvel @ 2017-04-28 13:22 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
joro-zLv9SwRftAIdnm+yROfE0A, Robin Murphy,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
In-Reply-To: <20170428131744.GL13675-5wv7dgnIgG8@public.gmane.org>
On 28 April 2017 at 14:17, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Apr 28, 2017 at 02:14:49PM +0100, Ard Biesheuvel wrote:
>> On 28 April 2017 at 14:11, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > Hi Ard,
>> >
>> > [+ devicetree@]
>> >
>> > On Fri, Apr 14, 2017 at 01:43:15PM +0100, Ard Biesheuvel wrote:
>> >> DT nodes may have a status property, and if they do, such nodes should
>> >> only be considered present if the status property is set to 'okay'.
>> >>
>> >> Currently, we call the init function of IOMMUs described by the device
>> >> tree without taking this into account, which may result in the output
>> >> below on systems where some SMMUs may be legally disabled.
>> >>
>> >> Failed to initialise IOMMU /smb/smmu@e0200000
>> >> Failed to initialise IOMMU /smb/smmu@e0c00000
>> >> arm-smmu e0a00000.smmu: probing hardware configuration...
>> >> arm-smmu e0a00000.smmu: SMMUv1 with:
>> >> arm-smmu e0a00000.smmu: stage 2 translation
>> >> arm-smmu e0a00000.smmu: coherent table walk
>> >> arm-smmu e0a00000.smmu: stream matching with 32 register groups, mask 0x7fff
>> >> arm-smmu e0a00000.smmu: 8 context banks (8 stage-2 only)
>> >> arm-smmu e0a00000.smmu: Supported page sizes: 0x60211000
>> >> arm-smmu e0a00000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
>> >> Failed to initialise IOMMU /smb/smmu@e0600000
>> >> Failed to initialise IOMMU /smb/smmu@e0800000
>> >>
>> >> Since this is not an error condition, only call the init function if
>> >> the device is enabled, which also inhibits the spurious error messages.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >> ---
>> >> drivers/iommu/of_iommu.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> >> index 2683e9fc0dcf..2dd1206e6c0d 100644
>> >> --- a/drivers/iommu/of_iommu.c
>> >> +++ b/drivers/iommu/of_iommu.c
>> >> @@ -183,7 +183,7 @@ static int __init of_iommu_init(void)
>> >> for_each_matching_node_and_match(np, matches, &match) {
>> >> const of_iommu_init_fn init_fn = match->data;
>> >>
>> >> - if (init_fn(np))
>> >> + if (of_device_is_available(np) && init_fn(np))
>> >> pr_err("Failed to initialise IOMMU %s\n",
>> >> of_node_full_name(np));
>> >> }
>> >
>> > Is there a definition of what status = "disabled" is supposed to mean for an
>> > IOMMU? For example, that could mean that the firmware has pre-programmed the
>> > SMMU with particular translations or memory attributes (a bit like the
>> > CCA=1, CPM=1, DACS=0 case in ACPI IORT), or even disabled DMA traffic
>> > altogether.
>> >
>> > So I think we'd need an update to the generic IOMMU binding text to say
>> > exactly what the semantics are supposed to be here.
>> >
>>
>> I agree that it might make sense to describe the behavior of the IOMMU
>> when it is left in the state we found it in. But that is not the same
>> as status=disabled.
>>
>> The DTS subtree contains loads and loads of boilerplate
>> configurations, where only some pieces are enabled in the final image
>> by setting status=okay. So a node that has status 'disabled' should be
>> treated as 'not present', not as 'present but can be ignored under
>> assumptions such and such'
>>
>> In other words, I think we are talking about two different issues here.
>
> I'm not so sure... if we have a master device that has an iommus= property
> pointing to an IOMMU with status="disabled", I really don't know whether we
> should:
>
> 1. Assume the master can do DMA with a 1:1 mapping of memory and no
> changes to memory attributes
>
> 2. Assume the master can do DMA with a 1:1 mapping of memory, but
> potentially with changes to the attributes
>
> 3. Assume the master can do DMA, but with some pre-existing translation
> (what?)
>
> 4. Assume the master can't do DMA
>
> and I also don't know whether the "dma-coherent" property remains valid.
>
Ah yes. Good point.
So indeed, there should be some IOMMU specific status property that
can convey all of the above, or 1. and 4. at the minimum
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Chris Brandt @ 2017-04-28 13:18 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75Vcp_eMWrjZRX-x3=Tt3JRXcL_wWG43MymF=oyLLP4EJwg@mail.gmail.com>
On Friday, April 28, 2017, Andy Shevchenko wrote:
> > In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control
> Logical Diagram (but that wasn't obvious to me at first).
>
> Please, post a link to it or copy essential parts.
This board the RZ/A1 GENMAI board.
https://www.renesas.com/en-us/products/software-tools/boards-and-kits/evaluation-demo-solution-boards/genmai-cpu-board-rtk772100bc00000br.html
The schematic is included in the "User's manual"
https://www.renesas.com/en-us/doc/products/tool/doc/003/r20ut2596ej_r7s72100evum.pdf
The RZ/A1H Hardware manual is here:
https://www.renesas.com/en-us/document/hw-manual?hwLayerShowFlg=true&prdLayerId=186374&layerName=RZ%252FA1H&coronrService=document-prd-search&hwDocUrl=%2Fen-us%2Fdoc%2Fproducts%2Fmpumcu%2Fdoc%2Frz%2Fr01uh0403ej0300_rz_a1h.pdf&hashKey=54f335753742b5add524d4725b7242e6
Chapter 54 is the port/pin controller.
"54.18 Port Control Logical Diagram" is the diagram I was talking about. Note that is says "Note: This figure shows the logic for reference, not the circuit."
"54.3.13 Port Bidirection Control Register (PBDCn)" is the magic register needed to get some pins to work.
> I'm quite skeptical that cheap hardware can implement something more
> costable than simplest open-source / open-drain + bias
I don't think this is an open-source / open-drain + bias issue. It's a "the internal signal paths are not getting hooked up correctly" issue.
Regardless, on this part, we needed a way to flag that some pins when put in some function modes needed 'an extra register setting'. At first we tried to sneak that info in with a simple #define in the pin/pinmux DT node properties. But, Linus didn't want it there so we had to make up a new generic property called "bi-directional".
What is your end goal here? Get "bi-directional" changed to something else?
Chris
^ permalink raw reply
* Re: [PATCH] drivers/of_iommu: ignore SMMU DT nodes with status 'disabled'
From: Will Deacon @ 2017-04-28 13:17 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
joro-zLv9SwRftAIdnm+yROfE0A, Robin Murphy,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
In-Reply-To: <CAKv+Gu_G9fw0kwSetXmGjomc8Y_nu95O=rEVzgfafNRs0dtgvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Apr 28, 2017 at 02:14:49PM +0100, Ard Biesheuvel wrote:
> On 28 April 2017 at 14:11, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> > Hi Ard,
> >
> > [+ devicetree@]
> >
> > On Fri, Apr 14, 2017 at 01:43:15PM +0100, Ard Biesheuvel wrote:
> >> DT nodes may have a status property, and if they do, such nodes should
> >> only be considered present if the status property is set to 'okay'.
> >>
> >> Currently, we call the init function of IOMMUs described by the device
> >> tree without taking this into account, which may result in the output
> >> below on systems where some SMMUs may be legally disabled.
> >>
> >> Failed to initialise IOMMU /smb/smmu@e0200000
> >> Failed to initialise IOMMU /smb/smmu@e0c00000
> >> arm-smmu e0a00000.smmu: probing hardware configuration...
> >> arm-smmu e0a00000.smmu: SMMUv1 with:
> >> arm-smmu e0a00000.smmu: stage 2 translation
> >> arm-smmu e0a00000.smmu: coherent table walk
> >> arm-smmu e0a00000.smmu: stream matching with 32 register groups, mask 0x7fff
> >> arm-smmu e0a00000.smmu: 8 context banks (8 stage-2 only)
> >> arm-smmu e0a00000.smmu: Supported page sizes: 0x60211000
> >> arm-smmu e0a00000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
> >> Failed to initialise IOMMU /smb/smmu@e0600000
> >> Failed to initialise IOMMU /smb/smmu@e0800000
> >>
> >> Since this is not an error condition, only call the init function if
> >> the device is enabled, which also inhibits the spurious error messages.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> drivers/iommu/of_iommu.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> >> index 2683e9fc0dcf..2dd1206e6c0d 100644
> >> --- a/drivers/iommu/of_iommu.c
> >> +++ b/drivers/iommu/of_iommu.c
> >> @@ -183,7 +183,7 @@ static int __init of_iommu_init(void)
> >> for_each_matching_node_and_match(np, matches, &match) {
> >> const of_iommu_init_fn init_fn = match->data;
> >>
> >> - if (init_fn(np))
> >> + if (of_device_is_available(np) && init_fn(np))
> >> pr_err("Failed to initialise IOMMU %s\n",
> >> of_node_full_name(np));
> >> }
> >
> > Is there a definition of what status = "disabled" is supposed to mean for an
> > IOMMU? For example, that could mean that the firmware has pre-programmed the
> > SMMU with particular translations or memory attributes (a bit like the
> > CCA=1, CPM=1, DACS=0 case in ACPI IORT), or even disabled DMA traffic
> > altogether.
> >
> > So I think we'd need an update to the generic IOMMU binding text to say
> > exactly what the semantics are supposed to be here.
> >
>
> I agree that it might make sense to describe the behavior of the IOMMU
> when it is left in the state we found it in. But that is not the same
> as status=disabled.
>
> The DTS subtree contains loads and loads of boilerplate
> configurations, where only some pieces are enabled in the final image
> by setting status=okay. So a node that has status 'disabled' should be
> treated as 'not present', not as 'present but can be ignored under
> assumptions such and such'
>
> In other words, I think we are talking about two different issues here.
I'm not so sure... if we have a master device that has an iommus= property
pointing to an IOMMU with status="disabled", I really don't know whether we
should:
1. Assume the master can do DMA with a 1:1 mapping of memory and no
changes to memory attributes
2. Assume the master can do DMA with a 1:1 mapping of memory, but
potentially with changes to the attributes
3. Assume the master can do DMA, but with some pre-existing translation
(what?)
4. Assume the master can't do DMA
and I also don't know whether the "dma-coherent" property remains valid.
Will
--
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] drivers/of_iommu: ignore SMMU DT nodes with status 'disabled'
From: Ard Biesheuvel @ 2017-04-28 13:14 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170428131133.GJ13675-5wv7dgnIgG8@public.gmane.org>
On 28 April 2017 at 14:11, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Ard,
>
> [+ devicetree@]
>
> On Fri, Apr 14, 2017 at 01:43:15PM +0100, Ard Biesheuvel wrote:
>> DT nodes may have a status property, and if they do, such nodes should
>> only be considered present if the status property is set to 'okay'.
>>
>> Currently, we call the init function of IOMMUs described by the device
>> tree without taking this into account, which may result in the output
>> below on systems where some SMMUs may be legally disabled.
>>
>> Failed to initialise IOMMU /smb/smmu@e0200000
>> Failed to initialise IOMMU /smb/smmu@e0c00000
>> arm-smmu e0a00000.smmu: probing hardware configuration...
>> arm-smmu e0a00000.smmu: SMMUv1 with:
>> arm-smmu e0a00000.smmu: stage 2 translation
>> arm-smmu e0a00000.smmu: coherent table walk
>> arm-smmu e0a00000.smmu: stream matching with 32 register groups, mask 0x7fff
>> arm-smmu e0a00000.smmu: 8 context banks (8 stage-2 only)
>> arm-smmu e0a00000.smmu: Supported page sizes: 0x60211000
>> arm-smmu e0a00000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
>> Failed to initialise IOMMU /smb/smmu@e0600000
>> Failed to initialise IOMMU /smb/smmu@e0800000
>>
>> Since this is not an error condition, only call the init function if
>> the device is enabled, which also inhibits the spurious error messages.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> drivers/iommu/of_iommu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 2683e9fc0dcf..2dd1206e6c0d 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -183,7 +183,7 @@ static int __init of_iommu_init(void)
>> for_each_matching_node_and_match(np, matches, &match) {
>> const of_iommu_init_fn init_fn = match->data;
>>
>> - if (init_fn(np))
>> + if (of_device_is_available(np) && init_fn(np))
>> pr_err("Failed to initialise IOMMU %s\n",
>> of_node_full_name(np));
>> }
>
> Is there a definition of what status = "disabled" is supposed to mean for an
> IOMMU? For example, that could mean that the firmware has pre-programmed the
> SMMU with particular translations or memory attributes (a bit like the
> CCA=1, CPM=1, DACS=0 case in ACPI IORT), or even disabled DMA traffic
> altogether.
>
> So I think we'd need an update to the generic IOMMU binding text to say
> exactly what the semantics are supposed to be here.
>
I agree that it might make sense to describe the behavior of the IOMMU
when it is left in the state we found it in. But that is not the same
as status=disabled.
The DTS subtree contains loads and loads of boilerplate
configurations, where only some pieces are enabled in the final image
by setting status=okay. So a node that has status 'disabled' should be
treated as 'not present', not as 'present but can be ignored under
assumptions such and such'
In other words, I think we are talking about two different issues here.
^ permalink raw reply
* Re: [PATCH] drivers/of_iommu: ignore SMMU DT nodes with status 'disabled'
From: Will Deacon @ 2017-04-28 13:11 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
joro-zLv9SwRftAIdnm+yROfE0A, robin.murphy-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170414124315.2401-1-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Ard,
[+ devicetree@]
On Fri, Apr 14, 2017 at 01:43:15PM +0100, Ard Biesheuvel wrote:
> DT nodes may have a status property, and if they do, such nodes should
> only be considered present if the status property is set to 'okay'.
>
> Currently, we call the init function of IOMMUs described by the device
> tree without taking this into account, which may result in the output
> below on systems where some SMMUs may be legally disabled.
>
> Failed to initialise IOMMU /smb/smmu@e0200000
> Failed to initialise IOMMU /smb/smmu@e0c00000
> arm-smmu e0a00000.smmu: probing hardware configuration...
> arm-smmu e0a00000.smmu: SMMUv1 with:
> arm-smmu e0a00000.smmu: stage 2 translation
> arm-smmu e0a00000.smmu: coherent table walk
> arm-smmu e0a00000.smmu: stream matching with 32 register groups, mask 0x7fff
> arm-smmu e0a00000.smmu: 8 context banks (8 stage-2 only)
> arm-smmu e0a00000.smmu: Supported page sizes: 0x60211000
> arm-smmu e0a00000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
> Failed to initialise IOMMU /smb/smmu@e0600000
> Failed to initialise IOMMU /smb/smmu@e0800000
>
> Since this is not an error condition, only call the init function if
> the device is enabled, which also inhibits the spurious error messages.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/iommu/of_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2683e9fc0dcf..2dd1206e6c0d 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -183,7 +183,7 @@ static int __init of_iommu_init(void)
> for_each_matching_node_and_match(np, matches, &match) {
> const of_iommu_init_fn init_fn = match->data;
>
> - if (init_fn(np))
> + if (of_device_is_available(np) && init_fn(np))
> pr_err("Failed to initialise IOMMU %s\n",
> of_node_full_name(np));
> }
Is there a definition of what status = "disabled" is supposed to mean for an
IOMMU? For example, that could mean that the firmware has pre-programmed the
SMMU with particular translations or memory attributes (a bit like the
CCA=1, CPM=1, DACS=0 case in ACPI IORT), or even disabled DMA traffic
altogether.
So I think we'd need an update to the generic IOMMU binding text to say
exactly what the semantics are supposed to be here.
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] clk: Provide dummy of_clk_get_from_provider() for compile-testing
From: Geert Uytterhoeven @ 2017-04-28 13:08 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Russell King, Rob Herring,
Mark Rutland, John Crispin, Ralf Baechle
Cc: linux-clk, devicetree, linux-mips, linux-kernel,
Geert Uytterhoeven
When CONFIG_ON=n, dummies are provided for of_clk_get() and
of_clk_get_by_name(), but not for of_clk_get_from_provider().
Provide a dummy for the latter, to improve the ability to do
compile-testing. This requires removing the existing dummy in the
Lantiq clock code.
Fixes: 766e6a4ec602d0c1 ("clk: add DT clock binding support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Remove conflicting dummy in Lantiq clock code (reported by 0day).
---
arch/mips/lantiq/clk.c | 5 -----
include/linux/clk.h | 4 ++++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/mips/lantiq/clk.c b/arch/mips/lantiq/clk.c
index 149f0513c4f5d0d4..a263d1b751ffe48d 100644
--- a/arch/mips/lantiq/clk.c
+++ b/arch/mips/lantiq/clk.c
@@ -160,11 +160,6 @@ void clk_deactivate(struct clk *clk)
}
EXPORT_SYMBOL(clk_deactivate);
-struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
-{
- return NULL;
-}
-
static inline u32 get_counter_resolution(void)
{
u32 res;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index e9d36b3e49de5b1b..3ed97abb5cbb7f94 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -539,6 +539,10 @@ static inline struct clk *of_clk_get_by_name(struct device_node *np,
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+ return ERR_PTR(-ENOENT);
+}
#endif
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Eduardo Valentin @ 2017-04-28 13:07 UTC (permalink / raw)
To: Jon Mason
Cc: Florian Fainelli, Zhang Rui, Rob Herring, Mark Rutland,
BCM Kernel Feedback, linux-arm-kernel, open list, linux-pm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAC3K-4pr4LY-9unHNxMDN9YmCYHKekUo66813OUdiKkQH4QzVw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3863 bytes --]
On Thu, Apr 27, 2017 at 01:42:25PM -0400, Jon Mason wrote:
> On Thu, Apr 27, 2017 at 12:37 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> > Hey Jason,
>
> It's Jon :)
Apologies. I think I either read too fast, or my fingers were faster
than my brain. Sorry.
>
> >
> > On Tue, Apr 25, 2017 at 04:49:10PM -0400, Jon Mason wrote:
> >> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
> >> the ns-thermal driver to be selected via menuconfig. Also, change the
> >> ns-thermal driver to work on any iProc based SoC. Finally, tweak the
> >> Kconfig description to mention support for NSP and make the default on
> >> for iProc based platforms.
> >
> >
> > Thanks for the patch, but..
> >>
> >> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >> ---
> >> arch/arm/mach-bcm/Kconfig | 2 ++
> >> drivers/thermal/broadcom/Kconfig | 9 +++++----
> >> 2 files changed, 7 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> >> index a0e66d8..da2bfeb 100644
> >> --- a/arch/arm/mach-bcm/Kconfig
> >> +++ b/arch/arm/mach-bcm/Kconfig
> >> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
> >> select GPIOLIB
> >> select ARM_AMBA
> >> select PINCTRL
> >> + select THERMAL
> >> + select THERMAL_OF
> >> help
> >> This enables support for systems based on Broadcom IPROC architected SoCs.
> >> The IPROC complex contains one or more ARM CPUs along with common
> >
> > It would be better if this is split and sent through your arch tree, to
> > avoid conflicts. I could also pick it if you get an ack from one of your
> > maintainers. Still, first option is preferable.
>
> Sure, I'll be happy to split this off. I should've thought to split
> it up before sending. Thanks for the suggestion.
Cool!
>
> >
> >> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> >> index f0dea8a..26d706c 100644
> >> --- a/drivers/thermal/broadcom/Kconfig
> >> +++ b/drivers/thermal/broadcom/Kconfig
> >> @@ -1,8 +1,9 @@
> >> config BCM_NS_THERMAL
> >> tristate "Northstar thermal driver"
> >> depends on ARCH_BCM_IPROC || COMPILE_TEST
> >> + default ARCH_BCM_IPROC
> >
> > Not sure if this is really what you wanted. Based on your commit log
> > message, you meant the following, perhaps?
> >
> > + default y if ARCH_BCM_IPROC
>
> IIUC, my original default works, as we have used it frequently in
> other places in the kernel.
> grep -rI "default ARCH_BCM_IPROC" * | wc -l
> 15
Yeah... Are you sure they are all correct?
>
> However, if the above is preferred (or the other 15 massively broken),
> I'll be happy to do it that way.
Your construction is syntactically correct. Maybe might still work (did
not check myself) for the purpose you describe, but the construction
mentioned in Documentation/kbuild/kconfig-language.txt is:
+ default y if BAR
So, please fix it.
>
>
> >> help
> >> - Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
> >> - BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
> >> - with a thermal sensor that allows checking CPU temperature. This
> >> - driver provides support for it.
> >> + Support for the Northstar and Northstar Plus family of SoCs (e.g.
> >> + BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
> >
> > Did we look BCM47094 somehow on this patch?
>
> Naa, just trying to be more concise, while adding the NSP products to
> the list.. BCM47094 is a type of BCM4709. So, it is still there :)
>
> >
> >> + Management Unit) block with a thermal sensor that allows checking CPU
> >> + temperature.
> >> --
> >> 2.7.4
> >>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: renesas: Extract common ULCB board support
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas@glider.be>
The Renesas ULCB development board can be equipped with either an R-Car
H3 or M3-W SiP, which are pin-compatible. Both boards use different
DTBs.
Reduce duplication by extracting common ULCB board support into its own
.dtsi file. References to SoC-specific clocks are handled through cpp
definitions. Sort device nodes while at it.
For H3ULCB, there are no functional changes.
For M3ULCB, the following new devices are now described in DT:
- External audio, CAN, and PCIe clocks,
- CS2000 clock generator,
- AK4613 Audio Codec.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Drop RFC state,
- Rebased.
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 341 +--------------------
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 201 +-----------
.../dts/renesas/{r8a7795-h3ulcb.dts => ulcb.dtsi} | 264 ++++++++--------
3 files changed, 126 insertions(+), 680 deletions(-)
copy arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => ulcb.dtsi} (91%)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 3574965e074718d8..a1fbf0ab8ad8e425 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -9,24 +9,16 @@
* kind, whether express or implied.
*/
+#define CPG_AUDIO_CLK_I R8A7795_CLK_S0D4
+
/dts-v1/;
#include "r8a7795.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
+#include "ulcb.dtsi"
/ {
model = "Renesas H3ULCB board based on r8a7795";
compatible = "renesas,h3ulcb", "renesas,r8a7795";
- aliases {
- serial0 = &scif2;
- ethernet0 = &avb;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
memory@48000000 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -47,331 +39,4 @@
device_type = "memory";
reg = <0x7 0x00000000 0x0 0x40000000>;
};
-
- leds {
- compatible = "gpio-leds";
-
- led5 {
- gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
- };
- led6 {
- gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
- };
- };
-
- keyboard {
- compatible = "gpio-keys";
-
- key-1 {
- linux,code = <KEY_1>;
- label = "SW3";
- wakeup-source;
- debounce-interval = <20>;
- gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
- };
- };
-
- x12_clk: x12 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <24576000>;
- };
-
- reg_1p8v: regulator0 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- reg_3p3v: regulator1 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vcc_sdhi0: regulator-vcc-sdhi0 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI0 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi0: regulator-vccq-sdhi0 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI0 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-
- audio_clkout: audio-clkout {
- /*
- * This is same as <&rcar_sound 0>
- * but needed to avoid cs2000/rcar_sound probe dead-lock
- */
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <11289600>;
- };
-
- rsnd_ak4613: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcpu>;
- simple-audio-card,frame-master = <&sndcpu>;
-
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
-
- sndcodec: simple-audio-card,codec {
- sound-dai = <&ak4613>;
- };
- };
-};
-
-&extal_clk {
- clock-frequency = <16666666>;
-};
-
-&extalr_clk {
- clock-frequency = <32768>;
-};
-
-&pfc {
- pinctrl-0 = <&scif_clk_pins>;
- pinctrl-names = "default";
-
- scif2_pins: scif2 {
- groups = "scif2_data_a";
- function = "scif2";
- };
-
- scif_clk_pins: scif_clk {
- groups = "scif_clk_a";
- function = "scif_clk";
- };
-
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
- };
-
- avb_pins: avb {
- groups = "avb_mdc";
- function = "avb";
- };
-
- sdhi0_pins: sd0 {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <3300>;
- };
-
- sdhi0_pins_uhs: sd0_uhs {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <1800>;
- };
-
- sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <1800>;
- };
-
- sound_pins: sound {
- groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
- function = "ssi";
- };
-
- sound_clk_pins: sound-clk {
- groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
- "audio_clkout_a", "audio_clkout3_a";
- function = "audio_clk";
- };
-
- usb1_pins: usb1 {
- groups = "usb1";
- function = "usb1";
- };
-};
-
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-
- clock-frequency = <100000>;
-
- ak4613: codec@10 {
- compatible = "asahi-kasei,ak4613";
- #sound-dai-cells = <0>;
- reg = <0x10>;
- clocks = <&rcar_sound 3>;
-
- asahi-kasei,in1-single-end;
- asahi-kasei,in2-single-end;
- asahi-kasei,out1-single-end;
- asahi-kasei,out2-single-end;
- asahi-kasei,out3-single-end;
- asahi-kasei,out4-single-end;
- asahi-kasei,out5-single-end;
- asahi-kasei,out6-single-end;
- };
-
- cs2000: clk-multiplier@4f {
- #clock-cells = <0>;
- compatible = "cirrus,cs2000-cp";
- reg = <0x4f>;
- clocks = <&audio_clkout>, <&x12_clk>;
- clock-names = "clk_in", "ref_clk";
-
- assigned-clocks = <&cs2000>;
- assigned-clock-rates = <24576000>; /* 1/1 divide */
- };
-};
-
-&rcar_sound {
- pinctrl-0 = <&sound_pins &sound_clk_pins>;
- pinctrl-names = "default";
-
- /* Single DAI */
- #sound-dai-cells = <0>;
-
- /* audio_clkout0/1/2/3 */
- #clock-cells = <1>;
- clock-frequency = <11289600>;
-
- status = "okay";
-
- /* update <audio_clk_b> to <cs2000> */
- clocks = <&cpg CPG_MOD 1005>,
- <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
- <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
- <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
- <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
- <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
- <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
- <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
- <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
- <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
- <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
- <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
- <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
- <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
- <&audio_clk_a>, <&cs2000>,
- <&audio_clk_c>,
- <&cpg CPG_CORE R8A7795_CLK_S0D4>;
-
- rcar_sound,dai {
- dai0 {
- playback = <&ssi0 &src0 &dvc0>;
- capture = <&ssi1 &src1 &dvc1>;
- };
- };
-};
-
-&sdhi0 {
- pinctrl-0 = <&sdhi0_pins>;
- pinctrl-1 = <&sdhi0_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi0>;
- vqmmc-supply = <&vccq_sdhi0>;
- cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&sdhi2 {
- /* used for on-board 8bit eMMC */
- pinctrl-0 = <&sdhi2_pins>;
- pinctrl-1 = <&sdhi2_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_1p8v>;
- bus-width = <8>;
- mmc-hs200-1_8v;
- non-removable;
- status = "okay";
-};
-
-&ssi1 {
- shared-pin;
-};
-
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
-};
-
-&audio_clk_a {
- clock-frequency = <22579200>;
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-&usb2_phy1 {
- pinctrl-0 = <&usb1_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&ehci1 {
- status = "okay";
-};
-
-&ohci1 {
- status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 440d93e8388df3ed..38b58b7fca4bf0e9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -9,24 +9,16 @@
* kind, whether express or implied.
*/
+#define CPG_AUDIO_CLK_I R8A7796_CLK_S0D4
+
/dts-v1/;
#include "r8a7796.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
+#include "ulcb.dtsi"
/ {
model = "Renesas M3ULCB board based on r8a7796";
compatible = "renesas,m3ulcb", "renesas,r8a7796";
- aliases {
- serial0 = &scif2;
- ethernet0 = &avb;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
memory@48000000 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -37,191 +29,4 @@
device_type = "memory";
reg = <0x6 0x00000000 0x0 0x40000000>;
};
-
- leds {
- compatible = "gpio-leds";
-
- led5 {
- gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
- };
- led6 {
- gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
- };
- };
-
- keyboard {
- compatible = "gpio-keys";
-
- key-1 {
- linux,code = <KEY_1>;
- label = "SW3";
- wakeup-source;
- debounce-interval = <20>;
- gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
- };
- };
-
- reg_1p8v: regulator0 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- reg_3p3v: regulator1 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vcc_sdhi0: regulator-vcc-sdhi0 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI0 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi0: regulator-vccq-sdhi0 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI0 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-};
-
-&extal_clk {
- clock-frequency = <16666666>;
-};
-
-&extalr_clk {
- clock-frequency = <32768>;
-};
-
-&pfc {
- pinctrl-0 = <&scif_clk_pins>;
- pinctrl-names = "default";
-
- avb_pins: avb {
- groups = "avb_mdc";
- function = "avb";
- };
-
- scif2_pins: scif2 {
- groups = "scif2_data_a";
- function = "scif2";
- };
-
- scif_clk_pins: scif_clk {
- groups = "scif_clk_a";
- function = "scif_clk";
- };
-
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
- };
-
- sdhi0_pins: sd0 {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <3300>;
- };
-
- sdhi0_pins_uhs: sd0_uhs {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <1800>;
- };
-
- sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <1800>;
- };
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-&sdhi0 {
- pinctrl-0 = <&sdhi0_pins>;
- pinctrl-1 = <&sdhi0_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi0>;
- vqmmc-supply = <&vccq_sdhi0>;
- cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&sdhi2 {
- /* used for on-board 8bit eMMC */
- pinctrl-0 = <&sdhi2_pins>;
- pinctrl-1 = <&sdhi2_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_1p8v>;
- bus-width = <8>;
- mmc-hs200-1_8v;
- non-removable;
- status = "okay";
-};
-
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/ulcb.dtsi
similarity index 91%
copy from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
copy to arch/arm64/boot/dts/renesas/ulcb.dtsi
index 3574965e074718d8..2bc7ceb2efa45598 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for the H3ULCB (R-Car Starter Kit Premier) board
+ * Device Tree Source for the R-Car Gen3 ULCB board
*
* Copyright (C) 2016 Renesas Electronics Corp.
* Copyright (C) 2016 Cogent Embedded, Inc.
@@ -9,14 +9,11 @@
* kind, whether express or implied.
*/
-/dts-v1/;
-#include "r8a7795.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
- model = "Renesas H3ULCB board based on r8a7795";
- compatible = "renesas,h3ulcb", "renesas,r8a7795";
+ model = "Renesas R-Car Gen3 ULCB board";
aliases {
serial0 = &scif2;
@@ -27,36 +24,14 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x38000000>;
- };
-
- memory@500000000 {
- device_type = "memory";
- reg = <0x5 0x00000000 0x0 0x40000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x40000000>;
- };
-
- memory@700000000 {
- device_type = "memory";
- reg = <0x7 0x00000000 0x0 0x40000000>;
- };
-
- leds {
- compatible = "gpio-leds";
-
- led5 {
- gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
- };
- led6 {
- gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
- };
+ audio_clkout: audio-clkout {
+ /*
+ * This is same as <&rcar_sound 0>
+ * but needed to avoid cs2000/rcar_sound probe dead-lock
+ */
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <11289600>;
};
keyboard {
@@ -71,10 +46,15 @@
};
};
- x12_clk: x12 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <24576000>;
+ leds {
+ compatible = "gpio-leds";
+
+ led5 {
+ gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+ led6 {
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+ };
};
reg_1p8v: regulator0 {
@@ -95,6 +75,22 @@
regulator-always-on;
};
+ rsnd_ak4613: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&sndcpu>;
+ simple-audio-card,frame-master = <&sndcpu>;
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ };
+
+ sndcodec: simple-audio-card,codec {
+ sound-dai = <&ak4613>;
+ };
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -119,33 +115,36 @@
1800000 0>;
};
- audio_clkout: audio-clkout {
- /*
- * This is same as <&rcar_sound 0>
- * but needed to avoid cs2000/rcar_sound probe dead-lock
- */
+ x12_clk: x12 {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <11289600>;
+ clock-frequency = <24576000>;
};
+};
- rsnd_ak4613: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcpu>;
- simple-audio-card,frame-master = <&sndcpu>;
+&audio_clk_a {
+ clock-frequency = <22579200>;
+};
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ status = "okay";
- sndcodec: simple-audio-card,codec {
- sound-dai = <&ak4613>;
- };
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1500>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
};
};
+&ehci1 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -154,10 +153,60 @@
clock-frequency = <32768>;
};
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ clock-frequency = <100000>;
+
+ ak4613: codec@10 {
+ compatible = "asahi-kasei,ak4613";
+ #sound-dai-cells = <0>;
+ reg = <0x10>;
+ clocks = <&rcar_sound 3>;
+
+ asahi-kasei,in1-single-end;
+ asahi-kasei,in2-single-end;
+ asahi-kasei,out1-single-end;
+ asahi-kasei,out2-single-end;
+ asahi-kasei,out3-single-end;
+ asahi-kasei,out4-single-end;
+ asahi-kasei,out5-single-end;
+ asahi-kasei,out6-single-end;
+ };
+
+ cs2000: clk-multiplier@4f {
+ #clock-cells = <0>;
+ compatible = "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&audio_clkout>, <&x12_clk>;
+ clock-names = "clk_in", "ref_clk";
+
+ assigned-clocks = <&cs2000>;
+ assigned-clock-rates = <24576000>; /* 1/1 divide */
+ };
+};
+
+&ohci1 {
+ status = "okay";
+};
+
&pfc {
pinctrl-0 = <&scif_clk_pins>;
pinctrl-names = "default";
+ avb_pins: avb {
+ groups = "avb_mdc";
+ function = "avb";
+ };
+
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -168,16 +217,6 @@
function = "scif_clk";
};
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
- };
-
- avb_pins: avb {
- groups = "avb_mdc";
- function = "avb";
- };
-
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -219,53 +258,6 @@
};
};
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-
- clock-frequency = <100000>;
-
- ak4613: codec@10 {
- compatible = "asahi-kasei,ak4613";
- #sound-dai-cells = <0>;
- reg = <0x10>;
- clocks = <&rcar_sound 3>;
-
- asahi-kasei,in1-single-end;
- asahi-kasei,in2-single-end;
- asahi-kasei,out1-single-end;
- asahi-kasei,out2-single-end;
- asahi-kasei,out3-single-end;
- asahi-kasei,out4-single-end;
- asahi-kasei,out5-single-end;
- asahi-kasei,out6-single-end;
- };
-
- cs2000: clk-multiplier@4f {
- #clock-cells = <0>;
- compatible = "cirrus,cs2000-cp";
- reg = <0x4f>;
- clocks = <&audio_clkout>, <&x12_clk>;
- clock-names = "clk_in", "ref_clk";
-
- assigned-clocks = <&cs2000>;
- assigned-clock-rates = <24576000>; /* 1/1 divide */
- };
-};
-
&rcar_sound {
pinctrl-0 = <&sound_pins &sound_clk_pins>;
pinctrl-names = "default";
@@ -296,7 +288,7 @@
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
- <&cpg CPG_CORE R8A7795_CLK_S0D4>;
+ <&cpg CPG_CORE CPG_AUDIO_CLK_I>;
rcar_sound,dai {
dai0 {
@@ -306,6 +298,17 @@
};
};
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+};
+
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-1 = <&sdhi0_pins_uhs>;
@@ -337,30 +340,6 @@
shared-pin;
};
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
-};
-
-&audio_clk_a {
- clock-frequency = <22579200>;
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
&usb2_phy1 {
pinctrl-0 = <&usb1_pins>;
pinctrl-names = "default";
@@ -368,10 +347,7 @@
status = "okay";
};
-&ehci1 {
- status = "okay";
-};
-
-&ohci1 {
+&wdt0 {
+ timeout-sec = <60>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: renesas: Extract common Salvator-X board support
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas@glider.be>
The Renesas Salvator-X development board can be equipped with either an
R-Car H3 or M3-W SiP, which are pin-compatible. Both boards use
different DTBs.
Reduce duplication by extracting common Salvator-X board support into
its own .dtsi file. References to SoC-specific clocks are handled
through cpp definitions. Sort device nodes while at it.
For boards with an R-Car H3 SiP, there are no functional changes.
For boards with an R-Car M3-W SiP, the following new devices are now
described in DT:
- External audio, CAN, and PCIe clocks,
- USB Vbus regulator,
- CS2000 clock generator,
- AK4613 Audio Codec,
- VGA.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Drop RFC state,
- Remove forgotten amixer help from r8a7795-salvator-x.dts,
- Rebased.
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 543 +--------------------
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 259 +---------
.../{r8a7795-salvator-x.dts => salvator-x.dtsi} | 393 +++++++--------
3 files changed, 182 insertions(+), 1013 deletions(-)
copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => salvator-x.dtsi} (91%)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index ff68bac4cd7ed2f5..52fce67df3413f1f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -8,48 +8,16 @@
* kind, whether express or implied.
*/
-/*
- * SSI-AK4613
- *
- * This command is required when Playback/Capture
- *
- * amixer set "DVC Out" 100%
- * amixer set "DVC In" 100%
- *
- * You can use Mute
- *
- * amixer set "DVC Out Mute" on
- * amixer set "DVC In Mute" on
- *
- * You can use Volume Ramp
- *
- * amixer set "DVC Out Ramp Up Rate" "0.125 dB/64 steps"
- * amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
- * amixer set "DVC Out Ramp" on
- * aplay xxx.wav &
- * amixer set "DVC Out" 80% // Volume Down
- * amixer set "DVC Out" 100% // Volume Up
- */
+#define CPG_AUDIO_CLK_I R8A7795_CLK_S0D4
/dts-v1/;
#include "r8a7795.dtsi"
-#include <dt-bindings/gpio/gpio.h>
+#include "salvator-x.dtsi"
/ {
model = "Renesas Salvator-X board based on r8a7795";
compatible = "renesas,salvator-x", "renesas,r8a7795";
- aliases {
- serial0 = &scif2;
- serial1 = &scif1;
- ethernet0 = &avb;
- };
-
- chosen {
- bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
- stdout-path = "serial0:115200n8";
- };
-
memory@48000000 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -70,531 +38,30 @@
device_type = "memory";
reg = <0x7 0x00000000 0x0 0x40000000>;
};
-
- x12_clk: x12 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <24576000>;
- };
-
- reg_1p8v: regulator0 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- reg_3p3v: regulator1 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vcc_sdhi0: regulator-vcc-sdhi0 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI0 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi0: regulator-vccq-sdhi0 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI0 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-
- vcc_sdhi3: regulator-vcc-sdhi3 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI3 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio3 15 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi3: regulator-vccq-sdhi3 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI3 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-
- vbus0_usb2: regulator-vbus0-usb2 {
- compatible = "regulator-fixed";
-
- regulator-name = "USB20_VBUS0";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
-
- gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- audio_clkout: audio_clkout {
- /*
- * This is same as <&rcar_sound 0>
- * but needed to avoid cs2000/rcar_sound probe dead-lock
- */
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <11289600>;
- };
-
- rsnd_ak4613: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcpu>;
- simple-audio-card,frame-master = <&sndcpu>;
-
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
-
- sndcodec: simple-audio-card,codec {
- sound-dai = <&ak4613>;
- };
- };
-
- vga-encoder {
- compatible = "adi,adv7123";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- adv7123_in: endpoint {
- remote-endpoint = <&du_out_rgb>;
- };
- };
- port@1 {
- reg = <1>;
- adv7123_out: endpoint {
- remote-endpoint = <&vga_in>;
- };
- };
- };
- };
-
- vga {
- compatible = "vga-connector";
-
- port {
- vga_in: endpoint {
- remote-endpoint = <&adv7123_out>;
- };
- };
- };
};
-&du {
- pinctrl-0 = <&du_pins>;
- pinctrl-names = "default";
+&ehci2 {
status = "okay";
-
- ports {
- port@0 {
- endpoint {
- remote-endpoint = <&adv7123_in>;
- };
- };
- port@3 {
- lvds_connector: endpoint {
- };
- };
- };
-};
-
-&extal_clk {
- clock-frequency = <16666666>;
};
-&extalr_clk {
- clock-frequency = <32768>;
+&ohci2 {
+ status = "okay";
};
&pfc {
- pinctrl-0 = <&scif_clk_pins>;
- pinctrl-names = "default";
-
- scif1_pins: scif1 {
- groups = "scif1_data_a", "scif1_ctrl";
- function = "scif1";
- };
- scif2_pins: scif2 {
- groups = "scif2_data_a";
- function = "scif2";
- };
- scif_clk_pins: scif_clk {
- groups = "scif_clk_a";
- function = "scif_clk";
- };
-
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
- };
-
- avb_pins: avb {
- mux {
- groups = "avb_link", "avb_phy_int", "avb_mdc",
- "avb_mii";
- function = "avb";
- };
-
- pins_mdc {
- groups = "avb_mdc";
- drive-strength = <24>;
- };
-
- pins_mii_tx {
- pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
- "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
- drive-strength = <12>;
- };
- };
-
- du_pins: du {
- groups = "du_rgb888", "du_sync", "du_oddf", "du_clk_out_0";
- function = "du";
- };
-
- sdhi0_pins: sd0 {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <3300>;
- };
-
- sdhi0_pins_uhs: sd0_uhs {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <1800>;
- };
-
- sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <1800>;
- };
-
- sdhi3_pins: sd3 {
- groups = "sdhi3_data4", "sdhi3_ctrl";
- function = "sdhi3";
- power-source = <3300>;
- };
-
- sdhi3_pins_uhs: sd3_uhs {
- groups = "sdhi3_data4", "sdhi3_ctrl";
- function = "sdhi3";
- power-source = <1800>;
- };
-
- sound_pins: sound {
- groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
- function = "ssi";
- };
-
- sound_clk_pins: sound_clk {
- groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
- "audio_clkout_a", "audio_clkout3_a";
- function = "audio_clk";
- };
-
- usb0_pins: usb0 {
- groups = "usb0";
- function = "usb0";
- };
-
- usb1_pins: usb1 {
- mux {
- groups = "usb1";
- function = "usb1";
- };
-
- ovc {
- pins = "GP_6_27";
- bias-pull-up;
- };
-
- pwen {
- pins = "GP_6_26";
- bias-pull-down;
- };
- };
-
usb2_pins: usb2 {
groups = "usb2";
function = "usb2";
};
};
-&scif1 {
- pinctrl-0 = <&scif1_pins>;
- pinctrl-names = "default";
-
- uart-has-rtscts;
- status = "okay";
-};
-
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-
- clock-frequency = <100000>;
-
- ak4613: codec@10 {
- compatible = "asahi-kasei,ak4613";
- #sound-dai-cells = <0>;
- reg = <0x10>;
- clocks = <&rcar_sound 3>;
-
- asahi-kasei,in1-single-end;
- asahi-kasei,in2-single-end;
- asahi-kasei,out1-single-end;
- asahi-kasei,out2-single-end;
- asahi-kasei,out3-single-end;
- asahi-kasei,out4-single-end;
- asahi-kasei,out5-single-end;
- asahi-kasei,out6-single-end;
- };
-
- cs2000: clk_multiplier@4f {
- #clock-cells = <0>;
- compatible = "cirrus,cs2000-cp";
- reg = <0x4f>;
- clocks = <&audio_clkout>, <&x12_clk>;
- clock-names = "clk_in", "ref_clk";
-
- assigned-clocks = <&cs2000>;
- assigned-clock-rates = <24576000>; /* 1/1 divide */
- };
-};
-
-&rcar_sound {
- pinctrl-0 = <&sound_pins &sound_clk_pins>;
- pinctrl-names = "default";
-
- /* Single DAI */
- #sound-dai-cells = <0>;
-
- /* audio_clkout0/1/2/3 */
- #clock-cells = <1>;
- clock-frequency = <11289600>;
-
- status = "okay";
-
- /* update <audio_clk_b> to <cs2000> */
- clocks = <&cpg CPG_MOD 1005>,
- <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
- <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
- <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
- <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
- <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
- <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
- <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
- <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
- <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
- <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
- <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
- <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
- <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
- <&audio_clk_a>, <&cs2000>,
- <&audio_clk_c>,
- <&cpg CPG_CORE R8A7795_CLK_S0D4>;
-
- rcar_sound,dai {
- dai0 {
- playback = <&ssi0 &src0 &dvc0>;
- capture = <&ssi1 &src1 &dvc1>;
- };
- };
-};
-
&sata {
status = "okay";
};
-&sdhi0 {
- pinctrl-0 = <&sdhi0_pins>;
- pinctrl-1 = <&sdhi0_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi0>;
- vqmmc-supply = <&vccq_sdhi0>;
- cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&sdhi2 {
- /* used for on-board 8bit eMMC */
- pinctrl-0 = <&sdhi2_pins>;
- pinctrl-1 = <&sdhi2_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_1p8v>;
- bus-width = <8>;
- mmc-hs200-1_8v;
- non-removable;
- status = "okay";
-};
-
-&sdhi3 {
- pinctrl-0 = <&sdhi3_pins>;
- pinctrl-1 = <&sdhi3_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi3>;
- vqmmc-supply = <&vccq_sdhi3>;
- cd-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&ssi1 {
- shared-pin;
-};
-
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
-};
-
-&audio_clk_a {
- clock-frequency = <22579200>;
-};
-
-&i2c_dvfs {
- status = "okay";
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-&xhci0 {
- status = "okay";
-};
-
-&usb2_phy0 {
- pinctrl-0 = <&usb0_pins>;
- pinctrl-names = "default";
-
- vbus-supply = <&vbus0_usb2>;
- status = "okay";
-};
-
-&usb2_phy1 {
- pinctrl-0 = <&usb1_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
&usb2_phy2 {
pinctrl-0 = <&usb2_pins>;
pinctrl-names = "default";
status = "okay";
};
-
-&ehci0 {
- status = "okay";
-};
-
-&ehci1 {
- status = "okay";
-};
-
-&ehci2 {
- status = "okay";
-};
-
-&ohci0 {
- status = "okay";
-};
-
-&ohci1 {
- status = "okay";
-};
-
-&ohci2 {
- status = "okay";
-};
-
-&hsusb {
- status = "okay";
-};
-
-&pcie_bus_clk {
- clock-frequency = <100000000>;
-};
-
-&pciec0 {
- status = "okay";
-};
-
-&pciec1 {
- status = "okay";
-};
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 31f02219ed2fb18a..db4f162d6bdd2c42 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -8,25 +8,16 @@
* kind, whether express or implied.
*/
+#define CPG_AUDIO_CLK_I R8A7796_CLK_S0D4
+
/dts-v1/;
#include "r8a7796.dtsi"
-#include <dt-bindings/gpio/gpio.h>
+#include "salvator-x.dtsi"
/ {
model = "Renesas Salvator-X board based on r8a7796";
compatible = "renesas,salvator-x", "renesas,r8a7796";
- aliases {
- serial0 = &scif2;
- serial1 = &scif1;
- ethernet0 = &avb;
- };
-
- chosen {
- bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
- stdout-path = "serial0:115200n8";
- };
-
memory@48000000 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -37,248 +28,4 @@
device_type = "memory";
reg = <0x6 0x00000000 0x0 0x80000000>;
};
-
- reg_1p8v: regulator0 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- reg_3p3v: regulator1 {
- compatible = "regulator-fixed";
- regulator-name = "fixed-3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- vcc_sdhi0: regulator-vcc-sdhi0 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI0 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi0: regulator-vccq-sdhi0 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI0 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-
- vcc_sdhi3: regulator-vcc-sdhi3 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI3 Vcc";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
-
- gpio = <&gpio3 15 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- vccq_sdhi3: regulator-vccq-sdhi3 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI3 VccQ";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
-
- gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <3300000 1
- 1800000 0>;
- };
-};
-
-&pfc {
- pinctrl-0 = <&scif_clk_pins>;
- pinctrl-names = "default";
-
- avb_pins: avb {
- mux {
- groups = "avb_link", "avb_phy_int", "avb_mdc",
- "avb_mii";
- function = "avb";
- };
-
- pins_mdc {
- groups = "avb_mdc";
- drive-strength = <24>;
- };
-
- pins_mii_tx {
- pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
- "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
- drive-strength = <12>;
- };
- };
-
- scif1_pins: scif1 {
- groups = "scif1_data_a", "scif1_ctrl";
- function = "scif1";
- };
-
- scif2_pins: scif2 {
- groups = "scif2_data_a";
- function = "scif2";
- };
- scif_clk_pins: scif_clk {
- groups = "scif_clk_a";
- function = "scif_clk";
- };
-
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
- };
-
- sdhi0_pins: sd0 {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <3300>;
- };
-
- sdhi0_pins_uhs: sd0_uhs {
- groups = "sdhi0_data4", "sdhi0_ctrl";
- function = "sdhi0";
- power-source = <1800>;
- };
-
- sdhi2_pins: sd2 {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <3300>;
- };
-
- sdhi2_pins_uhs: sd2_uhs {
- groups = "sdhi2_data8", "sdhi2_ctrl";
- function = "sdhi2";
- power-source = <1800>;
- };
-
- sdhi3_pins: sd3 {
- groups = "sdhi3_data4", "sdhi3_ctrl";
- function = "sdhi3";
- power-source = <3300>;
- };
-
- sdhi3_pins_uhs: sd3_uhs {
- groups = "sdhi3_data4", "sdhi3_ctrl";
- function = "sdhi3";
- power-source = <1800>;
- };
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-&extal_clk {
- clock-frequency = <16666666>;
-};
-
-&extalr_clk {
- clock-frequency = <32768>;
-};
-
-&sdhi0 {
- pinctrl-0 = <&sdhi0_pins>;
- pinctrl-1 = <&sdhi0_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi0>;
- vqmmc-supply = <&vccq_sdhi0>;
- cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&sdhi2 {
- /* used for on-board 8bit eMMC */
- pinctrl-0 = <&sdhi2_pins>;
- pinctrl-1 = <&sdhi2_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_1p8v>;
- bus-width = <8>;
- mmc-hs200-1_8v;
- non-removable;
- status = "okay";
-};
-
-&sdhi3 {
- pinctrl-0 = <&sdhi3_pins>;
- pinctrl-1 = <&sdhi3_pins_uhs>;
- pinctrl-names = "default", "state_uhs";
-
- vmmc-supply = <&vcc_sdhi3>;
- vqmmc-supply = <&vccq_sdhi3>;
- cd-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
- bus-width = <4>;
- sd-uhs-sdr50;
- status = "okay";
-};
-
-&scif1 {
- pinctrl-0 = <&scif1_pins>;
- pinctrl-names = "default";
-
- uart-has-rtscts;
- status = "okay";
-};
-
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
-};
-
-&i2c_dvfs {
- status = "okay";
};
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
similarity index 91%
copy from arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
copy to arch/arm64/boot/dts/renesas/salvator-x.dtsi
index ff68bac4cd7ed2f5..47a482f20c9d511f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for the Salvator-X board
*
- * Copyright (C) 2015 Renesas Electronics Corp.
+ * Copyright (C) 2015-2016 Renesas Electronics Corp.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -31,13 +31,11 @@
* amixer set "DVC Out" 100% // Volume Up
*/
-/dts-v1/;
-#include "r8a7795.dtsi"
#include <dt-bindings/gpio/gpio.h>
/ {
- model = "Renesas Salvator-X board based on r8a7795";
- compatible = "renesas,salvator-x", "renesas,r8a7795";
+ model = "Renesas Salvator-X board";
+ compatible = "renesas,salvator-x";
aliases {
serial0 = &scif2;
@@ -50,31 +48,14 @@
stdout-path = "serial0:115200n8";
};
- memory@48000000 {
- device_type = "memory";
- /* first 128MB is reserved for secure area. */
- reg = <0x0 0x48000000 0x0 0x38000000>;
- };
-
- memory@500000000 {
- device_type = "memory";
- reg = <0x5 0x00000000 0x0 0x40000000>;
- };
-
- memory@600000000 {
- device_type = "memory";
- reg = <0x6 0x00000000 0x0 0x40000000>;
- };
-
- memory@700000000 {
- device_type = "memory";
- reg = <0x7 0x00000000 0x0 0x40000000>;
- };
-
- x12_clk: x12 {
+ audio_clkout: audio_clkout {
+ /*
+ * This is same as <&rcar_sound 0>
+ * but needed to avoid cs2000/rcar_sound probe dead-lock
+ */
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <24576000>;
+ clock-frequency = <11289600>;
};
reg_1p8v: regulator0 {
@@ -95,6 +76,33 @@
regulator-always-on;
};
+ rsnd_ak4613: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&sndcpu>;
+ simple-audio-card,frame-master = <&sndcpu>;
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ };
+
+ sndcodec: simple-audio-card,codec {
+ sound-dai = <&ak4613>;
+ };
+ };
+
+ vbus0_usb2: regulator-vbus0-usb2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB20_VBUS0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -143,40 +151,13 @@
1800000 0>;
};
- vbus0_usb2: regulator-vbus0-usb2 {
- compatible = "regulator-fixed";
-
- regulator-name = "USB20_VBUS0";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
-
- gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- audio_clkout: audio_clkout {
- /*
- * This is same as <&rcar_sound 0>
- * but needed to avoid cs2000/rcar_sound probe dead-lock
- */
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <11289600>;
- };
-
- rsnd_ak4613: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcpu>;
- simple-audio-card,frame-master = <&sndcpu>;
-
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
+ vga {
+ compatible = "vga-connector";
- sndcodec: simple-audio-card,codec {
- sound-dai = <&ak4613>;
+ port {
+ vga_in: endpoint {
+ remote-endpoint = <&adv7123_out>;
+ };
};
};
@@ -202,14 +183,29 @@
};
};
- vga {
- compatible = "vga-connector";
+ x12_clk: x12 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+};
- port {
- vga_in: endpoint {
- remote-endpoint = <&adv7123_out>;
- };
- };
+&audio_clk_a {
+ clock-frequency = <22579200>;
+};
+
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1500>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
};
};
@@ -231,6 +227,14 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -239,27 +243,73 @@
clock-frequency = <32768>;
};
-&pfc {
- pinctrl-0 = <&scif_clk_pins>;
+&hsusb {
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "default";
- scif1_pins: scif1 {
- groups = "scif1_data_a", "scif1_ctrl";
- function = "scif1";
- };
- scif2_pins: scif2 {
- groups = "scif2_data_a";
- function = "scif2";
- };
- scif_clk_pins: scif_clk {
- groups = "scif_clk_a";
- function = "scif_clk";
+ status = "okay";
+
+ clock-frequency = <100000>;
+
+ ak4613: codec@10 {
+ compatible = "asahi-kasei,ak4613";
+ #sound-dai-cells = <0>;
+ reg = <0x10>;
+ clocks = <&rcar_sound 3>;
+
+ asahi-kasei,in1-single-end;
+ asahi-kasei,in2-single-end;
+ asahi-kasei,out1-single-end;
+ asahi-kasei,out2-single-end;
+ asahi-kasei,out3-single-end;
+ asahi-kasei,out4-single-end;
+ asahi-kasei,out5-single-end;
+ asahi-kasei,out6-single-end;
};
- i2c2_pins: i2c2 {
- groups = "i2c2_a";
- function = "i2c2";
+ cs2000: clk_multiplier@4f {
+ #clock-cells = <0>;
+ compatible = "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&audio_clkout>, <&x12_clk>;
+ clock-names = "clk_in", "ref_clk";
+
+ assigned-clocks = <&cs2000>;
+ assigned-clock-rates = <24576000>; /* 1/1 divide */
};
+};
+
+&i2c_dvfs {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pcie_bus_clk {
+ clock-frequency = <100000000>;
+};
+
+&pciec0 {
+ status = "okay";
+};
+
+&pciec1 {
+ status = "okay";
+};
+
+&pfc {
+ pinctrl-0 = <&scif_clk_pins>;
+ pinctrl-names = "default";
avb_pins: avb {
mux {
@@ -285,6 +335,26 @@
function = "du";
};
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
+ scif1_pins: scif1 {
+ groups = "scif1_data_a", "scif1_ctrl";
+ function = "scif1";
+ };
+
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_a";
+ function = "scif_clk";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -353,66 +423,6 @@
bias-pull-down;
};
};
-
- usb2_pins: usb2 {
- groups = "usb2";
- function = "usb2";
- };
-};
-
-&scif1 {
- pinctrl-0 = <&scif1_pins>;
- pinctrl-names = "default";
-
- uart-has-rtscts;
- status = "okay";
-};
-
-&scif2 {
- pinctrl-0 = <&scif2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&scif_clk {
- clock-frequency = <14745600>;
-};
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-
- clock-frequency = <100000>;
-
- ak4613: codec@10 {
- compatible = "asahi-kasei,ak4613";
- #sound-dai-cells = <0>;
- reg = <0x10>;
- clocks = <&rcar_sound 3>;
-
- asahi-kasei,in1-single-end;
- asahi-kasei,in2-single-end;
- asahi-kasei,out1-single-end;
- asahi-kasei,out2-single-end;
- asahi-kasei,out3-single-end;
- asahi-kasei,out4-single-end;
- asahi-kasei,out5-single-end;
- asahi-kasei,out6-single-end;
- };
-
- cs2000: clk_multiplier@4f {
- #clock-cells = <0>;
- compatible = "cirrus,cs2000-cp";
- reg = <0x4f>;
- clocks = <&audio_clkout>, <&x12_clk>;
- clock-names = "clk_in", "ref_clk";
-
- assigned-clocks = <&cs2000>;
- assigned-clock-rates = <24576000>; /* 1/1 divide */
- };
};
&rcar_sound {
@@ -445,7 +455,7 @@
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
- <&cpg CPG_CORE R8A7795_CLK_S0D4>;
+ <&cpg CPG_CORE CPG_AUDIO_CLK_I>;
rcar_sound,dai {
dai0 {
@@ -455,10 +465,25 @@
};
};
-&sata {
+&scif1 {
+ pinctrl-0 = <&scif1_pins>;
+ pinctrl-names = "default";
+
+ uart-has-rtscts;
status = "okay";
};
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+};
+
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
pinctrl-1 = <&sdhi0_pins_uhs>;
@@ -505,38 +530,6 @@
shared-pin;
};
-&wdt0 {
- timeout-sec = <60>;
- status = "okay";
-};
-
-&audio_clk_a {
- clock-frequency = <22579200>;
-};
-
-&i2c_dvfs {
- status = "okay";
-};
-
-&avb {
- pinctrl-0 = <&avb_pins>;
- pinctrl-names = "default";
- renesas,no-ether-link;
- phy-handle = <&phy0>;
- status = "okay";
-
- phy0: ethernet-phy@0 {
- rxc-skew-ps = <1500>;
- reg = <0>;
- interrupt-parent = <&gpio2>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-&xhci0 {
- status = "okay";
-};
-
&usb2_phy0 {
pinctrl-0 = <&usb0_pins>;
pinctrl-names = "default";
@@ -552,49 +545,11 @@
status = "okay";
};
-&usb2_phy2 {
- pinctrl-0 = <&usb2_pins>;
- pinctrl-names = "default";
-
- status = "okay";
-};
-
-&ehci0 {
- status = "okay";
-};
-
-&ehci1 {
- status = "okay";
-};
-
-&ehci2 {
- status = "okay";
-};
-
-&ohci0 {
- status = "okay";
-};
-
-&ohci1 {
- status = "okay";
-};
-
-&ohci2 {
- status = "okay";
-};
-
-&hsusb {
- status = "okay";
-};
-
-&pcie_bus_clk {
- clock-frequency = <100000000>;
-};
-
-&pciec0 {
+&wdt0 {
+ timeout-sec = <60>;
status = "okay";
};
-&pciec1 {
+&xhci0 {
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: r8a7796: Add placeholders for various devices
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas@glider.be>
Add empty device nodes serving as placeholders for devices that are not
yet supported and/or tested on R-Car M3-W, but are supported and used on
Salvator-X or H3ULCB boards equipped with an R-Car H3 SoC.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Drop RFC state.
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 82 ++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 8e2aab8b6b103cc9..60a4289d0b14fe50 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -961,6 +961,38 @@
dma-channels = <16>;
};
+ hsusb: usb@e6590000 {
+ /* placeholder */
+ };
+
+ xhci0: usb@ee000000 {
+ /* placeholder */
+ };
+
+ ohci0: usb@ee080000 {
+ /* placeholder */
+ };
+
+ ehci0: usb@ee080100 {
+ /* placeholder */
+ };
+
+ usb2_phy0: usb-phy@ee080200 {
+ /* placeholder */
+ };
+
+ ohci1: usb@ee0a0000 {
+ /* placeholder */
+ };
+
+ ehci1: usb@ee0a0100 {
+ /* placeholder */
+ };
+
+ usb2_phy1: usb-phy@ee0a0200 {
+ /* placeholder */
+ };
+
sdhi0: sd@ee100000 {
compatible = "renesas,sdhi-r8a7796";
reg = <0 0xee100000 0 0x2000>;
@@ -1063,5 +1095,55 @@
};
};
};
+
+ rcar_sound: sound@ec500000 {
+ /* placeholder */
+
+ rcar_sound,dvc {
+ dvc0: dvc-0 {
+ };
+
+ dvc1: dvc-1 {
+ };
+ };
+
+ rcar_sound,src {
+ src0: src-0 {
+ };
+ src1: src-1 {
+ };
+ };
+
+ rcar_sound,ssi {
+ ssi0: ssi-0 {
+ };
+
+ ssi1: ssi-1 {
+ };
+ };
+ };
+
+ pciec0: pcie@fe000000 {
+ /* placeholder */
+ };
+
+ pciec1: pcie@ee800000 {
+ /* placeholder */
+ };
+
+ du: display@feb00000 {
+ /* placeholder */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: r8a7796: Add external PCIe bus clock
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Geert Uytterhoeven
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Add the external PCIe bus clock as a zero Hz fixed-frequency clock.
Boards that provide this clock should override it.
Based on r8a7795.dtsi.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v2:
- Correct one-line summary prefix.
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 101cd41d693a7ab5..8e2aab8b6b103cc9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -157,6 +157,13 @@
clock-frequency = <0>;
};
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.7.4
--
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 v2 1/5] arm64: dts: r8a7796: Add external audio clocks
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland, linux-renesas-soc,
devicetree, linux-arm-kernel, Geert Uytterhoeven
In-Reply-To: <1493384324-29344-1-git-send-email-geert+renesas@glider.be>
Add the external audio clocks as zero Hz fixed-frequency clocks.
Boards that provide these clocks should override them.
Based on commit 623197b90c7aa97c ("arm64: renesas: r8a7795: Sound SSI
PIO support").
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v2:
- Correct one-line summary prefix,
- Add Acked-by.
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 2ec1ed5f499165ad..101cd41d693a7ab5 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -120,6 +120,29 @@
clock-frequency = <0>;
};
+ /*
+ * The external audio clocks are configured as 0 Hz fixed frequency
+ * clocks by default.
+ * Boards that provide audio clocks should override them.
+ */
+ audio_clk_a: audio_clk_a {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_b: audio_clk_b {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_c: audio_clk_c {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External CAN clock - to be overridden by boards that provide it */
can_clk: can {
compatible = "fixed-clock";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-28 12:58 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: Vladimir Barinov, Rob Herring, Mark Rutland,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Geert Uytterhoeven
Hi Simon, Magnus,
The Renesas Salvator-X and ULCB development board can be equipped with
either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
use separate DTBs, but currently there's no sharing of board-specific
devices in DTS.
This series reduces duplication by extracting common board support into
their own .dtsi files. As the level of support varies across boards and
SoCs, this requires the addition of a few external clocks and
placeholder devices on R-Car M3-W, so the common board support DTS can
refer to them.
- Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
M3-W, which are present in r8a7795.dtsi, and used in
r8a7795-salvator-x.dts,
- Patch 3 adds placeholders for devices that are not yet supported
and/or tested on R-Car M3-W, but used on R-Car H3,
- Patch 4 extracts common Salvator-X board support,
- Patch 5 extracts common ULCB board support.
For R-Car H3 based boards, there are no functional changes.
For R-Car M3-W based boards, some new devices are now described in DT.
Compared to v1, the most important change is a rebase to remove the
dependency on "[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and
M3-W SiP" (http://www.spinics.net/lists/devicetree/msg173820.html).
Please refer to the individual patches for more changelog information.
Dependencies:
- renesas-devel-20170428-v4.11-rc8.
DTB changes have been inspected using scripts/dtc/dtx_diff.
This has been tested on Salvator-X (both H3 and M3-W), H3ULCB, and
M3ULCB.
Thanks for applying!
Geert Uytterhoeven (5):
arm64: dts: r8a7796: Add external audio clocks
arm64: dts: r8a7796: Add external PCIe bus clock
arm64: dts: r8a7796: Add placeholders for various devices
arm64: dts: renesas: Extract common Salvator-X board support
arm64: dts: renesas: Extract common ULCB board support
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 341 +------------
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 543 +--------------------
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 201 +-------
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 259 +---------
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 112 +++++
.../{r8a7795-salvator-x.dts => salvator-x.dtsi} | 393 +++++++--------
.../dts/renesas/{r8a7795-h3ulcb.dts => ulcb.dtsi} | 264 +++++-----
7 files changed, 420 insertions(+), 1693 deletions(-)
copy arch/arm64/boot/dts/renesas/{r8a7795-salvator-x.dts => salvator-x.dtsi} (91%)
copy arch/arm64/boot/dts/renesas/{r8a7795-h3ulcb.dts => ulcb.dtsi} (91%)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties
From: jmondi @ 2017-04-28 12:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdbkBtJGJ_5MVy2QSAa0zcKVm=_H+vC_kH4AUcX58TiaLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Linus,
On Fri, Apr 28, 2017 at 10:16:22AM +0200, Linus Walleij wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
>
> > Add PIN_CONF_UNPACK_PARAM and PIN_CONF_UNPACK_ARGS macros useful to
> > unpack generic properties and their arguments
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
>
> (...)
>
> /*
> * Helpful configuration macro to be used in tables etc.
>
> Then this should say "macros" rather than "macro".
>
> > -#define PIN_CONF_PACKED(p, a) ((a << 8) | ((unsigned long) p & 0xffUL))
> > +#define PIN_CONF_PACKED(p, a) (((a) << 8) | ((unsigned long) (p) & 0xffUL))
>
> Also adding some extra parantheses I see.
>
> > +#define PIN_CONF_UNPACK_PARAM(c) ((c) & 0xffUL)
> > +#define PIN_CONF_UNPACK_ARGS(c) ((c) >> 8)
>
> But why.
>
> I have these two static inlines just below your new macros:
>
> static inline enum pin_config_param pinconf_to_config_param(unsigned
> long config)
> {
> return (enum pin_config_param) (config & 0xffUL);
> }
>
> static inline u32 pinconf_to_config_argument(unsigned long config)
> {
> return (u32) ((config >> 8) & 0xffffffUL);
> }
>
> Why can't you use this in your code instead of macros?
>
> We generally prefer static inlines over macros because they are easier
> to read.
>
Right. I haven't noticed them.
I'll drop this patch, sorry for noise
> Yours,
> Linus Walleij
--
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: r7s72100: add usb clocks to device tree
From: Chris Brandt @ 2017-04-28 12:47 UTC (permalink / raw)
To: Simon Horman, Geert Uytterhoeven
Cc: Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20170428080400.GI10196@verge.net.au>
On Friday, April 28, 2017, Simon Horman wrote:
> On Fri, Apr 28, 2017 at 09:34:54AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt@renesas.com>
> wrote:
> > > This adds the USB0 and USB1 clocks to the device tree.
> > >
> > > Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
>
> Thanks, I see that now.
I was going to say that I simply look at sections:
6.10.6 Internal Clock Signals (1)
6.10.7 Internal Clock Signals (2)
Because it lists all the IP blocks and their corresponding clock sources in one place.
Chris
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-28 12:28 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Vladimir Barinov
In-Reply-To: <20170428073256.GG10196-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On Fri, Apr 28, 2017 at 9:32 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Fri, Apr 28, 2017 at 09:11:36AM +0200, Geert Uytterhoeven wrote:
>> On Fri, Apr 28, 2017 at 9:04 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>> > On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
>> >> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
>> >> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
>> >> > CC Vladimir (which I forgot to CC initially, sorry for that)
>> >> >
>> >> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
>> >> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>> >> >>> The Renesas Salvator-X and ULCB development board can be equipped with
>> >> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>> >> >>> use separate DTBs, but currently there's no sharing of board-specific
>> >> >>> devices in DTS.
>> >> >>>
>> >> >>> This series reduces duplication by extracting common board support into
>> >> >>> their own .dtsi files. As the level of support varies across boards and
>> >> >>> SoCs, this requires the addition of a few external clocks and
>> >> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
>> >> >>> refer to them.
>> >> >>>
>> >> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>> >> >>> M3-W, which are present in r8a7795.dtsi, and used in
>> >> >>> r8a7795-salvator-x.dts,
>> >> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
>> >> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
>> >> >>> - RFC patch 4 extracts common Salvator-X board support,
>> >> >>> - RFC patch 5 extracts common ULCB board support.
>> >> >>>
>> >> >>> For R-Car H3 based boards, there are no functional changes.
>> >> >>> For R-Car M3-W based boards, some new devices are now described in DT.
>> >> >>>
>> >> >>> Dependencies:
>> >> >>> - renesas-devel-20170420-v4.11-rc7,
>> >> >>> - Patches 1 and 2 can be applied as-is,
>> >> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>> >> >>> out R-Car H3 and M3-W SiP"
>> >> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> >> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>> >> >>> This has been tested on Salvator-X (both H3 and M3-W).
>> >> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>> >> >>>
>> >> >>> Thanks for your comments!
>> >> >>
>> >> >> Thanks for tackling this important problem. I have looked over the changes
>> >> >> and they seem nice to me. I would, however, be more comfortable applying
>> >> >> them if they were rested on the ULCB boards.
>> >> >
>> >> > tested?
>> >> >
>> >> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>> >>
>> >> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
>> >> No issues detected.
>> >
>> > Great! Any objections to me queuing this up?
>>
>> The dependency above (no feedback about the SiP types yet).
>>
>> I can respin without that dependency, if that is preferred...
>
> It seems to me that it would be nice to get these in sooner than later - in
> particular earlier rather than later in the (v4.13) development cycle. But
> I defer to your judgement on what is best.
Agreed. Stay tuned for v2...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Andy Shevchenko @ 2017-04-28 12:15 UTC (permalink / raw)
To: Chris Brandt
Cc: Linus Walleij, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King - ARM Linux,
Linux-Renesas, linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB1165E7E651BE96CD7B7738B08A130@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Fri, Apr 28, 2017 at 3:07 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, April 28, 2017, Linus Walleij wrote:
>> > For me it looks like you are trying to alias open-drain + bias or
>> > alike. Don't actually see the benefit of it.
>>
>> Andy is bringing up a valid point. And I remember asking about this before.
>>
>> What does "bi-directional" really mean, electrically speaking?
> Take the SDHI data pins. You send AND receive data over those pins (and they are not open drain).
Can you point to schematics and electrical characteristics of such buffer?
(Yes, I can imagine one case where it's possible to have an
"automatic" switch based on which current is bigger output of your
side or remote's. But! I would like to see actual specifications to
prove this or otherwise.)
> The issue is that the PFC HW that enables the connections between the SDHI IP block and the I/O pad buffers can only enable one path/signal/direction to the buffer enables (in or out). So for a pin that needs both directions, the PFC enables output and the "bidirectional register" is used to enable the input buffer as well.
> In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control Logical Diagram (but that wasn't obvious to me at first).
Please, post a link to it or copy essential parts.
I'm quite skeptical that cheap hardware can implement something more
costable than simplest open-source / open-drain + bias.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
From: Chris Brandt @ 2017-04-28 12:07 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Rob Herring,
Mark Rutland, Russell King - ARM Linux, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdayW0qPXDcc_JofkwtX5UHhDPxiY_8deZZ7+hPNJkjgeQ@mail.gmail.com>
On Friday, April 28, 2017, Linus Walleij wrote:
> > For me it looks like you are trying to alias open-drain + bias or
> > alike. Don't actually see the benefit of it.
>
> Andy is bringing up a valid point. And I remember asking about this before.
>
> What does "bi-directional" really mean, electrically speaking?
>
> Does is just mean open drain and/or open source actually?
> (See Documentation/gpio/driver.txt for an explanation of how open
> drain/source works.)
>
> When you set an output without setting a value, what happens electrically?
>
> Isn't this bias-high-impedance / High-Z?
>
> Hopefully you can find the answer from Renesas hardware dept.
>
> You can certainly call it whatever the datasheet calls it in your driver
> #defines but for the DT bindings we would ideally have the physical world
> things.
The main reason is this pin controller is too dumb to do what it's supposed to with 1 register setting.
Take the SDHI data pins. You send AND receive data over those pins (and they are not open drain). The issue is that the PFC HW that enables the connections between the SDHI IP block and the I/O pad buffers can only enable one path/signal/direction to the buffer enables (in or out). So for a pin that needs both directions, the PFC enables output and the "bidirectional register" is used to enable the input buffer as well.
In the RZ/A1 HW manual you can kind of see that in 54.18 Port Control Logical Diagram (but that wasn't obvious to me at first).
# side note, the way the registers are arranged is also ridiculous in my opinion. I'm not a fan of this particular IP.
The good news is the RZ/A1 is the only chip series I've seen with this PFC IP (I can't even figure out where it came from internally). And as far as I know, it will not appear in any other RZ series chips.
Chris
^ permalink raw reply
* [RFC v3 2/2] mux: mmio-based syscon mux controller
From: Philipp Zabel @ 2017-04-28 11:52 UTC (permalink / raw)
To: Peter Rosin
Cc: Rob Herring, Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree, linux-kernel, kernel, Philipp Zabel
In-Reply-To: <1493380324-20638-1-git-send-email-p.zabel@pengutronix.de>
This adds a driver for mmio-based syscon multiplexers controlled by
bitfields in a syscon register range.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
Changes since v2:
- Updated CONFIG description to multi-mux
- Use mux_control_get_index instead of open-coding it
- Read mux-reg-masks and idle-states values in a single loop using
individual read_u32_index calls instead of using read_u32_array
- Verify bitmask
---
drivers/mux/Kconfig | 13 +++++
drivers/mux/Makefile | 1 +
drivers/mux/mux-mmio.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 drivers/mux/mux-mmio.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 34b8284d6d29e..50e7c5d557a05 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -43,4 +43,17 @@ config MUX_GPIO
To compile the driver as a module, choose M here: the module will
be called mux-gpio.
+config MUX_MMIO
+ tristate "MMIO register bitfield-controlled Multiplexer"
+ depends on OF && MFD_SYSCON
+ help
+ MMIO register bitfield-controlled Multiplexer controller.
+
+ The driver builds multiplexer controllers for bitfields in a syscon
+ register. For N bit wide bitfields, there will be 2^N possible
+ multiplexer states.
+
+ To compile the driver as a module, choose M here: the module will
+ be called mux-mmio.
+
endif
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index b00a7d37d2fbe..6bac5b0fea137 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_MULTIPLEXER) += mux-core.o
obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
+obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
diff --git a/drivers/mux/mux-mmio.c b/drivers/mux/mux-mmio.c
new file mode 100644
index 0000000000000..d2477d62d6eed
--- /dev/null
+++ b/drivers/mux/mux-mmio.c
@@ -0,0 +1,140 @@
+/*
+ * MMIO register bitfield-controlled multiplexer driver
+ *
+ * Copyright (C) 2017 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/bitops.h>
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/mux/driver.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+static int mux_mmio_set(struct mux_control *mux, int state)
+{
+ struct regmap_field **fields = mux_chip_priv(mux->chip);
+
+ return regmap_field_write(fields[mux_control_get_index(mux)], state);
+}
+
+static const struct mux_control_ops mux_mmio_ops = {
+ .set = mux_mmio_set,
+};
+
+static const struct of_device_id mux_mmio_dt_ids[] = {
+ { .compatible = "mmio-mux", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mux_mmio_dt_ids);
+
+static int mux_mmio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct regmap_field **fields;
+ struct mux_chip *mux_chip;
+ struct regmap *regmap;
+ int num_fields;
+ int ret;
+ int i;
+
+ regmap = syscon_node_to_regmap(np->parent);
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ dev_err(dev, "failed to get regmap: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_count_u32_elems(np, "mux-reg-masks");
+ if (ret == 0 || ret % 2)
+ ret = -EINVAL;
+ if (ret < 0) {
+ dev_err(dev, "mux-reg-masks property missing or invalid: %d\n",
+ ret);
+ return ret;
+ }
+ num_fields = ret / 2;
+
+ mux_chip = devm_mux_chip_alloc(dev, num_fields, num_fields *
+ sizeof(*fields));
+ if (IS_ERR(mux_chip))
+ return PTR_ERR(mux_chip);
+
+ fields = mux_chip_priv(mux_chip);
+
+ for (i = 0; i < num_fields; i++) {
+ struct mux_control *mux = &mux_chip->mux[i];
+ struct reg_field field;
+ s32 idle_state = MUX_IDLE_AS_IS;
+ u32 reg, mask;
+ int bits;
+
+ ret = of_property_read_u32_index(np, "mux-reg-masks",
+ 2 * i, ®);
+ if (!ret)
+ ret = of_property_read_u32_index(np, "mux-reg-masks",
+ 2 * i + 1, &mask);
+ if (ret < 0) {
+ dev_err(dev, "bitfield %d: failed to read mux-reg-masks property: %d\n",
+ i, ret);
+ return ret;
+ }
+
+ field.reg = reg;
+ field.msb = fls(mask) - 1;
+ field.lsb = ffs(mask) - 1;
+
+ if (mask != GENMASK(field.msb, field.lsb)) {
+ dev_err(dev, "bitfield %d: invalid mask 0x%x\n",
+ i, mask);
+ return -EINVAL;
+ }
+
+ fields[i] = devm_regmap_field_alloc(dev, regmap, field);
+ if (IS_ERR(fields[i])) {
+ ret = PTR_ERR(fields[i]);
+ dev_err(dev, "bitfield %d: failed allocate: %d\n",
+ i, ret);
+ return ret;
+ }
+
+ bits = 1 + field.msb - field.lsb;
+ mux->states = 1 << bits;
+
+ of_property_read_u32_index(np, "idle-states", i, &idle_state);
+ if (idle_state != MUX_IDLE_AS_IS) {
+ if (idle_state < 0 || idle_state >= mux->states) {
+ dev_err(dev, "bitfield: %d: out of range idle state %d\n",
+ i, idle_state);
+ return -EINVAL;
+ }
+
+ mux->idle_state = idle_state;
+ }
+ }
+
+ mux_chip->ops = &mux_mmio_ops;
+
+ return devm_mux_chip_register(dev, mux_chip);
+}
+
+static struct platform_driver mux_mmio_driver = {
+ .driver = {
+ .name = "mmio-mux",
+ .of_match_table = of_match_ptr(mux_mmio_dt_ids),
+ },
+ .probe = mux_mmio_probe,
+};
+module_platform_driver(mux_mmio_driver);
+
+MODULE_DESCRIPTION("MMIO register bitfield-controlled multiplexer driver");
+MODULE_AUTHOR("Philipp Zabel <p.zabel@pengutronix.de>");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [RFC v3 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Philipp Zabel @ 2017-04-28 11:52 UTC (permalink / raw)
To: Peter Rosin
Cc: Rob Herring, Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Philipp Zabel
This adds device tree binding documentation for mmio-based syscon
multiplexers controlled by a bitfieldis in a syscon register range.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since v2:
- Updated multi-mux DT binding description
- Removed superfluous @3 from example
---
Documentation/devicetree/bindings/mux/mmio-mux.txt | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
new file mode 100644
index 0000000000000..a9bfb4d8b6ac8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
@@ -0,0 +1,60 @@
+MMIO register bitfield-based multiplexer controller bindings
+
+Define register bitfields to be used to control multiplexers. The parent
+device tree node must be a syscon node to provide register access.
+
+Required properties:
+- compatible : "mmio-mux"
+- #mux-control-cells : <1>
+- mux-reg-masks : an array of register offset and pre-shifted bitfield mask
+ pairs, each describing a single mux control.
+* Standard mux-controller bindings as decribed in mux-controller.txt
+
+Optional properties:
+- idle-states : if present, the state the muxes will have when idle. The
+ special state MUX_IDLE_AS_IS is the default.
+
+The multiplexer state of each multiplexer is defined as the value of the
+bitfield described by the corresponding register offset and bitfield mask pair
+in the mux-reg-masks array, accessed through the parent syscon.
+
+Example:
+
+ syscon {
+ compatible = "syscon";
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+
+ mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */
+ <0x3 0x40>, /* 1: reg 0x3, bit 6 */
+ idle-states = <MUX_IDLE_AS_IS>, <0>;
+ };
+ };
+
+ video-mux {
+ compatible = "video-mux";
+ mux-controls = <&mux 0>;
+
+ ports {
+ /* inputs 0..3 */
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ port@2 {
+ reg = <2>;
+ };
+ port@3 {
+ reg = <3>;
+ };
+
+ /* output */
+ port@4 {
+ reg = <4>;
+ };
+ };
+ };
--
2.11.0
--
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: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-28 11:41 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <1493347596.29314.55.camel@mtkswgap22>
On Fri, Apr 28, 2017 at 4:46 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Thu, 2017-04-27 at 21:06 +0200, Arnd Bergmann wrote:
>> On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
>> >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> Are any of the registers the same at all, e.g. for MSI handling?
>
> No, It doesn't support MSI. All I can do is using the registers that designer provide
> to me. The others are inviable for software. So I treat it as different hardware.
> Furthermore, we hope that we can put all mediatek drivers together
> regardless of in-house IP or lincense IP
>
> We have no particular IP name but just use chip name to call it. So I
> will temporarily use "mediatek,gen2v1-pcie" in patch v1.
I think using the chip name as in the first version of your patch name is
better then, in particular since the 'gen2v1' would not be an actual version
number but just say which variant got merged into mainline first.
A related question would be on how general we want the binding to be.
Your binding text starts out by describing that there are three root ports
and what their capabilities are.
If you think there might be other (existing or future) chips that use the
same binding and driver, then being a little more abstract could help
in the long run.
Arnd
^ permalink raw reply
* Re: [PATCH v4 2/2] of: Add unit tests for applying overlays
From: Geert Uytterhoeven @ 2017-04-28 11:25 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, stephen.boyd, Michal Marek,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild
In-Reply-To: <1493165394-29367-3-git-send-email-frowand.list@gmail.com>
Hi Frank,
On Wed, Apr 26, 2017 at 2:09 AM, <frowand.list@gmail.com> wrote:
> From: Frank Rowand <frank.rowand@sony.com>
>
> Existing overlay unit tests examine individual pieces of the overlay
> code. The new tests target the entire process of applying an overlay.
>
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
>
> There are checkpatch warnings. I have reviewed them and feel they
> can be ignored.
>
> drivers/of/fdt.c | 14 +-
> drivers/of/of_private.h | 12 +
> drivers/of/unittest-data/Makefile | 17 +-
> drivers/of/unittest-data/overlay.dts | 53 ++++
> drivers/of/unittest-data/overlay_bad_phandle.dts | 20 ++
> drivers/of/unittest-data/overlay_base.dts | 80 ++++++
> drivers/of/unittest.c | 317 +++++++++++++++++++++++
> 7 files changed, 505 insertions(+), 8 deletions(-)
>
> create mode 100644 drivers/of/unittest-data/overlay.dts
> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
> create mode 100644 drivers/of/unittest-data/overlay_base.dts
Shouldn't these be called .dtso instead of .dts?
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
> +# enable creation of __symbols__ node
> +DTC_FLAGS_overlay := -@
> +DTC_FLAGS_overlay_bad_phandle := -@
> +DTC_FLAGS_overlay_base := -@
This flag is needed for all DTs that will be involved with overlays.
Hence what about enabling this globally instead, cfr. "Enable DT symbols when"
CONFIG_OF_OVERLAY is used
("http://www.spinics.net/lists/devicetree/msg103363.html")?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-28 11:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rajendra Nayak, Mark Brown, Rafael Wysocki,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b3f5b62c-9423-98e4-d366-78186ab02fb9-5wv7dgnIgG8@public.gmane.org>
On 28-04-17, 10:44, Sudeep Holla wrote:
> Just thinking out loud, I can see platforms with have OPPs can move to
> this binding in future eliminating the need to specify the clock and
> regulators explicitly. So, I am not saying I against this idea, but I
> see it might complicate the above case in terms of the precedence that
> we consider in DT from backward compatibility.
>
> E.g. if you now use this for just regulators, then I assume you continue
> to use clocks. However, that makes it difficult for platforms
> implementing *real* OPPs to reuse this binding as they may expect to
> skip clock altogether.
>
> Also we may need OPPs(both volt/freq), voltage only and clock only
> bindings though all 3 are driven by the firmware and all are at abstract
> levels. I am trying to broaden the scope now without having to churn
> this binding again in near future.
>
> So I don't totally agree that voltage regulators much have *real*
> voltages and not abstract scale. Yes the correct bindings might have
> such restrictions but can't we extend it ?
>
> Anyways these are just my opinion.
Everyone's opinion has equal merit here :)
I believe that some of your hesitation came from the point that I have
made opp-hz optional. That isn't the case anymore with V6.
Can we please take the discussion to that thread now and see if you
can find similar problems there as well.
Thanks a lot.
--
viresh
--
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
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