* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Jyri Sarha @ 2016-11-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-2-git-send-email-bgolaszewski@baylibre.com>
On 11/21/16 19:16, Bartosz Golaszewski wrote:
> It has been determined that the highest resolution supported correctly
> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
> crtc_max_width().
>
I don't think this is the right way to limit the supported video modes.
There is technically there is no such limit, is there?
If memory bandwidth is limiting the functionality of higher resolutions,
you should use "max-bandwidth" tilcdc device-tree property [1].
Cheers,
Jyri
[1] In "Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt":
Optional properties:
- max-bandwidth: The maximum pixels per second that the memory
interface / lcd controller combination can sustain
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index dfe3dd0..9081de5 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -683,7 +683,7 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
> int max_width = 0;
>
> if (priv->rev == 1)
> - max_width = 1024;
> + max_width = 800;
> else if (priv->rev == 2)
> max_width = 2048;
>
>
^ permalink raw reply
* [PATCH] arm64: dts: r8a7796: Add all MSIOF nodes
From: Geert Uytterhoeven @ 2016-11-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
Add the device nodes for all MSIOF SPI controllers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Tested with MSIOF2(B) on EXIO connector D of r8a7796/salvator-x, using
spidev, gpio-74x164, and a logic analyzer.
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d2f1925552..c34c684088542850 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -368,6 +368,60 @@
status = "disabled";
};
+ msiof0: spi at e6e90000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6e90000 0 0x0064>;
+ interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 211>;
+ dmas = <&dmac1 0x41>, <&dmac1 0x40>,
+ <&dmac2 0x41>, <&dmac2 0x40>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof1: spi at e6ea0000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6ea0000 0 0x0064>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 210>;
+ dmas = <&dmac1 0x43>, <&dmac1 0x42>,
+ <&dmac2 0x43>, <&dmac2 0x42>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof2: spi at e6c00000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c00000 0 0x0064>;
+ interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 209>;
+ dmas = <&dmac0 0x45>, <&dmac0 0x44>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof3: spi at e6c10000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c10000 0 0x0064>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 208>;
+ dmas = <&dmac0 0x47>, <&dmac0 0x46>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7796",
"renesas,rcar-dmac";
--
1.9.1
^ permalink raw reply related
* pull request: linux-firmware: Update Mediatek MT8173 VPU firmware
From: Kyle McMartin @ 2016-11-21 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478866149-2023-1-git-send-email-andrew-ct.chen@mediatek.com>
On Fri, Nov 11, 2016 at 08:09:08PM +0800, Andrew-CT Chen wrote:
> Hi linux-firmware maintainers,
>
> The following changes since commit a179db97914da5e650c21ba8f9b0bae04a0f8a41:
>
> amdgpu: update SMC firmware for VI parts (2016-10-05 10:30:11 -0700)
>
> are available in the git repository at:
>
> https://github.com/andrewct-chen/linux_fw_vpu_v1.0.3.git v1.0.3
>
pulled, thanks.
--kyle
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2016-11-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d414c4d-3d08-f3d9-2bc5-aa90c8a631ce@lechnology.com>
On Mon, Nov 21, 2016 at 6:04 PM, David Lechner <david@lechnology.com> wrote:
> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>
>> This adds the DT node for the ohci controller and
>> enables it for the omapl138-lckd platform.
>>
>> DEPENDENCIES:
>>
>> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
>> https://lkml.org/lkml/2016/11/21/558
>>
>> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
>> https://lkml.org/lkml/2016/11/4/465
>>
>> Axel Haslam (2):
>> ARM: dts: da850: Add usb device node
>> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>>
>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>> 2 files changed, 16 insertions(+)
>>
>
> It does not look like you rebased these patches. Sekhar pushed the musb
> counterpart to v4.10/dt yesterday, which will cause conflicts with this
> series.
>
> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
Hi David,
i verified that they apply to the current linux-davinci/master.
Anyways, i can rebase
and resend once the dependencies are met, and we are ready to merge it.
Regards
Axel.
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013ba47-e7e4-045e-0232-4ebd7450c3ad@ti.com>
2016-11-21 18:26 GMT+01:00 Jyri Sarha <jsarha@ti.com>:
> On 11/21/16 19:16, Bartosz Golaszewski wrote:
>> It has been determined that the highest resolution supported correctly
>> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
>> crtc_max_width().
>>
>
> I don't think this is the right way to limit the supported video modes.
> There is technically there is no such limit, is there?
>
> If memory bandwidth is limiting the functionality of higher resolutions,
> you should use "max-bandwidth" tilcdc device-tree property [1].
>
> Cheers,
> Jyri
>
Will do, thanks.
Bartosz Golaszewski
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121140349.GG1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > remove, I've added it because I was getting a ->disable() hook call
> > > > before any ->enable() was called at startup time. I need to revisit
> > > > this as I remember Daniel was commenting that this was not needed.
> > >
> > > Removing that test results in:
> > >
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > >
> > > and the kernel hanging, seemingly in an IRQs-off region.
> >
> > Right, I need to sort this one out. Are you doing these tests out of
> > some tagged branch that I can get in sync with?
Hi Russell,
>
> No, not yet, and some of the changes I have are rather hacky.
>
> I do always build my full tree of patches (which is currently running at
> around 320 patches at the moment) but I never share that entire patch
> set. However, none of those touch i2c (apart from the ones I've recently
> posted) and the only patches touching hdlcd are those I've posted so far.
>
> Most of the problems I'm finding are through trying basic stuff - I'm not
> doing anything special or unusual to find them, at the moment quite
> literally just starting Xorg up and shutting it down. For example, the
> above was caused by logging in on serial, running:
>
> Xorg -terminate -verbose
>
> and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> prompts on both the "framebuffer" and serial - I don't want Xorg coming
> up when the machine is booting for its nightly KVM boot tests.)
>
> I'm afraid that when I try someone elses code, I have a tendency to find
> loads of seemingly trivial bugs when I try putting it through some basic
> tests.
I'm not being able to reproduce your bug conditions. I'm running the following
setup when testing:
- mainline v4.9-rc6
- edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
- patched tda998x_drv.c to set interlace_allowed = 0, see below why
- modified the hdlcd_crtc.c file with the following patch:
-8<-----------------------------------------------------------------------
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae..656dc43 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
- if (!crtc->state->active)
- return;
-
+ drm_crtc_vblank_off(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
clk_disable_unprepare(hdlcd->clk);
}
->8-----------------------------------------------------------------------
That takes care of the pxlclk refcounting issue you were seeing. I've started
Xorg several times (and yes, I do see EDID checksum error every now and then,
specially when running xrandr). When closing down Xorg I get back the framebuffer
console with the login prompt and no image shifting. My monitor is a TV that
reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
propertly with each other to be able to set the interlaced mode correctly, so
I've had to disable support for interlacing mode in tda998x_drv.c and now the
preferred mode that gets picked up is 1920x1200 at 60Hz.
Please advise on what other steps I can take to try to reproduce this.
P.S: What revision of Juno do you have? Any chance you can capture the start
of the boot process where the firmware component prints the version numbers?
Best regards,
Liviu
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply related
* [PATCH] ARM: dts: AM571x-IDK Initial Support
From: Rob Herring @ 2016-11-21 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121055801.573-1-lokeshvutla@ti.com>
On Mon, Nov 21, 2016 at 11:28:01AM +0530, Lokesh Vutla wrote:
> From: Schuyler Patton <spatton@ti.com>
>
> The AM571x-IDK board is a board based on TI's AM5718 SOC
> which has a single core 1.5GHz A15 processor. This board is a
> development platform for the Industrial market with:
> - 1GB of DDR3L
> - Dual 1Gbps Ethernet
> - HDMI,
> - PRU-ICSS
> - uSD
> - 16GB eMMC
> - CAN
> - RS-485
> - PCIe
> - USB3.0
> - Video Input Port
> - Industrial IO port and expansion connector
>
> The link to the data sheet and TRM can be found here:
>
> http://www.ti.com/product/AM5718
>
> Initial support is only for basic peripherals.
>
> Signed-off-by: Schuyler Patton <spatton@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
>
> Logs: http://pastebin.ubuntu.com/23510390/
>
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am571x-idk.dts | 82 ++++++++++++++++++++++
> 3 files changed, 86 insertions(+)
> create mode 100644 arch/arm/boot/dts/am571x-idk.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index f53e2ee..647ffd3 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -175,6 +175,9 @@ Boards:
> - AM5728 IDK
> compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
>
> +- AM5718 IDK
> + compatible = "ti,am5718-idk", "ti,am5728", "ti,dra722", "ti,dra72", "ti,dra7"
I've said this before I think, but 5 compat string is a bit much. Some
of these genericish ones should be dropped. Doesn't really hurt though.
A couple of nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
> +
> - DRA742 EVM: Software Development Board for DRA742
> compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..c298078 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -588,6 +588,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
> am57xx-cl-som-am57x.dtb \
> am57xx-sbc-am57x.dtb \
> am572x-idk.dtb \
> + am571x-idk.dtb \
> dra7-evm.dtb \
> dra72-evm.dtb \
> dra72-evm-revc.dtb
> diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
> new file mode 100644
> index 0000000..a6a743e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am571x-idk.dts
> @@ -0,0 +1,82 @@
> +/*
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.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.
> + */
> +/dts-v1/;
> +
> +#include "dra72x.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "am57xx-idk-common.dtsi"
> +
> +/ {
> + model = "TI AM5718 IDK";
> + compatible = "ti,am5718-idk", "ti,am5718", "ti,dra722",
> + "ti,dra72", "ti,dra7";
> +
> + memory at 0 {
unit address is wrong.
> + device_type = "memory";
> + reg = <0x0 0x80000000 0x0 0x40000000>;
> + };
> +
> + status-leds {
Just "leds"
> + compatible = "gpio-leds";
> + cpu0-led {
> + label = "status0:red:cpu0";
> + gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "cpu0";
> + };
> +
> + usr0-led {
> + label = "status0:green:usr";
> + gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + heartbeat-led {
> + label = "status0:blue:heartbeat";
> + gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + usr1-led {
> + label = "status1:red:usr";
> + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + usr2-led {
> + label = "status1:green:usr";
> + gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + mmc0-led {
> + label = "status1:blue:mmc0";
> + gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> + };
> +
> + extcon_usb2: extcon_usb2 {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = <&gpio5 7 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&ldo1_reg>;
> + bus-width = <4>;
> + cd-gpios = <&gpio6 27 0>; /* gpio 219 */
> +};
> +
> +&omap_dwc3_2 {
> + extcon = <&extcon_usb2>;
> +};
> --
> 2.10.1
>
^ permalink raw reply
* [PATCHv3 5/6] arm64: Use __pa_symbol for kernel symbols
From: Laura Abbott @ 2016-11-21 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118143543.GC1197@leverpostej>
On 11/18/2016 06:35 AM, Mark Rutland wrote:
> Hi Laura,
>
> On Thu, Nov 17, 2016 at 05:16:55PM -0800, Laura Abbott wrote:
>>
>> __pa_symbol is technically the marco that should be used for kernel
>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
>> will do bounds checking.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v3: Conversion of more sites besides just _end. Addition of __lm_sym_addr
>> macro to take care of the _va(__pa_symbol(..)) idiom.
>>
>> Note that a copy of __pa_symbol was added to avoid a mess of headers
>> since the #ifndef __pa_symbol case is defined in linux/mm.h
>
> I think we also need to fix up virt_to_phys(__cpu_soft_restart) in
> arch/arm64/kernel/cpu-reset.h. Otherwise, this looks complete for uses
> falling under arch/arm64/.
>
> I also think it's worth mentioning in the commit message that this patch
> adds and __lm_sym_addr() and uses it in some places so that low-level
> helpers can use virt_to_phys() or __pa() consistently.
>
> The PSCI change doesn't conflict with patches [1] that'll go via
> arm-soc, so I'm happy for that PSCI change to go via the arm64 tree,
> though it may be worth splitting into its own patch just in case
> something unexpected crops up.
>
> With those fixed up:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/466522.html
>
> Otherwise, I just have a few nits below.
>
>> @@ -271,7 +271,7 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
>> kvm_flush_dcache_to_poc(page_address(page), PUD_SIZE);
>> }
>>
>> -#define kvm_virt_to_phys(x) __virt_to_phys((unsigned long)(x))
>> +#define kvm_virt_to_phys(x) __pa_symbol((unsigned long)(x))
>
> Nit: we can drop the unsigned long cast given __pa_symbol() contains
> one.
>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index ffbb9a5..c2041a3 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -52,7 +52,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
>> * for zero-mapped memory areas etc..
>> */
>> extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>> -#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa(empty_zero_page)))
>> +#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa_symbol(empty_zero_page)))
>
> Nit: I think we can also simplify this to:
>
> phys_to_page(__pa_symbol(empty_zero_page))
>
> ... since phys_to_page(p) is (pfn_to_page(__phys_to_pfn(p)))
> ... and __phys_to_pfn(p) is PHYS_PFN(p)
>
>> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>> index 6f2ac4f..af8967a 100644
>> --- a/arch/arm64/kernel/insn.c
>> +++ b/arch/arm64/kernel/insn.c
>> @@ -97,7 +97,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
>> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
>> page = vmalloc_to_page(addr);
>> else if (!module)
>> - page = pfn_to_page(PHYS_PFN(__pa(addr)));
>> + page = pfn_to_page(PHYS_PFN(__pa_symbol(addr)));
>
> Nit: likewise, we can use phys_to_page() here.
>
>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>> index a2c2478..791e87a 100644
>> --- a/arch/arm64/kernel/vdso.c
>> +++ b/arch/arm64/kernel/vdso.c
>> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
>> return -ENOMEM;
>>
>> /* Grab the vDSO data page. */
>> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
>> + vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa_symbol(vdso_data)));
>
> Nit: phys_to_page() again.
>
>>
>> /* Grab the vDSO code pages. */
>> for (i = 0; i < vdso_pages; i++)
>> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
>> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
>
> Nit: phys_to_page() again.
I think it makes sense to keep this one as is. It's offsetting
by pfn number and trying force phys_to_page would make it more
difficult to read.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: David Lechner @ 2016-11-21 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTPxwxtE1xs1b6+sfwvRNKVLGKM-9Fjs3tVOSaBA+5Wnxg@mail.gmail.com>
On 11/21/2016 11:29 AM, Axel Haslam wrote:
> On Mon, Nov 21, 2016 at 6:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>>
>>> This adds the DT node for the ohci controller and
>>> enables it for the omapl138-lckd platform.
>>>
>>> DEPENDENCIES:
>>>
>>> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
>>> https://lkml.org/lkml/2016/11/21/558
>>>
>>> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
>>> https://lkml.org/lkml/2016/11/4/465
>>>
>>> Axel Haslam (2):
>>> ARM: dts: da850: Add usb device node
>>> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>>>
>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>> 2 files changed, 16 insertions(+)
>>>
>>
>> It does not look like you rebased these patches. Sekhar pushed the musb
>> counterpart to v4.10/dt yesterday, which will cause conflicts with this
>> series.
>>
>> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
>
> Hi David,
>
> i verified that they apply to the current linux-davinci/master.
> Anyways, i can rebase
> and resend once the dependencies are met, and we are ready to merge it.
>
> Regards
> Axel.
>
OK. I think the first patch is fine, but you will have two &usb_phy {
status = "okay"; }; in da850-lcdk.dts now even if applies cleanly. ;-)
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Robin Murphy @ 2016-11-21 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUXJi6PDq0qc-0+r2mLPASLpJUt_njWtXr4Mx4k0Fa82g@mail.gmail.com>
Hi Bartosz, Sekhar,
On 21/11/16 16:48, Bartosz Golaszewski wrote:
> 2016-11-21 17:33 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> +{
>>> + const struct da8xx_ddrctl_config_knob *knob;
>>> + const struct da8xx_ddrctl_setting *setting;
>>> + struct device_node *node;
>>> + struct resource *res;
>>> + void __iomem *ddrctl;
>>> + struct device *dev;
>>> + u32 reg;
>>> +
>>> + dev = &pdev->dev;
>>> + node = dev->of_node;
>>> +
>>> + setting = da8xx_ddrctl_get_board_settings();
>>> + if (!setting) {
>>> + dev_err(dev, "no settings for board '%s'\n",
>>> + of_flat_dt_get_machine_name());
>>> + return -EINVAL;
>>> + }
>>
>> This causes a section mismatch because of_flat_dt_get_machine_name()
>> has an __init annotation. I did not notice that before, sorry.
>>
>> It can be fixed with a patch like below:
>>
>> ---8<---
>> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
>> index a20e7bbbcbe0..9ca5aab3ac54 100644
>> --- a/drivers/memory/da8xx-ddrctl.c
>> +++ b/drivers/memory/da8xx-ddrctl.c
>> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
>> return NULL;
>> }
>>
>> +static const char* da8xx_ddrctl_get_machine_name(void)
>> +{
>> + const char *str;
>> + int ret;
>> +
>> + ret = of_property_read_string(of_root, "model", &str);
>> + if (ret)
>> + ret = of_property_read_string(of_root, "compatible", &str);
>> +
>> + return str;
>> +}
>> +
>> static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> {
>> const struct da8xx_ddrctl_config_knob *knob;
>> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> setting = da8xx_ddrctl_get_board_settings();
>> if (!setting) {
>> dev_err(dev, "no settings for board '%s'\n",
>> - of_flat_dt_get_machine_name());
>> + da8xx_ddrctl_get_machine_name());
>> return -EINVAL;
>> }
>> ---8<---
>>
>> A similar fix is required for the other driver in this series (patch
>> 2/5). I need some advise on whether I should introduce a common
>> function to get the machine name post kernel boot-up (I cannot see an
>> existing one). If yes, any advise on which file it should go into?
>>
>
> Hi Sekhar,
>
> thanks for spotting that.
>
> I think we should introduce this function right away, rather than
> having two static functions doing the same thing. If you don't mind,
> I'll try to find a good spot for it and send a follow-up series fixing
> the issue.
As it happens, that was already proposed last week, for much the same
reason:
http://www.mail-archive.com/linuxppc-dev at lists.ozlabs.org/msg111395.html
Robin.
>
> Best regards,
> Bartosz Golaszewski
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121173231.GM1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > this as I remember Daniel was commenting that this was not needed.
> > > >
> > > > Removing that test results in:
> > > >
> > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > >
> > > > and the kernel hanging, seemingly in an IRQs-off region.
> > >
> > > Right, I need to sort this one out. Are you doing these tests out of
> > > some tagged branch that I can get in sync with?
>
> Hi Russell,
>
> >
> > No, not yet, and some of the changes I have are rather hacky.
> >
> > I do always build my full tree of patches (which is currently running at
> > around 320 patches at the moment) but I never share that entire patch
> > set. However, none of those touch i2c (apart from the ones I've recently
> > posted) and the only patches touching hdlcd are those I've posted so far.
> >
> > Most of the problems I'm finding are through trying basic stuff - I'm not
> > doing anything special or unusual to find them, at the moment quite
> > literally just starting Xorg up and shutting it down. For example, the
> > above was caused by logging in on serial, running:
> >
> > Xorg -terminate -verbose
> >
> > and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > up when the machine is booting for its nightly KVM boot tests.)
> >
> > I'm afraid that when I try someone elses code, I have a tendency to find
> > loads of seemingly trivial bugs when I try putting it through some basic
> > tests.
>
> I'm not being able to reproduce your bug conditions. I'm running the following
> setup when testing:
>
> - mainline v4.9-rc6
> - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
> hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> - modified the hdlcd_crtc.c file with the following patch:
>
> -8<-----------------------------------------------------------------------
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae..656dc43 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>
> - if (!crtc->state->active)
> - return;
> -
> + drm_crtc_vblank_off(crtc);
Don't you need a drm_crtc_vblank_on() call in the enable function?
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> clk_disable_unprepare(hdlcd->clk);
> }
> ->8-----------------------------------------------------------------------
>
> That takes care of the pxlclk refcounting issue you were seeing. I've started
> Xorg several times (and yes, I do see EDID checksum error every now and then,
> specially when running xrandr). When closing down Xorg I get back the framebuffer
> console with the login prompt and no image shifting.
For me, the image shift was 100% reproducable. With the above patch
and a call to drm_crtc_vblank_on() in the enable path, it seems to
behave correctly - I can alternately switch between 1920x1080 and
1280x1024 and it behaves correctly. Indeed, my debug prints show that
the right thing is happening wrt disabling the controller:
[ 76.869136] hdlcd_crtc_disable: active 0
[ 76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
[ 85.262451] hdlcd_crtc_disable: active 0
[ 85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
[ 92.658038] hdlcd_crtc_disable: active 0
[ 92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
[ 97.805205] hdlcd_crtc_disable: active 0
[ 97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
> My monitor is a TV that
> reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> propertly with each other to be able to set the interlaced mode correctly, so
> I've had to disable support for interlacing mode in tda998x_drv.c and now the
> preferred mode that gets picked up is 1920x1200 at 60Hz.
That's more of a generic DRM issue - the CRTC layer doesn't get a
look-in when a connector parses the modes supplied from the display,
so there's no real way for the CRTC layer to apply any kind of
limitations to the available modes, except when a mode is attempted
to be set.
I don't want to see an "interlace" DT property introduced for the
TDA998x, because that's the wrong approach - it would be adding a
property for the needs of the implementation, and not a description
of the hardware.
> Please advise on what other steps I can take to try to reproduce this.
I guess if you've tried and failed to reproduce it, there is something
very specific to my setup which I can't describe.
> P.S: What revision of Juno do you have? Any chance you can capture the start
> of the boot process where the firmware component prints the version numbers?
All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
(he spent _all_ of last Tuesday logged in to one of my systems trying
to upgrade the firmware) is now running the Linaro 16.10 firmware.
Sudeep says that my hardware is a very early revision which went out
the door without being properly calibrated.
Whether that has any bearing on the reproducability of this or not, I've
no idea.
If you want to see the boot messages, head to my autobuilder status page
and look at the juno-kvm entries - they contain all the boot messages
from initial power up of the juno. I'll send you a link in private
mail so googlebot doesn't end up hammering on it after it expires.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Sudeep Holla @ 2016-11-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0f3bc66-6dfd-dcdc-a15d-a8f9fdda6048@arm.com>
Hi Robin,
On 21/11/16 17:47, Robin Murphy wrote:
> Hi Bartosz, Sekhar,
>
> On 21/11/16 16:48, Bartosz Golaszewski wrote:
[...]
>> Hi Sekhar,
>>
>> thanks for spotting that.
>>
>> I think we should introduce this function right away, rather than
>> having two static functions doing the same thing. If you don't mind,
>> I'll try to find a good spot for it and send a follow-up series fixing
>> the issue.
>
> As it happens, that was already proposed last week, for much the same
> reason:
>
> http://www.mail-archive.com/linuxppc-dev at lists.ozlabs.org/msg111395.html
>
Thanks for pointing this out, yet another platform to move to the new
API after v4.10.
Hi Shekar, Bartosz,
For v4.10, please continue with the open coding as proposed in this
thread in order to avoid cross tree dependencies. I will rework on the
above patch once v4.10 merge window closes to include all these
occurrence and replace them.
--
Regards,
Sudeep
^ permalink raw reply
* [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Jean-Francois Moine @ 2016-11-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1c9a02ff-ce6c-7ad7-36fa-8a2ea0b7675e@megous.com>
On Mon, 21 Nov 2016 01:54:53 +0100
Ond?ej Jirman <megous@megous.com> wrote:
> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3, but it could be
> > used/extended for other SoCs as the A64, H2 and H5.
>
> Hi,
>
> I'm trying to test your patches on Orange Pi PC, and I've run into a few
> issues: (I'm using sunxi-ng with the same patches as last time, to make
> it work with your driver)
>
> 1] I just get pink output on the monitor - there's some signal, but it's
> pink (or more like magenta).
>
> dmesg ouput indicates no error:
>
> [ 1.887823] [drm] Initialized
> [ 1.888503] sun8i-de2 1000000.de-controller: bound
> 1c0c000.lcd-controller (ops 0xc0a63894)
> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
> 0xc0a63b54)
> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 2.057307] [drm] No driver support for vblank timestamp query.
> [ 2.690862] Console: switching to colour frame buffer device 240x67
> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
[snip]
My H3 boards work correctly, except the Orange PI 2 when it cannot read
the EDID (but it is OK after reboot).
Did you check if the EDID was correctly read?
Which resolution do you expect?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121175602.GM1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable. With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:
Here's my version of your patch:
8<=============
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.
This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.
Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.
Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index c239616f5334..9d683be2e5d3 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
clk_prepare_enable(hdlcd->clk);
hdlcd_crtc_mode_set_nofb(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+ drm_crtc_vblank_on(crtc);
}
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
- if (!crtc->state->active)
- return;
-
+ drm_crtc_vblank_off(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
clk_disable_unprepare(hdlcd->clk);
}
--
2.7.4
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121175602.GM1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > > this as I remember Daniel was commenting that this was not needed.
> > > > >
> > > > > Removing that test results in:
> > > > >
> > > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > >
> > > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > >
> > > > Right, I need to sort this one out. Are you doing these tests out of
> > > > some tagged branch that I can get in sync with?
> >
> > Hi Russell,
> >
> > >
> > > No, not yet, and some of the changes I have are rather hacky.
> > >
> > > I do always build my full tree of patches (which is currently running at
> > > around 320 patches at the moment) but I never share that entire patch
> > > set. However, none of those touch i2c (apart from the ones I've recently
> > > posted) and the only patches touching hdlcd are those I've posted so far.
> > >
> > > Most of the problems I'm finding are through trying basic stuff - I'm not
> > > doing anything special or unusual to find them, at the moment quite
> > > literally just starting Xorg up and shutting it down. For example, the
> > > above was caused by logging in on serial, running:
> > >
> > > Xorg -terminate -verbose
> > >
> > > and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> > > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > > up when the machine is booting for its nightly KVM boot tests.)
> > >
> > > I'm afraid that when I try someone elses code, I have a tendency to find
> > > loads of seemingly trivial bugs when I try putting it through some basic
> > > tests.
> >
> > I'm not being able to reproduce your bug conditions. I'm running the following
> > setup when testing:
> >
> > - mainline v4.9-rc6
> > - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
> > hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> > - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> > - modified the hdlcd_crtc.c file with the following patch:
> >
> > -8<-----------------------------------------------------------------------
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae..656dc43 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> > {
> > struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >
> > - if (!crtc->state->active)
> > - return;
> > -
> > + drm_crtc_vblank_off(crtc);
>
> Don't you need a drm_crtc_vblank_on() call in the enable function?
I do, thanks for calling me on that!
>
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > clk_disable_unprepare(hdlcd->clk);
> > }
> > ->8-----------------------------------------------------------------------
> >
> > That takes care of the pxlclk refcounting issue you were seeing. I've started
> > Xorg several times (and yes, I do see EDID checksum error every now and then,
> > specially when running xrandr). When closing down Xorg I get back the framebuffer
> > console with the login prompt and no image shifting.
>
> For me, the image shift was 100% reproducable. With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:
OK, so I'll take it that you did not also use your patch to fix the base plane
calculations, or was that included as well in your stack?
>
> [ 76.869136] hdlcd_crtc_disable: active 0
> [ 76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 85.262451] hdlcd_crtc_disable: active 0
> [ 85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 92.658038] hdlcd_crtc_disable: active 0
> [ 92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 97.805205] hdlcd_crtc_disable: active 0
> [ 97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
>
> > My monitor is a TV that
> > reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> > propertly with each other to be able to set the interlaced mode correctly, so
> > I've had to disable support for interlacing mode in tda998x_drv.c and now the
> > preferred mode that gets picked up is 1920x1200 at 60Hz.
>
> That's more of a generic DRM issue - the CRTC layer doesn't get a
> look-in when a connector parses the modes supplied from the display,
> so there's no real way for the CRTC layer to apply any kind of
> limitations to the available modes, except when a mode is attempted
> to be set.
>
> I don't want to see an "interlace" DT property introduced for the
> TDA998x, because that's the wrong approach - it would be adding a
> property for the needs of the implementation, and not a description
> of the hardware.
AFAICT the issue is the fact that while HDLCD could scan out the alternate
lines with a bit of a convoluted hack, there is no way to tell TDA19988
to generate the interlaced timings. And no, I'm not advocating introducing
a DT property as this is a runtime mode, depending on the resolution
selected by userspace.
>
> > Please advise on what other steps I can take to try to reproduce this.
>
> I guess if you've tried and failed to reproduce it, there is something
> very specific to my setup which I can't describe.
>
> > P.S: What revision of Juno do you have? Any chance you can capture the start
> > of the boot process where the firmware component prints the version numbers?
>
> All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
> (he spent _all_ of last Tuesday logged in to one of my systems trying
> to upgrade the firmware) is now running the Linaro 16.10 firmware.
> Sudeep says that my hardware is a very early revision which went out
> the door without being properly calibrated.
:) That is what you get for having special access to early samples of hardware :)
Might be worth asking your ARM contacts if a swap with an R2 is possible.
But, yes, my tests were also run on a Juno R0 (HBI0282B is just the R0 code)
and mine I'm pretty sure is earlier build than yours (board #13 no less).
>
> Whether that has any bearing on the reproducability of this or not, I've
> no idea.
The one factor that could affect it is the capability of the SCP firmware
to generate the exact pixel clock for your 1080p mode. If it doesn't, then
restoring the old mode might lead to an incorrect synchronisation with the
TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
frequencies).
Best regards,
Liviu
>
> If you want to see the boot messages, head to my autobuilder status page
> and look at the juno-kvm entries - they contain all the boot messages
> from initial power up of the juno. I'll send you a link in private
> mail so googlebot doesn't end up hammering on it after it expires.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121181616.GN1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 06:16:16PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
>
> Here's my version of your patch:
Thanks! I'll add it to my tree and see if David Airlie is happy to push it
this late into the release cycle. Otherwise it is going to end up in linux-next
quickly and then in drm-next before v4.10.
>
> 8<=============
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
>
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
>
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> Further debugging shows that we try to update the controller
> configuration while enabled.
>
> Alwys ensure that the HDLCD is disabled prior to updating the
> controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
> so that DRM knows whether it can expect vblank interrupts.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index c239616f5334..9d683be2e5d3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> clk_prepare_enable(hdlcd->clk);
> hdlcd_crtc_mode_set_nofb(crtc);
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> + drm_crtc_vblank_on(crtc);
> }
>
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>
> - if (!crtc->state->active)
> - return;
> -
> + drm_crtc_vblank_off(crtc);
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> clk_disable_unprepare(hdlcd->clk);
> }
> --
> 2.7.4
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Ondřej Jirman @ 2016-11-21 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121191416.706b80c25d476fa002a001b1@free.fr>
Dne 21.11.2016 v 19:14 Jean-Francois Moine napsal(a):
> On Mon, 21 Nov 2016 01:54:53 +0100
> Ond?ej Jirman <megous@megous.com> wrote:
>
>> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
>>> This patchset series adds HDMI video support to the Allwinner
>>> sun8i SoCs which include the display engine 2 (DE2).
>>> The driver contains the code for the A83T and H3, but it could be
>>> used/extended for other SoCs as the A64, H2 and H5.
>>
>> Hi,
>>
>> I'm trying to test your patches on Orange Pi PC, and I've run into a few
>> issues: (I'm using sunxi-ng with the same patches as last time, to make
>> it work with your driver)
>>
>> 1] I just get pink output on the monitor - there's some signal, but it's
>> pink (or more like magenta).
>>
>> dmesg ouput indicates no error:
>>
>> [ 1.887823] [drm] Initialized
>> [ 1.888503] sun8i-de2 1000000.de-controller: bound
>> 1c0c000.lcd-controller (ops 0xc0a63894)
>> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
>> 0xc0a63b54)
>> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 2.057307] [drm] No driver support for vblank timestamp query.
>> [ 2.690862] Console: switching to colour frame buffer device 240x67
>> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
> [snip]
>
> My H3 boards work correctly, except the Orange PI 2 when it cannot read
> the EDID (but it is OK after reboot).
>
> Did you check if the EDID was correctly read?
EDID is correctly read (I verified that it is the same as with the v5
version of the driver), but there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.
> Which resolution do you expect?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/1453ca53/attachment.sig>
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121182324.GP1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 06:23:24PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
>
> OK, so I'll take it that you did not also use your patch to fix the base
> plane calculations, or was that included as well in your stack?
It was before that patch - so it was using crtc_x and crtc_y. However,
I can guarantee that those were both zero (as I've previously
described.)
> > That's more of a generic DRM issue - the CRTC layer doesn't get a
> > look-in when a connector parses the modes supplied from the display,
> > so there's no real way for the CRTC layer to apply any kind of
> > limitations to the available modes, except when a mode is attempted
> > to be set.
> >
> > I don't want to see an "interlace" DT property introduced for the
> > TDA998x, because that's the wrong approach - it would be adding a
> > property for the needs of the implementation, and not a description
> > of the hardware.
>
> AFAICT the issue is the fact that while HDLCD could scan out the alternate
> lines with a bit of a convoluted hack, there is no way to tell TDA19988
> to generate the interlaced timings. And no, I'm not advocating introducing
> a DT property as this is a runtime mode, depending on the resolution
> selected by userspace.
The TDA998x doesn't "generate" the timings. They come from the input
to it, the TDA998x merely tracks where it is within the frame, so it
knows where it can place things like the infoframes and other data.
So, the responsibility for generating the interlaced timings is with
the CRTC.
That means the CRTC needs to not only scan out alternate lines (which
is the easy bit - setting the pitch to twice the value) but it also
needs to be able to adjust the timing of the vertical sync by half
a line. The HDLCD from what I can see does not support that, the
overall system does not support for interlaced modes.
> > Whether that has any bearing on the reproducability of this or not, I've
> > no idea.
>
> The one factor that could affect it is the capability of the SCP firmware
> to generate the exact pixel clock for your 1080p mode. If it doesn't, then
> restoring the old mode might lead to an incorrect synchronisation with the
> TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
> sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
> frequencies).
The TDA998x takes the sync signals itself to synchronise with the CRTC,
and the pixel clock had better be synchronous with the data being closed
out of the CRTC otherwise its going to be in violation of the RGB data
setup and hold timings - which will cause random colour errors.
That isn't what's going on here - the image is rock stable, it's just
shifted.
I tried inverting the sync signals from the CRTC to the TDA998x, and
that shifts the display (as I expect, because the TDA998x synchronises
on the transition of the sync signals not on their absolute values) and
at that point I get the black sync bars appearing - again as expected.
Same kind of effect if I swap the horizontal front and back porches.
Of course, adjusting such things necessitates the TDA998x to re-lock
to the CRTC each time something like that changes, and the image
shift remains.
As I described originally, the _only_ two things that solved the image
shift was (a) shifting the framebuffer start address earlier than it
should be, or (b) disabling the CRTC and re-enabling the CRTC. Both
of those were tried using devmem2 in userspace with no patches to the
HDLCD code over v4.9-rc5.
The only patches that would be in effect are my TDA998x patch stack
(which you've already tested), the i2c-designware patches to sort that
crappy thing out, and a dirty patch to the TDA998x code to read the
EDID in 16 byte chunks [*], so that the i2c-designware crappage never
causes a problem.
* - I'm not submitting this patch, because while it may solve the
EDID reading issue on Juno, it's putting intimate knowledge of
i2c-designware into the TDA998x driver - it's a hack around the
problem, it's not a real fix. It's possible that there are other
i2c-designware crappages out there which have even smaller FIFOs
which would need us to read in even smaller chunks for reliability.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Catalin Marinas @ 2016-11-21 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5ff1b88-aba3-2c3a-f65f-66a2e00f4764@arm.com>
On Mon, Nov 21, 2016 at 03:45:55PM +0000, Kevin Brodsky wrote:
> On 04/11/16 20:03, Catalin Marinas wrote:
> >On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
> >>On 28/10/16 04:09, Jisheng Zhang wrote:
> >>>On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
> >>>>+# Force -O2 to avoid libgcc dependencies
> >>>>+VDSO_CFLAGS := -march=armv8-a -O2
> >>>
> >>>For completeness, bringing 32bit compiler need to check whether the 32bit
> >>>toolchain support some options. IIRC, armv8-a support isn't enabled until
> >>>gcc 4.8, so old toolchains such gcc-4.7 will complain:
> >>> error: unrecognized argument in option ?-march=armv8-a?
> >>
> >>That's a fair point. I guess -march=armv8-a is not strictly necessary and
> >>the produced vDSO should be fine if arch/arm/vdso also compiles fine.
> >>However we would still need to pass -march=armv7-a. I'm not sure what to do
> >>between:
> >>* Checking that the compiler supports -march=armv8-a when inspecting
> >>CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
> >>* Checking whether -march=armv8-a is available here, and if it is not fall
> >>back to -march=armv7-a.
> >
> >Does v8 vs v7 make any difference in the generated code? If not, we
> >could just stick to armv7-a permanently.
>
> I've just tried compiling with -march=armv7-a, and in fact it doesn't
> compile at all. It turns out vgettimeofday.c uses smp_rmb(), which expands
> to dmb ishld on arm64, and ishld doesn't exist in ARMv7. We could possibly
> work around that, but I think requiring GCC 4.8 is reasonable.
Since vgettimeofday.c is meant to be compiled for AArch32, it wouldn't
look too bad to define its own barriers rather than relying on the
AArch64 ones. So you could define v7_smp_rmb/v7_smp_wmb and use them in
this file. Alternatively, replace smp_rmb() with smp_mb() in this file
but with a big comment about ARMv7 compilation requirement and "ishld"
not being available.
--
Catalin
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2016-11-21 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4095b7bc-a6dd-144b-4a65-40d86c710087@lechnology.com>
On Mon, Nov 21, 2016 at 6:45 PM, David Lechner <david@lechnology.com> wrote:
> On 11/21/2016 11:29 AM, Axel Haslam wrote:
>>
>> On Mon, Nov 21, 2016 at 6:04 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>>>
>>>>
>>>> This adds the DT node for the ohci controller and
>>>> enables it for the omapl138-lckd platform.
>>>>
>>>> DEPENDENCIES:
>>>>
>>>> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
>>>> https://lkml.org/lkml/2016/11/21/558
>>>>
>>>> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb
>>>> drivers
>>>> https://lkml.org/lkml/2016/11/4/465
>>>>
>>>> Axel Haslam (2):
>>>> ARM: dts: da850: Add usb device node
>>>> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>>>>
>>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>> 2 files changed, 16 insertions(+)
>>>>
>>>
>>> It does not look like you rebased these patches. Sekhar pushed the musb
>>> counterpart to v4.10/dt yesterday, which will cause conflicts with this
>>> series.
>>>
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
>>
>>
>> Hi David,
>>
>> i verified that they apply to the current linux-davinci/master.
>> Anyways, i can rebase
>> and resend once the dependencies are met, and we are ready to merge it.
>>
>> Regards
>> Axel.
>>
>
> OK. I think the first patch is fine, but you will have two &usb_phy {
> status = "okay"; }; in da850-lcdk.dts now even if applies cleanly. ;-)
mmm, right! ill remove it when i resend.
^ permalink raw reply
* [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: maitysanchayan at gmail.com @ 2016-11-21 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121191847.vg32cwople4qmini@sirena.org.uk>
Hello Mark,
On 16-11-21 19:18:47, Mark Brown wrote:
> On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > Current DMA implementation had a bug where the DMA transfer would
> > exit the loop in dspi_transfer_one_message after the completion of
> > a single transfer. This results in a multi message transfer submitted
> > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
>
> Please don't resend already applied patches. If there are any changes
> needed please send incremental changes on top of what's already applied.
This is not a resend of an applied patch. The whole series applies on
top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
incremental changes
- Sanchaya.
^ permalink raw reply
* [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: Mark Brown @ 2016-11-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbdbc8df434dd2af74eb351b799a2812a1c1967e.1479706671.git.maitysanchayan@gmail.com>
On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> Current DMA implementation had a bug where the DMA transfer would
> exit the loop in dspi_transfer_one_message after the completion of
> a single transfer. This results in a multi message transfer submitted
> with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Please don't resend already applied patches. If there are any changes
needed please send incremental changes on top of what's already applied.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/59a1e93d/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
From: maitysanchayan at gmail.com @ 2016-11-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121191430.GA24521@Sanchayan-Arch.localdomain>
Hello Mark,
On 16-11-22 00:44:30, maitysanchayan at gmail.com wrote:
> Hello Mark,
>
> On 16-11-21 19:18:47, Mark Brown wrote:
> > On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > > Current DMA implementation had a bug where the DMA transfer would
> > > exit the loop in dspi_transfer_one_message after the completion of
> > > a single transfer. This results in a multi message transfer submitted
> > > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> >
> > Please don't resend already applied patches. If there are any changes
> > needed please send incremental changes on top of what's already applied.
>
> This is not a resend of an applied patch. The whole series applies on
> top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
> incremental changes
>
Sorry. I take that back. I now see you applied the patch and I got the applied
mail after I replied.
- Sanchayan.
^ permalink raw reply
* Applied "spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE" to the spi tree
From: Mark Brown @ 2016-11-21 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbdbc8df434dd2af74eb351b799a2812a1c1967e.1479384571.git.maitysanchayan@gmail.com>
The patch
spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9811430465fccae17862213d07eba017c149eb9c Mon Sep 17 00:00:00 2001
From: Sanchayan Maity <maitysanchayan@gmail.com>
Date: Thu, 17 Nov 2016 17:46:48 +0530
Subject: [PATCH] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple
SPI_IOC_MESSAGE
Current DMA implementation had a bug where the DMA transfer would
exit the loop in dspi_transfer_one_message after the completion of
a single transfer. This results in a multi message transfer submitted
with SPI_IOC_MESSAGE to terminate incorrectly without an error.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-fsl-dspi.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index bc64700b514d..b1ee1f521ba0 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -714,7 +714,7 @@ static int dspi_transfer_one_message(struct spi_master *master,
SPI_RSER_TFFFE | SPI_RSER_TFFFD |
SPI_RSER_RFDFE | SPI_RSER_RFDFD);
status = dspi_dma_xfer(dspi);
- goto out;
+ break;
default:
dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
trans_mode);
@@ -722,9 +722,13 @@ static int dspi_transfer_one_message(struct spi_master *master,
goto out;
}
- if (wait_event_interruptible(dspi->waitq, dspi->waitflags))
- dev_err(&dspi->pdev->dev, "wait transfer complete fail!\n");
- dspi->waitflags = 0;
+ if (trans_mode != DSPI_DMA_MODE) {
+ if (wait_event_interruptible(dspi->waitq,
+ dspi->waitflags))
+ dev_err(&dspi->pdev->dev,
+ "wait transfer complete fail!\n");
+ dspi->waitflags = 0;
+ }
if (transfer->delay_usecs)
udelay(transfer->delay_usecs);
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: NS2: Add sdio1, PCI phys
From: Florian Fainelli @ 2016-11-21 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479425103-2119-1-git-send-email-jon.mason@broadcom.com>
On 11/17/2016 03:25 PM, Jon Mason wrote:
> The second SDIO seems to have been forgotten to be enabled in the
> Northstar2 SVK dts. Also, the PCI PHY entries are missing from the PCI
> bus device tree entries.
Series applied, thanks Jon
--
Florian
^ 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