* [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: 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 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
* [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
* 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
* [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
* [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 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 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 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 2/3] usb: musb: core: added helper function for parsing DT
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 the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy <petr@barix.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
drivers/usb/musb/musb_core.h | 6 ++++++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e01116e..9b44566 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/usb.h>
+#include <linux/usb/of.h>
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-------------------------------------------------------------------------*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..76f00f6 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,10 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/*
+ * gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
^ permalink raw reply related
* [PATCH v5 1/3] dt/bindings: Add binding for the DA8xx MUSB 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>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v5 0/3] driver: Add DT support for DA8xx
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
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:
* Nothing. Resent the v4 in two seppaated series: one for platform and one for
driver.
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 6 +++
4 files changed, 114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH 2/2] drm/i2c: tda998x: allow sharing of the CEC device accesses
From: Russell King @ 2016-11-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device. This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.
Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.
As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 53 +++++++++++++++++++++++++--------------
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 74fb59a35269..f59d6664315d 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -41,6 +41,7 @@ struct tda998x_priv {
struct i2c_client *hdmi;
struct mutex mutex;
u16 rev;
+ u8 cec_addr;
u8 current_page;
bool is_on;
bool supports_infoframes;
@@ -374,35 +375,46 @@ struct tda998x_priv {
static void
cec_write(struct tda998x_priv *priv, u16 addr, u8 val)
{
- struct i2c_client *client = priv->cec;
u8 buf[] = {addr, val};
+ struct i2c_msg msg = {
+ .addr = priv->cec_addr,
+ .len = 2,
+ .buf = buf,
+ };
int ret;
- ret = i2c_master_send(client, buf, sizeof(buf));
+ ret = i2c_transfer(priv->hdmi->adapter, &msg, 1);
if (ret < 0)
- dev_err(&client->dev, "Error %d writing to cec:0x%x\n", ret, addr);
+ dev_err(&priv->hdmi->dev, "Error %d writing to cec:0x%x\n",
+ ret, addr);
}
static u8
cec_read(struct tda998x_priv *priv, u8 addr)
{
- struct i2c_client *client = priv->cec;
u8 val;
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv->cec_addr,
+ .len = 1,
+ .buf = &addr,
+ }, {
+ .addr = priv->cec_addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = &val,
+ },
+ };
int ret;
- ret = i2c_master_send(client, &addr, sizeof(addr));
- if (ret < 0)
- goto fail;
-
- ret = i2c_master_recv(client, &val, sizeof(val));
- if (ret < 0)
- goto fail;
+ ret = i2c_transfer(priv->hdmi->adapter, msg, ARRAY_SIZE(msg));
+ if (ret < 0) {
+ dev_err(&priv->hdmi->dev, "Error %d reading from cec:0x%x\n",
+ ret, addr);
+ val = 0;
+ }
return val;
-
-fail:
- dev_err(&client->dev, "Error %d reading from cec:0x%x\n", ret, addr);
- return 0;
}
static int
@@ -1471,17 +1483,16 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
struct device_node *np = client->dev.of_node;
u32 video;
int rev_lo, rev_hi, ret;
- unsigned short cec_addr;
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
+ /* CEC I2C address bound to TDA998x I2C addr by configuration pins */
+ priv->cec_addr = 0x34 + (client->addr & 0x03);
priv->current_page = 0xff;
priv->hdmi = client;
- /* CEC I2C address bound to TDA998x I2C addr by configuration pins */
- cec_addr = 0x34 + (client->addr & 0x03);
- priv->cec = i2c_new_dummy(client->adapter, cec_addr);
+ priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
if (!priv->cec)
return -ENODEV;
@@ -1722,6 +1733,10 @@ static const struct component_ops tda998x_ops = {
static int
tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_warn(&client->dev, "adapter does not support I2C\n");
+ return -EIO;
+ }
return component_add(&client->dev, &tda998x_ops);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared
From: Russell King @ 2016-11-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
The TDA998x contains two different I2C devices - there is the HDMI
encoder, and the TDA9950 CEC engine. These two share the same interrupt
signal.
In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This patch follows on from:
"drm/i2c: tda998x: power down pre-filter and color conversion"
which is now part of my drm-tda998x-devel branch, a branch which will
shortly be part of linux-next. This patch and the following patch are
not part of that branch yet.
I don't believe I received any testing for the power-down patch above
either, so if I can have some tested-bys/reviewed-bys for it and these
two patches, that'd be great. Thanks.
As my Juno has now been fixed, I've been able to test these two patches
on the HDLCD on Juno and Dove Cubox.
drivers/gpu/drm/i2c/tda998x_drv.c | 52 ++++++++++++++++++++-------------------
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index bf5eec0c1b4f..74fb59a35269 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -634,28 +634,30 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
bool handled = false;
sta = cec_read(priv, REG_CEC_INTSTATUS);
- cec = cec_read(priv, REG_CEC_RXSHPDINT);
- lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
- flag0 = reg_read(priv, REG_INT_FLAGS_0);
- flag1 = reg_read(priv, REG_INT_FLAGS_1);
- flag2 = reg_read(priv, REG_INT_FLAGS_2);
- DRM_DEBUG_DRIVER(
- "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
- sta, cec, lvl, flag0, flag1, flag2);
-
- if (cec & CEC_RXSHPDINT_HPD) {
- if (lvl & CEC_RXSHPDLEV_HPD)
- tda998x_edid_delay_start(priv);
- else
- schedule_work(&priv->detect_work);
-
- handled = true;
- }
+ if (sta & CEC_INTSTATUS_HDMI) {
+ cec = cec_read(priv, REG_CEC_RXSHPDINT);
+ lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
+ flag0 = reg_read(priv, REG_INT_FLAGS_0);
+ flag1 = reg_read(priv, REG_INT_FLAGS_1);
+ flag2 = reg_read(priv, REG_INT_FLAGS_2);
+ DRM_DEBUG_DRIVER(
+ "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
+ sta, cec, lvl, flag0, flag1, flag2);
+
+ if (cec & CEC_RXSHPDINT_HPD) {
+ if (lvl & CEC_RXSHPDLEV_HPD)
+ tda998x_edid_delay_start(priv);
+ else
+ schedule_work(&priv->detect_work);
+
+ handled = true;
+ }
- if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
- priv->wq_edid_wait = 0;
- wake_up(&priv->wq_edid);
- handled = true;
+ if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
+ priv->wq_edid_wait = 0;
+ wake_up(&priv->wq_edid);
+ handled = true;
+ }
}
return IRQ_RETVAL(handled);
@@ -1542,7 +1544,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
/* initialize the optional IRQ */
if (client->irq) {
- int irqf_trigger;
+ unsigned long irq_flags;
/* init read EDID waitqueue and HDP work */
init_waitqueue_head(&priv->wq_edid);
@@ -1552,11 +1554,11 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
reg_read(priv, REG_INT_FLAGS_1);
reg_read(priv, REG_INT_FLAGS_2);
- irqf_trigger =
+ irq_flags =
irqd_get_trigger_type(irq_get_irq_data(client->irq));
+ irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
ret = request_threaded_irq(client->irq, NULL,
- tda998x_irq_thread,
- irqf_trigger | IRQF_ONESHOT,
+ tda998x_irq_thread, irq_flags,
"tda998x", priv);
if (ret) {
dev_err(&client->dev,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-16 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4c8da0e-d66d-1268-78e5-d994399c9166@ti.com>
On 11/16/2016 11:41 AM, Sekhar Nori wrote:
> On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
>> On 11/15/2016 11:46 AM, Sekhar Nori wrote:
>>> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>>>> This adds the device tree node for the usb otg
>>>> controller present in the da850 family of SoC's.
>>>> This also enables the otg usb controller for the lcdk board.
>>>>
>>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>>> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
>>>> 2 files changed, 23 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
>>>> index 7b8ab21..9f5040c 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";
>>>> + };
>>>
>>> As mentioned by David already, this node needs to be removed. Please
>
>> I have missed it. But why should I remove it?
>> Without it, usb otg won't work.
>
> Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
> preserved (but please fix the indentation on the closing brace).
OK. Thanks for the confirmation.
>
> The part in da850.dtsi needs to be removed as it is already merged.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 2/2] soc: ti: knav_qmss_queue: replace IS_ERR_OR_NULL by IS_ERR
From: Julia Lawall @ 2016-11-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293014-18811-1-git-send-email-Julia.Lawall@lip6.fr>
knav_queue_open always returns an ERR_PTR value, never NULL. This can be
confirmed by unfolding the function calls and conforms to the function's
documentation. Thus, replace IS_ERR_OR_NULL by IS_ERR in error checks.
The change is made using the following semantic patch:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x;
statement S;
@@
x = knav_queue_open(...);
if (
- IS_ERR_OR_NULL
+ IS_ERR
(x)) S
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
The patches in this series are completely independent of each other, except
for having been made from the same specification.
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b73e353..d90df84 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -777,7 +777,7 @@ void *knav_pool_create(const char *name,
}
pool->queue = knav_queue_open(name, KNAV_QUEUE_GP, 0);
- if (IS_ERR_OR_NULL(pool->queue)) {
+ if (IS_ERR(pool->queue)) {
dev_err(kdev->dev,
"failed to open queue for pool(%s), error %ld\n",
name, PTR_ERR(pool->queue));
^ permalink raw reply related
* [PATCH 0/2] replace IS_ERR_OR_NULL by IS_ERR
From: Julia Lawall @ 2016-11-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
Replace IS_ERR_OR_NULL by IS_ERR on knav_queue_open calls.
---
drivers/net/ethernet/ti/netcp_core.c | 6 +++---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Sekhar Nori @ 2016-11-16 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2050c80-255e-25d6-99ba-7634f2c7e39a@baylibre.com>
On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
> On 11/15/2016 11:46 AM, Sekhar Nori wrote:
>> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>>> This adds the device tree node for the usb otg
>>> controller present in the da850 family of SoC's.
>>> This also enables the otg usb controller for the lcdk board.
>>>
>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>> ---
>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
>>> 2 files changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
>>> index 7b8ab21..9f5040c 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";
>>> + };
>>
>> As mentioned by David already, this node needs to be removed. Please
> I have missed it. But why should I remove it?
> Without it, usb otg won't work.
Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
preserved (but please fix the indentation on the closing brace).
The part in da850.dtsi needs to be removed as it is already merged.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7] soc: qcom: add l2 cache perf events driver
From: Mark Rutland @ 2016-11-16 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e917b871-d6ee-d52b-aedc-b3ee75aed05f@codeaurora.org>
On Fri, Nov 11, 2016 at 04:52:35PM -0500, Leeder, Neil wrote:
> So is there a use-case for individual uncore PMUs when they can't be
> used in task mode or per-cpu?
>
> The main (only?) use will be in system mode, in which case surely it
> makes sense to provide a single aggregated count?
If you are aware of the system topology, the numbers may be more useful
than the summed count. If you aren't, it's still possible to sum them in
userspace.
Having them summed by the kernel means that the kernel is implying it
supports group semantics that it cannot, since it cannot start/stop all
counters in a group atomically if they're split across several units.
> With individual PMUs exposed there will be potentially dozens of
> nodes for userspace to collect from which would make perf
> command-line usage unwieldy at best.
FWIW, for uncore/system PMUs, even on x86 there are a number of
independent units.
Some PMUs (those which are symmetric across the topology) get hidden
behind the same struct PMU, but instances are still isolated (and their
values not summed).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-16 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c94c5e0-9d2c-fff5-1213-2fb2adb20ab0@ti.com>
On 11/15/2016 11:46 AM, Sekhar Nori wrote:
> On Thursday 03 November 2016 09:29 PM, Alexandre Bailon wrote:
>> This adds the device tree node for the usb otg
>> controller present in the da850 family of SoC's.
>> This also enables the otg usb controller for the lcdk board.
>>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
>> index 7b8ab21..9f5040c 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";
>> + };
>
> As mentioned by David already, this node needs to be removed. Please
I have missed it. But why should I remove it?
Without it, usb otg won't work.
> rebase this on top of latest linux-davinci/master when ready for merging
> (driver changes accepted).
>
>> +
>> +&usb0 {
>> + status = "okay";
>> +};
>> +
>> &aemif {
>> pinctrl-names = "default";
>> pinctrl-0 = <&nand_pins>;
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..322a31a 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -372,6 +372,21 @@
>> >;
>> status = "disabled";
>> };
>> + usb_phy: usb-phy {
>> + compatible = "ti,da830-usb-phy";
>> + #phy-cells = <1>;
>> + 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";
>> + };
>
> Can you separate out the soc specific changes from board changes? Please
> place the usb0 node above the mdio node. I am trying to get to a rough
> ordering based on reg property.
I will do.
>
> Thanks,
> Sekhar
>
Thanks,
Alexandre
^ permalink raw reply
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Viresh Kumar @ 2016-11-16 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479290751-9705-1-git-send-email-geert+renesas@glider.be>
On 16-11-16, 11:05, 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: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Geert Uytterhoeven @ 2016-11-16 10:05 UTC (permalink / raw)
To: linux-arm-kernel
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.
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index fcc5bcfe57efe1c3..0c73c7dbd5878919 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -55,6 +55,8 @@
{ .compatible = "renesas,r7s72100", },
{ .compatible = "renesas,r8a73a4", },
{ .compatible = "renesas,r8a7740", },
+ { .compatible = "renesas,r8a7743", },
+ { .compatible = "renesas,r8a7745", },
{ .compatible = "renesas,r8a7778", },
{ .compatible = "renesas,r8a7779", },
{ .compatible = "renesas,r8a7790", },
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-16 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95cd052e-7e0d-d13b-fedb-21f7b49d17bb@rock-chips.com>
Hi Shawn,
Am Mittwoch, 16. November 2016, 17:33:21 CET schrieb Shawn Lin:
> ? 2016/11/16 6:38, Heiko Stuebner ??:
> > The General Register Files are an area of registers containing a lot
> > of single-bit settings for numerous components as well full components
> > like usbphy control. Therefore all used components are accessed
> > via the syscon provided by the grf nodes or from the sub-devices
> > created through the simple-mfd created from the grf node.
> >
> > Some settings are not used by anything but will need to be set up
> > according to expectations on the kernel side.
> >
> > Best example is the force_jtag setting, which defaults to on and
> > results in the soc switching the pin-outputs between jtag and sdmmc
> > automatically depending on the card-detect status. This conflicts
> > heavily with how the dw_mmc driver expects to do its work and also
> > with the clock-controller, which has most likely deactivated the
> > jtag clock due to it being unused.
>
> I hate force_jtag personally... :)
yep, I still remember when we had strange mmc errors which simply came from
the soc switching away from the mmc function before the mmc driver was
finished, so I also find that functionality unhelpful ;-) .
> > So far the handling of this setting was living in the mach-rockchip
> > code for the arm32-based rk3288 but that of course doesn't work
> > for arm64 socs and would also look ugly for further arm32 socs.
>
> yes, I did this inside the loader.... when running arm64
>
> > Also always disabling this setting is quite specific to linux and
> > its subsystems, other operating systems might prefer other settings,
> > so that the bootloader cannot really set a sane default for all.
> >
> > So introduce a top-level driver for the grf that handles these
> > settings that need to be a certain way but nobody cares about.
> >
> > Other needed settings might surface in the future and can then
> > be added here, but only as a last option. Ideally general GRF
> > settings should be handled in the driver needing them.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> >
> > drivers/soc/rockchip/Kconfig | 10 ++++
> > drivers/soc/rockchip/Makefile | 1 +
> > drivers/soc/rockchip/grf.c | 134
> > ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 145
> > insertions(+)
> > create mode 100644 drivers/soc/rockchip/grf.c
> >
> > diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> > index 7140ff8..20da55d 100644
> > --- a/drivers/soc/rockchip/Kconfig
> > +++ b/drivers/soc/rockchip/Kconfig
> > @@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
> >
> > #
> > # Rockchip Soc drivers
> > #
> >
> > +
> > +config ROCKCHIP_GRF
> > + bool
> > + default y
> > + help
> > + The General Register Files are a central component providing
> > + special additional settings registers for a lot of soc-components.
> > + In a lot of cases there also need to be default settings initialized
> > + to make some of them conform to expectations of the kernel.
> > +
> >
> > config ROCKCHIP_PM_DOMAINS
> >
> > bool "Rockchip generic power domain"
> > depends on PM
> >
> > diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> > index 3d73d06..c851fa0 100644
> > --- a/drivers/soc/rockchip/Makefile
> > +++ b/drivers/soc/rockchip/Makefile
> > @@ -1,4 +1,5 @@
> >
> > #
> > # Rockchip Soc drivers
> > #
> >
> > +obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> >
> > obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> >
> > diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
> > new file mode 100644
> > index 0000000..0c85476a
> > --- /dev/null
> > +++ b/drivers/soc/rockchip/grf.c
> > @@ -0,0 +1,134 @@
> > +/*
> > + * Rockchip Generic Register Files setup
> > + *
> > + * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
>
> The order :)
I just noticed that there is a second inclusion of regmap.h here, which can go
away.
>
> > +
> > +#define HIWORD_UPDATE(val, mask, shift) \
> > + ((val) << (shift) | (mask) << ((shift) + 16))
> > +
> > +struct rockchip_grf_value {
> > + const char *desc;
> > + u32 reg;
> > + u32 val;
> > +};
> > +
> > +struct rockchip_grf_info {
> > + const struct rockchip_grf_value *values;
> > + int num_values;
> > +};
> > +
> > +#define RK3036_GRF_SOC_CON0 0x140
> > +
> > +static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
> > + /*
> > + * Disable auto jtag/sdmmc switching that causes issues with the
> > + * clock-framework and the mmc controllers making them unreliable.
> > + */
> > + { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3036_grf __initconst = {
> > + .values = rk3036_defaults,
> > + .num_values = ARRAY_SIZE(rk3036_defaults),
> > +};
> > +
> > +#define RK3288_GRF_SOC_CON0 0x244
> > +
> > +static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
> > + { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3288_grf __initconst = {
> > + .values = rk3288_defaults,
> > + .num_values = ARRAY_SIZE(rk3288_defaults),
> > +};
> > +
> > +#define RK3368_GRF_SOC_CON15 0x43c
> > +
> > +static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
> > + { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3368_grf __initconst = {
> > + .values = rk3368_defaults,
> > + .num_values = ARRAY_SIZE(rk3368_defaults),
> > +};
> > +
> > +#define RK3399_GRF_SOC_CON7 0xe21c
> > +
> > +static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
> > + { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
> > +};
> > +
> > +static const struct rockchip_grf_info rk3399_grf __initconst = {
> > + .values = rk3399_defaults,
> > + .num_values = ARRAY_SIZE(rk3399_defaults),
> > +};
> > +
> > +static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
> > + {
> > + .compatible = "rockchip,rk3036-grf",
> > + .data = (void *)&rk3036_grf,
> > + }, {
> > + .compatible = "rockchip,rk3288-grf",
> > + .data = (void *)&rk3288_grf,
> > + }, {
> > + .compatible = "rockchip,rk3368-grf",
> > + .data = (void *)&rk3368_grf,
> > + }, {
> > + .compatible = "rockchip,rk3399-grf",
> > + .data = (void *)&rk3399_grf,
> > + },
> > + { /* sentinel */ },
> > +};
> > +
> > +static int __init rockchip_grf_init(void)
> > +{
> > + const struct rockchip_grf_info *grf_info;
> > + const struct of_device_id *match;
> > + struct device_node *np;
> > + struct regmap *grf;
> > + int ret, i;
> > +
> > + np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match,
> > &match); + if (!np)
> > + return -ENODEV;
> > + if (!match || !match->data) {
> > + pr_err("%s: missing grf data\n", __func__);
> > + return -EINVAL;
> > + }
> > +
> > + grf_info = match->data;
> > +
> > + grf = syscon_node_to_regmap(np);
> > + if (IS_ERR(grf)) {
> > + pr_err("%s: could not get grf syscon\n", __func__);
> > + return PTR_ERR(grf);
> > + }
> > +
> > + for (i = 0; i < grf_info->num_values; i++) {
> > + const struct rockchip_grf_value *val = &grf_info->values[i];
> > +
> > + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
> > + val->desc, val->reg, val->val);
> > + ret = regmap_write(grf, val->reg, val->val);
> > + if (ret < 0)
> > + pr_err("%s: write to %#6x failed with %d\n",
> > + __func__, val->reg, ret);
>
> So, when failing to do one of the settings, should we still let it goes?
> Sometimes the log of postcore_initcall is easy to be neglected when
> people finally find problems later but the very earlier log was missing
> due to whatever reason like buffer limitation, etc.
I expect errors here to be very rare. I.e. Doug thought that regmap might
return errors if we write outside the mapped region, which would mean someone
really messed up in this core component or a core-element of the dts.
But in general the GRF is always a mmio-regmap, so there won't be any i2c/spi/
whatever errors possible.
Also settings are pretty individual, so if setting 1 fails, setting 2 can
still succeed and the boot can continue somewhat farther.
The overall target is supposed to always boot as far as possible, so that
people might recover or get more information and not fail (and die) early.
Heiko
^ permalink raw reply
* [PATCH] mxs-auart: count FIFO overrun errors
From: Greg Kroah-Hartman @ 2016-11-16 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207929.4985.25.camel@reccoware.de>
On Tue, Nov 15, 2016 at 12:05:29PM +0100, Wolfgang Ocker 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>
> ---
> ?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
This patch is corrupted and can not be applied, what did you do here?
Please fix up and resend.
thanks,
greg k-h
^ 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