* [PATCH 2/3] arm64: dts: renesas: r8a77995: Add VIN4
From: jacopo mondi @ 2018-05-13 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511134516.omsv25i2wi4cxypc@verge.net.au>
Hi Simon,
On Fri, May 11, 2018 at 03:45:16PM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 01:25:23PM +0200, Niklas S?derlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-11 12:00:01 +0200, Jacopo Mondi wrote:
> > > Describe VIN4 interface for R-Car D3 R8A77995 SoC.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> >
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > index 82aed7e..bdf7017 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> > > @@ -783,6 +783,17 @@
> > > };
> > > };
> > > };
> > > +
> > > + vin4: video at e6ef4000 {
> > > + compatible = "renesas,vin-r8a77995";
> > > + reg = <0 0xe6ef4000 0 0x1000>;
> > > + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&cpg CPG_MOD 807>;
> > > + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> > > + resets = <&cpg 807>;
> > > + renesas,id = <4>;
> > > + status = "disabled";
> > > + };
> > > };
>
> Thanks, I have moved the new node to preserve sorting of nodes by bus
> address and applied the result. It is as follows:
Great, thanks for doing this, I should have take care of sorting nodes
opprtunely.
Thanks
j
>
> From: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Subject: [PATCH] arm64: dts: renesas: r8a77995: Add VIN4
>
> Describe VIN4 interface for R-Car D3 R8A77995 SoC.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> [simon: sorted node by bus address]
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index ba98865b0c9b..2506f46293e8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -610,6 +610,17 @@
> status = "disabled";
> };
s
> + vin4: video at e6ef4000 {
> + compatible = "renesas,vin-r8a77995";
> + reg = <0 0xe6ef4000 0 0x1000>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 807>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 807>;
> + renesas,id = <4>;
> + status = "disabled";
> + };
> +
> ohci0: usb at ee080000 {
> compatible = "generic-ohci";
> reg = <0 0xee080000 0 0x100>;
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-13 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY3snB9o4e14by4xui+o_Vhqpe2zh6Pp_e0t-DCTKvMHWA@mail.gmail.com>
On 05/13/2018 06:36 PM, Jassi Brar wrote:
> On Tue, May 8, 2018 at 5:14 PM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>
> ....
>>
>> +config SERIAL_TEGRA_TCU
>> + tristate "NVIDIA Tegra Combined UART"
>> + depends on ARCH_TEGRA && MAILBOX
>> + select SERIAL_CORE
>> + help
>> + Support for the mailbox-based TCU (Tegra Combined UART) serial port.
>> + TCU is a virtual serial port that allows multiplexing multiple data
>> + streams into a single hardware serial port.
>> +
> Maybe make it depend upon TEGRA_HSP_MBOX ?
Yeah, that probably makes more sense. MAILBOX is enough to build it but
it won't be of any use without TEGRA_HSP_MBOX.
>
> ......
>
>> +
>> +static void tegra_tcu_write(const char *s, unsigned int count)
>> +{
>> + struct tegra_tcu *tcu = tegra_tcu_uart_port.private_data;
>> + unsigned int written = 0, i = 0;
>> + bool insert_nl = false;
>> + uint32_t value = 0;
>> +
>> + while (i < count) {
>> + if (insert_nl) {
>> + value |= '\n' << (written++ * 8);
>> + insert_nl = false;
>> + i++;
>> + } else if (s[i] == '\n') {
>> + value |= '\r' << (written++ * 8);
>> + insert_nl = true;
>> + } else {
>> + value |= s[i++] << (written++ * 8);
>> + }
>> +
>> + if (written == 3) {
>> + value |= 3 << 24;
>> + value |= BIT(26);
>> + mbox_send_message(tcu->tx, &value);
>>
> How is this supposed to work? tegra_hsp_doorbell_send_data() ignores
> the second argument.
The previous patch in the series adds support for what are called
"shared mailboxes" to the tegra-hsp driver. For these the second
argument is used.
Thanks,
Mikko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-13 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfYF_u2bZ+temGbReEB9K-t3A75aUNYwffyv9-=zEi0Lw@mail.gmail.com>
On 05/13/2018 05:16 PM, Andy Shevchenko wrote:
> On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
>> multiplexing multiple "virtual UARTs" into a single hardware serial
>> port. The TCU is the primary serial port on Tegra194 devices.
>>
>> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
>> are part of Tegra HSP blocks that are already controlled by the Tegra
>> HSP mailbox driver.
>
> First question, can it be done utilizing SERDEV framework?
Based on some brief research, the SERDEV framework is for devices that
are behind some UART interface. In this case, this driver implements the
UART interface itself, so by my understanding SERDEV is not appropriate.
Please correct me if I'm wrong.
>
>> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
>> +{
>
>> + (void)port;
>> + (void)mctrl;
>
> Huh?
The serial core calls these callbacks without checking if they are set.
They don't make sense for this driver so they are stubbed out.
>
>> +}
>
>> +static void tegra_tcu_uart_stop_tx(struct uart_port *port)
>> +{
>> + (void)port;
>> +}
>
> Ditto.
>
>> + if (written == 3) {
>> + value |= 3 << 24;
>> + value |= BIT(26);
>> + mbox_send_message(tcu->tx, &value);
>
>> + }
>
> (1)
>
>> + }
>> +
>> + if (written) {
>> + value |= written << 24;
>> + value |= BIT(26);
>> + mbox_send_message(tcu->tx, &value);
>> + }
>
> (2)
>
> These are code duplications.
Indeed - the length of the duplicated code is so short, and the
instances are so close to each other, that I don't find it necessary (or
clearer) to have an extra function.
>
>> +static void tegra_tcu_uart_stop_rx(struct uart_port *port)
>> +{
>> + (void)port;
>> +}
>> +
>> +static void tegra_tcu_uart_break_ctl(struct uart_port *port, int ctl)
>> +{
>> + (void)port;
>> + (void)ctl;
>> +}
>> +
>> +static int tegra_tcu_uart_startup(struct uart_port *port)
>> +{
>> + (void)port;
>> +
>> + return 0;
>> +}
>> +
>> +static void tegra_tcu_uart_shutdown(struct uart_port *port)
>> +{
>> + (void)port;
>> +}
>> +
>> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
>> + struct ktermios *new,
>> + struct ktermios *old)
>> +{
>> + (void)port;
>> + (void)new;
>> + (void)old;
>> +}
>
> Remove those unused stub contents.
Sure. I had these here so that we don't get unused parameter warnings,
but I can just as well remove the parameter names.
>
>> + return uart_set_options(&tegra_tcu_uart_port, cons,
>> + 115200, 'n', 8, 'n');
>
> Can't it be one line?
It would be a total of 81 characters in length on one line, so no.
>
>> +static void tegra_tcu_receive(struct mbox_client *client, void *msg_p)
>> +{
>> + struct tty_port *port = &tegra_tcu_uart_port.state->port;
>
>> + uint32_t msg = *(uint32_t *)msg_p;
>
> Redundant casting.
Will remove.
>
>> + unsigned int num_bytes;
>> + int i;
>> +
>
>> + num_bytes = (msg >> 24) & 0x3;
>
> Two magic numbers.
Sure, will add defines.
>
>> + for (i = 0; i < num_bytes; i++)
>> + tty_insert_flip_char(port, (msg >> (i*8)) & 0xff, TTY_NORMAL);
>> +
>> + tty_flip_buffer_push(port);
>> +}
>
>> +MODULE_AUTHOR("Mikko Perttunen <mperttunen@nvidia.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("NVIDIA Tegra Combined UART driver");
>> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
>> index dce5f9dae121..eaf3c303cba6 100644
>> --- a/include/uapi/linux/serial_core.h
>> +++ b/include/uapi/linux/serial_core.h
>> @@ -281,4 +281,7 @@
>> /* MediaTek BTIF */
>> #define PORT_MTK_BTIF 117
>>
>> +/* NVIDIA Tegra Combined UART */
>> +#define PORT_TEGRA_TCU 118
>
> Check if there is an unused gap. IIRC we still have one near to 40ish.
>
Correct, looks like 41-43 are unused. I'll change this 41.
Thanks for reviewing!
Mikko
^ permalink raw reply
* [PATCH] thermal: exynos: Reduce severity of too early temperature read
From: Krzysztof Kozlowski @ 2018-05-13 17:54 UTC (permalink / raw)
To: linux-arm-kernel
Thermal core tries to read temperature during sensor registering in
thermal_zone_of_sensor_register(). In that time Exynos TMU driver and
hardware are not yet initialized. Commit 0eb875d88aaa ("thermal:
exynos: Reading temperature makes sense only when TMU is turned on")
added a boolean flag to prevent reading bogus temperature in such
case but it exposed warning message during boot:
[ 3.864913] thermal thermal_zone0: failed to read out thermal zone (-22)
Return EAGAIN in such case to skip omitting such message because it
might mislead user.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/thermal/samsung/exynos_tmu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 3b20309789e3..c24969d740d1 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -666,8 +666,14 @@ static int exynos_get_temp(void *p, int *temp)
struct exynos_tmu_data *data = p;
int value, ret = 0;
- if (!data || !data->tmu_read || !data->enabled)
+ if (!data || !data->tmu_read)
return -EINVAL;
+ else if (!data->enabled)
+ /*
+ * Called too early, probably
+ * from thermal_zone_of_sensor_register().
+ */
+ return -EAGAIN;
mutex_lock(&data->lock);
clk_enable(data->clk);
--
2.14.1
^ permalink raw reply related
* [GIT PULL 2/5] Broadcom defconfig-arm64 changes for 4.18
From: Florian Fainelli @ 2018-05-13 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-2-f.fainelli@gmail.com>
Le 05/11/18 ? 14:43, Florian Fainelli a ?crit?:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/defconfig-arm64
>
> for you to fetch changes up to dce4c94eedbd35cd63aa04ee9b022de6d23ee587:
>
> Merge tag 'bcm2835-defconfig-64-next-2018-04-30' into defconfig-arm64/next (2018-05-01 11:54:16 -0700)
>
> ----------------------------------------------------------------
> This pull request contains Broadcom ARM64-based SoCs defconfig changes
> for 4.18, please pull the following:
>
> - Stefan provides a set of updates targeting the Raspberry Pi 3 B+
> platform: LAN7515 USB Ethernet driver, Cypress CYW43455 Bluetooth when
> using the Pi 3 B+ in AArch64 boot mode.
>
> ----------------------------------------------------------------
> Florian Fainelli (1):
> Merge tag 'bcm2835-defconfig-64-next-2018-04-30' into defconfig-arm64/next
>
> Stefan Wahren (1):
> arm64: defconfig: Enable LAN and BT support for RPi 3 B+
Olof, Arnd, Kevin, please disregard this pull request (v1) and consider
this one instead:
https://www.spinics.net/lists/arm-kernel/msg652043.html
thank you!
--
Florian
^ permalink raw reply
* [GIT PULL 2/5 v2] Broadcom defconfig-arm64 changes for 4.18
From: Florian Fainelli @ 2018-05-13 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511214339.24139-2-f.fainelli@gmail.com>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/defconfig-arm64
for you to fetch changes up to ebf089248dab2ef569e5e26a607f0977a71182b7:
arm64: defconfig: Increase CMA size for VC4 (2018-05-13 09:55:21 -0700)
----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoCs defconfig changes
for 4.18, please pull the following:
- Stefan provides a set of updates targeting the Raspberry Pi 3 B+
platform: LAN7515 USB Ethernet driver, Cypress CYW43455 Bluetooth when
using the Pi 3 B+ in AArch64 boot mode. He also updates the ARM64
defconfig to create a bigger default CMA region to let the VideoCore 4
driver initialize correctly.
----------------------------------------------------------------
Florian Fainelli (1):
Merge tag 'bcm2835-defconfig-64-next-2018-04-30' into defconfig-arm64/next
Stefan Wahren (2):
arm64: defconfig: Enable LAN and BT support for RPi 3 B+
arm64: defconfig: Increase CMA size for VC4
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
^ permalink raw reply
* [PATCH] arm64: defconfig: Increase CMA size for VC4
From: Florian Fainelli @ 2018-05-13 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525296700-3588-1-git-send-email-stefan.wahren@i2se.com>
Le 05/02/18 ? 14:31, Stefan Wahren a ?crit?:
> The VC4 needs more memory than the default setting (16 MB):
>
> vc4-drm soc:gpu: swiotlb: coherent allocation failed, size=16777216
> [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12.
> You may need to enable CMA or give it more memory.
> vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops [vc4]): -12
> vc4-drm soc:gpu: master bind failed: -12
> vc4-drm: probe of soc:gpu failed with error -12
>
> So increase the value to 32 MB and fix this issue.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied to defconfig-arm64/next, thanks!
--
Florian
^ permalink raw reply
* [GIT PULL 5/5] ARM: exynos: mach/soc for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-6-krzk@kernel.org>
On Sun, May 13, 2018 at 5:42 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.18
>
> for you to fetch changes up to 9ad9a2183bf51da7f8840f2e7087816c0fc8c91d:
>
> ARM: exynos: Remove unused soc_is_exynos{4,5} (2018-05-13 14:07:03 +0200)
>
> ----------------------------------------------------------------
> Samsung mach/soc changes for v4.18
>
> 1. Remove at24_platform_data in S3C2440.
> 2. Fix invalid SPDX identifier.
> 3. Remove Exynos5440 entirely.
> 4. Cleanups.
> 5. Remove static mapping of SCU SFR and rely on DTS.
>
> ----------------------------------------------------------------
> Bartlomiej Zolnierkiewicz (1):
> ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer
>
> Bartosz Golaszewski (1):
> ARM: s3c24xx: mini2440: Use device properties for at24 eeprom
>
> Krzysztof Kozlowski (1):
> ARM: exynos: Remove support for Exynos5440
I forgot to mention here possible conflict with dma-mapping tree and
its commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT
config symbol in lib/Kconfig"). Since Exynos5440 is going away,
conflict is easy to solve - just remove.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL 5/5] ARM: exynos: mach/soc for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-1-krzk@kernel.org>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.18
for you to fetch changes up to 9ad9a2183bf51da7f8840f2e7087816c0fc8c91d:
ARM: exynos: Remove unused soc_is_exynos{4,5} (2018-05-13 14:07:03 +0200)
----------------------------------------------------------------
Samsung mach/soc changes for v4.18
1. Remove at24_platform_data in S3C2440.
2. Fix invalid SPDX identifier.
3. Remove Exynos5440 entirely.
4. Cleanups.
5. Remove static mapping of SCU SFR and rely on DTS.
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
ARM: exynos: no need to select ARCH_HAS_BANDGAP any longer
Bartosz Golaszewski (1):
ARM: s3c24xx: mini2440: Use device properties for at24 eeprom
Krzysztof Kozlowski (1):
ARM: exynos: Remove support for Exynos5440
Pankaj Dubey (2):
ARM: exynos: Remove static mapping of SCU SFR
ARM: exynos: Remove unused soc_is_exynos{4,5}
Thomas Gleixner (1):
ARM: s3c24xx: Fix invalid SPDX identifier
Wolfram Sang (1):
ARM: samsung: simplify getting .drvdata
arch/arm/mach-exynos/Kconfig | 13 ----------
arch/arm/mach-exynos/common.h | 17 ++++---------
arch/arm/mach-exynos/exynos.c | 37 ++--------------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 27 +++++++++++++++-----
arch/arm/mach-exynos/pm.c | 4 +--
arch/arm/mach-exynos/suspend.c | 4 +--
arch/arm/mach-s3c24xx/h1940-bluetooth.c | 2 +-
arch/arm/mach-s3c24xx/mach-mini2440.c | 10 ++++----
arch/arm/plat-samsung/adc.c | 3 +--
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ---
11 files changed, 37 insertions(+), 86 deletions(-)
^ permalink raw reply
* [GIT PULL 4/5] arm64: dts: exynos: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-1-krzk@kernel.org>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.18
for you to fetch changes up to 8dd6203f32f20cb83469eb859efded9e403b3e9f:
arm64: dts: exynos: Add mem-2-mem Scaler devices (2018-05-13 11:26:13 +0200)
----------------------------------------------------------------
Samsung DTS ARM64 changes for v4.18
1. Fix DTC warnings.
2. Add mem-2-mem Scaler devices.
----------------------------------------------------------------
Andrzej Pietrasiewicz (1):
arm64: dts: exynos: Add mem-2-mem Scaler devices
Krzysztof Kozlowski (2):
arm64: dts: exynos: Move syscon poweroff and restart nodes under the PMU
arm64: dts: exynos: Remove unneeded address space mapping for soc node
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 66 +++++++++++++++++++++++++-----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 ++++----
2 files changed, 65 insertions(+), 19 deletions(-)
^ permalink raw reply
* [GIT PULL 3/5] ARM: dts: exynos: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-1-krzk@kernel.org>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.18
for you to fetch changes up to 83cb529b2ef4f3446e60e75522d76fdaaea4724c:
ARM: dts: exynos: Update x and y properties for mms114 touchscreen (2018-05-13 15:15:49 +0200)
----------------------------------------------------------------
Samsung DTS ARM changes for v4.18
1. Add support for USB OTG port on Origen board.
2. Allow earlycon on Rinato board.
3. Cleanup from obsolete properties.
4. Fix DTC warnings.
5. Remove Exynos5440 entirely.
6. Add mem-2-mem Scaler devices.
----------------------------------------------------------------
Andi Shyti (1):
ARM: dts: exynos: Update x and y properties for mms114 touchscreen
Andrzej Pietrasiewicz (1):
ARM: dts: exynos: Add mem-2-mem Scaler devices
Krzysztof Kozlowski (11):
ARM: dts: exynos: Move syscon poweroff and restart nodes under the PMU
ARM: dts: exynos: Fix invalid node referenced by i2c20 alias in Peach Pit and Pi
ARM: dts: exynos: Remove unnecessary address/size properties in Midas boards
ARM: dts: exynos: Remove unnecessary address/size properties in Origen
ARM: dts: exynos: Remove regulators node container in Origen and N710x
ARM: dts: exynos: Bring order in fixed-regulators naming in Midas boards
ARM: dts: exynos: Remove unnecessary address/size properties in dp-controller of Exynos5
ARM: dts: exynos: Remove Exynos5440
ARM: dts: s3c24xx: Remove skeleton.dtsi and fix DTC warning for /memory
ARM: dts: s3c24xx: Fix unnecessary address/size cells DTC warnings
ARM: dts: s3c64xx: Remove skeleton.dtsi and fix DTC warnings for /memory
Marek Szyprowski (3):
ARM: dts: exynos: Add support for USB OTG port on Origen board
ARM: dts: exynos: Add serial path for Rinato board to get earlycon support
ARM: dts: exynos: Remove obsolete clock properties from power domains
Mathieu Malaterre (1):
ARM: dts: exynos/s3c: Remove leading 0x and 0s from bindings notation
.../bindings/arm/samsung/samsung-boards.txt | 2 -
arch/arm/boot/dts/Makefile | 2 -
arch/arm/boot/dts/exynos-syscon-restart.dtsi | 28 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 4 +
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos4.dtsi | 3 +-
arch/arm/boot/dts/exynos4210-origen.dts | 34 +-
arch/arm/boot/dts/exynos4210-trats.dts | 4 +-
arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 36 +--
arch/arm/boot/dts/exynos4412-midas.dtsi | 86 +++--
arch/arm/boot/dts/exynos4412-n710x.dts | 16 +-
arch/arm/boot/dts/exynos4412-origen.dts | 2 +-
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 3 -
arch/arm/boot/dts/exynos5250.dtsi | 7 +-
arch/arm/boot/dts/exynos5410.dtsi | 1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +-
arch/arm/boot/dts/exynos5420.dtsi | 87 +++--
arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
arch/arm/boot/dts/exynos5440-sd5v1.dts | 42 ---
arch/arm/boot/dts/exynos5440-ssdk5440.dts | 81 -----
arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 20 --
arch/arm/boot/dts/exynos5440-trip-points.dtsi | 21 --
arch/arm/boot/dts/exynos5440.dtsi | 355 ---------------------
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +-
arch/arm/boot/dts/s3c2416-smdk2416.dts | 5 +-
arch/arm/boot/dts/s3c2416.dtsi | 11 +-
arch/arm/boot/dts/s3c24xx.dtsi | 4 +-
arch/arm/boot/dts/s3c6410-mini6410.dts | 3 +-
arch/arm/boot/dts/s3c6410-smdk6410.dts | 3 +-
arch/arm/boot/dts/s3c64xx.dtsi | 4 +-
31 files changed, 183 insertions(+), 695 deletions(-)
delete mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
delete mode 100644 arch/arm/boot/dts/exynos5440-ssdk5440.dts
delete mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
delete mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
delete mode 100644 arch/arm/boot/dts/exynos5440.dtsi
^ permalink raw reply
* [GIT PULL 2/5] soc: samsung: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-1-krzk@kernel.org>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.18
for you to fetch changes up to b2b568c591ddbb20d597e256212579d70dbf3000:
soc: samsung: pm_domains: Deprecate support for clocks (2018-04-17 17:25:42 +0200)
----------------------------------------------------------------
Samsung soc drivers changes for v4.18
1. Clock operations during power domain on/off were moved to respective
clock driver so clean up obsolete code from power domain driver.
----------------------------------------------------------------
Marek Szyprowski (1):
soc: samsung: pm_domains: Deprecate support for clocks
.../devicetree/bindings/power/pd-samsung.txt | 20 +----
drivers/soc/samsung/pm_domains.c | 90 +---------------------
2 files changed, 5 insertions(+), 105 deletions(-)
^ permalink raw reply
* [GIT PULL 1/5] ARM: defconfig: Exynos for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513154238.22508-1-krzk@kernel.org>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.18
for you to fetch changes up to b0121046cacdbc99475871aceb2e9e57995c2ba1:
ARM: multi_v7_config: enable S6E63J0X03 panel driver (2018-04-16 20:22:28 +0200)
----------------------------------------------------------------
Samsung defconfig changes for v4.18
1. Enable Samsung S6E63J0X03 DSI panel.
----------------------------------------------------------------
Marek Szyprowski (2):
ARM: exynos_defconfig: enable S6E63J0X03 panel driver
ARM: multi_v7_config: enable S6E63J0X03 panel driver
arch/arm/configs/exynos_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
2 files changed, 2 insertions(+)
^ permalink raw reply
* [GIT PULL 0/5] ARM: samsung/exynos: Stuff for v4.18
From: Krzysztof Kozlowski @ 2018-05-13 15:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Changes for v4.18. No dependencies, no specific order of pulls.
Support for Exynos5440 is removed step by step through different trees.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Jassi Brar @ 2018-05-13 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-7-mperttunen@nvidia.com>
On Tue, May 8, 2018 at 5:14 PM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
....
>
> +config SERIAL_TEGRA_TCU
> + tristate "NVIDIA Tegra Combined UART"
> + depends on ARCH_TEGRA && MAILBOX
> + select SERIAL_CORE
> + help
> + Support for the mailbox-based TCU (Tegra Combined UART) serial port.
> + TCU is a virtual serial port that allows multiplexing multiple data
> + streams into a single hardware serial port.
> +
Maybe make it depend upon TEGRA_HSP_MBOX ?
......
> +
> +static void tegra_tcu_write(const char *s, unsigned int count)
> +{
> + struct tegra_tcu *tcu = tegra_tcu_uart_port.private_data;
> + unsigned int written = 0, i = 0;
> + bool insert_nl = false;
> + uint32_t value = 0;
> +
> + while (i < count) {
> + if (insert_nl) {
> + value |= '\n' << (written++ * 8);
> + insert_nl = false;
> + i++;
> + } else if (s[i] == '\n') {
> + value |= '\r' << (written++ * 8);
> + insert_nl = true;
> + } else {
> + value |= s[i++] << (written++ * 8);
> + }
> +
> + if (written == 3) {
> + value |= 3 << 24;
> + value |= BIT(26);
> + mbox_send_message(tcu->tx, &value);
>
How is this supposed to work? tegra_hsp_doorbell_send_data() ignores
the second argument.
^ permalink raw reply
* [PATCH v1 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Tao Huang @ 2018-05-13 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508694354.7btLQf7nsA@phil>
Hi Heiko:
On 2018?05?12? 06:11, Heiko Stuebner wrote:
> Here I have a naming question. When looking at the vendor kernel
> it looks like the px30 is largely related to the rk3326.
> (rk3326.dtsi includeing the px30.dtsi)
>
> What is the reason for basing the naming on the px30 this time? And could
> we possibly keep to rkXXXX names for the basic things in the kernel, thus
> keeping the pxXX as second name, like with the other px-variants before?
>
PX30 and RK3326 are different chips. PX30 has more features. You can simply think that RK3326 is a subset of PX30. The RK3326 is more like a PX30 derivative chip. This is not the same as the previous chips.
So we use PX30 instead of RK3326 for name, and the opening document is only for PX30, we think this is more convenient for developers.
Best Regards,
Tao Huang
^ permalink raw reply
* [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()
From: Andy Shevchenko @ 2018-05-13 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510112229.GE6977@amd>
On Thu, May 10, 2018 at 2:22 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Thu 2018-05-10 13:21:01, Pavel Machek wrote:
>> I know this is not your fault, but if you have a space or "[]" in
>> netdev names, confusing things will happen.
>
> Hmm. If we are doing this we really should check trigger names for
> forbidden characters. At least "[] " should be forbidden.
So, string_escape_mem() is your helper here.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 3/3] tty: implement led triggers
From: Andy Shevchenko @ 2018-05-13 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508100543.12559-4-u.kleine-koenig@pengutronix.de>
On Tue, May 8, 2018 at 1:05 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> The rx trigger fires when data is pushed to the ldisc by the driver. This
> is a bit later than the actual receiving of data but has the nice benefit
> that it doesn't need adaption for each driver and isn't in the hot path.
>
> Similarly the tx trigger fires when data was copied from userspace and is
> given to the ldisc.
> #include <uapi/linux/tty.h>
> #include <linux/rwsem.h>
> #include <linux/llist.h>
> +#include <linux/leds.h>
Even for unordered lists of inclusions I would still try to put new
lines in "somehow" ordered positions.
For example here, I would rather put it before llist.h.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Andy Shevchenko @ 2018-05-13 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-7-mperttunen@nvidia.com>
On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
> multiplexing multiple "virtual UARTs" into a single hardware serial
> port. The TCU is the primary serial port on Tegra194 devices.
>
> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
> are part of Tegra HSP blocks that are already controlled by the Tegra
> HSP mailbox driver.
First question, can it be done utilizing SERDEV framework?
> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> + (void)port;
> + (void)mctrl;
Huh?
> +}
> +static void tegra_tcu_uart_stop_tx(struct uart_port *port)
> +{
> + (void)port;
> +}
Ditto.
> + if (written == 3) {
> + value |= 3 << 24;
> + value |= BIT(26);
> + mbox_send_message(tcu->tx, &value);
> + }
(1)
> + }
> +
> + if (written) {
> + value |= written << 24;
> + value |= BIT(26);
> + mbox_send_message(tcu->tx, &value);
> + }
(2)
These are code duplications.
> +static void tegra_tcu_uart_stop_rx(struct uart_port *port)
> +{
> + (void)port;
> +}
> +
> +static void tegra_tcu_uart_break_ctl(struct uart_port *port, int ctl)
> +{
> + (void)port;
> + (void)ctl;
> +}
> +
> +static int tegra_tcu_uart_startup(struct uart_port *port)
> +{
> + (void)port;
> +
> + return 0;
> +}
> +
> +static void tegra_tcu_uart_shutdown(struct uart_port *port)
> +{
> + (void)port;
> +}
> +
> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
> + struct ktermios *new,
> + struct ktermios *old)
> +{
> + (void)port;
> + (void)new;
> + (void)old;
> +}
Remove those unused stub contents.
> + return uart_set_options(&tegra_tcu_uart_port, cons,
> + 115200, 'n', 8, 'n');
Can't it be one line?
> +static void tegra_tcu_receive(struct mbox_client *client, void *msg_p)
> +{
> + struct tty_port *port = &tegra_tcu_uart_port.state->port;
> + uint32_t msg = *(uint32_t *)msg_p;
Redundant casting.
> + unsigned int num_bytes;
> + int i;
> +
> + num_bytes = (msg >> 24) & 0x3;
Two magic numbers.
> + for (i = 0; i < num_bytes; i++)
> + tty_insert_flip_char(port, (msg >> (i*8)) & 0xff, TTY_NORMAL);
> +
> + tty_flip_buffer_push(port);
> +}
> +MODULE_AUTHOR("Mikko Perttunen <mperttunen@nvidia.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("NVIDIA Tegra Combined UART driver");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index dce5f9dae121..eaf3c303cba6 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -281,4 +281,7 @@
> /* MediaTek BTIF */
> #define PORT_MTK_BTIF 117
>
> +/* NVIDIA Tegra Combined UART */
> +#define PORT_TEGRA_TCU 118
Check if there is an unused gap. IIRC we still have one near to 40ish.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
From: Daniel Vetter @ 2018-05-13 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525866725-16685-1-git-send-email-satendra.t@samsung.com>
On Wed, May 9, 2018 at 1:52 PM, Satendra Singh Thakur
<satendra.t@samsung.com> wrote:
> On Thu, May 08, 2018 at 16:28:30 +0530, Satendra Singh Thakur wrote:
>> On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote:
>> > On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
>> > > 1.There is a function in drm-core to calculate display timing parameters:
>> > > horizontal front porch, back porch, sync length,
>> > > vertical front porch, back porch, sync length and
>> > > clock in Hz.
>> > > However, some drivers are still calculating these parameters themselves.
>> > > Therefore, there is a duplication of the code.
>> > > This patch series replaces this redundant code with the function
>> > > drm_display_mode_to_videomode.
>> > > This removes nearly 100 redundant lines from the related drivers.
>> > > 2.For some drivers (sun4i) the reverse helper
>> > > drm_display_mode_from_videomode is used.
>> > > 3.For some drivers it replaces arithmatic operators (*, /) with shifting
>> > > operators (>>, <<).
>> > > 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_* flags.
>> > > 5.These changes apply to following crtc and encoder drivers:
>> > > atmel-hlcdc
>> > > bridge-tc358767
>> > > exynos-dsi
>> > > fsl-dcu
>> > > gma500-mdfld_dsi_dpi
>> > > hisilicon-kirin_dsi, ade
>> > > meson-encoder
>> > > pl111-display
>> > > sun4i-tv
>> > > ti lcdc
>> > > tegra dc
>> > > mediatek dpi dsi
>> > > bridge-adv7533
>> >
>> > The drm_mode_to_videomode helper is meant for interop between drm and v4l,
>> > which have different internal structures to represent modes.
>> >
>> > For drivers that only use drm I think the better option would be to add
>> > these fields to struct drm_display_mode as another set of crtc_* values
>> > (the computed values are stored in crtc_ prefixed members). And compute
>> > front/back porch in drm_mode_set_crtcinfo.
>> >
>> > Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
>> > fields in all the drivers you're changing. This way you avoid having to
>> > change all the drm drivers to use v4l #defines.
>> >
>> > Thanks,
>> > Daniel
>>
>> Hi Daniel,
>> Thanks for the comments.
>> I will look into it.
>>
>> Thanks
>> -Satendra
>
> Hi Daniel,
> Thanks for the comments.
> Please find below my understanding in this direction.
>
> 1. Currently struct videomode is being used in 50 drm drivers and 14 fbdev drivers.
> Since, it's already being used by so many drm drivers, that is the reason
> these fbdev objects (struct videmode and func drm_display_mode_to_videomode) were used in this patch series.
The biggest contributor for that seems to be of_get_videomode. We
should probably have a of_drm_get_display_mode helper, which
automatically converts the of/dt video description into the drm
display mode structure.
And I found way less than 50 drm drivers using videomode, much less if
we ignore of.
> 2. Anyway, if fbdev related objects (struct/func) are not encouraged in drm drivers, then we may add
> h/v front/back porches in struct drm_display_mode as adviced by you.
>
> 3. We can calculate these params in func drm_mode_set_crtcinfo at the end of it.
> int drm_mode_set_crtcinfo ()
> {
> .
> .
> crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
> crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
> .
> .
> crtc_clock_hz = crtc_clock*1000;
> };
>
> 4. Normally mode is programmed in HW in following callbacks of crtc and encoder drivers
> -mode_set
> -mode_set_nofb
> -atomic_enable
>
>
> Normally drm_mode_set_crtcinfo is used in
> -mode_fixup callbacks (CBs)
> of encoder and crtc drivers.
>
> if mode_fixup CBs are called before mode_set CBs then
> drm_mode_set_crtcinfo is right place to calculate sync/porch params.
> We can use crtc_hfront/back_porches directly and program them to HW
> in above mentioned callbacks.
>
> int my_mode_set ()
> {
> REG_WRITE(crtc_hfront_porch);
> REG_WRITE(crtc_hback_porch);
> .
> .
> }
Agreed with your plan up to point 5 here.
> 6. However, if these params are being modified after calling drm_set_crtcinfo as mentioned below:
>
> bool amdgpu_atombios_encoder_mode_fixup(struct drm_encoder *encoder,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
>
> /* set the active encoder to connector routing */
> amdgpu_encoder_set_active_device(encoder);
> ***drm_mode_set_crtcinfo(adjusted_mode, 0);****
>
> /* hw bug */
> if ((mode->flags & DRM_MODE_FLAG_INTERLACE)
> && (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2)))
> adjusted_mode->crtc_vsync_start = adjusted_mode->crtc_vdisplay + 2;
>
> Then we may need to define new func like
>
> void drm_calc_hv_porches_sync()
> {
> crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
> crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
> .
> .
> crtc_clock_hz = crtc_clock*1000;
> } and call this func in mode_set*, atomic_enable CBS before programming the HW with this mode.
>
>
> Should I create patches around this idea ?
> Please let me know your comments.
I'm not sure about point 6. I think we should wait with coming up with
a solution to this problem once there's a clear need for it. Most
likely I think drivers who both need to adjust computed timings and
who need v/hfront/back porch just need to adjust everything on their
own. And we won't provide any additional helpers.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Andy Shevchenko @ 2018-05-13 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Ve3Ugnjjm8EZkPQTZSvH1qad1e5SqjOn8zz5syHSQea_g@mail.gmail.com>
> I will refer to above as (1) later on.
> The question is, why you didn't utilize what SPI core provides you?
Here I should have referred to (1).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Andy Shevchenko @ 2018-05-13 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-6-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 1:38 PM, Radu Pirea <radu.pirea@microchip.com> wrote:
> This is the driver for at91-usart in spi mode. The USART IP can be configured
> to work in many modes and one of them is SPI.
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
Here is something wrong. You need to use latter one in new code.
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_gpio.h>
Hmm... Do you need all of them?
> +static inline void at91_usart_spi_cs_activate(struct spi_device *spi)
> +{
...
> + gpiod_set_value(ausd->npcs_pin, active);
> + aus->cs_active = true;
> +}
> +
> +static inline void at91_usart_spi_cs_deactivate(struct spi_device *spi)
> +{
...
> + gpiod_set_value(ausd->npcs_pin, !active);
> + aus->cs_active = false;
> +}
...
> + if (!ausd) {
> + if (gpio_is_valid(spi->cs_gpio)) {
> + npcs_pin = gpio_to_desc(spi->cs_gpio);
...
> + }
...
> + gpiod_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
> +
> + ausd->npcs_pin = npcs_pin;
...
> + }
I will refer to above as (1) later on.
> + dev_dbg(&spi->dev, "new message %p submitted for %s\n",
> + msg, dev_name(&spi->dev));
%p does make a very little sense.
> + list_for_each_entry(xfer, &msg->transfers, transfer_list) {
> + ret = at91_usart_spi_one_transfer(controller, msg, xfer);
> + if (ret)
> + goto msg_done;
> + }
Cant SPI core do this for your?
> +static void at91_usart_spi_cleanup(struct spi_device *spi)
> +{
> + struct at91_usart_spi_device *ausd = spi->controller_state;
> +
> + if (!ausd)
> + return;
Is it even possible?
Anyway the code below will work fine even if it's the case.
> +
> + spi->controller_state = NULL;
> + kfree(ausd);
> +}
> +static int at91_usart_spi_gpio_cs(struct platform_device *pdev)
> +{
> + struct spi_controller *controller = platform_get_drvdata(pdev);
> + struct device_node *np = controller->dev.parent->of_node;
> + struct gpio_desc *cs_gpio;
> + int nb;
> + int i;
> +
> + if (!np)
> + return 0;
> +
> + nb = of_gpio_named_count(np, "cs-gpios");
> + for (i = 0; i < nb; i++) {
> + cs_gpio = devm_gpiod_get_from_of_node(&pdev->dev,
> + pdev->dev.parent->of_node,
> + "cs-gpios",
> + i, GPIOD_OUT_HIGH,
> + dev_name(&pdev->dev));
> + if (IS_ERR(cs_gpio))
> + return PTR_ERR(cs_gpio);
> + }
> +
> + controller->num_chipselect = nb;
> +
> + return 0;
> +}
The question is, why you didn't utilize what SPI core provides you?
> + spi_writel(aus, MR, US_MR_SPI_MASTER | US_MR_CHRL | US_MR_CLKO |
> + US_MR_WRDBT);
> + spi_writel(aus, CR, US_CR_RXDIS | US_CR_TXDIS | US_CR_RSTRX |
> + US_CR_RSTTX);
I didn't check over, but it seems like you might have duplication in
these bitwise ORs. Consider to unify them into another (shorter)
definitions and reuse all over the code.
> + regs = platform_get_resource(to_platform_device(pdev->dev.parent),
> + IORESOURCE_MEM, 0);
> + if (!regs)
> + return -ENXIO;
Strange error code for getting MMIO resource. ENOMEM sounds better.
> + dev_info(&pdev->dev,
> + "Atmel USART SPI Controller version 0x%x at 0x%08lx (irq %d)\n",
> + spi_readl(aus, VERSION),
> + (unsigned long)regs->start, irq);
If you do explicit casting when printing something you are doing wrong.
Please use %pR or %pr in this case.
> +static struct platform_driver at91_usart_spi_driver = {
> + .driver = {
> + .name = "at91_usart_spi",
> + .of_match_table = of_match_ptr(at91_usart_spi_dt_ids),
Can it work as pure platform driver? If no, of_match_ptr() is redundant.
> + },
> + .probe = at91_usart_spi_probe,
> + .remove = at91_usart_spi_remove, };
Two lines at one. Split.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* common non-cache coherent direct dma mapping ops
From: Helge Deller @ 2018-05-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511075945.16548-1-hch@lst.de>
On 11.05.2018 09:59, Christoph Hellwig wrote:
> this series continues consolidating the dma-mapping code, with a focus
> on architectures that do not (always) provide cache coherence for DMA.
> Three architectures (arm, mips and powerpc) are still left to be
> converted later due to complexity of their dma ops selection.
>
> The dma-noncoherent ops calls the dma-direct ops for the actual
> translation of streaming mappins and allow the architecture to provide
> any cache flushing required for cpu to device and/or device to cpu
> ownership transfers. The dma coherent allocator is for now still left
> entirely to architecture supplied implementations due the amount of
> variations. Hopefully we can do some consolidation for them later on
> as well.
>
> A lot of architectures are currently doing very questionable things
> in their dma mapping routines, which are documented in the changelogs
> for each patch. Please review them very careful and correct me on
> incorrect assumptions.
>
> Because this series sits on top of two previously submitted series
> a git tree might be useful to actually test it. It is provided here:
>
> git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
>
> Changes since RFC:
> - fix a typo accidentally disabling the device to cpu transfer sync
> - fixed a few compile failures
I tested it again on parisc (this time again on top of git head) and it still breaks
the same way as I reported in my mail on April 21st: the lasi82956 network driver works
unreliable. NIC gets IP, but ping doesn't work.
See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions.
See comment in James mail from April 21st too:
-> you just made every 32 bit parisc system unnecessarily use non-coherent.
Helge
^ permalink raw reply
* [PATCH v3 3/6] MAINTAINERS: add at91 usart spi driver
From: Andy Shevchenko @ 2018-05-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-4-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 1:38 PM, Radu Pirea <radu.pirea@microchip.com> wrote:
> Added entry for at91 usart mfd driver.
>
You are adding a record for not existing file?
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ca06c6f58299..9243b9007966 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9199,6 +9199,13 @@ S: Supported
> F: drivers/mfd/at91-usart.c
> F: include/dt-bindings/mfd/at91-usart.h
>
> +MICROCHIP AT91 USART SPI DRIVER
> +M: Radu Pirea <radu.pirea@microchip.com>
> +L: linux-spi at vger.kernel.org
> +S: Supported
> +F: drivers/spi/spi-at91-usart.c
> +F: Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> +
> MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
> M: Woojung Huh <Woojung.Huh@microchip.com>
> M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> --
> 2.17.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port
From: Niklas Söderlund @ 2018-05-13 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509184558.14960-1-horms+renesas@verge.net.au>
Hi Simon,
Thanks for your patch.
On 2018-05-09 20:45:58 +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669..2a0c59e97f40 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -107,9 +107,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
> status = "okay";
>
> port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> bus-width = <8>;
> --
> 2.11.0
>
--
Regards,
Niklas S?derlund
^ 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