* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Thierry Reding @ 2016-11-30 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6706502.us21ohNYZA@wuerfel>
On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > arm64: tegra: Default configuration updates for v4.10-rc1
> >
> > Enable Tegra186 support.
> >
>
> This was already in next/arm64 (but I didn't see a notification),
> and with the arm64-dt branch now merged as well, we should have
> everything you sent.
I had also sent a couple of individual patches that seemed to not have
it made into v4.9 and v4.8 for some reason (they were part of the pull
requests, as far as I can tell). Do you think you could pull those in
as well?
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/b14ea724/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Sudeep Holla @ 2016-11-30 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480452310-29286-1-git-send-email-jeremy.linton@arm.com>
Hi Jeremy,
On 29/11/16 20:45, Jeremy Linton wrote:
> The PCIe root complex on Juno translates the MMIO mapped
> at 0x5f800000 to the PIO address range starting at 0
> (which is common because PIO addresses are generally < 64k).
> Correct the DT to reflect this.
>
I have another DT fix that I have asked ARM-SoC guys to pick up directly
from the list. If that doesn't happen, I will send PR including both.
If that happens then we need to send this to them to be picked directly.
At this point I want to wait for couple of days to avoid confusion.
--
Regards,
Sudeep
^ permalink raw reply
* [sample] A sample program for MRS emulation
From: Dave Martin @ 2016-11-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480518901-18544-11-git-send-email-suzuki.poulose@arm.com>
On Wed, Nov 30, 2016 at 03:15:01PM +0000, Suzuki K Poulose wrote:
> Here is a sample program which demonstrates how to use mrs
> emulation to fetch the ID registers.
Are we planning to add this in Documentation/? If so, we might want
some tweaks (noted below).
>
> ----8>----
> /*
> * Sample program to demonstrate the MRS emulation
> * ABI.
overwrapped?
> * Copyright (C) 2015-2016, ARM Ltd
> *
> * Author: Suzuki K Poulose <suzuki.poulose@arm.com>
> *
> * 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.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> * 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.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> */
>
> #include <stdio.h>
>
> #define get_cpu_ftr(id) ({ \
> unsigned long long __val; \
> asm("mrs %0, "#id : "=r" (__val)); \
> printf("%-20s: 0x%016lx\n", #id, __val); \
> })
>
> int main()
(void)
> {
We don't wan't people using the MRS emulation without checking for its
availability first.
Something like this may work (untested), with the caveat that getauxval()
is a GNU libc extension, and other environments may require a different
mechanism to obtain the hwcaps.
--8<--
#include <sys/auxv.h>
#include <asm/hwcap.h>
/* ... */
if (!getauxval(AT_HWCAP) & HWCAP_CPUID) {
fputs("CPUID registers unavailable\n", stderr);
return 1;
}
-->8--
Cheers
---Dave
>
> get_cpu_ftr(ID_AA64ISAR0_EL1);
> get_cpu_ftr(ID_AA64ISAR1_EL1);
> get_cpu_ftr(ID_AA64MMFR0_EL1);
> get_cpu_ftr(ID_AA64MMFR1_EL1);
> get_cpu_ftr(ID_AA64PFR0_EL1);
> get_cpu_ftr(ID_AA64PFR1_EL1);
> get_cpu_ftr(ID_AA64DFR0_EL1);
> get_cpu_ftr(ID_AA64DFR1_EL1);
>
> get_cpu_ftr(MIDR_EL1);
> get_cpu_ftr(MPIDR_EL1);
> get_cpu_ftr(REVIDR_EL1);
> return 0;
> }
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Lorenzo Pieralisi @ 2016-11-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130155616.GA9693@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Nov 30, 2016 at 09:56:17AM -0600, Bjorn Helgaas wrote:
> On Wed, Nov 30, 2016 at 12:04:25PM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> > > Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> > > Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> > > descriptors. The Consumer/Producer bit is defined only for the Extended
> > > Address Space descriptor.
> > >
> > > Ignore Consumer/Producer except for Extended Address Space descriptors.
> > >
> > > Note that for QWord/DWord/Word descriptors, we previously applied the
> > > translation offset (_TRA) only when the Consumer/Producer bit was set.
> >
> > "..Consumer/Producer bit was clear" ? If that bit was set:
> >
> > struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
> >
> > and we are not applying the _TRA offset in that case, right ?
>
> Right, of course. How about this instead?
>
> Note that for QWord/DWord/Word descriptors, we previously applied the
> translation offset (_TRA) only for Producers, i.e., when the Consumer/
> Producer bit was clear. This patch changes that: for those descriptors,
> we ignore Consumer/Producer and always apply the translation offset.
Yes that's a perfect description, thanks a lot !
Lorenzo
> > > This patch changes that: for those descriptors, we ignore Consumer/Producer
> > > and always apply the translation offset.
> > >
> > > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > > ---
> > > drivers/acpi/resource.c | 16 +++++++++++-----
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> > > index 2732d39e..b45cd8f 100644
> > > --- a/drivers/acpi/resource.c
> > > +++ b/drivers/acpi/resource.c
> > > @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > > * primary side. Non-bridge devices must list 0 for all Address
> > > * Translation offset bits.
> > > */
> > > - if (addr->producer_consumer == ACPI_PRODUCER)
> > > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> > > + if (addr->producer_consumer == ACPI_PRODUCER)
> > > + offset = attr->translation_offset;
> > > + else if (attr->translation_offset)
> > > + pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > + attr->translation_offset);
> > > + } else {
> > > offset = attr->translation_offset;
> > > - else if (attr->translation_offset)
> > > - pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> > > - attr->translation_offset);
> > > + }
> > > +
> > > start = attr->minimum + offset;
> > > end = attr->maximum + offset;
> > >
> > > @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> > > return false;
> > > }
> > >
> > > - if (addr->producer_consumer == ACPI_PRODUCER)
> > > + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> > > + addr->producer_consumer == ACPI_PRODUCER)
> > > res->flags |= IORESOURCE_WINDOW;
> > >
> > > if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-11-30 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn0BZNH82kY_7UR1EjV7M1G+9jGihGb4-uCs9=XiPHUYxQ@mail.gmail.com>
Hi,
> I was too busy in another project but now I am ready to complete the
> upstream of the STM32F4 I2C driver.
Nice.
> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + u32 clk_rate, cr2, freq;
> >> +
> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
> >> +
> >> + clk_rate = clk_get_rate(i2c_dev->clk);
> >> + freq = clk_rate / MHZ_TO_HZ;
> >> +
> >> + if (freq > STM32F4_I2C_MAX_FREQ)
> >> + freq = STM32F4_I2C_MAX_FREQ;
> >> + if (freq < STM32F4_I2C_MIN_FREQ)
> >> + freq = STM32F4_I2C_MIN_FREQ;
> >
> > clamp() to enforce the range?
> Sorry but what do you mean by "clamp()" ?
The kernel has a clamp() function which would fit this purpose, I think.
Regards,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/e13dca49/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m21sxtkkg1.fsf@baylibre.com>
On 11/30/2016 05:21 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Hi Laurent,
>> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>>
>>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>>> a Linux-specific concept. You can name it meson.txt, but a better option would
>>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>>
>> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>>
>> I will move it to amlogic,meson.txt, seems far better.
>>
>
> To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
>
> Kevin
>
Yes, seems more coherent.
Thanks,
Neil
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Kevin Hilman @ 2016-11-30 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e1b16c6-eec5-8cf3-5795-d6de02f36570@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Hi Laurent,
> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>
>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>> a Linux-specific concept. You can name it meson.txt, but a better option would
>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>
> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>
> I will move it to amlogic,meson.txt, seems far better.
>
To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
Kevin
^ permalink raw reply
* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-30 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5c36597-d917-0555-89cd-35f68087c1c5@free-electrons.com>
> What do you prefer everything in one commit or two seperated commit ? (one
> including the new fields for fm_mask and another one to add support for
> a3700-i2c).
One commit is fine!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/0fcbc15f/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-30 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAADWXX_ipJ+pVmV5s2oLCKBrC5qUDASOZf=tpBfJWELExam+hQ@mail.gmail.com>
On Tue, Nov 29, 2016 at 03:39:11PM -0800, Linus Torvalds wrote:
> Bjorn, this email was marked as spam, because:
>
> It has a from address in google.com but has failed google.com's
> required tests for authentication
>
> in particular, it looks like you used a non-google smtp server
> (kernel.org) to send the email, so there is no DKIM hash (or perhaps
> google just uses some other non-standard marker for "this actually
> came from google"). So gmail marks it as spam because dmarc fails:
>
> dmarc=fail (p=REJECT dis=NONE) header.from=google.com
>
> Just to let you know. If you use your google.com email, you do need to
> go through the google smtp server.
>
> This may or may not be new - I didn't go and look at old messages of
> yours, but it is possible that google.com enabled dmarc/dkim recently.
Argh, thanks for letting me know. Looks like I've had this broken for a
long time, but I didn't notice. I think I have it fixed so git will record
the author as bhelgaas at google.com, but git/stgit will send email from
helgaas at kernel.org via the kernel.org smtp server.
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2016-11-30 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-3-git-send-email-sricharan@codeaurora.org>
Sricharan, Robin,
I gave this series a go on ACPI and apart from an SMMU v3 fix-up
it seems to work, more thorough testing required though.
A key question below.
On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU configuration represents unchanging properties of the hardware,
> and as such should only need happen once in a device's lifetime, but
> the necessary interaction with the IOMMU device and driver complicates
> exactly when that point should be.
>
> Since the only reasonable tool available for handling the inter-device
> dependency is probe deferral, we need to prepare of_iommu_configure()
> to run later than it is currently called (i.e. at driver probe rather
> than device creation), to handle being retried, and to tell whether a
> not-yet present IOMMU should be waited for or skipped (by virtue of
> having declared a built-in driver or not).
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index ee49081..349bd1d 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> int err;
>
> ops = iommu_get_instance(fwnode);
> - if (!ops || !ops->of_xlate)
> + if ((ops && !ops->of_xlate) ||
> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
IIUC of_match_node() here is there to check there is a driver compiled
in for this device_node (aka compatible string in OF world), correct ?
If that's the case (and I think that's what Sricharan was referring to
in his ACPI query) I need to cook-up something on the ACPI side to
emulate the OF linker table behaviour (or anyway to detect a driver is
actually in the kernel), it is not that difficult but it is key to know,
I will give it some thought to make it as clean as possible.
Thanks,
Lorenzo
> return NULL;
>
> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> if (err)
> return ERR_PTR(err);
> + /*
> + * The otherwise-empty fwspec handily serves to indicate the specific
> + * IOMMU device we're waiting for, which will be useful if we ever get
> + * a proper probe-ordering dependency mechanism in future.
> + */
> + if (!ops)
> + return ERR_PTR(-EPROBE_DEFER);
>
> err = ops->of_xlate(dev, iommu_spec);
> if (err)
> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> struct device_node *master_np)
> {
> const struct iommu_ops *ops;
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>
> if (!master_np)
> return NULL;
>
> + if (fwspec) {
> + if (fwspec->ops)
> + return fwspec->ops;
> +
> + /* In the deferred case, start again from scratch */
> + iommu_fwspec_free(dev);
> + }
> +
> if (dev_is_pci(dev))
> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> else
> ops = of_platform_iommu_init(dev, master_np);
> + /*
> + * If we have reason to believe the IOMMU driver missed the initial
> + * add_device callback for dev, replay it to get things in order.
> + */
> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> + dev->bus && !dev->iommu_group) {
> + int err = ops->add_device(dev);
> +
> + if (err)
> + ops = ERR_PTR(err);
> + }
>
> return IS_ERR(ops) ? NULL : ops;
> }
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* [GIT PULL v2] firmware: SCPI updates for v4.10
From: Arnd Bergmann @ 2016-11-30 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118115615.GB14913@e107155-lin>
On Friday, November 18, 2016 11:56:15 AM CET Sudeep Holla wrote:
> Hi ARM-SoC Team,
>
> I have decoupled the platform specific binding from generic SCPI. Also
> I have renamed "arm,legacy-scpi" to "arm,scpi-pre-1.0". Since I haven't
> heard back any objections from Olof/Rob for my response, I am sending
> the pull request now.
>
Pulled into next/drivers now, sorry for the delay.
Arnd
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118161719.24153-10-thierry.reding@gmail.com>
On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> arm64: tegra: Default configuration updates for v4.10-rc1
>
> Enable Tegra186 support.
>
This was already in next/arm64 (but I didn't see a notification),
and with the arm64-dt branch now merged as well, we should have
everything you sent.
Arnd
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>
On 11/30/2016 05:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>
Thanks. I'll resend.
--
regards,
-grygorii
^ permalink raw reply
* [GIT PULL v2 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121102312.19968-1-thierry.reding@gmail.com>
On Monday, November 21, 2016 11:23:12 AM CET Thierry Reding wrote:
> arm64: tegra: Device tree changes for v4.10-rc1
>
> This adds initial support for Tegra186, the P3310 processor module as
> well as the P2771 development board. Not much is functional, but there
> is enough to boot to an initial ramdisk with debug serial output.
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10006210.eA8q2ZWXP0@avalon>
On 11/30/2016 05:02 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
>> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
>> boards.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
>> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
>> 8 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -356,5 +356,24 @@
>> status = "disabled";
>> };
>> };
>> +
>> + vpu: vpu at d0100000 {
>> + compatible = "amlogic,meson-gx-vpu";
>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>> + <0x0 0xc883c000 0x0 0x1000>,
>> + <0x0 0xc8838000 0x0 0x1000>;
>> + reg-names = "vpu", "hhi", "dmc";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* CVBS VDAC output port */
>> + port at 0 {
>> + reg = <0>;
>> +
>> + cvbs_vdac_out: endpoint {
>> + };
>
> Endpoints require a remote-endpoint property. You should move the endpoint to
> board DT files.
OK, I was wondering, it looked dirty to me.
>
>> + };
>> + };
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
>> 9696820..390f7db 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -142,6 +142,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> Unless the board has a label for the connector (either on the board, on the
> casing or in the user manual) I'd leave this out. Same comment for the other
> boards.
OK,
Thanks,
Neil
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -229,3 +240,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
>> 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -125,6 +125,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -234,3 +245,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> @@ -506,3 +506,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
>> e99101a..7bd0538 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -117,6 +117,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -203,3 +214,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> @@ -299,3 +299,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
>> d320727..5b99749 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -90,6 +90,17 @@
>> compatible = "mmc-pwrseq-emmc";
>> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -167,3 +178,7 @@
>> max-speed = <1000>;
>> };
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> @@ -112,3 +112,7 @@
>> };
>> };
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
>> +};
>
^ permalink raw reply
* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Neil Armstrong @ 2016-11-30 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3713265.h5djxipShb@avalon>
On 11/30/2016 05:03 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> I'm afraid I don't have time for a complete review, but could you please get
> rid of the of_machine_is_compatible() calls and match on the VPU compatible
> string instead ?
Oops, I knew I forgot to change this one...
I will get rid of these for the v3.
Thanks,
Neil
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13104644.f9boR54smD@avalon>
Hi Laurent,
On 11/30/2016 04:56 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>> mode 100644
>> index 0000000..e52869a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,101 @@
[...]
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +VPU: Video Processing Unit
>> +--------------------------
>> +
>> +Required properties:
>> +- compatible: value should be different for each SoC family as :
>> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> + - GXM (S912) : "amlogic,meson-gxm-vpu"
>> + followed by the common "amlogic,meson-gx-vpu"
>> +- reg: base address and size of he following memory-mapped regions :
>> + - vpu
>> + - hhi
>> + - dmc
>> +- reg-names: should contain the names of the previous memory regions
>> +- interrupts: should contain the VENC Vsync interrupt number
>> +
>> +- ports: A ports node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt.
>> + The first port should be connected to a CVBS connector endpoint if
>> available.
>
> This is a bit vague, I propose clarifying it with a description similar to the
> one in the renesas,du.txt bindings.
>
> Required nodes:
>
> The connections to the VPU output video ports are modeled using the OF graph
> bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> The following table lists for each supported model the port number
> corresponding to each DU output.
>
> Port 0 Port1 Port2 Port3
> -----------------------------------------------------------------------------
> R8A7779 (H1) DPAD 0 DPAD 1 - -
> R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
> R8A7791 (M2-W) DPAD LVDS 0 - -
> R8A7792 (V2H) DPAD 0 DPAD 1 - -
> R8A7793 (M2-N) DPAD LVDS 0 - -
> R8A7794 (E2) DPAD 0 DPAD 1 - -
> R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
> R8A7796 (M3-W) DPAD HDMI LVDS -
>
> (You should obviously replace the table with Amlogic data)
>
> It doesn't matter if the current driver implementation only supports CVBS, the
> DT bindings can already document the other ports.
>
Ok, it's a pretty table ! Will integrate this.
>> +
>> +Example:
>> +
>> +tv: connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> I'd remove the label here, as it doesn't bring any additional information.
> Unless the board you're using has a label for the connector, in case that
> label should be used.
Indeed, I already removed it in the dts.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
[...]
Thanks for the review,
Neil
^ permalink raw reply
* [PATCH v2 1/4] drm: Add support for Amlogic Meson Graphic Controller
From: Laurent Pinchart @ 2016-11-30 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-2-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
I'm afraid I don't have time for a complete review, but could you please get
rid of the of_machine_is_compatible() calls and match on the VPU compatible
string instead ?
On Wednesday 30 Nov 2016 16:43:42 Neil Armstrong wrote:
> The Amlogic Meson Display controller is composed of several components :
>
> DMC|---------------VPU (Video Processing
> Unit)----------------|------HHI------| |
> vd1 _______ _____________ _________________ | |
> D |-------| |----| | | | | HDMI
> PLL | D | vd2 | VIU | | Video Post | | Video Encoders
> |<---|-----VCLK | R |-------| |----| Processing
> | | | | | |
> osd2 | | | |---| Enci ----------|----|-----VDAC------|
> R |-------| CSC |----| Scalers | | Encp
> ----------|----|----HDMI-TX----| A | osd1 | | | Blenders | |
> Encl ----------|----|---------------|
> M |-------|______|----|____________| |________________| |
> |
> ___|__________________________________________________________|____________
> ___|
>
> VIU: Video Input Unit
> ---------------------
>
> The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> It fetches the frames addresses, stride and parameters from the "Canvas"
> memory. This part is also in charge of the CSC (Colorspace Conversion).
> It can handle 2 OSD Planes and 2 Video Planes.
>
> VPP: Video Post Processing
> --------------------------
>
> The Video Post Processing is in charge of the scaling and blending of the
> various planes into a single pixel stream.
> There is a special "pre-blending" used by the video planes with a dedicated
> scaler and a "post-blending" to merge with the OSD Planes.
> The OSD planes also have a dedicated scaler for one of the OSD.
>
> VENC: Video Encoders
> --------------------
>
> The VENC is composed of the multiple pixel encoders :
> - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> - ENCP : Progressive Video Encoder for HDMI
> - ENCL : LCD LVDS Encoder
> The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
> tree and provides the scanout clock to the VPP and VIU.
> The ENCI is connected to a single VDAC for Composite Output.
> The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
>
> This driver is a DRM/KMS driver using the following DRM components :
> - GEM-CMA
> - PRIME-CMA
> - Atomic Modesetting
> - FBDev-CMA
>
> For the following SoCs :
> - GXBB Family (S905)
> - GXL Family (S905X, S905D)
> - GXM Family (S912)
>
> The current driver only supports the CVBS PAL/NTSC output modes, but the
> CRTC/Planes management should support bigger modes.
> But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
> a second time.
>
> The Device Tree bindings makes use of the endpoints video interface
> definitions to connect to the optional CVBS and in the future the HDMI
> Connector nodes.
>
> HDMI Support is planned for a next release.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/meson/Kconfig | 9 +
> drivers/gpu/drm/meson/Makefile | 4 +
> drivers/gpu/drm/meson/meson_canvas.c | 68 ++
> drivers/gpu/drm/meson/meson_canvas.h | 42 +
> drivers/gpu/drm/meson/meson_crtc.c | 208 +++++
> drivers/gpu/drm/meson/meson_crtc.h | 32 +
> drivers/gpu/drm/meson/meson_drv.c | 343 ++++++++
> drivers/gpu/drm/meson/meson_drv.h | 60 ++
> drivers/gpu/drm/meson/meson_plane.c | 230 +++++
> drivers/gpu/drm/meson/meson_plane.h | 30 +
> drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++++++++++
> drivers/gpu/drm/meson/meson_vclk.c | 167 ++++
> drivers/gpu/drm/meson/meson_vclk.h | 34 +
> drivers/gpu/drm/meson/meson_venc.c | 254 ++++++
> drivers/gpu/drm/meson/meson_venc.h | 72 ++
> drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 +++++++
> drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
> drivers/gpu/drm/meson/meson_viu.c | 331 ++++++++
> drivers/gpu/drm/meson/meson_viu.h | 64 ++
> drivers/gpu/drm/meson/meson_vpp.c | 162 ++++
> drivers/gpu/drm/meson/meson_vpp.h | 35 +
> 23 files changed, 3877 insertions(+)
> create mode 100644 drivers/gpu/drm/meson/Kconfig
> create mode 100644 drivers/gpu/drm/meson/Makefile
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
> create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
> create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
> create mode 100644 drivers/gpu/drm/meson/meson_drv.c
> create mode 100644 drivers/gpu/drm/meson/meson_drv.h
> create mode 100644 drivers/gpu/drm/meson/meson_plane.c
> create mode 100644 drivers/gpu/drm/meson/meson_plane.h
> create mode 100644 drivers/gpu/drm/meson/meson_registers.h
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
> create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc.h
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
> create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
> create mode 100644 drivers/gpu/drm/meson/meson_viu.c
> create mode 100644 drivers/gpu/drm/meson/meson_viu.h
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
> create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Laurent Pinchart @ 2016-11-30 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-3-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
> boards.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
> 8 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -356,5 +356,24 @@
> status = "disabled";
> };
> };
> +
> + vpu: vpu at d0100000 {
> + compatible = "amlogic,meson-gx-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port at 0 {
> + reg = <0>;
> +
> + cvbs_vdac_out: endpoint {
> + };
Endpoints require a remote-endpoint property. You should move the endpoint to
board DT files.
> + };
> + };
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
> 9696820..390f7db 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -142,6 +142,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
Unless the board has a label for the connector (either on the board, on the
casing or in the user manual) I'd leave this out. Same comment for the other
boards.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -229,3 +240,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
> 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -125,6 +125,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -234,3 +245,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -506,3 +506,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
> e99101a..7bd0538 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -117,6 +117,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -203,3 +214,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -299,3 +299,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
> d320727..5b99749 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -90,6 +90,17 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -167,3 +178,7 @@
> max-speed = <1000>;
> };
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -112,3 +112,7 @@
> };
> };
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2734274.BAOZxRirYz@avalon>
Hi Laurent,
On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>
> I forgot to mention that the file should not be named meson-drm.txt as DRM is
> a Linux-specific concept. You can name it meson.txt, but a better option would
> be amlogic,meson.txt. By the way does it really need a subdirectory ?
I took example of the sun4i layout the naming, and no it does not need a subdirector..
I will move it to amlogic,meson.txt, seems far better.
Thanks,
Neil
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
^ permalink raw reply
* [PATCH v2 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Laurent Pinchart @ 2016-11-30 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-5-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:45 Neil Armstrong wrote:
> Add myself as maintainer for Amlogic DRM drivers.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
After updating this patch due to the rename I proposed in patch 3/4,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> MAINTAINERS | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7..b2486fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4078,6 +4078,15 @@ S: Supported
> F: drivers/gpu/drm/sun4i/
> F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>
> +DRM DRIVERS FOR AMLOGIC SOCS
> +M: Neil Armstrong <narmstrong@baylibre.com>
> +L: dri-devel at lists.freedesktop.org
> +L: linux-amlogic at lists.infradead.org
> +W: http://linux-meson.com/
> +S: Supported
> +F: drivers/gpu/drm/meson/
> +F: Documentation/devicetree/bindings/display/meson/meson-drm.txt
> +
> DRM DRIVERS FOR EXYNOS
> M: Inki Dae <inki.dae@samsung.com>
> M: Joonyoung Shim <jy0922.shim@samsung.com>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA update for v4.10
From: Arnd Bergmann @ 2016-11-30 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-2-dinguyen@kernel.org>
On Monday, November 21, 2016 10:23:09 AM CET Dinh Nguyen wrote:
> SoCFPGA update for v4.10
> - Fixup spelling error
>
Pulled into next/fixes-non-critical, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
I forgot to mention that the file should not be named meson-drm.txt as DRM is
a Linux-specific concept. You can name it meson.txt, but a better option would
be amlogic,meson.txt. By the way does it really need a subdirectory ?
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS update for v4.10, part 3
From: Arnd Bergmann @ 2016-11-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-1-dinguyen@kernel.org>
On Monday, November 21, 2016 10:23:08 AM CET Dinh Nguyen wrote:
> SoCFPGA DTS update for v4.10, part 3
> - Fine tune L2 cache configuration
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
> mode 100644
> index 0000000..e52869a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,101 @@
> +Amlogic Meson Display Controller
> +================================
> +
> +The Amlogic Meson Display controller is composed of several components
> +that are going to be documented below:
> +
> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
> + | vd1 _______ _____________ _____________ | |
> +D |-------| |----| | | | | HDMI PLL |
> +D | vd2 | VIU | | Video Post | | Video Encs |<---|-----VCLK |
> +R |-------| |----| Processing | | | | |
> + | osd2 | | | |---| Enci ------|----|-----VDAC------|
> +R |-------| CSC |----| Scalers | | Encp ------|----|----HDMI-TX----|
> +A | osd1 | | | Blenders | | Encl-------|----|---------------|
> +M |-------|______|----|____________| |____________| | |
> +___|______________________________________________________|_______________|
> +
> +
> +VIU: Video Input Unit
> +---------------------
> +
> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> +It fetches the frames addresses, stride and parameters from the "Canvas"
> memory.
> +This part is also in charge of the CSC (Colorspace Conversion).
> +It can handle 2 OSD Planes and 2 Video Planes.
> +
> +VPP: Video Post Processing
> +--------------------------
> +
> +The Video Post Processing is in charge of the scaling and blending of the
> +various planes into a single pixel stream.
> +There is a special "pre-blending" used by the video planes with a dedicated
> +scaler and a "post-blending" to merge with the OSD Planes.
> +The OSD planes also have a dedicated scaler for one of the OSD.
> +
> +VENC: Video Encoders
> +--------------------
> +
> +The VENC is composed of the multiple pixel encoders :
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
> clock
> +tree and provides the scanout clock to the VPP and VIU.
> +The ENCI is connected to a single VDAC for Composite Output.
> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> +Device Tree Bindings:
> +---------------------
> +
> +VPU: Video Processing Unit
> +--------------------------
> +
> +Required properties:
> +- compatible: value should be different for each SoC family as :
> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
> + - GXM (S912) : "amlogic,meson-gxm-vpu"
> + followed by the common "amlogic,meson-gx-vpu"
> +- reg: base address and size of he following memory-mapped regions :
> + - vpu
> + - hhi
> + - dmc
> +- reg-names: should contain the names of the previous memory regions
> +- interrupts: should contain the VENC Vsync interrupt number
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + The first port should be connected to a CVBS connector endpoint if
> available.
This is a bit vague, I propose clarifying it with a description similar to the
one in the renesas,du.txt bindings.
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
(You should obviously replace the table with Amlogic data)
It doesn't matter if the current driver implementation only supports CVBS, the
DT bindings can already document the other ports.
> +
> +Example:
> +
> +tv: connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
I'd remove the label here, as it doesn't bring any additional information.
Unless the board you're using has a label for the connector, in case that
label should be used.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + port {
> + tv_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> +};
> +
> +vpu: vpu at d0100000 {
> + compatible = "amlogic,meson-gxbb-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port at 0 {
> + cvbs_vdac_out: endpoint {
> + reg = <0>;
> + remote-endpoint = <&tv_connector_in>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
^ 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