* [PATCH 0/6] STM32F4 Add RTC & QSPI clocks
From: gabriel.fernandez at st.com @ 2016-09-30 14:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch-set introduce RTC and QSPI clocks for STM32F4 socs
RTC clock has 3 parents clock oscillators (lsi/lse/hse_rtc)
example to use rtc clock:
rtc: rtc at 40002800 {
compatible = "st,stm32-rtc";
reg = <0x40002800 0x400>;
...
clocks = <&rcc 1 CLK_RTC>;
assigned-clocks = <&rcc 1 CLK_RTC>;
assigned-clock-parents = <&rcc 1 CLK_LSE>;
...
};
Gabriel Fernandez (6):
clk: stm32f4: Add LSI & LSE clocks
ARM: dts: stm32f429: add LSI and LSE clocks
arm: stmf32: Enable SYSCON
clk: stm32f4: Add RTC clock
clk: stm32f469: Add QSPI clock
ARM: dts: stm32f429: Add QSPI clock
.../devicetree/bindings/clock/st,stm32-rcc.txt | 4 +-
arch/arm/boot/dts/stm32f429.dtsi | 18 +
arch/arm/boot/dts/stm32f469-disco.dts | 4 +
arch/arm/configs/stm32_defconfig | 1 +
drivers/clk/clk-stm32f4.c | 450 ++++++++++++++++++++-
5 files changed, 455 insertions(+), 22 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller
From: Sekhar Nori @ 2016-09-30 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475166715-7857-4-git-send-email-bgolaszewski@baylibre.com>
On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
>
> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> with some default timings for 800x600.
>
> Tested on an LCDK connected on the VGA port (the LCDC is connected to
> this port via a THS8135).
>
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz:
> - fixed whitespace errors
> - tweaked the description
> - fixed the incorrect hback-porch value
> - other minor tweaks]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> + lcd_pins: pinmux_lcd_pins {
> + pinctrl-single,bits = <
> + /*
> + * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
> + * LCD_D[6], LCD_D[7]
> + */
> + 0x40 0x22222200 0xffffff00
> + /*
> + * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
> + * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
> + */
> + 0x44 0x22222222 0xffffffff
> + /* LCD_D[8], LCD_D[9] */
> + 0x48 0x00000022 0x000000ff
> +
> + /* LCD_PCLK */
> + 0x48 0x02000000 0x0f000000
> + /* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
> + 0x4c 0x02000022 0x0f0000ff
> + >;
> + };
Since almost all boards that use LCD will configure the pins in the same
way, we can move this to da850.dtsi. Please see existing examples of the
same.
The only place where we don't do this is if the common pinmux definition
may not find much reuse because of differing nature of how the external
peripherals are interfaced.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 1/1] arm64: Add DTS support for FSL's LS1012A SoC
From: Stuart Yoder @ 2016-09-30 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472207241-18461-1-git-send-email-Bhaskar.Upadhaya@nxp.com>
> + dspi0: dspi at 2100000 {
> + compatible = "fsl,ls1012a-dspi",
> + "fsl,ls1043a-dspi",
> + "fsl,ls1021a-v1.0-dspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2100000 0x0 0x10000>;
> + interrupts = <0 64 0x4>;
> + clock-names = "dspi";
> + clocks = <&clockgen 4 0>;
> + spi-num-chipselects = <5>;
> + big-endian;
> + status = "enabled";
"enabled" is not a valid status value.
Stuart
^ permalink raw reply
* [PATCH v2 1/1] arm64: Add DTS support for FSL's LS1012A SoC
From: Stuart Yoder @ 2016-09-30 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0401MB22753C87DE074EE7BF456CE48CC10@AM4PR0401MB2275.eurprd04.prod.outlook.com>
> >> +&qspi {
> >> + num-cs = <2>;
> >> + bus-num = <0>;
> >> + status = "disabled";
> >
> >Why is it being disabled?
>
> Ok, will change like below.
> status = "okay";
The comment was not "change this to okay". The question is why is this disabled?
Can you explain why it was disabled? Should it have been disasbled? Is qspi
working and tested on this board?
>
> >
> >> + fsl,ddr-sampling-point = <4>;
> >
> >I do not find the bindings for this property, neither how driver supports it.
>
> Yes the QSPI DDR mode is not yet up-streamed, so I will remove this property as of now.
>
> >
> >> +
> >> + qflash0: s25fs512s at 0 {
> >> + compatible = "spansion,m25p80";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + spi-max-frequency = <20000000>;
> >> + m25p,fast-read;
> >> + reg = <0>;
> >> + };
> >> +};
> >> +
> >> +&i2c0 {
> >> + status = "okay";
> >> +
> >> + codec: sgtl5000 at a {
> >> + #sound-dai-cells = <0>;
> >> + compatible = "fsl,sgtl5000";
> >> + reg = <0xa>;
> >> + VDDA-supply = <®_1p8v>;
> >> + VDDIO-supply = <®_1p8v>;
> >> + clocks = <&sys_mclk>;
> >> + };
> >> +};
> >> +
> >> +&duart0 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&esdhc0 {
> >> + status = "disabled";
> >
> >We prefer to disable devices which have board level options by default in
> ><soc>.dtsi, and enable them per availability in <board>.dts.
>
> Ok , will make the status as okay i.e. status = "okay";
Again, the feedback was not "set this to okay". Why was esdhc0 set to "disabled"
here in the first place? Was there a reason?
The comment is that if there are certain boards where esdhc0 is not available,
then fsl-ls1012a.dtsi should set this to "disabled" and board .dts files should
override it.
> >
> >> +};
> >> +
> >> +&esdhc1 {
> >> + status = "disabled";
> >> +};
> >> +
> >> +&sai2 {
> >> + status = "disabled";
> >> +};
Same comment for the above nodes. The fsl-ls1012a.dtsi should set them to
disabled and any .dts file should override with "ok" if applicable.
Stuart
^ permalink raw reply
* [PATCH] drm: tilcdc: add a da850-specific compatible string
From: Bartosz Golaszewski @ 2016-09-30 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475240456-22936-1-git-send-email-bgolaszewski@baylibre.com>
2016-09-30 15:00 GMT+02:00 Bartosz Golaszewski <bgolaszewski@baylibre.com>:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
>
> Suggested-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index a694977..231f2c7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -723,6 +723,7 @@ static int tilcdc_pdev_remove(struct platform_device *pdev)
>
> static struct of_device_id tilcdc_of_match[] = {
> { .compatible = "ti,am33xx-tilcdc", },
> + { .compatible = "ti,da850-tilcdc", },
> { },
> };
> MODULE_DEVICE_TABLE(of, tilcdc_of_match);
> --
> 2.9.3
>
Superseded by v2.
^ permalink raw reply
* [PATCH v2] drm: tilcdc: add a da850-specific compatible string
From: Bartosz Golaszewski @ 2016-09-30 13:52 UTC (permalink / raw)
To: linux-arm-kernel
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- added the new compatible to the bindings documentation
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4 ++--
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index a83abd7..33b6e8a 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -1,7 +1,7 @@
Device-Tree bindings for tilcdc DRM driver
Required properties:
- - compatible: value should be "ti,am33xx-tilcdc".
+ - compatible: value should be "ti,am33xx-tilcdc" or "ti,da850-tilcdc".
- interrupts: the interrupt number
- reg: base address and size of the LCDC device
@@ -51,7 +51,7 @@ Optional nodes:
Example:
fb: fb at 4830e000 {
- compatible = "ti,am33xx-tilcdc";
+ compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index a694977..231f2c7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -723,6 +723,7 @@ static int tilcdc_pdev_remove(struct platform_device *pdev)
static struct of_device_id tilcdc_of_match[] = {
{ .compatible = "ti,am33xx-tilcdc", },
+ { .compatible = "ti,da850-tilcdc", },
{ },
};
MODULE_DEVICE_TABLE(of, tilcdc_of_match);
--
2.9.3
^ permalink raw reply related
* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Bartosz Golaszewski @ 2016-09-30 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930124942.ul737vxmdmkxqdre@gobelin>
2016-09-30 14:49 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
>> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> > Hi,
>> >
>> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>> >> Add svga timings for 1024x768 resolution to the da850-lcdk
>> >> device tree.
>> >>
>> >
>>
>> [snip]
>>
>> >
>> > Why do you also call 1024x768 svga ?
>> >
>>
>> Thanks, should have been xga. will fix in v2.
>>
>> > I don't think the LCDK can cope with this resolution at this frequency
>> > (in terms of mem bandwidth), at least that's what I observed back in
>> > August. If confirmed I think it is worth mentioning in the log at least,
>> > but then I doubt adding this config would be useful.
>> >
>>
>> Thanks for the heads up. How would that manifest itself? This seems to
>> work fine for me - I'm not getting any warnings on a simple system -
>> maybe if I added some additional memory load it would complain.
>>
>
> A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
> should suffice to make the issue visible and trigger FIFO underflows.
>
Thanks, this is correct unfortunately.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH] drm: tilcdc: add a da850-specific compatible string
From: Sekhar Nori @ 2016-09-30 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475240456-22936-1-git-send-email-bgolaszewski@baylibre.com>
On Friday 30 September 2016 06:30 PM, Bartosz Golaszewski wrote:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
>
> Suggested-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
This patch should document the new compatible in
Documentation/devicetree/bindings/..
Thanks,
Sekhar
^ permalink raw reply
* [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed
From: Robin Murphy @ 2016-09-30 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475009318-2617-6-git-send-email-eric.auger@redhat.com>
Hi Eric,
On 27/09/16 21:48, Eric Auger wrote:
> iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on
> IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap
> they reserve the IOVA window to prevent the iova allocator to
> allocate in those areas.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> drivers/iommu/dma-iommu.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/dma-iommu.h | 18 ++++++++++++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 04bbc85..db21143 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -759,3 +759,51 @@ int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
> +
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> + phys_addr_t paddr, size_t size, int prot)
> +{
> + struct iova_domain *iovad;
> + unsigned long lo, hi;
> + int ret;
> +
> + if (domain->type != IOMMU_DOMAIN_MIXED)
> + return -EINVAL;
> +
> + if (!domain->iova_cookie)
> + return -EINVAL;
> +
> + iovad = cookie_iovad(domain);
> +
> + lo = iova_pfn(iovad, iova);
> + hi = iova_pfn(iovad, iova + size - 1);
> + reserve_iova(iovad, lo, hi);
This can't work reliably - reserve_iova() will (for good reason) merge
any adjacent or overlapping entries, so any unmap is liable to free more
IOVA space than actually gets unmapped, and things will get subtly out
of sync and go wrong later.
The more general issue with this whole approach, though, is that it
effectively rules out userspace doing guest memory hotplug or similar,
and I'm not we want to paint ourselves into that corner. Basically, as
soon as a device is attached to a guest, the entirety of the unallocated
IPA space becomes reserved, and userspace can never add anything further
to it, because any given address *might* be in use for an MSI mapping.
I think it still makes most sense to stick with the original approach of
cooperating with userspace to reserve a bounded area - it's just that we
can then let automatic mapping take care of itself within that area.
Speaking of which, I've realised the same fundamental reservation
problem already applies to PCI without ACS, regardless of MSIs. I just
tried on my Juno with guest memory placed at 0x4000000000, (i.e.
matching the host PA of the 64-bit PCI window), and sure enough when the
guest kicks off some DMA on the passed-through NIC, the root complex
interprets the guest IPA as (unsupported) peer-to-peer DMA to a BAR
claimed by the video card, and it fails. I guess this doesn't get hit in
practice on x86 because the guest memory map is unlikely to be much
different from the host's.
It seems like we basically need a general way of communicating fixed and
movable host reservations to userspace :/
Robin.
> + ret = iommu_map(domain, iova, paddr, size, prot);
> + if (ret)
> + free_iova(iovad, lo);
> + return ret;
> +}
> +EXPORT_SYMBOL(iommu_dma_map_mixed);
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> + size_t size)
> +{
> + struct iova_domain *iovad;
> + unsigned long lo;
> + size_t ret;
> +
> + if (domain->type != IOMMU_DOMAIN_MIXED)
> + return -EINVAL;
> +
> + if (!domain->iova_cookie)
> + return -EINVAL;
> +
> + iovad = cookie_iovad(domain);
> + lo = iova_pfn(iovad, iova);
> +
> + ret = iommu_unmap(domain, iova, size);
> + if (ret == size)
> + free_iova(iovad, lo);
> + return ret;
> +}
> +EXPORT_SYMBOL(iommu_dma_unmap_mixed);
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 1c55413..f2aa855 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -70,6 +70,12 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> dma_addr_t base, u64 size);
>
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> + phys_addr_t paddr, size_t size, int prot);
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> + size_t size);
> +
> #else
>
> struct iommu_domain;
> @@ -99,6 +105,18 @@ static inline int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> return -ENODEV;
> }
>
> +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> + phys_addr_t paddr, size_t size, int prot)
> +{
> + return -ENODEV;
> +}
> +
> +size_t iommu_dma_unmap_mixed(struct iommu_domain *domain, unsigned long iova,
> + size_t size)
> +{
> + return -ENODEV;
> +}
> +
> #endif /* CONFIG_IOMMU_DMA */
> #endif /* __KERNEL__ */
> #endif /* __DMA_IOMMU_H */
>
^ permalink raw reply
* [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller
From: Karl Beldan @ 2016-09-30 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJU45aP7=vs5h6s2T=v-gB5q06AvhGJdcRV9WDgNzs+Enw@mail.gmail.com>
On Fri, Sep 30, 2016 at 11:42:14AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:40 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
> >> From: Karl Beldan <kbeldan@baylibre.com>
> >>
> >> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> >> with some default timings for 800x600.
> >>
> >> Tested on an LCDK connected on the VGA port (the LCDC is connected to
> >> this port via a THS8135).
> >>
> >> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> >> [Bartosz:
> >> - fixed whitespace errors
> >> - tweaked the description
> >
> > The description tweak you mention is the removal of an erratum which is
> > in the mentioned commit I put on github @
> > (https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
> > it included an erratum wrt FIFO threshold I think is worth keeping:
> > {
> > There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
> > [...]
> > "This problem may occur if the LCDC FIFO threshold size (
> > LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
> > Increasing the FIFO threshold size will reduce or eliminate underflows.
> > Setting the threshold size to 256 double words or larger is
> > recommended."
> > }
>
> Isn't this the issue that is fixed by changing the memory priority for lcdc?
>
It is possible that the erratum and the memory priority settings try to
address the symptoms of the same underlying issue, it is impossible to
state with the publicly available information, however, the erratum
relates to the LCDC registers settings, namely the fifo-th propperty of
panel-info in the dts, which is really different from the memory
priority adjustments in the SYSCFG and DDR_CTL.
Regards,
Karl
> >
> >> - fixed the incorrect hback-porch value
> >
> > It can't be a fix, this value depends on the monitor connected.
> >
>
> Thanks, I'm new to drm. From reading the datasheet it seemed to me
> that this depends on the resolution. FWIW it seems that most LCDs are
> able to adjust to this themselves - I tested with two different
> displays and the value I introduced worked on both while the previous
> one shifted the image to the right. I'll look into that.
>
> >> - other minor tweaks]
> >
> > I didn't see any other change while diffing.
> >
>
> Dropped the refresh rate from the timings node name.
>
> Thanks,
> Bartosz
^ permalink raw reply
* [PATCH] arm: dts: imx6dl: force the 'compatible' field for the uart[12345] to 'fsl, imx21-uart'.
From: Giorgio Dal Molin @ 2016-09-30 13:13 UTC (permalink / raw)
To: linux-arm-kernel
Without this fix the imx uart kernel driver selects 'fsl,imx6q-uart' as
its compatible value and the port does not work properly.
The kind of malfunctioning I noticed was while receiving bytes from the
uart, sending out was OK.
Signed-off-by: Giorgio Dal Molin <iw3gtf@arcor.de>
---
arch/arm/boot/dts/imx6dl.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9a4c22c..1a1d5fd 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -131,3 +131,23 @@
&vpu {
compatible = "fsl,imx6dl-vpu", "cnm,coda960";
};
+
+&uart1 {
+ compatible = "fsl,imx21-uart";
+};
+
+&uart2 {
+ compatible = "fsl,imx21-uart";
+};
+
+&uart3 {
+ compatible = "fsl,imx21-uart";
+};
+
+&uart4 {
+ compatible = "fsl,imx21-uart";
+};
+
+&uart5 {
+ compatible = "fsl,imx21-uart";
+};
--
2.10.0
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-09-30 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e0586e9-7f95-fbab-924a-fe046892a66b@ti.com>
2016-09-30 11:34 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> Add a disabled LCDC node to be reused in device trees including
>> da850.dtsi for boards equipped with tilcdc enabled.
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz: added the commit description]
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..9f39296 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -399,6 +399,14 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + lcdc: lcdc at 213000 {
>
> node name should be generic per the ePAPR so please use "display".
>
>> + compatible = "ti,am33xx-tilcdc";
>
> Can you please introduce a da850 specific compatible. Something like:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>
I sent a relevant patch to the drm mailing list.
> Even if you dont use it in the driver today, please have it in the .dts
> I am pretty sure there will be some da850 specific tweak required for
> the LCDC at some point. Having a compatible already in place will make
> migration easier. You will have to document the compatible though.
>
> This will affect 1/6 too.
>
I'll include these changes in v2.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH] drm: tilcdc: add a da850-specific compatible string
From: Bartosz Golaszewski @ 2016-09-30 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index a694977..231f2c7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -723,6 +723,7 @@ static int tilcdc_pdev_remove(struct platform_device *pdev)
static struct of_device_id tilcdc_of_match[] = {
{ .compatible = "ti,am33xx-tilcdc", },
+ { .compatible = "ti,da850-tilcdc", },
{ },
};
MODULE_DEVICE_TABLE(of, tilcdc_of_match);
--
2.9.3
^ permalink raw reply related
* [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc
From: Peter Ujfalusi @ 2016-09-30 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475166715-7857-7-git-send-email-bgolaszewski@baylibre.com>
On 09/29/16 19:31, Bartosz Golaszewski wrote:
> Default memory settings of da850 do not meet the throughput/latency
> requirements of tilcdc. This results in the image displayed being
> incorrect and the following warning being displayed by the LCDC
> drm driver:
>
> tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>
> Reconfigure the LCDC priority to the highest. This is a workaround
> for the da850-lcdk board which has the LCD controller enabled in
> the device tree, but a long-term, system-wide fix is needed for
> all davinci boards.
>
> This patch has been modified for mainline linux. It comes from a
> downstream TI release for da850[1].
>
> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>
> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 43 ++++++++++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 4 +++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index f8ecc02..9d29670 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -44,9 +44,52 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
>
> +/*
> + * Adjust the default memory settings to cope with the LCDC
> + *
> + * REVISIT: This issue occurs on other davinci boards as well. Find
> + * a proper system-wide fix.
> + */
> +static void da850_lcdc_adjust_memory_bandwidth(void)
> +{
> + void __iomem *cfg_mstpri1_base;
> + void __iomem *cfg_mstpri2_base;
> + void __iomem *emifb;
> + u32 val;
> +
> + /*
> + * Default master priorities in reg 0 are all lower by default than LCD
> + * which is set below to 0. Hence don't need to change here.
> + */
> +
> + /* set EDMA30TC0 and TC1 to lower than LCDC (4 < 0) */
> + cfg_mstpri1_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI1_REG);
> + val = __raw_readl(cfg_mstpri1_base);
> + val &= 0xFFFF00FF;
> + val |= 4 << 8; /* 0-high, 7-low priority*/
> + val |= 4 << 12; /* 0-high, 7-low priority*/
> + __raw_writel(val, cfg_mstpri1_base);
> +
> + /*
> + * Reconfigure the LCDC priority to the highest to ensure that
> + * the throughput/latency requirements for the LCDC are met.
> + */
> + cfg_mstpri2_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI2_REG);
> +
> + val = __raw_readl(cfg_mstpri2_base);
> + val &= 0x0fffffff;
> + __raw_writel(val, cfg_mstpri2_base);
> +
> + /* set BPRIO */
> + emifb = ioremap(DA8XX_DDR_CTL_BASE, SZ_4K);
> + __raw_writel(0x20, emifb + DA8XX_PBBPR_REG);
> + iounmap(emifb);
Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
0x20)? Most probably it is, but this setting has nothing to do with LCDC.
The whole priority configuration has nothing to do with the LCDC, it is a
system level priority.
Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
highest priority?
> +}
> +
> static void __init da850_init_machine(void)
> {
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> + da850_lcdc_adjust_memory_bandwidth();
> }
>
> static const char *const da850_boards_compat[] __initconst = {
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index f9f9713..5549eff 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -56,6 +56,8 @@ extern unsigned int da850_max_speed;
> #define DA8XX_SYSCFG0_VIRT(x) (da8xx_syscfg0_base + (x))
> #define DA8XX_JTAG_ID_REG 0x18
> #define DA8XX_HOST1CFG_REG 0x44
> +#define DA8XX_MSTPRI1_REG 0x114
> +#define DA8XX_MSTPRI2_REG 0x118
> #define DA8XX_CHIPSIG_REG 0x174
> #define DA8XX_CFGCHIP0_REG 0x17c
> #define DA8XX_CFGCHIP1_REG 0x180
> @@ -79,6 +81,8 @@ extern unsigned int da850_max_speed;
> #define DA8XX_AEMIF_CTL_BASE 0x68000000
> #define DA8XX_SHARED_RAM_BASE 0x80000000
> #define DA8XX_ARM_RAM_BASE 0xffff0000
> +#define DA8XX_DDR_CTL_BASE 0xB0000000
> +#define DA8XX_PBBPR_REG 0x00000020
>
> void da830_init(void);
> void da850_init(void);
>
--
P?ter
^ permalink raw reply
* [PATCH v2] arm64: make rpm failed due to incorrect path to Image.gz
From: Vadim Lomovtsev @ 2016-09-30 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930091414.GE10184@arm.com>
On Fri, Sep 30, 2016 at 10:14:15AM +0100, Will Deacon wrote:
> On Fri, Sep 30, 2016 at 12:03:26AM -0700, Vadim Lomovtsev wrote:
> > [Adding Will Deacon]
> > Sorry, should do this at the very beginning. (
> >
> > On Thu, Sep 29, 2016 at 07:46:07AM -0700, Vadim Lomovtsev wrote:
> > > The "make rpm" and "make rpm-pkg" commands for arm64 platform
> > > are broken due to rpmbuild couldn't find Image.gz file at
> > > default location (which is kernel src root):
> > > cp: cannot stat 'Image.gz': No such file or directory
> > > error: Bad exit status from /var/tmp/rpm-tmp.ocFBmP (%install)
> > >
> > > While the correct path to arm64 kernel image file
> > > is "arch/arm64/boot/Image.gz".
> > >
> > > The exact file name (Image.gz) is stored at KBUILD_IMAGE variable
> > > and read by rpmbuild with "make image_name" command at
> > > install phase after kernel build is complete.
> > >
> > > Accordingly to Michal's Marek comment the KBUILD_IMAGE
> > > variable has to be set to point to actual file.
> > >
> > > Since the KBUILD_IMAGE variable is used in general cases of
> > > build we need to prevent other build types breakage by changing it.
> > >
> > > The solution is to add to arch/arm64/Makefie extra target "image_name"
> > > with dependency "KBUILD_IMAGE:=<proper path to Image.gz file>".
> > > Thus it will allow to set proper path to Image.gz file only for
> > > the "image_name" build target and this exact value will be picked up
> > > while rpm build install phase.
> > >
> > > Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > > ---
> > > arch/arm64/Makefile | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index ab51aed..09926d3 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -101,6 +101,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
> > >
> > > boot := arch/arm64/boot
> > >
> > > +image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE)
> > > +
> > > Image: vmlinux
> > > $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>
> It might be worth fixing the other architectures that just set KBUILD_IMAGE
> to the filename too. Then you could remove the bodge from
> scripts/package/builddeb that tries to support both formats.
>
> Will
>
Agree.
And I would do that but I have no other setup except arm64
and x86 to test such changes.
However, possible solution could be in the same manner:
add extra rule into make file to provide correct KBUILD_IMAGE
value by "make image_name" command. Also builddeb script should
be updated with such command call before copy. Thus for each
architecture it would be possible to provide correct path along
with filename.
Vadim
^ permalink raw reply
* [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution
From: Karl Beldan @ 2016-09-30 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJVA+p1st7HzwoOJftArqpY-wUQb8WKbQFAEWnBOysxF6w@mail.gmail.com>
On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> >> Add svga timings for 1024x768 resolution to the da850-lcdk
> >> device tree.
> >>
> >
>
> [snip]
>
> >
> > Why do you also call 1024x768 svga ?
> >
>
> Thanks, should have been xga. will fix in v2.
>
> > I don't think the LCDK can cope with this resolution at this frequency
> > (in terms of mem bandwidth), at least that's what I observed back in
> > August. If confirmed I think it is worth mentioning in the log at least,
> > but then I doubt adding this config would be useful.
> >
>
> Thanks for the heads up. How would that manifest itself? This seems to
> work fine for me - I'm not getting any warnings on a simple system -
> maybe if I added some additional memory load it would complain.
>
A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
should suffice to make the issue visible and trigger FIFO underflows.
Regards,
Karl
^ permalink raw reply
* [PATCH v2 2/2] drm: zte: add initial vou drm driver
From: Emil Velikov @ 2016-09-30 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474727185-24180-3-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
A couple of fly-by suggestions, which I hope you'll find useful :-)
On 24 September 2016 at 15:26, Shawn Guo <shawn.guo@linaro.org> wrote:
> +
> + val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
To save some writing/minimise the chances to typos getting, in you can
have single/collection to static inline functions similar to msm [1].
On a similar note inline wrappers zte_read/write/mask (around
writel/readl) will provide quite useful for debugging/tracing :-)
[1] drivers/gpu/drm/msm/adreno/a4xx.xml.h
> + if (IS_ERR(zcrtc->pixclk))
> + return ERR_PTR(PTR_ERR(zcrtc->pixclk));
You might want to s/ERR_PTR(PTR_ERR// or s/ERR_PTR(PTR_ERR/ERR_CAST/
through the patch.
> +static int zx_drm_bind(struct device *dev)
> +{
> + struct drm_device *drm;
> + struct zx_drm_private *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + drm = drm_dev_alloc(&zx_drm_driver, dev);
> + if (!drm)
> + return -ENOMEM;
> +
> + drm->dev_private = priv;
> + dev_set_drvdata(dev, drm);
> +
> + drm_mode_config_init(drm);
> + drm->mode_config.min_width = 16;
> + drm->mode_config.min_height = 16;
> + drm->mode_config.max_width = 4096;
> + drm->mode_config.max_height = 4096;
> + drm->mode_config.funcs = &zx_drm_mode_config_funcs;
> +
> + ret = drm_dev_register(drm, 0);
The documentation states that drm_dev_register() should be called
after the hardware is setup. which some drivers seems to interpret as
...
> + if (ret)
> + goto out_free;
> +
> + ret = component_bind_all(dev, drm);
> + if (ret) {
> + DRM_ERROR("Failed to bind all components\n");
> + goto out_unregister;
> + }
> +
> + ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> + if (ret < 0) {
> + DRM_ERROR("failed to initialise vblank\n");
> + goto out_unbind;
> + }
> +
> + /*
> + * We will manage irq handler on our own. In this case, irq_enabled
> + * need to be true for using vblank core support.
> + */
> + drm->irq_enabled = true;
> +
> + drm_mode_config_reset(drm);
> + drm_kms_helper_poll_init(drm);
> +
> + priv->fbdev = drm_fbdev_cma_init(drm, 32, drm->mode_config.num_crtc,
> + drm->mode_config.num_connector);
... calling it after these. If that's the correct case - perhaps we
can throw a WARN or similar within the above functions to catch
present/future misuse ?
> + if (IS_ERR(priv->fbdev)) {
> + ret = PTR_ERR(priv->fbdev);
> + priv->fbdev = NULL;
> + goto out_fini;
> + }
> +
> + return 0;
> +
> +out_fini:
> + drm_kms_helper_poll_fini(drm);
> + drm_mode_config_cleanup(drm);
> + drm_vblank_cleanup(drm);
> +out_unbind:
> + component_unbind_all(dev, drm);
> +out_unregister:
> + drm_dev_unregister(drm);
> +out_free:
> + dev_set_drvdata(dev, NULL);
> + drm_dev_unref(drm);
> + return ret;
> +}
> +
> +static void zx_drm_unbind(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> + struct zx_drm_private *priv = drm->dev_private;
> +
> + if (priv->fbdev) {
> + drm_fbdev_cma_fini(priv->fbdev);
> + priv->fbdev = NULL;
> + }
> + drm_kms_helper_poll_fini(drm);
> + component_unbind_all(dev, drm);
> + drm_vblank_cleanup(drm);
> + drm_mode_config_cleanup(drm);
> + drm_dev_unregister(drm);
> + drm_dev_unref(drm);
> + drm->dev_private = NULL;
> + dev_set_drvdata(dev, NULL);
This and the teardown path in bind() are asymmetrical. Furthermore you
want to call drm_dev_unregister() first, according to its
documentation.
As mentioned above - perhaps it's worth providing feedback for drivers
which get the order wrong ?
> +static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
> +{
> +
> + clk_prepare_enable(hdmi->cec_clk);
> + clk_prepare_enable(hdmi->osc_clk);
> + clk_prepare_enable(hdmi->xclk);
> +
> + ret = zx_hdmi_register(drm, hdmi);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static void zx_hdmi_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct zx_hdmi *hdmi = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(hdmi->cec_clk);
> + clk_disable_unprepare(hdmi->osc_clk);
> + clk_disable_unprepare(hdmi->xclk);
Nit: you want the teardown to happen in reverse order of the setup. I
might have missed a few similar cases within the patch, so please
double-check.
> +static int zx_gl_get_fmt(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_ARGB8888:
> + case DRM_FORMAT_XRGB8888:
> + return GL_FMT_ARGB8888;
> + case DRM_FORMAT_RGB888:
> + return GL_FMT_RGB888;
> + case DRM_FORMAT_RGB565:
> + return GL_FMT_RGB565;
> + case DRM_FORMAT_ARGB1555:
> + return GL_FMT_ARGB1555;
> + case DRM_FORMAT_ARGB4444:
> + return GL_FMT_ARGB4444;
> + default:
> + WARN_ONCE(1, "invalid pixel format %d\n", format);
> + return -EINVAL;
Afaics the only user of this is atomic_update() and that function
cannot fail. You might want to move this to the _check() function.
Same logic goes for the rest of the driver, in case I've missed any.
Regards,
Emil
^ permalink raw reply
* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Richard Genoud @ 2016-09-30 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930115424.yhy6f72jomz5bknw@piout.net>
2016-09-30 13:54 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 30/09/2016 at 13:45:47 +0200, Richard Genoud wrote :
>> 2016-09-30 13:16 GMT+02:00 Alexandre Belloni
>> <alexandre.belloni@free-electrons.com>:
>> > On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
>> >> Anyway, the problematics setups are all the setups with USMODE_HWHS
>> >> enabled on platform without Fifos or PDC,
>> >> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
>> >>
>> >
>> > This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
>> > Please, don't break those platforms.
>> >
>> > The only affected platforms are sam9x5, sama5d3 and sama5d4.
>> Have you tested them ?
>>
>> And why are you saying that rm9200 and g45 will be broken with this patch ?
>> If they have a pdc, they will fall in the case:
>> (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
>> and thus use:
>> mode |= ATMEL_US_USMODE_HWHS;
>>
>> won't they ?
>
> Well, this patch wouldn't have my ack if it was breaking them.
It's not.
Read the code.
>However, I'm still not sure about 3/3.
As I said 2 weeks from now ( https://lkml.org/lkml/2016/9/14/263 ) the
only case where
we would want to drop the CRTSCTS flag is when there's no pin muxed
for CTS/RTS nor GPIOs.
Fell free to give a patch for that.
To be clear : this patch (2/3) unbreaks ALL platforms with GPIOs as CTS/RTS
and 3/3 unbreaks sam9x5 / sama5d3 / sama5d4 platform with CTS/RTS as !GPIOs.
^ permalink raw reply
* [PATCH v4 5/5] ARM: sunxi: Enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..d830e258db59 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -98,6 +98,7 @@ CONFIG_MEDIA_RC_SUPPORT=y
CONFIG_RC_DEVICES=y
CONFIG_IR_SUNXI=y
CONFIG_DRM=y
+CONFIG_DRM_RGB_TO_VGA=y
CONFIG_DRM_SUN4I=y
CONFIG_FB=y
CONFIG_FB_SIMPLE=y
--
2.9.3
^ permalink raw reply related
* [PATCH v4 4/5] ARM: multi_v7: enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..22ef41afc658 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -567,6 +567,7 @@ CONFIG_DRM=y
CONFIG_DRM_I2C_ADV7511=m
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
+CONFIG_DRM_RGB_TO_VGA=m
CONFIG_DRM_NXP_PTN3460=m
CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_NOUVEAU=m
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/5] ARM: sun5i: a13-olinuxino: Enable VGA bridge
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index b3c234c65ea1..01ce7ea9032d 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -72,6 +72,47 @@
default-state = "on";
};
};
+
+ bridge {
+ compatible = "rgb-to-vga-bridge";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
+};
+
+&be0 {
+ status = "okay";
};
&ehci0 {
@@ -211,6 +252,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 239 +++++++++++++++++++++
4 files changed, 295 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
diff --git a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
new file mode 100644
index 000000000000..a8375bc1f9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
@@ -0,0 +1,48 @@
+Dumb RGB to VGA bridge
+----------------------
+
+This binding is aimed for dumb RGB to VGA bridges that do not require
+any configuration.
+
+Required properties:
+
+- compatible: Must be "rgb-to-vga-bridge"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+
+Example
+-------
+
+bridge {
+ compatible = "rgb-to-vga-bridge";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e678052d..d690398c541c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -17,6 +17,13 @@ config DRM_ANALOGIX_ANX78XX
the HDMI output of an application processor to MyDP
or DisplayPort.
+config DRM_RGB_TO_VGA
+ tristate "Dumb RGB to VGA Bridge support"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Support for passive RGB to VGA bridges
+
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e878f5..3bb8cbe09fe9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_RGB_TO_VGA) += rgb-to-vga.o
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/rgb-to-vga.c b/drivers/gpu/drm/bridge/rgb-to-vga.c
new file mode 100644
index 000000000000..14843baa5d11
--- /dev/null
+++ b/drivers/gpu/drm/bridge/rgb-to-vga.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2015-2016 Free Electrons
+ * Copyright (C) 2015-2016 NextThing Co
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+struct dumb_vga {
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_adapter *ddc;
+};
+
+static inline struct dumb_vga *
+drm_bridge_to_dumb_vga(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct dumb_vga, bridge);
+}
+
+static inline struct dumb_vga *
+drm_connector_to_dumb_vga(struct drm_connector *connector)
+{
+ return container_of(connector, struct dumb_vga, connector);
+}
+
+static int dumb_vga_get_modes(struct drm_connector *connector)
+{
+ struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+ struct edid *edid;
+ int ret;
+
+ if (IS_ERR(vga->ddc))
+ goto fallback;
+
+ edid = drm_get_edid(connector, vga->ddc);
+ if (!edid) {
+ DRM_INFO("EDID readout failed, falling back to standard modes\n");
+ goto fallback;
+ }
+
+ drm_mode_connector_update_edid_property(connector, edid);
+ return drm_add_edid_modes(connector, edid);
+
+fallback:
+ /*
+ * In case we cannot retrieve the EDIDs (broken or missing i2c
+ * bus), fallback on the XGA standards
+ */
+ ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+ /* And prefer a mode pretty much anyone can handle */
+ drm_set_preferred_mode(connector, 1024, 768);
+
+ return ret;
+}
+
+static struct drm_encoder *
+dumb_vga_best_encoder(struct drm_connector *connector)
+{
+ struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+
+ return vga->bridge.encoder;
+}
+
+static const struct drm_connector_helper_funcs dumb_vga_con_helper_funcs = {
+ .get_modes = dumb_vga_get_modes,
+};
+
+static enum drm_connector_status
+dumb_vga_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
+
+ /*
+ * Even if we have an I2C bus, we can't assume that the cable
+ * is disconnected if drm_probe_ddc fails. Some cables don't
+ * wire the DDC pins, or the I2C bus might not be working at
+ * all.
+ */
+ if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ return connector_status_connected;
+
+ return connector_status_unknown;
+}
+
+static void
+dumb_vga_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs dumb_vga_con_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .detect = dumb_vga_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = dumb_vga_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int dumb_vga_attach(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Missing encoder\n");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(&vga->connector,
+ &dumb_vga_con_helper_funcs);
+ ret = drm_connector_init(bridge->dev, &vga->connector,
+ &dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_mode_connector_attach_encoder(&vga->connector,
+ bridge->encoder);
+
+ return 0;
+}
+
+static void dumb_vga_nop(struct drm_bridge *bridge) {};
+
+static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
+ .attach = dumb_vga_attach,
+};
+
+static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
+{
+ struct device_node *end_node, *phandle, *remote;
+ struct i2c_adapter *ddc;
+
+ end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+ if (!end_node) {
+ dev_err(dev, "Missing connector endpoint\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ remote = of_graph_get_remote_port_parent(end_node);
+ of_node_put(end_node);
+ if (!remote) {
+ dev_err(dev, "Enable to parse remote node\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
+ of_node_put(remote);
+ if (!phandle)
+ return ERR_PTR(-ENODEV);
+
+ ddc = of_get_i2c_adapter_by_node(phandle);
+ of_node_put(phandle);
+ if (!ddc)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return ddc;
+}
+
+static int dumb_vga_probe(struct platform_device *pdev)
+{
+ struct dumb_vga *vga;
+ int ret;
+
+ vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
+ if (!vga)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, vga);
+
+ vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
+ if (IS_ERR(vga->ddc)) {
+ if (PTR_ERR(vga->ddc) == -ENODEV) {
+ dev_info(&pdev->dev,
+ "No i2c bus specified... Disabling EDID readout\n");
+ } else {
+ dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
+ return PTR_ERR(vga->ddc);
+ }
+ }
+
+ vga->bridge.funcs = &dumb_vga_bridge_funcs;
+ vga->bridge.of_node = pdev->dev.of_node;
+
+ ret = drm_bridge_add(&vga->bridge);
+ if (ret && !IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return ret;
+}
+
+static int dumb_vga_remove(struct platform_device *pdev)
+{
+ struct dumb_vga *vga = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(&vga->bridge);
+
+ if (!IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return 0;
+}
+
+static const struct of_device_id dumb_vga_match[] = {
+ { .compatible = "rgb-to-vga-bridge" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dumb_vga_match);
+
+struct platform_driver dumb_vga_driver = {
+ .probe = dumb_vga_probe,
+ .remove = dumb_vga_remove,
+ .driver = {
+ .name = "rgb-to-vga-bridge",
+ .of_match_table = dumb_vga_match,
+ },
+};
+module_platform_driver(dumb_vga_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Dumb RGB to VGA bridge driver");
+MODULE_LICENSE("GPL");
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/5] drm/sun4i: rgb: Remove the bridge enable/disable functions
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930121352.30184-1-maxime.ripard@free-electrons.com>
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 4e4bea6f395c..d198ad7e5323 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -155,9 +155,6 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
if (!IS_ERR(tcon->panel))
drm_panel_prepare(tcon->panel);
- /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
- drm_bridge_enable(encoder->bridge);
-
sun4i_tcon_channel_enable(tcon, 0);
if (!IS_ERR(tcon->panel))
@@ -177,9 +174,6 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
sun4i_tcon_channel_disable(tcon, 0);
- /* encoder->bridge can be NULL; drm_bridge_disable checks for it */
- drm_bridge_disable(encoder->bridge);
-
if (!IS_ERR(tcon->panel))
drm_panel_unprepare(tcon->panel);
}
--
2.9.3
^ permalink raw reply related
* [PATCH v4 0/5] drm: Add Support for Passive RGB to VGA bridges
From: Maxime Ripard @ 2016-09-30 12:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.
This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.
Let me know what you think,
Maxime
Changes from v3:
- Depends on OF in Kconfig
- Fixed typos in the driver comments
- Removed the mention of a "passive" bridge in the bindings doc
- Made the strcuture const
- Removed the nops and best_encoders implementations
- Removed the call to drm_bridge_enable in the sun4i driver
Changes from v2:
- Changed the compatible as suggested
- Rebased on top 4.8
Changes from v1:
- Switch to using a vga-connector
- Use drm_encoder bridge pointer instead of doing our own
- Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
- Switch to of_i2c_get_adapter by node, and put the reference when done
- Rebased on linux-next
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 239 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 -
8 files changed, 351 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
--
2.9.3
^ permalink raw reply
* [PATCHv4 2/3] tty/serial: at91: fix hardware handshake with GPIOs
From: Alexandre Belloni @ 2016-09-30 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACQ1gAg21UEeyT_yGed58HB1gkwfg4LA8u5AVMkKsY=d5-EbMQ@mail.gmail.com>
On 30/09/2016 at 13:45:47 +0200, Richard Genoud wrote :
> 2016-09-30 13:16 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
> > On 30/09/2016 at 13:04:28 +0200, Richard Genoud wrote :
> >> Anyway, the problematics setups are all the setups with USMODE_HWHS
> >> enabled on platform without Fifos or PDC,
> >> i.e. all platforms but sama5d2 (Cyrille, correct me if I'm wrong).
> >>
> >
> > This is a wrong assumption, at91rm9200 to at91sam9g45 all have a pdc.
> > Please, don't break those platforms.
> >
> > The only affected platforms are sam9x5, sama5d3 and sama5d4.
> Have you tested them ?
>
> And why are you saying that rm9200 and g45 will be broken with this patch ?
> If they have a pdc, they will fall in the case:
> (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
> and thus use:
> mode |= ATMEL_US_USMODE_HWHS;
>
> won't they ?
Well, this patch wouldn't have my ack if it was breaking them. However,
I'm still not sure about 3/3.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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