Re: [PATCH v2 08/10] drivers: watchdog: Replace GPL license notice with SPDX identifier

x watchdog * * Copyright (c) 2017 Andreas Färber * - * SPDX-License-Identifier: GPL-2.0+ */ #include Acked-by: Andreas Färber # for RTD119x Thanks, Andreas -- SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudi

Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

Am 06.11.19 um 16:34 schrieb Rob Herring: > On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber wrote: >> Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring: >>> This patch is problematic because there's changes in arm-soc juno/dt >>> branch and there's n

Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring: > On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber > wrote: > > Instead of grouping alphabetically by third-party vendor, leading > > to > > one-element enums, sort by Mali model number, as done for Utgard. > &g

[RFC 4/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1195

Define a compatible string for Realtek RTD1195 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree

[RFC 6/7] dt-bindings: gpu: mali-utgard: Add Realtek RTD1395

Define compatible strings for Mali-470 and Realtek RTD1395 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation

Re: [PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619

$subject: "mali-bifrost" obviously. Fixed on my branch. Am 04.11.19 um 02:39 schrieb Andreas Färber: > Define a compatible string for Realtek RTD1619 SoC family. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml |

[PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML

uot;dt-bindings: Convert Arm Mali Midgard GPU to DT schema") Fixes: 1be5b54d26ae ("dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible") Cc: Rob Herring Signed-off-by: Andreas Färber --- .../devicetree/bindings/gpu/arm,mali-midgard.yaml | 32 ++

[PATCH 7/7] dt-bindings: gpu: arm-bifrost: Add Realtek RTD1619

Define a compatible string for Realtek RTD1619 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree

[PATCH 2/7] dt-bindings: gpu: mali-midgard: Add Realtek RTD1295

Define a compatible string for Realtek RTD1295 SoC family. Signed-off-by: Andreas Färber --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree

Re: [PATCH v9 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs

Am 30.04.19 um 16:40 schrieb Guido Günther: > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since > this is an IP core it will likely be found on others in the future. So > instead of adding this to the nwl host driver make it a generic PHY > driver. > > The driver supports the i

Re: [PATCH RESEND v7 1/3] dt-bindings: Add vendor prefix for Mixel Inc

ixelMixel, Inc. > mosaixtech Mosaix Technologies, Inc. > motorola Motorola, Inc. > moxa Moxa Inc. Reviewed-by: Andreas Färber in case you still need it for something else in light of Rob's comment. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg,

Re: vc4: NULL pointer dereference in drm_client_dev_hotplug

Hi Stefan and Daniel, Am 02.10.18 um 11:48 schrieb Stefan Wahren: > Hi Daniel, > > [add Peter and Andreas] > > Am 02.10.2018 um 10:44 schrieb Daniel Vetter: >> On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote: Sergey Suloev hat am 1. Oktober 2018 um 12:17 geschrieben: >>

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

Am 22.12.2017 um 11:34 schrieb Türk, Jan: >> On Wed, Dec 20, 2017 at 02:47:04PM +0100, jan.tu...@emtrion.com wrote: >>> + * SPDX-License-Identifier: GPL-2.0 >> >> You have this. >> >> Also, the rules around this are getting a bit stricter saying the SPDX >> tag should be the first line of the file

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

Hi, Am 22.12.2017 um 11:40 schrieb Alexandre Belloni: > On 22/12/2017 at 11:34:31 +0100, Türk, Jan wrote: diff --git a/arch/arm/boot/dts/imx6q-emcon.dtsi b/arch/arm/boot/dts/imx6q- >>> emcon.dtsi new file mode 100644 index ..64fc0cd74c05 --- /dev/null +++ b/arc

Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

> 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Andreas Färber Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ dri-deve

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

nsertion(+) Reviewed-by: Andreas Färber Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lis

exynos drm build failure due to cec_* symbols

Hello, We're observing the following build failure with v4.12-rc3, latest linux.git and linux-next.git: [ 9825s] LD vmlinux.o [ 9904s] MODPOST vmlinux.o [ 9915s] drivers/built-in.o: In function `hdmi_get_modes': [ 9915s] /home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.rc3.51.ga374846/lin

[RFC PATCH v1 0/4] Add Rockchip RGA support

Hi Yakir, Am 21.03.2016 um 13:17 schrieb Yakir Yang: > On 03/21/2016 07:29 PM, Heiko Stübner wrote: >> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang: >>> This patch set would add the RGA direct rendering based 2d graphics >>> acceleration module. >> very cool to see that. > ;) >>> This p

[RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

Am 27.03.2015 um 20:21 schrieb Javier Martinez Canillas: > Hello Krzysztof, > > On 03/27/2015 05:08 PM, Krzysztof Kozlowski wrote: >> After adding display power domain for Exynos5250 in commit >> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the >> display on Chromebook Snow a

[PATCH v5 8/9] ARM: dts: exynos5250: add display power domain

Am 02.02.2015 um 14:20 schrieb Marek Szyprowski: > From: Andrzej Hajda > > The patch adds domain definition and references to it in appropriate devices. > > Signed-off-by: Andrzej Hajda > [mszyprow: rebased onto generic power domains dt bindings] > Signed-off-by: Marek Szyprowski > Tested-by:

[PATCH v5 7/9] ARM: dts: Exynos: add 'hdmi' clock to mixer nodes

Am 02.02.2015 um 14:20 schrieb Marek Szyprowski: > Mixed block needs to control hdmi clock to properly perform power on/off > operation, so add 'hdmi' clock also to mixer nodes. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos5250.dtsi | 5 +++-- > arch/arm/boot/dts/exynos542

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

Hi, Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas: > On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: >> On 11/21/2014 06:32 PM, Ajay kumar wrote: >>> I have rebased my bridge series on top of linux-next. >>> >>> This is my git log: >>> 4b38a6f Revert "Revert "ARM: exynos_defconfi

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

Am 21.11.2014 um 00:49 schrieb Paolo Pisati: > vanilla kgene/for-next as of today: > > 7552917 Revert "ARM: exynos_defconfig: Enable options for display panel > support" > ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next > 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next > cf8

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

Am 19.11.2014 um 17:28 schrieb Javier Martinez Canillas: > On 11/19/2014 05:22 PM, Paolo Pisati wrote: >> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote: >>> >>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all >>> the needed patches. >>> >>> Aja

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: > On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber wrote: >> Am 31.07.2014 12:23, schrieb Thierry Reding: >>> On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote: Am 31.07.2014 10:38, schrieb Ajay kumar: > With just the spring-brid

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Ajay, Am 01.08.2014 09:02, schrieb Ajay kumar: > On Thu, Jul 31, 2014 at 7:52 PM, Andreas F?rber wrote: >> So, with simplefb reverted in U-Boot and ... >> >> * with just the v6 applied (...~2), I get only a black screen from >> Linux, no penguins, but the backlight seems on. System comes up ok

[PATCH] drm/msm/hdmi: enable lpm-mux if it is present

Hi, Am 31.07.2014 16:46, schrieb Stephane Viau: > From: Beeresh Gopal > > lpm-mux is programmed to enable HDMI connector > on the docking station for S805 chipset based > devices. > > Signed-off-by: Beeresh Gopal You forgot to sign off yourself. [...] > diff --git a/drivers/gpu/drm/msm/hdmi/

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Am 31.07.2014 12:23, schrieb Thierry Reding: > On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote: >> Am 31.07.2014 10:38, schrieb Ajay kumar: >>> With just the spring-bridge.v6 branch of your own tree, I am able to see >>> bootup logo on Skate(a variant of spring which also contains ps

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Am 31.07.2014 12:23, schrieb Thierry Reding: > On Thu, Jul 31, 2014 at 10:57:55AM +0200, Andreas F?rber wrote: >> Am 31.07.2014 10:38, schrieb Ajay kumar: > [...] >>> With just the spring-bridge.v6 branch of your own tree, I am able to see >>> bootup logo on Skate(a variant of spring which also con

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Ajay, Am 31.07.2014 10:38, schrieb Ajay kumar: > On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber wrote: >> Am 30.07.2014 08:21, schrieb Ajay kumar: >>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber wrote: Am 28.07.2014 08:13, schrieb Ajay kumar: > On 7/27/14, Andreas F?rber wrote: >>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Ajay, Am 30.07.2014 08:21, schrieb Ajay kumar: > On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber wrote: >> Am 28.07.2014 08:13, schrieb Ajay kumar: >>> On 7/27/14, Andreas F?rber wrote: Am 25.07.2014 21:22, schrieb Ajay Kumar: > This series is based on exynos-drm-next branch of Inki

[PATCH 0/3] drm/exynos: Allow module to be autoloaded

Am 29.07.2014 10:05, schrieb Sjoerd Simons: > On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: >> On 2014? 07? 28? 23:45, Sjoerd Simons wrote: >>> On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014? 07? 28? 17:30, Sjoerd Simons wrote: I don't see why Exynos drm driver should be

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Am 29.07.2014 13:36, schrieb Thierry Reding: > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote: >> Hi Ajay, >> >> Am 28.07.2014 08:13, schrieb Ajay kumar: >>> On 7/27/14, Andreas F?rber wrote: Am 25.07.2014 21:22, schrieb Ajay Kumar: > This series is based on exynos-drm-nex

[PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

Am 25.07.2014 21:22, schrieb Ajay Kumar: > From: Vincent Palatin > > This patch adds drm_bridge driver for parade DisplayPort > to LVDS bridge chip. > > Signed-off-by: Vincent Palatin > Signed-off-by: Andrew Bresticker > Signed-off-by: Sean Paul > Signed-off-by: Rahul Sharma > Signed-off-by:

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Ajay, Am 28.07.2014 08:13, schrieb Ajay kumar: > On 7/27/14, Andreas F?rber wrote: >> Am 25.07.2014 21:22, schrieb Ajay Kumar: >>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> I have teste

[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

Hi Lars-Peter, Am 25.07.2014 01:00, schrieb Andreas F?rber: > most notably I'm missing > ADI ADV7513 and AXI-HDMI support [...] > Cc: Lars-Peter Clausen (HDMI) Could you please enlighten us what the status of upstreaming ADV7511/ADV7513 support is? It is declared "work in progress" here: http:

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

Hi Ajay, Am 25.07.2014 21:22, schrieb Ajay Kumar: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > I have tested this after adding few DT changes for exynos5250-snow, > exynos5420-peach-pit and exyno

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

Hi Ajay, Am 03.07.2014 16:55, schrieb Ajay kumar: > On Thu, Jul 3, 2014 at 10:49 AM, Andreas F?rber wrote: >> Am 11.06.2014 20:26, schrieb Ajay Kumar: >>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

Hi Ajay, Thanks a lot for your work on this. Am 11.06.2014 20:26, schrieb Ajay Kumar: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > I have tested this after adding few DT changes for exynos5250-s

[PATCH V2] drm/exynos: Support DP CLKCON register in FIMD driver

Am 26.06.2014 16:36, schrieb Ajay Kumar: > Add the missing setting for DP CLKCON register. > > This register is present on Exynos5 based FIMD controllers, > and needs to be used if we are using DP. > > Signed-off-by: Ajay Kumar > --- > Changes since V1: > - Remove usage of driver_data to config

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

Am 24.06.2014 07:21, schrieb Inki Dae: > On 2014? 06? 23? 14:32, Rahul Sharma wrote: >> Allowing only one layer update per vsync can cause issues >> while there are update available for both layers. There is >> a good amount of possibility to loose updates if we allow >> single update per vsync. >>