* [PATCH v5 3/3] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293545-7516-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 2440f88..f205a03 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 510000)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -487,6 +512,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power = get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -537,11 +572,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
^ permalink raw reply related
* [PATCH v5 0/2] platform: Add DT support for DA8xx
From: Alexandre Bailon @ 2016-11-16 11:07 UTC (permalink / raw)
To: linux-arm-kernel
This add and enable the usb otg for da850 and da850-lcdk.
This series depends on "driver: dd DT support for DA8xx" patch set.
If this series is applied before the "usb: musb: da8xx: Fix few issues" patch
set then the usb driver will always retrun -ENODEV.
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Change in v4:
* Fix a nit
Changes in v5:
* Remove usb_phy node from d850.dtsi because it has already been merged.
* Separated the patch in two: one for the board and one for the SoC.
Alexandre Bailon (2):
ARM: dts: da850: Add the usb otg device node
ARM: dts: da850-lcdk: Enable the usb otg device node
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
2 files changed, 18 insertions(+)
--
2.7.3
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-16 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479294456-7942-1-git-send-email-abailon@baylibre.com>
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 2534aab..ddf4c6e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -383,6 +383,16 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
mdio: mdio at 224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
--
2.7.3
^ permalink raw reply related
* [PATCH v5 2/2] ARM: dts: da850-lcdk: Enable the usb otg device node
From: Alexandre Bailon @ 2016-11-16 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479294456-7942-1-git-send-email-abailon@baylibre.com>
This enables the usb otg controller for the lcdk board.
Signed-off-by: Alexandre Bailon <abailon@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..03f9bfd 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
--
2.7.3
^ permalink raw reply related
* [PATCH] clk: rockchip: rk3399: fix copy-paste error
From: Heiko Stuebner @ 2016-11-16 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479255581-7489-1-git-send-email-jay.xu@rock-chips.com>
Am Mittwoch, 16. November 2016, 08:19:41 CET schrieb Jianqun Xu:
> Fix RK3368_* to RK3399_* for rk3399 clk_test clock.
>
> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
applied to my clk branch for 4.10
Thanks
Heiko
^ permalink raw reply
* ILP32 for ARM64: testing with glibc testsuite
From: Maxim Kuvyrkov @ 2016-11-16 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109095650.GA22804@yury-N73SV>
> On Nov 9, 2016, at 1:56 PM, Yury Norov <ynorov@caviumnetworks.com> wrote:
>
> On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
>> Hi all,
>>
>> [add libc-alpha mail list]
>>
>> For libc-alpha: this is the part of LKML submission with latest
>> patches for aarch64/ilp32.
>> https://www.spinics.net/lists/arm-kernel/msg537846.html
>>
>> Glibc that I use has also included consolidation patches from Adhemerval
>> Zanella and me that are still not in the glibc master. The full series is:
>> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
>>
>> Below is the results of glibc testsuite run for aarch64/lp64
>> in different configurations. Column names meaning:
>> kvgv: kernel is vanilla, glibc is vanilla;
>> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config;
>> glibc is vanilla;
>> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
>> kege: kernel patches are applied and enabled, glibc patches are applied.
>>
>> Only different lines are shown. Full results are in attached archive.
Hi Yury,
The general requirement merging ILP32 glibc patches is that LP64 does not regress in any reasonable configuration. This means that there should be 0 regressions between kvgv and kvge -- i.e., glibc in LP64 mode with and without ILP32 patches does not regress on the vanilla kernel. The kvge configuration is not in your testing matrix, and I suggest you make sure it has no regressions before fixing the more "advanced" configuration of kege.
Ideally, there should be no regressions between kvgv and kege configurations, but I don't consider this to a requirement for glibc acceptance of ILP32 patches, since any regressions between kvge and kege configurations are likely to be on the kernel side.
Speculating on the kernel requirements for ILP32 kernel patchset, I think there should be 0 regressions between kvgv and kdgv configurations, where you have only 3 tests to investigate and fix.
[I do appreciate that there are progressions in your results as well, but the glibc policy is that they do not offset regressions.]
The above only concerns LP64 support in kernel and glibc.
Regarding ILP32 runtime, my opinion is that it is acceptable for ILP32 to have extra failures compared to LP64, since these are not regressions, but, rather, failures of a new configuration. From a superficial glance is seems that ILP32 linknamespace support requires attention, as well as stack unwinding (judging from NPTL failures).
--
Maxim Kuvyrkov
www.linaro.org
>
> The same, plus ILP32 regressions:
>
> Test kvgv kdgv kegv kege ilp32
> conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
> csu/tst-atomic PASS PASS PASS FAIL PASS
> elf/check-localplt PASS PASS PASS FAIL FAIL
> iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL
> iconvdata/tst-loading PASS FAIL PASS PASS PASS
> io/check-installed-headers-c PASS PASS PASS FAIL FAIL
> io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL
> malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS
> malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS
> malloc/tst-malloc-usable FAIL PASS PASS PASS PASS
> malloc/tst-mallocfork FAIL PASS PASS PASS PASS
> malloc/tst-mallocstate FAIL PASS PASS PASS PASS
> malloc/tst-mallopt FAIL PASS PASS PASS PASS
> malloc/tst-mcheck FAIL PASS PASS PASS PASS
> malloc/tst-memalign FAIL PASS PASS PASS PASS
> malloc/tst-obstack FAIL PASS PASS PASS PASS
> malloc/tst-posix_memalign FAIL PASS PASS PASS PASS
> malloc/tst-pvalloc FAIL PASS PASS PASS PASS
> malloc/tst-realloc FAIL PASS PASS PASS PASS
> malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS
> malloc/tst-trim1 FAIL PASS PASS PASS PASS
> nptl/tst-eintr4 PASS PASS PASS NA NA
> posix/tst-regex2 PASS FAIL FAIL FAIL FAIL
> posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS
> posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS
> sysvipc/test-sysvmsg NA NA NA FAIL PASS
> sysvipc/test-sysvsem NA NA NA FAIL PASS
> sysvipc/test-sysvshm NA NA NA FAIL PASS
>
> c++-types-check PASS PASS PASS PASS FAIL
> debug/tst-backtrace4 PASS PASS PASS PASS FAIL
> elf/check-abi-libc PASS PASS PASS PASS FAIL
> elf/tst-tls1 PASS PASS PASS PASS FAIL
> elf/tst-tls1-static PASS PASS PASS PASS FAIL
> elf/tst-tls2 PASS PASS PASS PASS FAIL
> elf/tst-tls2-static PASS PASS PASS PASS FAIL
> elf/tst-tls3 PASS PASS PASS PASS FAIL
> math/check-abi-libm PASS PASS PASS PASS FAIL
> misc/tst-writev PASS PASS PASS PASS NA
> nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL
> nptl/tst-cancel1 PASS PASS PASS PASS FAIL
> nptl/tst-cancel10 PASS PASS PASS PASS FAIL
> nptl/tst-cancel11 PASS PASS PASS PASS FAIL
> nptl/tst-cancel13 PASS PASS PASS PASS FAIL
> nptl/tst-cancel15 PASS PASS PASS PASS FAIL
> nptl/tst-cancel16 PASS PASS PASS PASS FAIL
> nptl/tst-cancel17 PASS PASS PASS PASS FAIL
> nptl/tst-cancel18 PASS PASS PASS PASS FAIL
> nptl/tst-cancel2 PASS PASS PASS PASS FAIL
> nptl/tst-cancel20 PASS PASS PASS PASS FAIL
> nptl/tst-cancel21 PASS PASS PASS PASS FAIL
> nptl/tst-cancel24 PASS PASS PASS PASS FAIL
> nptl/tst-cancel25 PASS PASS PASS PASS FAIL
> nptl/tst-cancel26 PASS PASS PASS PASS FAIL
> nptl/tst-cancel27 PASS PASS PASS PASS FAIL
> nptl/tst-cancel3 PASS PASS PASS PASS FAIL
> nptl/tst-cancel4 PASS PASS PASS PASS FAIL
> nptl/tst-cancel5 PASS PASS PASS PASS FAIL
> nptl/tst-cancel6 PASS PASS PASS PASS FAIL
> nptl/tst-cancel7 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx10 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx11 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx13 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx15 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx16 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx17 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx18 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx2 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx20 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx21 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx3 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx4 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx5 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx6 PASS PASS PASS PASS FAIL
> nptl/tst-cancelx7 PASS PASS PASS PASS FAIL
> nptl/tst-cleanup4 PASS PASS PASS PASS FAIL
> nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL
> nptl/tst-cond-except PASS PASS PASS PASS FAIL
> nptl/tst-cond7 PASS PASS PASS PASS FAIL
> nptl/tst-cond8 PASS PASS PASS PASS FAIL
> nptl/tst-fini1 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL
> nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL
> nptl/tst-join5 PASS PASS PASS PASS FAIL
> nptl/tst-key3 PASS PASS PASS PASS FAIL
> nptl/tst-mutex8 PASS PASS PASS PASS FAIL
> nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL
> nptl/tst-once3 PASS PASS PASS PASS FAIL
> nptl/tst-once4 PASS PASS PASS PASS FAIL
> nptl/tst-oncex3 PASS PASS PASS PASS FAIL
> nptl/tst-oncex4 PASS PASS PASS PASS FAIL
> nptl/tst-rwlock15 PASS PASS PASS PASS FAIL
> nptl/tst-rwlock8 PASS PASS PASS PASS FAIL
> nptl/tst-rwlock9 PASS PASS PASS PASS FAIL
> nptl/tst-sem11 PASS PASS PASS PASS FAIL
> nptl/tst-sem12 PASS PASS PASS PASS FAIL
> posix/bug-regex24 PASS PASS PASS PASS FAIL
> rt/tst-mqueue1 PASS PASS PASS PASS FAIL
> rt/tst-mqueue2 PASS PASS PASS PASS FAIL
> rt/tst-mqueue4 PASS PASS PASS PASS FAIL
> rt/tst-mqueue7 PASS PASS PASS PASS FAIL
> rt/tst-mqueue8 PASS PASS PASS PASS FAIL
> rt/tst-mqueue8x PASS PASS PASS PASS FAIL
> stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL
^ permalink raw reply
* [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Sriram Dash @ 2016-11-16 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0401MB1931C92287A8E92BC6B52B1991BE0@HE1PR0401MB1931.eurprd04.prod.outlook.com>
>From: Scott Wood
>On 11/15/2016 06:39 AM, Sriram Dash wrote:
>>> From: Scott Wood
>>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>> new file mode 100644
>>>> index 0000000..d934c80
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>>> @@ -0,0 +1,36 @@
>>>> +Driver for Freescale USB 3.0 PHY
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible : fsl,qoriq-usb3-phy
>>>
>>
>> Hi Scott,
>>
>>> This is a very vague compatible. Are there versioning registers
>>> within this register block?
>>>
>>
>> There are versioning registers for the phy (1.0 and 1.1). But the
>> current erratum
>> A008751 does not require the mentioning of the version numbers. Was
>> planning to take care of the versioning when there is code diversity
>> on the basis of the version number.
>
>That is not how device tree bindings work. The describe the hardware, not the
>driver.
>
>That said, is the block version sufficient to tell whether a given chip has this
>erratum? If so, you don't need a special property for the erratum. If not, what is
>different about the PHY that is not described by the versioning?
>
>In any case, it would be nice to mention the version register and its offset in the
>binding, just so that it becomes part of the definition of this compatible string, and
>if we come out with some QorIQ chip with a
>USB3 PHY that is totally different and doesn't have that version register, it'll be
>clear that it needs a different compatible.
>
Okay. Will include version number in the next rev for Documentation and dt.
>>>> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
>>>> +offset) {
>>>> + return __raw_readl(addr + offset); }
>>>> +
>>>> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
>>>> + u32 data)
>>>> +{
>>>> + __raw_writel(data, addr + offset); }
>>>
>>> Why raw? Besides missing barriers, this will cause the accesses to
>>> be native-endian which is not correct.
>>>
>>
>> The only reason for __raw_writel is to make the code faster.
>
>Does that really matter here?
>
>> However, shall I use writel(with both barriers and byte swap) instead
>
>Yes, if the registers are little-endian on all chips.
>
The endianness is not same for all Socs. But for most Socs, it is big-endian.
Is "iowrite32be" better instead?
>> and then make appropriate changes in the value 32'h27672B2A?
>
>Not sure what you mean here.
>
>> In my knowledge, there are more than 5 errata in pipeline,
>
>Then please get all of these errata described in the device tree ASAP (unless their
>presence can be reliably inferred from the block version, as discussed above).
>
Yes. We will push the errata asap.
>> However, in future, if any other erratum comes up, and it has to be
>> applied at any point other than during init, then the variable has to
>> be added in qoriq_usb3_phy struct and the property has to be read separately.
>
>Or if the erratum is detected by some means other than a device tree property...
>
Yes. For any other case also, it will be handled differently.
>-Scott
^ permalink raw reply
* [PATCH v5 1/2] drm: tilcdc: implement palette loading for rev1
From: Bartosz Golaszewski @ 2016-11-16 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fc032e5-cc23-ae7b-9f59-9c71c0a909b8@ti.com>
2016-10-31 17:05 GMT+01:00 Jyri Sarha <jsarha@ti.com>:
> On 10/31/16 16:19, Bartosz Golaszewski wrote:
>> Revision 1 of the IP doesn't work if we don't load the palette (even
>> if it's not used, which is the case for the RGB565 format).
>>
>> Add a function called from tilcdc_crtc_enable() which performs all
>> required actions if we're dealing with a rev1 chip.
>>
>
> There is only one thing I do not like about this patch. The palette
> loading is done so late that the frame buffer address are already placed
> into DMA base and ceiling registers, and we need to read them from the
> registers and restore them back after the palette loading.
>
> Could you try if the palette loading function works without trouble when
> called from tilcdc_pm_resume() before drm_atomic_helper_resume() call?
> If it does it would be cleaner in the sense that you could get rid off
> the old dma address restore code. You could reinit the completion always
> there right before the palette loading.
>
> If you can not get the above suggestion to work, then I can take this
> patch.
>
Hi Jyri,
the problem is that tilcdc_pm_resume() is not called when tilcdc is
initialized. We would have to have two calls in different places for
that to work.
>> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
>> +{
>> + u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
>> + struct tilcdc_crtc *tilcdc_crtc;
>> + struct drm_device *dev;
>> + u16 *first_entry;
>> +
>> + dev = crtc->dev;
>> + tilcdc_crtc = to_tilcdc_crtc(crtc);
>> + first_entry = tilcdc_crtc->palette_base;
>> +
>> + *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
>> +
>> + dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
>> + dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
>> + raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
>> +
>> + /* Tell the LCDC where the palette is located. */
>> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
>> + tilcdc_crtc->palette_dma_handle);
>> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
>> + (u32)tilcdc_crtc->palette_dma_handle
>
> Just a nit pick, but I would put the plus sign to the end of the line
> above instead of the beginning of the line bellow. However,
> check_patch.pl does not complain about this so I guess I can accept it too.
>
>> + + TILCDC_REV1_PALETTE_SIZE - 1);
>> +
I'll fix that in v6.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v2] mxs-auart: count FIFO overrun errors
From: Wolfgang Ocker @ 2016-11-16 11:37 UTC (permalink / raw)
To: linux-arm-kernel
The mxs-auart driver does not count FIFO overrun errors. These errors never
appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
masked by read_status_mask in the rx interrupt function, but the
AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
counting of overrun errors.
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
v2: sent with git-send-email. Evolution changes a leading space to 0xa0 :(
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 770454e0dfa3..8c1c9112b3fd 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1016,7 +1016,7 @@ static void mxs_auart_settermios(struct uart_port *u,
ctrl |= AUART_LINECTRL_EPS;
}
- u->read_status_mask = 0;
+ u->read_status_mask = AUART_STAT_OERR;
if (termios->c_iflag & INPCK)
u->read_status_mask |= AUART_STAT_PERR;
--
2.10.0
^ permalink raw reply related
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-16 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258013-6669-1-git-send-email-vijay.kilari@gmail.com>
On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
Do we have QEMU/kvmtool patches somewhere at this point so that I can
test this?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v2] mxs-auart: count FIFO overrun errors
From: Fabio Estevam @ 2016-11-16 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116113745.12026-1-weo@reccoware.de>
On Wed, Nov 16, 2016 at 9:37 AM, Wolfgang Ocker <weo@reccoware.de> wrote:
> The mxs-auart driver does not count FIFO overrun errors. These errors never
> appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
> masked by read_status_mask in the rx interrupt function, but the
> AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
> counting of overrun errors.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Ard Biesheuvel @ 2016-11-16 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115235331.GE25626@codeaurora.org>
On 15 November 2016 at 23:53, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/15, Ard Biesheuvel wrote:
>> On 15 November 2016 at 19:18, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> > On 11/15, Ard Biesheuvel wrote:
>> >> On 19 October 2016 at 00:42, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> >> >
>> >> > +static unsigned char ideal_nop4_arm_le[4] = { 0x00, 0x00, 0xa0, 0xe1 }; /* mov r0, r0 */
>> >> > +static unsigned char ideal_nop4_arm_be[4] = { 0xe1, 0xa0, 0x00, 0x00 }; /* mov r0, r0 */
>> >>
>> >> Shouldn't you be taking the difference between BE8 and BE32 into
>> >> account here? IIRC, BE8 uses little endian encoding for instructions.
>> >
>> > I admit I haven't tested on a pre-armv6 CPU so I haven't come
>> > across the case of a BE32 CPU. But from what I can tell that
>> > doesn't matter.
>> >
>> > According to scripts/Makefile.build, cmd_record_mcount only runs
>> > the recordmcount program if CONFIG_FTRACE_MCOUNT_RECORD=y. That
>> > config is defined as:
>> >
>> > config FTRACE_MCOUNT_RECORD
>> > def_bool y
>> > depends on DYNAMIC_FTRACE
>> > depends on HAVE_FTRACE_MCOUNT_RECORD
>> >
>> >
>> > And in arch/arm/Kconfig we see that DYNAMIC_FTRACE is selected:
>> >
>> > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
>> >
>> > which means that FTRACE_MCOUNT_RECORD can't be set when
>> > CPU_ENDIAN_BE32 is set.
>> >
>> > Do you agree that BE32 is not a concern here?
>> >
>>
>> Yes. But that implies then that you should not be using big-endian
>> instruction encodings at all, and simply use the _le variants for both
>> LE and BE8
>
> Ok. I understand what you're getting at now.
>
> I believe the linker is the one that does the instruction endian
> swap to little endian. So everything is built as big-endian data
> and instructions in the assembler phase and then when the linker
> runs to generate the final vmlinux elf file it does the swaps to
> make instructions little endian. recordmcount runs on the object
> files and not the vmlinux file.
>
Very interesting, I did not know that.
> For example, the do_undefinstr() function in
> arch/arm/kernel/traps.c is one place we nop out. On an le host
> and an le build without this patch I see:
>
> (This is all ARM, not thumb)
>
> 00000000 <do_undefinstr>:
> 0: e1a0c00d mov ip, sp
> 4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
> 8: e24cb004 sub fp, ip, #4
> c: e24dd08c sub sp, sp, #140 ; 0x8c
> 10: e52de004 push {lr} ; (str lr, [sp, #-4]!)
> 14: ebfffffe bl 0 <__gnu_mcount_nc>
>
> After this patch on an le host and le build I see:
>
> 00000000 <do_undefinstr>:
> 0: e1a0c00d mov ip, sp
> 4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
> 8: e24cb004 sub fp, ip, #4
> c: e24dd08c sub sp, sp, #140 ; 0x8c
> 10: e1a00000 nop ; (mov r0, r0)
> 14: e1a00000 nop ; (mov r0, r0)
>
> So far so good. Similarly, with this patch and an le host and be
> build I see:
>
> 00000000 <do_undefinstr>:
> 0: e1a0c00d mov ip, sp
> 4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
> 8: e24cb004 sub fp, ip, #4
> c: e24dd08c sub sp, sp, #140 ; 0x8c
> 10: e1a00000 nop ; (mov r0, r0)
> 14: e1a00000 nop ; (mov r0, r0)
>
> but with *_le instead of *_be used a be build I see:
>
> 00000000 <do_undefinstr>:
> 0: e1a0c00d mov ip, sp
> 4: e92dd9f0 push {r4, r5, r6, r7, r8, fp, ip, lr, pc}
> 8: e24cb004 sub fp, ip, #4
> c: e24dd08c sub sp, sp, #140 ; 0x8c
> 10: 0000a0e1 andeq sl, r0, r1, ror #1
> 14: 0000a0e1 andeq sl, r0, r1, ror #1
>
> I confirmed this by looking at the hexdump of the .exception.text
> section for the traps.o object file and the .text section of the
> vmlinux file. Basically objcopy the .exception.text of traps.o to
> get the first few instructions of the do_undefinstr() function:
>
> $ hexdump -C traps.o
> 00000000 e1 a0 c0 0d e9 2d d9 f0 e2 4c b0 04 e2 4d d0 8c
>
> And then objcopy the .text section in vmlinux and seek to the
> same function offset (there are a bunch of zeroes in front of it
> for padding):
>
> $ hexdump -C vmlinux
> ...
> 00001000 0d c0 a0 e1 f0 d9 2d e9 04 b0 4c e2 8c d0 4d e2
>
> As can be seen everything is swapped from the original object
> file in big-endian to be in little endian.
>
> Does that allay your concerns?
>
Yes, it does. Thanks
^ permalink raw reply
* [PATCH v2] input: touchscreen: silead: Add regulator support
From: Hans de Goede @ 2016-11-16 11:55 UTC (permalink / raw)
To: linux-arm-kernel
On some tablets the touchscreen controller is powered by separate
regulators, add support for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
-Use devm_regulator_bulk_get() and friends
-Use devm_add_action_or_reset() to disable the regulator
---
.../bindings/input/touchscreen/silead_gsl1680.txt | 2 ++
drivers/input/touchscreen/silead.c | 29 ++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
index e844c3f..b726823 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
@@ -22,6 +22,8 @@ Optional properties:
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
- silead,max-fingers : maximum number of fingers the touchscreen can detect
+- vddio-supply : regulator phandle for controller VDDIO
+- avdd-supply : regulator phandle for controller AVDD
Example:
diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
index f502c84..404830a 100644
--- a/drivers/input/touchscreen/silead.c
+++ b/drivers/input/touchscreen/silead.c
@@ -29,6 +29,7 @@
#include <linux/input/touchscreen.h>
#include <linux/pm.h>
#include <linux/irq.h>
+#include <linux/regulator/consumer.h>
#include <asm/unaligned.h>
@@ -73,6 +74,7 @@ struct silead_ts_data {
struct i2c_client *client;
struct gpio_desc *gpio_power;
struct input_dev *input;
+ struct regulator_bulk_data regulators[2];
char fw_name[64];
struct touchscreen_properties prop;
u32 max_fingers;
@@ -433,6 +435,13 @@ static int silead_ts_set_default_fw_name(struct silead_ts_data *data,
}
#endif
+static void silead_disable_regulator(void *arg)
+{
+ struct silead_ts_data *data = arg;
+
+ regulator_bulk_disable(ARRAY_SIZE(data->regulators), data->regulators);
+}
+
static int silead_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -465,6 +474,26 @@ static int silead_ts_probe(struct i2c_client *client,
if (client->irq <= 0)
return -ENODEV;
+ data->regulators[0].supply = "vddio";
+ data->regulators[1].supply = "avdd";
+ error = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->regulators),
+ data->regulators);
+ if (error)
+ return error;
+
+ /*
+ * Enable regulators at probe and disable them at remove, we need
+ * to keep the chip powered otherwise it forgets its firmware.
+ */
+ error = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
+ data->regulators);
+ if (error)
+ return error;
+
+ error = devm_add_action_or_reset(dev, silead_disable_regulator, data);
+ if (error)
+ return error;
+
/* Power GPIO pin */
data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
if (IS_ERR(data->gpio_power)) {
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Robin Murphy @ 2016-11-16 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479288013-30945-1-git-send-email-m.szyprowski@samsung.com>
On 16/11/16 09:20, Marek Szyprowski wrote:
> fs_initcall is definitely too late to initialize DMA-debug hash tables,
> because some drivers might get probed and use DMA mapping framework
> already in core_initcall. Late initialization of DMA-debug results in
> false warning about accessing memory, that was not allocated. This issue
> has been observed on ARM 32bit, but the same driver can be used also on
> ARM64.
>
> This patch moves initialization of DMA-debug to core_initcall. This is
> safe from the initialization perspective. dma_debug_do_init() internally
> calls debugfs functions and debugfs also gets initialised at
> core_initcall(), and that is earlier than arch code in the link order,
> so it will get initialized just before the DMA-debug.
>
> Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Cheers Marek - as it happens, the ARM SMMU drivers (and presumably the
Mediatek one) do hit this on arm64 since I added the DMA API support to
the io-pgtable code, I've just been quietly ignoring it in the hope we'd
get the probe-deferral stuff done before anyone else noticed.
Robin.
> ---
> For more details on this issue, see the patch for ARM 32bit arch:
> https://www.spinics.net/lists/arm-kernel/msg542721.html
> https://www.spinics.net/lists/arm-kernel/msg542782.html
> ---
> arch/arm64/mm/dma-mapping.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 3f74d0d..8653426 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -538,7 +538,7 @@ static int __init dma_debug_do_init(void)
> dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> return 0;
> }
> -fs_initcall(dma_debug_do_init);
> +core_initcall(dma_debug_do_init);
>
>
> #ifdef CONFIG_IOMMU_DMA
>
^ permalink raw reply
* [PATCH v2 10/10] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Heiko Stuebner @ 2016-11-16 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479125863-24646-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:17:43 CET schrieb Andy Yan:
> RK1108 EVB is designed by Rockchip for CVR field.
> This patch add basic support for it, which can boot with
> initramfs into shell.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
>
> ---
>
> Changes in v2:
> - move the board in the rockchip.txt to the block of Rockchip boards
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk1108-evb.dts | 69
> ++++++++++++++++++++++ 3 files changed, 74 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index 10b92b5..e658b62
> 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -1,6 +1,5 @@
> Rockchip platforms device tree bindings
> ---------------------------------------
> -
> - Kylin RK3036 board:
> Required root node properties:
> - compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
dropped this unrelated change
> @@ -111,6 +110,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
>
> +- Rockchip RK1108 Evaluation board
> + Required root node properties:
> + - compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
> +
> - Rockchip RK3368 evb:
> Required root node properties:
> - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
binding moved to a separate patch and applied to my dts64 to prevent conflicts
with px5 addition.
And the actual board dts of course applied to my dts32 branch.
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/2] ARM: dts: rockchip: enable sdmmc for rk1108-evb
From: Heiko Stuebner @ 2016-11-16 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479024799-29198-2-git-send-email-jacob-chen@iotwrt.com>
Am Sonntag, 13. November 2016, 16:13:19 CET schrieb Jacob Chen:
> From: Jacob Chen <jacob2.chen@rock-chips.com>
>
> This patch add sdmmc support for rk1108-evb, now I can load the rootfs
> from sdmmc.
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
> arch/arm/boot/dts/rk1108-evb.dts | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk1108-evb.dts
> b/arch/arm/boot/dts/rk1108-evb.dts index 3956cff..cea26e5 100644
> --- a/arch/arm/boot/dts/rk1108-evb.dts
> +++ b/arch/arm/boot/dts/rk1108-evb.dts
> @@ -56,6 +56,18 @@
> };
> };
>
> +&sdmmc {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + card-detect-delay = <200>;
> + disable-wp;
> + num-slots = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
> + status = "okay";
> +};
> +
> &uart0 {
> status = "okay";
> };
> @@ -67,3 +79,12 @@
> &uart2 {
> status = "okay";
> };
> +
> +&pinctrl {
> +
> + sdmmc {
> + sdmmc_pwr: sdmmc-pwr {
> + rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_up_drv_4ma>;
> + };
the above is unsued, and in general please use a fixed regulator as vmmc, as
all other Rockchip boards do already, so that the mmc core can handle it
itself.
Thanks
Heiko
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Catalin Marinas @ 2016-11-16 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479288013-30945-1-git-send-email-m.szyprowski@samsung.com>
On Wed, Nov 16, 2016 at 10:20:13AM +0100, Marek Szyprowski wrote:
> fs_initcall is definitely too late to initialize DMA-debug hash tables,
> because some drivers might get probed and use DMA mapping framework
> already in core_initcall. Late initialization of DMA-debug results in
> false warning about accessing memory, that was not allocated. This issue
> has been observed on ARM 32bit, but the same driver can be used also on
> ARM64.
>
> This patch moves initialization of DMA-debug to core_initcall. This is
> safe from the initialization perspective. dma_debug_do_init() internally
> calls debugfs functions and debugfs also gets initialised at
> core_initcall(), and that is earlier than arch code in the link order,
> so it will get initialized just before the DMA-debug.
Do we really want to rely on the link order within an initcall level?
What guarantees this?
I hope someone sorts out the deferred probe or some other dependency
detection mechanism to address this issue. But in the meantime I
wouldn't merge a patch which relies on just the link order.
--
Catalin
^ permalink raw reply
* [PATCH 1/2] ARM: dts: rockchip: add the sdmmc pinctrl for rk1108
From: Heiko Stuebner @ 2016-11-16 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479024799-29198-1-git-send-email-jacob-chen@iotwrt.com>
Am Sonntag, 13. November 2016, 16:13:18 CET schrieb Jacob Chen:
> From: Jacob Chen <jacob2.chen@rock-chips.com>
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
> arch/arm/boot/dts/rk1108.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
> index 9dccfea..6a06ad7 100644
> --- a/arch/arm/boot/dts/rk1108.dtsi
> +++ b/arch/arm/boot/dts/rk1108.dtsi
> @@ -321,6 +321,31 @@
> input-enable;
> };
>
> + sdmmc {
I've fixed the intendation here (needed tabs instead of spaces) and moved the
block to its alphabetically correct position between i2c and uart nodes and
applied the result to my dts32 branch.
Thanks
Heiko
^ permalink raw reply
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Simon Horman @ 2016-11-16 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479290751-9705-1-git-send-email-geert+renesas@glider.be>
On Wed, Nov 16, 2016 at 11:05:51AM +0100, Geert Uytterhoeven wrote:
> Add the compatible strings for supporting the generic cpufreq driver on
> the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Support for RZ/G1M and RZ/G1E is expected to land in v4.10.
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v6] drm: tilcdc: implement palette loading for rev1
From: Bartosz Golaszewski @ 2016-11-16 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- only allocate dma memory for revision 1
v2 -> v3:
- use devres managed API for dma memory allocation
v3 -> v4:
- reinit the palette completion in tilcdc_crtc_disable()
v4 -> v5:
[nothing regarding this patch]
v5 -> v6:
- minor coding style fixes
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 88 +++++++++++++++++++++++++++++++++++-
1 file changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index f4ee9c2..dfe3dd0 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -21,11 +21,15 @@
#include <drm/drm_flip_work.h>
#include <drm/drm_plane_helper.h>
#include <linux/workqueue.h>
+#include <linux/completion.h>
+#include <linux/dma-mapping.h>
#include "tilcdc_drv.h"
#include "tilcdc_regs.h"
-#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
+#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
+#define TILCDC_REV1_PALETTE_SIZE 32
+#define TILCDC_REV1_PALETTE_FIRST_ENTRY 0x4000
struct tilcdc_crtc {
struct drm_crtc base;
@@ -53,6 +57,10 @@ struct tilcdc_crtc {
int sync_lost_count;
bool frame_intact;
+
+ dma_addr_t palette_dma_handle;
+ void *palette_base;
+ struct completion palette_loaded;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -98,6 +106,55 @@ static void set_scanout(struct drm_crtc *crtc, struct drm_framebuffer *fb)
tilcdc_crtc->curr_fb = fb;
}
+/*
+ * The driver currently only supports the RGB565 format for revision 1. For
+ * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
+ * the framebuffer are still considered palette. The first 16-bit entry must
+ * be 0x4000 while all other entries must be zeroed.
+ */
+static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
+{
+ u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
+ struct tilcdc_crtc *tilcdc_crtc;
+ struct drm_device *dev;
+ u16 *first_entry;
+
+ dev = crtc->dev;
+ tilcdc_crtc = to_tilcdc_crtc(crtc);
+ first_entry = tilcdc_crtc->palette_base;
+
+ *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
+
+ dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
+ dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
+ raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+
+ /* Tell the LCDC where the palette is located. */
+ tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
+ tilcdc_crtc->palette_dma_handle);
+ tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
+ (u32)tilcdc_crtc->palette_dma_handle +
+ TILCDC_REV1_PALETTE_SIZE - 1);
+
+ /* Load it. */
+ tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
+ LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
+ tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+ LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
+
+ /* Enable the LCDC and wait for palette to be loaded. */
+ tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+ tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+ wait_for_completion(&tilcdc_crtc->palette_loaded);
+
+ /* Restore the registers. */
+ tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+ tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
+ tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
+ tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
+}
+
static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
{
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -154,6 +211,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+ struct tilcdc_drm_private *priv = dev->dev_private;
WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
@@ -164,6 +222,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
reset(crtc);
+ if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
+ tilcdc_crtc_load_palette(crtc);
+
tilcdc_crtc_enable_irqs(dev);
tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
@@ -202,6 +263,13 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
__func__);
}
+ /*
+ * LCDC will not retain the palette when reset. Make sure it gets
+ * reloaded on tilcdc_crtc_enable().
+ */
+ if (priv->rev == 1)
+ reinit_completion(&tilcdc_crtc->palette_loaded);
+
drm_crtc_vblank_off(crtc);
tilcdc_crtc_disable_irqs(dev);
@@ -804,6 +872,14 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
__func__, stat);
+ if (priv->rev == 1) {
+ if (stat & LCDC_PL_LOAD_DONE) {
+ complete(&tilcdc_crtc->palette_loaded);
+ tilcdc_clear(dev,
+ LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
+ }
+ }
+
/* For revision 2 only */
if (priv->rev == 2) {
if (stat & LCDC_FRAME_DONE) {
@@ -865,6 +941,16 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
return NULL;
}
+ if (priv->rev == 1) {
+ init_completion(&tilcdc_crtc->palette_loaded);
+ tilcdc_crtc->palette_base = dmam_alloc_coherent(dev->dev,
+ TILCDC_REV1_PALETTE_SIZE,
+ &tilcdc_crtc->palette_dma_handle,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!tilcdc_crtc->palette_base)
+ return ERR_PTR(-ENOMEM);
+ }
+
crtc = &tilcdc_crtc->base;
ret = tilcdc_plane_init(dev, &tilcdc_crtc->primary);
--
2.9.3
^ permalink raw reply related
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-16 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116032620.GV3000@localhost>
On 11/16/2016 04:26 AM, Vinod Koul wrote:
> On Thu, Nov 10, 2016 at 04:17:48PM +0100, Sylwester Nawrocki wrote:
>> This patch series aims to convert the s3c64xx platform to use
>> the new DMA channel request API, i.e. this is only meaningful
>> for non-dt systems using s3c64xx SoCs.
>>
>> Presumably the first 2 or 4 patches in this series could be queued
>> for v4.10-rc1 and the remaining patches could be left for subsequent
>> release, to avoid non-trivial conflict with patches already applied
>> in the ASoC tree.
>
> I am fine with dma patch (expect the subsystem tag) and others except arm
> ones have acks, so I think we can merge this for v4.10-rc1. I cna create a
> immutable tag and people can merge into their tree in case they have
> dependencies.
>
> Btw need acks on ARM patches before I can apply
Great, then we an Ack for these 2 patches:
ARM: s3c64xx: Add DMA slave maps for PL080 devices
ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH v2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-16 13:15 UTC (permalink / raw)
To: linux-arm-kernel
Just like on sun8i all sun5i tablets use the same interrupt and power
gpios for their touchscreens. I've checked all known a13 fex files and
only the UTOO P66 uses a different gpio for the interrupt.
Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
fills in the necessary gpios to avoid duplication in the tablet dts files,
just like we do in sun8i-reference-design-tablet.dtsi.
This will make future patches adding touchscreen nodes to a13 tablets
simpler.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use generic pin mux properties "pins", "function", "drive-strength" and
"bias-disable"
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
.../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index a8b0bcc..3d7ff10 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -83,22 +83,6 @@
allwinner,pins = "PG3";
};
-&i2c1 {
- icn8318: touchscreen at 40 {
- compatible = "chipone,icn8318";
- reg = <0x40>;
- interrupt-parent = <&pio>;
- interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
- pinctrl-names = "default";
- pinctrl-0 = <&ts_wake_pin_p66>;
- wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- touchscreen-inverted-x;
- touchscreen-swapped-x-y;
- };
-};
-
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_a>;
@@ -121,20 +105,26 @@
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
-
- ts_wake_pin_p66: ts_wake_pin at 0 {
- allwinner,pins = "PB3";
- allwinner,function = "gpio_out";
- allwinner,drive = <SUN4I_PINCTRL_10_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- };
-
};
®_usb0_vbus {
gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
};
+&touchscreen {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ /* The P66 uses a different EINT then the reference design */
+ interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ /* The icn8318 binding expects wake-gpios instead of power-gpios */
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ status = "okay";
+};
+
&uart1 {
/* The P66 uses the uart pins as gpios */
status = "disabled";
diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
index 20cc940..82f87cd 100644
--- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
@@ -41,6 +41,7 @@
*/
#include "sunxi-reference-design-tablet.dtsi"
+#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pwm/pwm.h>
/ {
@@ -84,6 +85,23 @@
};
&i2c1 {
+ /*
+ * The gsl1680 is rated at 400KHz and it will not work reliable at
+ * 100KHz, this has been confirmed on multiple different q8 tablets.
+ * All other devices on this bus are also rated for 400KHz.
+ */
+ clock-frequency = <400000>;
+
+ touchscreen: touchscreen {
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_power_pin>;
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ /* Tablet dts must provide reg and compatible */
+ status = "disabled";
+ };
+
pcf8563: rtc at 51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
@@ -125,6 +143,13 @@
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
+ ts_power_pin: ts_power_pin {
+ pins = "PB3";
+ function = "gpio_out";
+ drive-strength = <10>;
+ bias-disable;
+ };
+
usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
allwinner,pins = "PG1";
allwinner,function = "gpio_in";
--
2.9.3
^ permalink raw reply related
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479290189.17538.25.camel@baylibre.com>
> There two kind of PHYs supporting eee, the one advertising eee by
> default (like realtek) and the one not advertising it (like micrel).
I don't know too much about EEE. So maybe a dumb question. Does the
MAC need to be involved? Or is it just the PHY?
If the MAC needs to be involved, the PHY should not be advertising EEE
unless the MAC asks for it by calling phy_init_eee(). If this is true,
maybe we need to change the realtek driver, and others in that class.
Andrew
^ permalink raw reply
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Tomasz Nowicki @ 2016-11-16 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
On 09.11.2016 15:19, Lorenzo Pieralisi wrote:
> This patch series is v7 of a previous posting:
>
> https://lkml.org/lkml/2016/10/18/506
>
[...]
>
> The ACPI IORT table provides information that allows instantiating
> ARM SMMU devices and carrying out id mappings between components on
> ARM based systems (devices, IOMMUs, interrupt controllers).
>
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>
> Building on basic IORT support, this patchset enables ARM SMMUs support
> on ACPI systems.
>
> Most of the code is aimed at building the required generic ACPI
> infrastructure to create and enable IOMMU components and to bring
> the IOMMU infrastructure for ACPI on par with DT, which is going to
> make future ARM SMMU components easier to integrate.
>
[...]
>
> This patchset is provided for review/testing purposes here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/iort-smmu-v7
>
> Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
>
For all series:
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v7 0/7] Add DRM driver for Hisilicon Hibmc
From: Rongrong Zou @ 2016-11-16 13:43 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds a new drm driver for Hisilicon Hibmc. Hibmc is a
BMC SoC with a display controller intergrated, usually it is used on
server for Out-of-band management purpose. In this patch set, we just
support basic function for Hibmc display subsystem. Hibmc display
subsystem is connected to host CPU by PCIe as blow:
+----------+ +----------+
| | PCIe | Hibmc |
|host CPU( |<----->| display |
|arm64,x86)| |subsystem |
+----------+ +----------+
Hardware Detail for Hibmc display subsystem
-----------
The display subsystem of Hibmc is show as bellow:
+----+ +----+ +----+ +--------+
| | | | | | | |
| FB |----->| DE |----->|VDAC|---->|external|
| | | | | | | VGA |
+----+ +----+ +----+ +--------+
-DE(Display Engine) is the display controller.
-VDAC(Video Digital-to-Analog converter) converts the RGB diaital data
stream from DE to VGA analog signals.
Change History
------------
Changes in v7:
-remove hibmc_drm_power.c/hibmc_drm_power.h, move the functions to
hibmc_drm_drv.c.
-remove hibmc_drm_de.h and move the struct defined in head file to
hibmc_drm_de.c.
-plane is initialized inside crtc, not in hibmc_kms_init().
-connector is initialized inside encoder, not in hibmc_kms_init().
-remove plane/crtc/encoder/connector from hibmc_drm_private struct.
-call drm_atomic_helper_suspend/resume in hibmc_pm_suspend/resume.
-remove these empty stubs because caller will do NULL check.
hibmc_plane_atomic_disable
hibmc_crtc_atomic_check
hibmc_encoder_disable
hibmc_encoder_enable
hibmc_encoder_atomic_check
-clean up in all error paths of creating driver-private framebuffer.
Changes in v6:
-remove the embedded framebuffer and use a pointer of hibmc_framebuffer
instead.
-remove the deprecated drm_framebuffer_unregister_private(),
drm_framebuffer_unreference() will be called in hibmc_fbdev_destroy().
-uninstall irq in hibmc_unload().
Changes in v5:
-rebase on v4.9-rc2.
-replace drm_fb_helper_set_suspend with drm_fb_helper_set_suspend_unlocked.
and remove redundant console_lock and console_unlock.
Changes in v4:
-remove unused include files, and include header file when it is needed.
-remove unused FLAG in Kconfig: DRM_GEM_CMA_HELPER/DRM_KMS_CMA_HELPER.
-remove drm_helper_disable_unused_functions, since we use DRIVER_ATOMIC.
Changes in v3:
-enable KMS, in v2, only fbdev is enabled.
-management video memory with ttm.
-add vblank interrupt.
-remove drm_connector_register_all() and drm_connector_unregister_all().
-I have a basic test with igt.
Changes in v2:
-Remove self-defined macros for bit operations.
-Remove unused register.
-Replace those deprecated functions with new version of them.
-use drm_connector_register_all() to register connector after
drm_dev_register().
The patch v2 is at
https://lists.freedesktop.org/archives/dri-devel/2016-May/108661.html
Rongrong Zou (7):
drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
drm/hisilicon/hibmc: Add video memory management
drm/hisilicon/hibmc: Add support for frame buffer
drm/hisilicon/hibmc: Add support for display engine
drm/hisilicon/hibmc: Add support for VDAC
drm/hisilicon/hibmc: Add support for vblank interrupt
MAINTAINERS: Update HISILICON DRM entries
MAINTAINERS | 1 +
drivers/gpu/drm/hisilicon/Kconfig | 1 +
drivers/gpu/drm/hisilicon/Makefile | 1 +
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 9 +
drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 477 ++++++++++++++++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 456 ++++++++++++++++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 114 +++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 267 +++++++++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 196 ++++++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 147 ++++++
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 558 ++++++++++++++++++++++
12 files changed, 2231 insertions(+)
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
--
1.9.1
^ 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