* [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] 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
* [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] 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
* [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
* 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] 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
* [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] PCI: Add information about describing PCI in ACPI
From: Gabriele Paoloni @ 2016-11-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121164700.GL25762@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn
> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-
> owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: 21 November 2016 16:47
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> Subject: Re: [PATCH] PCI: Add information about describing PCI in ACPI
>
> On Mon, Nov 21, 2016 at 08:52:52AM +0000, Gabriele Paoloni wrote:
> > Hi Bjorn
> >
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > > Sent: 18 November 2016 17:54
> > > To: Gabriele Paoloni
> > > Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> > > acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > > kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> > > Subject: Re: [PATCH] PCI: Add information about describing PCI in
> ACPI
> > >
> > > On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > > > > -----Original Message-----
> > > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > > > Sent: 17 November 2016 18:00
> > >
> > > > > +Static tables like MCFG, HPET, ECDT, etc., are *not*
> mechanisms
> > > for
> > > > > +reserving address space! The static tables are for things the
> OS
> > > > > +needs to know early in boot, before it can parse the ACPI
> > > namespace.
> > > > > +If a new table is defined, an old OS needs to operate
> correctly
> > > even
> > > > > +though it ignores the table. _CRS allows that because it is
> > > generic
> > > > > +and understood by the old OS; a static table does not.
> > > >
> > > > Right so if my understanding is correct you are saying that
> resources
> > > > described in the MCFG table should also be declared in PNP0C02
> > > devices
> > > > so that the PNP driver can reserve these resources.
> > >
> > > Yes.
> > >
> > > > On the other side the PCI Root bridge driver should not reserve
> such
> > > > resources.
> > > >
> > > > Well if my understanding is correct I think we have a problem
> here:
> > > > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
> > > >
> > > > As you can see pci_ecam_create() will conflict with the pnp
> driver
> > > > as it will try to reserve the resources from the MCFG table...
> > > >
> > > > Maybe we need to rework pci_ecam_create() ?
> > >
> > > I think it's OK as it is.
> > >
> > > The pnp/system.c driver does try to reserve PNP0C02 resources, and
> it
> > > marks them as "not busy". That way they appear in /proc/iomem and
> > > won't be allocated for anything else, but they can still be
> requested
> > > by drivers, e.g., pci/ecam.c, which will mark them "busy".
> > >
> > > This is analogous to what the PCI core does in
> pci_claim_resource().
> > > This is really a function of the ACPI/PNP *core*, which should
> reserve
> > > all _CRS resources for all devices (not just PNP0C02 devices). But
> > > it's done by pnp/system.c, and only for PNP0C02, because there's a
> > > bunch of historical baggage there.
> > >
> > > You'll also notice that in this case, things are out of order:
> > > logically the pnp/system.c reservation should happen first, but in
> > > fact the pci/ecam.c request happens *before* the pnp/system.c one.
> > > That means the pnp/system.c one might fail and complain "[mem ...]
> > > could not be reserved".
> >
> > Correct me if I am wrong...
> >
> > So currently we are relying on the fact that pci_ecam_create() is
> called
> > before the pnp driver.
> > If the pnp driver came first we would end up in pci_ecam_create()
> failing
> > here:
> > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L76
> >
> > I am not sure but it seems to me like a bit weak condition to rely
> on...
> > what about removing the error condition in pci_ecam_create() and
> logging
> > just a dev_info()?
>
> Huh. I'm confused. I *thought* it would be safe to reverse the
> order, which would effectively be this:
>
> system_pnp_probe
> reserve_resources_of_dev
> reserve_range
> request_mem_region([mem 0xb0000000-0xb1ffffff])
> ...
> pci_ecam_create
> request_resource_conflict([mem 0xb0000000-0xb1ffffff])
>
>
> but I experimented with the patch below on qemu, and it failed as you
> predicted:
>
> ** res test **
> requested [mem 0xa0000000-0xafffffff]
> can't claim ECAM area [mem 0xa0000000-0xafffffff]: conflict with ECAM
> PNP [mem 0xa0000000-0xafffffff]
>
> I expected the request_resource_conflict() to succeed since it's
> completely contained in the "ECAM PNP" region. But I guess I don't
> understand kernel/resource.c well enough.
I think it fails because effectively the PNP driver is populating the
iomem_resource resource tree and therefore pci_ecam_create() finds that
it cannot add the cfg resource to the same hierarchy as it is already
there...
>
> I'm not sure we need to fix anything yet, since we currently do the
> ecam.c request before the system.c one, and any change there would be
> a long ways off. If/when that *does* change, I think the correct fix
> would be to change ecam.c so its request succeeds (by changing the way
> it does the request, fixing kernel/resource.c, or whatever) rather
> than to reduce the log level and ignore the failure.
Well in my mind I didn't want just to make the error disappear...
If all the resources should be reserved by the PNP driver then ideally
we could take away request_resource_conflict() from pci_ecam_create(),
but this would make buggy some systems with an already shipped BIOS
that relied on pci_ecam_create() reservation rather than PNP reservation.
Just removing the error condition and converting dev_err() into
dev_info() seems to me like accommodating already shipped BIOS images
and flagging a reservation that is already done by somebody else
without compromising the functionality of the PCI Root bridge driver
(so far the only reason why I can see the error condition there is
to catch a buggy MCFG with overlapping addresses; so if this is the
case maybe we need to have a different diagnostic check to make sure
that the MCFG table is alright)
BTW if you think that so far we can keep this as it is I am ok.
Many Thanks
Gab
>
> Bjorn
>
>
> diff --git a/arch/x86/pci/init.c b/arch/x86/pci/init.c
> index adb62aa..5a35638 100644
> --- a/arch/x86/pci/init.c
> +++ b/arch/x86/pci/init.c
> @@ -7,6 +7,8 @@
> in the right sequence from here. */
> static __init int pci_arch_init(void)
> {
> + struct resource *res, *conflict;
> + static struct resource cfg;
> #ifdef CONFIG_PCI_DIRECT
> int type = 0;
>
> @@ -39,6 +41,26 @@ static __init int pci_arch_init(void)
>
> dmi_check_skip_isa_align();
>
> + printk("\n** res test **\n");
> +
> + res = request_mem_region(0xa0000000, 0x10000000, "ECAM PNP");
> + printk("requested %pR\n", res);
> + if (!res)
> + return 0;
> + res->flags &= ~IORESOURCE_BUSY;
> +
> + cfg.start = 0xa0000000;
> + cfg.end = 0xafffffff;
> + cfg.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + cfg.name = "PCI ECAM";
> +
> + conflict = request_resource_conflict(&iomem_resource, &cfg);
> + if (conflict)
> + printk("can't claim ECAM area %pR: conflict with %s %pR\n",
> + &cfg, conflict->name, conflict);
> +
> + printk("\n");
> +
> return 0;
> }
> arch_initcall(pci_arch_init);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] coresight: perf: Add a missing call to etm_free_aux
From: Mathieu Poirier @ 2016-11-21 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119174124.20136-1-lambert.quentin@gmail.com>
On Sat, Nov 19, 2016 at 06:41:24PM +0100, Quentin Lambert wrote:
> Most error branches following the call to alloc_event_data contain a call to
> etm_free_aux. This patch add a call to etm_free_aux to an error branch
> that does not call it.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -215,7 +215,7 @@ static void *etm_setup_aux(int event_cpu
> */
> sink = coresight_get_enabled_sink(true);
> if (!sink)
> - return NULL;
> + goto err;
>
> INIT_WORK(&event_data->work, free_event_data);
>
Applied, after wrapping the commit log to 75 characters or less.
Please run checkpatch.pl on your next submission and compiling
your work before sending a patches is highly suggested.
Thanks,
Mathieu
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-1-git-send-email-bgolaszewski@baylibre.com>
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().
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;
--
2.9.3
^ permalink raw reply related
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
While debugging the drm_bridge support for revision 1 I noticed the
driver was selecting the 1024x768 resolution as default from the set
retrieved from EDID. The following patch reduces the max_width for
rev1 in tilcdc.
Bartosz Golaszewski (1):
drm: tilcdc: reduce max_width for revision 1
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH v4 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC
From: Rob Herring @ 2016-11-21 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479638740-20520-2-git-send-email-hao5781286@gmail.com>
On Sun, Nov 20, 2016 at 06:45:38PM +0800, Hao Zhang wrote:
> This add the property of Allwinner sun50i A64 dma.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The new Amlogic GXM SoC (S912) is part of the Meson GX family and is nearly
> identical to GXM but with a second Quad-A53 core cluster.
>
> The GXM dtsi includes the GXL dtsi and the p20x dtsi is refactored in a
> common p20x/q20x to support the GXM Q200 and Q201 board that uses the exact
> same board layout since the S905D and S912 are pinout compatible.
>
> The last patch adds support for the Nexbox A1 Set-Top-Box based on the S912.
>
> Changes since RFC :
> - Refactor the p20x/q20x dtsi into a single common file
> - Add support for Nexbox A1
Thanks for refactoring. Looks great.
Applied.
Kevin
^ permalink raw reply
* [PATCH v2 3/3] usb: ohci-da8xx: rename driver to ohci-da8xx
From: Axel Haslam @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-4-ahaslam@baylibre.com>
Hi Greg,
On Thu, Nov 3, 2016 at 5:03 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The davinci ohci driver name (currently "ohci") is too generic.
> To be consistent with other usb dirvers, append the "-da8xx" postfix
> to the name.
>
if there are no objections, would it be possible to pick up this patch?
the corresponding phy patch was merged and the platform changes
are ack'ed, and will we taken by the davinci maintainer once this patch
gets in.
i can resend stand-alone if its preferred.
Regards
Axel
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> drivers/usb/host/ohci-da8xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index 30c4878..429d58b 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -27,7 +27,7 @@
> #include "ohci.h"
>
> #define DRIVER_DESC "DA8XX"
> -#define DRV_NAME "ohci"
> +#define DRV_NAME "ohci-da8xx"
>
> static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
>
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH v6 2/5] drm: sun8i: add HDMI video support to A83T and H3
From: Rob Herring @ 2016-11-21 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cea6a5397664213c6a917028ec2e429d25972490.1479641523.git.moinejf@free.fr>
On Sun, Nov 20, 2016 at 10:56:23AM +0100, Jean-Francois Moine wrote:
> This patch adds a HDMI video driver to the Allwinner's SoCs A83T and H3.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 53 ++
> drivers/gpu/drm/sun8i/Kconfig | 7 +
> drivers/gpu/drm/sun8i/Makefile | 2 +
> drivers/gpu/drm/sun8i/de2_hdmi.c | 394 ++++++++++
> drivers/gpu/drm/sun8i/de2_hdmi.h | 51 ++
> drivers/gpu/drm/sun8i/de2_hdmi_io.c | 839 +++++++++++++++++++++
> 6 files changed, 1346 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> new file mode 100644
> index 0000000..85709ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> @@ -0,0 +1,53 @@
> +Allwinner HDMI Transmitter
> +==========================
> +
> +The Allwinner HDMI transmitters are included in the SoCs.
> +They support audio and video.
> +
> +Required properties:
> + - #address-cells : should be <1>
> + - #size-cells : should be <0>
> + - compatible : should be one of
> + "allwinner,sun8i-a83t-hdmi"
> + "allwinner,sun8i-h3-hdmi"
> + - clocks : phandles to the HDMI clocks as described in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - clock-names : must be
> + "gate" : bus gate
> + "clock" : streaming clock
> + "ddc-clock" : DDC clock
> + - resets : One or two phandles to the HDMI resets
> + - reset-names : when 2 phandles, must be
> + "hdmi0" and "hdmi1"
> +
> +Required nodes:
> + - port: Audio and video input port nodes with endpoint definitions
> + as defined in Documentation/devicetree/bindings/graph.txt.
> + port at 0 is video and port at 1 is audio.
This should probably also have an output port to the hdmi-connector
binding. It is not needed so much if this block handles DDC and HPD
itself, but if those are a separate I2C controller and GPIO,
respectively, then you need it for sure. There's also power on the
connector or other connectors like muxed on Type-C.
> +
> +Example:
> +
> + hdmi: hdmi at 01ee0000 {
> + compatible = "allwinner,sun8i-a83t-hdmi";
> + reg = <0x01ee0000 0x20000>;
> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
> + <&ccu CLK_HDMI_DDC>;
> + clock-names = "gate", "clock", "ddc-clock";
> + resets = <&ccu RST_HDMI0>, <&ccu RST_HDMI1>;
> + reset-names = "hdmi0", "hdmi1";
> + ...
Please show all properties in example.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 0 { /* video */
> + reg = <0>;
> + hdmi_lcd1: endpoint {
> + remote-endpoint = <&lcd1_hdmi>;
> + };
> + };
> + port at 1 { /* audio */
> + reg = <1>;
> + hdmi_i2s2: endpoint {
> + remote-endpoint = <&i2s2_hdmi>;
> + };
> + };
> + };
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-2-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> This commit renames the gxl-s905d-p23x DTSI in a common file for
> S905D p20x and S912 q20x boards.
>
> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 6 +
> arch/arm64/boot/dts/amlogic/Makefile | 2 +
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 190 +++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 19 +++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 7 +
> .../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
> .../boot/dts/amlogic/meson-gxl-s905d-p231.dts | 3 +-
> .../boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 188 --------------------
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 77 +++++++++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 58 +++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++
> 11 files changed, 477 insertions(+), 190 deletions(-)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> delete mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
Applied.
Git tip: for future reference, set 'git config diff.renames true' so and
the diffstat shows a better summary when files are moved/renamed.
e.g, rather than the large ++ and -- above, you'd see:
...gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} | 4 +-
Which is much more comforting to a maintainer than a bunch of
(potentially unrelated) adds and removes.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: David Lechner @ 2016-11-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
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
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: Enable OHCI as module
From: Axel Haslam @ 2016-11-21 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Enable the davinci ohci driver as a module for usb
tested with the omap138-lcdk hawk board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..b9bbbbd 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -157,6 +157,7 @@ CONFIG_HID_SONY=m
CONFIG_HID_SUNPLUS=m
CONFIG_USB=m
CONFIG_USB_MON=m
+CONFIG_USB_OHCI_HCD=m
CONFIG_USB_STORAGE=m
CONFIG_USB_MUSB_HDRC=m
CONFIG_MUSB_PIO_ONLY=y
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/5] drm: sun8i: Add a basic DRM driver for Allwinner DE2
From: Rob Herring @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff2140c86ea3b06406c77d9e8746474b6f8400c4.1479641523.git.moinejf@free.fr>
On Sun, Nov 20, 2016 at 10:53:25AM +0100, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../bindings/display/sunxi/sun8i-de2.txt | 83 +++
It's preferred to split bindings to a separate patch.
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sun8i/Kconfig | 19 +
> drivers/gpu/drm/sun8i/Makefile | 7 +
> drivers/gpu/drm/sun8i/de2_crtc.c | 440 +++++++++++++
> drivers/gpu/drm/sun8i/de2_crtc.h | 50 ++
> drivers/gpu/drm/sun8i/de2_drm.h | 48 ++
> drivers/gpu/drm/sun8i/de2_drv.c | 379 +++++++++++
> drivers/gpu/drm/sun8i/de2_plane.c | 712 +++++++++++++++++++++
> 10 files changed, 1741 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> create mode 100644 drivers/gpu/drm/sun8i/Kconfig
> create mode 100644 drivers/gpu/drm/sun8i/Makefile
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drm.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> new file mode 100644
> index 0000000..b9edd4b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> @@ -0,0 +1,83 @@
> +Allwinner sun8i Display Engine 2 subsystem
> +==========================================
> +
> +The Allwinner DE2 subsystem contains a display controller (DE2),
> +one or two LCD controllers (TCON) and their external interfaces.
> +
> +Display controller
> +==================
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "allwinner,sun8i-a83t-display-engine"
> + "allwinner,sun8i-h3-display-engine"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + "gate": DE bus gate
> + "clock": DE clock
> +
> +- resets: phandle to the reset of the device
> +
> +- ports: phandle's to the LCD ports
This should use OF graph to describe the connection from the DE to the
LCD controllers like the sun4i binding does.
No registers for the DE?
> +
> +LCD controller
> +==============
> +
> +Required properties:
> +
> +- compatible: should be
> + "allwinner,sun8i-a83t-tcon"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + "gate": TCON bus gate
> + "clock": TCON pixel clock
> +
> +- resets: phandle to the reset of the device
> +
> +- port: port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
Need to specify how many ports and endpoints.
> +
> +Example:
> +
> + de: de-controller at 01000000 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + ...
What are you not showing?
> + clocks = <&&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
> + clock-names = "gate", "clock";
> + resets = <&ccu RST_BUS_DE>;
> + ports = <&lcd0_p>;
> + };
> +
> + lcd0: lcd-controller at 01c0c000 {
> + compatible = "allwinner,sun8i-a83t-tcon";
> + ...
ditto.
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
> + clock-names = "gate", "clock";
> + resets = <&ccu RST_BUS_TCON0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_ep: endpoint {
> + remote-endpoint = <&hdmi_ep>;
> + };
> + };
> + };
> +
> + hdmi: hdmi at 01ee0000 {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + hdmi_ep: endpoint {
> + remote-endpoint = <&lcd0_ep>;
> + };
> + };
> + };
> +
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
Enable the usb1 controller (ohci) and phy for the lcdk board
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..a739603 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -86,6 +86,14 @@
};
};
+&usb_phy {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
&serial2 {
pinctrl-names = "default";
pinctrl-0 = <&serial2_rxtx_pins>;
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: da850: Add usb device node
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
Add the usb1 device node for the da850 soc.
This will allow boards to use the usb1 port
when booting through DT.
Signed-off-by: Axel Haslam <ahaslam@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 1bb1f6d..fbd50d6 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -406,6 +406,14 @@
>;
status = "disabled";
};
+ usb1: usb at 225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
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(+)
--
2.9.3
^ permalink raw reply
* [RESEND PATCH 3/3] ARM: davinci: remove ohci platform usage
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165349.29128-1-ahaslam@baylibre.com>
As all users of ohci platform data have been converted
to use a regulator, we dont need to pass platform
data to register the ohci device anymore.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 3 +--
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 16a401a..cb67885 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -129,7 +129,7 @@ static __init void da830_evm_usb_init(void)
if (ret)
pr_warn("fail to add ohci regulator\n");
- ret = da8xx_register_usb11(NULL);
+ ret = da8xx_register_usb11();
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
}
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a252404..cbe7324 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -197,7 +197,7 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- ret = da8xx_register_usb11(NULL);
+ ret = da8xx_register_usb11();
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n",
__func__, ret);
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 85ff218..b21ef07 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -91,7 +91,7 @@ int da8xx_register_spi_bus(int instance, unsigned num_chipselect);
int da8xx_register_watchdog(void);
int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
-int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
+int da8xx_register_usb11(void);
int da8xx_register_usb_refclkin(int rate);
int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index c6feecf..4ea91bb 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -119,9 +119,8 @@ static struct platform_device da8xx_usb11_device = {
.resource = da8xx_usb11_resources,
};
-int __init da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata)
+int __init da8xx_register_usb11(void)
{
- da8xx_usb11_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_usb11_device);
}
--
2.9.3
^ permalink raw reply related
* [RESEND PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165349.29128-1-ahaslam@baylibre.com>
The hawk board VBUS is fixed to a 5v source, and the over
current pin is actually not connected to the SoC.
Do not reseve these gpios for OHCI as they are not related
to usb.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 99 ++---------------------------
1 file changed, 4 insertions(+), 95 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a4e8726..a252404 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -28,9 +28,6 @@
#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12)
#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
-#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
-#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
-
static short omapl138_hawk_mii_pins[] __initdata = {
DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
@@ -181,76 +178,10 @@ static __init void omapl138_hawk_mmc_init(void)
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
-static da8xx_ocic_handler_t hawk_usb_ocic_handler;
-
-static const short da850_hawk_usb11_pins[] = {
- DA850_GPIO2_4, DA850_GPIO6_13,
- -1
-};
-
-static int hawk_usb_set_power(unsigned port, int on)
-{
- gpio_set_value(DA850_USB1_VBUS_PIN, on);
- return 0;
-}
-
-static int hawk_usb_get_power(unsigned port)
-{
- return gpio_get_value(DA850_USB1_VBUS_PIN);
-}
-
-static int hawk_usb_get_oci(unsigned port)
-{
- return !gpio_get_value(DA850_USB1_OC_PIN);
-}
-
-static int hawk_usb_ocic_notify(da8xx_ocic_handler_t handler)
-{
- int irq = gpio_to_irq(DA850_USB1_OC_PIN);
- int error = 0;
-
- if (handler != NULL) {
- hawk_usb_ocic_handler = handler;
-
- error = request_irq(irq, omapl138_hawk_usb_ocic_irq,
- IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
- "OHCI over-current indicator", NULL);
- if (error)
- pr_err("%s: could not request IRQ to watch "
- "over-current indicator changes\n", __func__);
- } else {
- free_irq(irq, NULL);
- }
- return error;
-}
-
-static struct da8xx_ohci_root_hub omapl138_hawk_usb11_pdata = {
- .set_power = hawk_usb_set_power,
- .get_power = hawk_usb_get_power,
- .get_oci = hawk_usb_get_oci,
- .ocic_notify = hawk_usb_ocic_notify,
- /* TPS2087 switch @ 5V */
- .potpgt = (3 + 1) / 2, /* 3 ms max */
-};
-
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
-{
- hawk_usb_ocic_handler(&omapl138_hawk_usb11_pdata, 1);
- return IRQ_HANDLED;
-}
-
static __init void omapl138_hawk_usb_init(void)
{
int ret;
- ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
- if (ret) {
- pr_warn("%s: USB 1.1 PinMux setup failed: %d\n", __func__, ret);
- return;
- }
-
ret = da8xx_register_usb20_phy_clk(false);
if (ret)
pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
@@ -266,34 +197,12 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- ret = gpio_request_one(DA850_USB1_VBUS_PIN,
- GPIOF_DIR_OUT, "USB1 VBUS");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "power control: %d\n", __func__, ret);
- return;
- }
-
- ret = gpio_request_one(DA850_USB1_OC_PIN,
- GPIOF_DIR_IN, "USB1 OC");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "over-current indicator: %d\n", __func__, ret);
- goto usb11_setup_oc_fail;
- }
-
- ret = da8xx_register_usb11(&omapl138_hawk_usb11_pdata);
- if (ret) {
- pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
- goto usb11_setup_fail;
- }
+ ret = da8xx_register_usb11(NULL);
+ if (ret)
+ pr_warn("%s: USB 1.1 registration failed: %d\n",
+ __func__, ret);
return;
-
-usb11_setup_fail:
- gpio_free(DA850_USB1_OC_PIN);
-usb11_setup_oc_fail:
- gpio_free(DA850_USB1_VBUS_PIN);
}
static __init void omapl138_hawk_init(void)
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox