* [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] 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 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 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] 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] 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/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] 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 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
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