Re: [PATCH 5/9] input: ati_remote2: fix typo 'can by' to 'can be'

[Dmitry Torokhov]

On Sun, May 06, 2018 at 01:23:49PM +0200, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang 

Applied, thank you.

> ---
>  drivers/input/misc/ati_remote2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/misc/ati_remote2.c 
> b/drivers/input/misc/ati_remote2.c
> index ded5b84e336dae..d8fd58fdf05086 100644
> --- a/drivers/input/misc/ati_remote2.c
> +++ b/drivers/input/misc/ati_remote2.c
> @@ -22,7 +22,7 @@ MODULE_LICENSE("GPL");
>  /*
>   * ATI Remote Wonder II Channel Configuration
>   *
> - * The remote control can by assigned one of sixteen "channels" in order to 
> facilitate
> + * The remote control can be assigned one of sixteen "channels" in order to 
> facilitate
>   * the use of multiple remote controls within range of each other.
>   * A remote's "channel" may be altered by pressing and holding the "PC" 
> button for
>   * approximately 3 seconds, after which the button will slowly flash the 
> count of the
> -- 
> 2.11.0
> 

-- 
Dmitry

Re: [PATCH] i2c: busses: remove superfluous ignoring of children for RPM

[Wolfram Sang]

On Sun, Apr 29, 2018 at 08:41:04PM +0200, Wolfram Sang wrote:
> These days, the I2C core ensures that the embedded adapter device
> ignores the PM states of its children already. Because the adapter
> device is an opaque logical device, there is no need for drivers to
> repeat that again.
> 
> Signed-off-by: Wolfram Sang 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: renesas: r8a77970: add SMP support

[Sergei Shtylyov]

On 05/08/2018 09:40 PM, Geert Uytterhoeven wrote:

>> Add the device node for the second Cortex-A53 CPU core.
>>
>> Based on the original (and large) patch by Daisuke Matsushita
>> .
>>
>> Signed-off-by: Vladimir Barinov 
>> Signed-off-by: Sergei Shtylyov 
> 
> Dupe of https://patchwork.kernel.org/patch/10032875/

   Sorry!
   Not an exact dupe, though -- mine has clock/power #define's used,
yours -- only bare #s. :-)

> From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
> (https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)

   Hmm... what's the fate of this series?

>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
>> @@ -41,6 +41,16 @@
>> enable-method = "psci";
>> };
>>
>> +   a53_1: cpu@1 {
>> +   device_type = "cpu";
>> +   compatible = "arm,cortex-a53","arm,armv8";
> 
> Missing space after the comma.

   Oops. :-)

> Gr{oetje,eeting}s,
> 
> Geert

MBR, Sergei

Re: [PATCH] arm64: dts: renesas: r8a77970: add SMP support

[Geert Uytterhoeven]

Hi Sergei,

On Tue, May 8, 2018 at 6:39 PM, Sergei Shtylyov
 wrote:
> Add the device node for the second Cortex-A53 CPU core.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Dupe of https://patchwork.kernel.org/patch/10032875/
>From series "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
(https://www.spinics.net/lists/linux-renesas-soc/msg19681.html)

> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -41,6 +41,16 @@
> enable-method = "psci";
> };
>
> +   a53_1: cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a53","arm,armv8";

Missing space after the comma.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v9 00/12] Sunxi: Add SMP support on A83T

[Florian Fainelli]

On 05/08/2018 06:19 AM, Maxime Ripard wrote:
> Hi,
> 
> On Fri, May 04, 2018 at 09:05:33PM +0200, Mylène Josserand wrote:
>> Hello everyone,
>>
>> This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
>> Based on sunxi's tree, sunxi/for-next branch.
>> Depends on a patch from Doug Berger that allows to include the "cpu-type"
>> header on assembly files that I included in my series (patch 01).
> 
> I applied the patches, with the remarks done by Russell on v8 fixed,
> and the function sun8i_a83t_cntvoff_init made static.

Did you push those patches to sunxi/linux.git yet? I would like to make
sure I have the same copy of patch 1 since that is necessary for some of
our Broadcom ARM SoCs for 4.18.

Thanks!
-- 
Florian

[PATCH] arm64: dts: renesas: r8a77970: add SMP support

[Sergei Shtylyov]

Add the device node for the second Cortex-A53 CPU core.

Based on the original (and large) patch by Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.

Signed-off-by: Vladimir Barinov <vladimir.bari...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'renesas-devel-20180508-v4.17-rc4' tag of Simon
Horman's 'renesas.git' repo.

 arch/arm64/boot/dts/renesas/r8a77970.dtsi |   10 ++
 1 file changed, 10 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -41,6 +41,16 @@
enable-method = "psci";
};
 
+   a53_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53","arm,armv8";
+   reg = <1>;
+   clocks = < CPG_CORE R8A77970_CLK_Z2>;
+   power-domains = < R8A77970_PD_CA53_CPU1>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
L2_CA53: cache-controller {
compatible = "cache";
power-domains = < R8A77970_PD_CA53_SCU>;

Re: [PATCH igt 0/8] Non-Intel test suite fixes

[Ulrich Hecht]

On Fri, Apr 27, 2018 at 6:03 PM, Laurent Pinchart
 wrote:
> Hi Ulrich,
>
> On Thursday, 15 March 2018 16:45:36 EEST Ulrich Hecht wrote:
>> Hi!
>>
>> I have run the tests on a Renesas R-Car M3-W's DU device, and have found a
>> number of false negatives that mostly stem from use of Intel-specifics
>> without checking if that makes sense first. So here's a bunch of fixes for
>> those, hope they are generic enough for upstreaming.
>
> I'm looking for instructions on how to compile and use igt on elinux.org but
> can't find them. Could you please point me to the relevant page ?

Here's a wikified version of what I have sent to our QA people:

https://elinux.org/R-Car/Tests:igt

CU
Uli

Re: [PATCH 0/2] ARM: dts: renesas: Add missing interrupt-affinity to PMU

[Simon Horman]

On Mon, May 07, 2018 at 03:40:03PM +0200, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> The Cortex-A9 PMU nodes on SH-Mobile AG5 and Emma Mobile EV2 reference
> two interrupts, but lack interrupt-affinity properties, leading to:
> 
> hw perfevents: no interrupt-affinity property for /pmu, guessing.
> 
> This series adds the missing properties to fix this.
> 
> Thanks!
> 
> Geert Uytterhoeven (2):
>   ARM: dts: sh73a0: Add missing interrupt-affinity to PMU node
>   ARM: dts: emev2: Add missing interrupt-affinity to PMU node

Thanks, applied.

Re: [PATCH v3 0/2] ARM: dts: renesas: Correct mask for GIC PPI interrupts

[Simon Horman]

On Mon, May 07, 2018 at 03:19:51PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
> 
> R-Car H2 and R-Mobile APE6 contain four Cortex-A15 and four Cortex-A7
> cores, hence the second interrupt specifier cell for Private Peripheral
> Interrupts should use "GIC_CPU_MASK_SIMPLE(8)", to make sure interrupts
> can be delivered to all 8 processor cores.
> 
> This brings the predecessors of R-Car Gen3 in line with what we're doing
> on other big.LITTLE SoCs, like R-Car H3 and M3-W.

Thanks, applied.

Re: [PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

[Simon Horman]

On Thu, Apr 26, 2018 at 08:24:43PM +0200, Jacopo Mondi wrote:
> Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Jacopo Mondi 

Thanks, applied.

Re: [PATCH] ARM: shmobile: r8a7794: alt: add EEPROM to DTS

[Simon Horman]

On Tue, May 08, 2018 at 01:14:25PM +0200, Geert Uytterhoeven wrote:
> On Mon, May 7, 2018 at 2:40 PM, Wolfram Sang
>  wrote:
> > Same EEPROM as on Koelsch, et al.
> >
> > Signed-off-by: Wolfram Sang 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v9 00/12] Sunxi: Add SMP support on A83T

[Maxime Ripard]

Hi,

On Fri, May 04, 2018 at 09:05:33PM +0200, Mylène Josserand wrote:
> Hello everyone,
> 
> This is a V9 of my series that adds SMP support for Allwinner sun8i-a83t.
> Based on sunxi's tree, sunxi/for-next branch.
> Depends on a patch from Doug Berger that allows to include the "cpu-type"
> header on assembly files that I included in my series (patch 01).

I applied the patches, with the remarks done by Russell on v8 fixed,
and the function sun8i_a83t_cntvoff_init made static.

> The difference with the v8 is just that the machine is renamed in sun8i-a83t
> (see patch 07), according to Maxime's review.

The machine name hasn't changed, and the name sun8i-a83t still doesn't
make much sense. I've fixed it as well.

Thanks,
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v9 01/12] ARM: Allow this header to be included by assembly files

[Russell King - ARM Linux]

On Fri, May 04, 2018 at 09:05:34PM +0200, Mylène Josserand wrote:
> From: Doug Berger 
> 
> The constants defined in this file are equally useful in assembly and C
> source files. The arm64 architecture version of this file allows
> inclusion in both assembly and C source files, so this this commit adds
> that capability to the arm architecture version so that the constants
> don't need to be defined in multiple places.
> 
> Signed-off-by: Doug Berger 
> Signed-off-by: Florian Fainelli 
> Signed-off-by: Mylène Josserand 

Acked-by: Russell King 

Thanks.

> ---
>  arch/arm/include/asm/cputype.h | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index cb546425da8a..e7632f536633 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -2,9 +2,6 @@
>  #ifndef __ASM_ARM_CPUTYPE_H
>  #define __ASM_ARM_CPUTYPE_H
>  
> -#include 
> -#include 
> -
>  #define CPUID_ID 0
>  #define CPUID_CACHETYPE  1
>  #define CPUID_TCM2
> @@ -98,6 +95,11 @@
>  /* Qualcomm implemented cores */
>  #define ARM_CPU_PART_SCORPION0x510002d0
>  
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +#include 
> +
>  extern unsigned int processor_id;
>  
>  #ifdef CONFIG_CPU_CP15
> @@ -326,4 +328,6 @@ static inline int __attribute_const__ 
> cpuid_feature_extract_field(u32 features,
>  #define cpuid_feature_extract(reg, field) \
>   cpuid_feature_extract_field(read_cpuid_ext(reg), field)
>  
> +#endif /* __ASSEMBLY__ */
> +
>  #endif
> -- 
> 2.11.0
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] PCI: rcar: Reuse generic pci_parse_request_of_pci_ranges() function

[Lorenzo Pieralisi]

On Wed, Apr 25, 2018 at 06:21:25PM +0300, Vladimir Zapolskiy wrote:
> The non-functional change removes a custom function to parse and
> allocate PCI resources in favour of pci_parse_request_of_pci_ranges().
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  drivers/pci/host/pcie-rcar.c | 42 +-
>  1 file changed, 1 insertion(+), 41 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 6ab28f29ac6a..66863b587380 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1063,44 +1063,6 @@ static const struct of_device_id rcar_pcie_of_match[] 
> = {
>   {},
>  };

Applied to pci/rcar for v4.18, thanks.

Lorenzo

> -static int rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
> -{
> - int err;
> - struct device *dev = pci->dev;
> - struct device_node *np = dev->of_node;
> - resource_size_t iobase;
> - struct resource_entry *win, *tmp;
> -
> - err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
> -);
> - if (err)
> - return err;
> -
> - err = devm_request_pci_bus_resources(dev, >resources);
> - if (err)
> - goto out_release_res;
> -
> - resource_list_for_each_entry_safe(win, tmp, >resources) {
> - struct resource *res = win->res;
> -
> - if (resource_type(res) == IORESOURCE_IO) {
> - err = pci_remap_iospace(res, iobase);
> - if (err) {
> - dev_warn(dev, "error %d: failed to map resource 
> %pR\n",
> -  err, res);
> -
> - resource_list_destroy_entry(win);
> - }
> - }
> - }
> -
> - return 0;
> -
> -out_release_res:
> - pci_free_resource_list(>resources);
> - return err;
> -}
> -
>  static int rcar_pcie_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -1118,9 +1080,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>  
>   pcie->dev = dev;
>  
> - INIT_LIST_HEAD(>resources);
> -
> - err = rcar_pcie_parse_request_of_pci_ranges(pcie);
> + err = pci_parse_request_of_pci_ranges(dev, >resources, NULL);
>   if (err)
>   goto err_free_bridge;
>  
> -- 
> 2.8.1
> 

Re: [PATCH] ARM: shmobile: r8a7794: alt: add EEPROM to DTS

[Geert Uytterhoeven]

On Mon, May 7, 2018 at 2:40 PM, Wolfram Sang
 wrote:
> Same EEPROM as on Koelsch, et al.
>
> Signed-off-by: Wolfram Sang 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v7 05/11] ARM: smp: Add initialization of CNTVOFF

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 11:10:16PM +0200, Mylène Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
> 
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.
> 
> Signed-off-by: Mylène Josserand 
> Reviewed-by: Geert Uytterhoeven 
> Tested-by: Geert Uytterhoeven 
> ---
>  arch/arm/common/Makefile  |  1 +
>  arch/arm/common/secure_cntvoff.S  | 31 +++
>  arch/arm/include/asm/secure_cntvoff.h |  8 
>  3 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/common/secure_cntvoff.S
>  create mode 100644 arch/arm/include/asm/secure_cntvoff.h
> 
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 70b4a14ed993..1e9f7af8f70f 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DMABOUNCE) += dmabounce.o
>  obj-$(CONFIG_SHARP_LOCOMO)   += locomo.o
>  obj-$(CONFIG_SHARP_PARAM)+= sharpsl_param.o
>  obj-$(CONFIG_SHARP_SCOOP)+= scoop.o
> +obj-$(CONFIG_SMP)+= secure_cntvoff.o
>  obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
>  obj-$(CONFIG_MCPM)   += mcpm_head.o mcpm_entry.o mcpm_platsmp.o 
> vlock.o
>  CFLAGS_REMOVE_mcpm_entry.o   = -pg
> diff --git a/arch/arm/common/secure_cntvoff.S 
> b/arch/arm/common/secure_cntvoff.S
> new file mode 100644
> index ..68a4a8344319
> --- /dev/null
> +++ b/arch/arm/common/secure_cntvoff.S
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0

For assembly files, the SPDX specifier is of this format:

/* SPDX-License-Identifier:  */

Please see Documentation/process/license-rules.rst for more
information, and fix your specifier to conform to the requirements.
Thanks.

> + *
> + * Copyright (C) 2014 Renesas Electronics Corporation
> + *
> + * Initialization of CNTVOFF register from secure mode
> + *
> + */
> +
> +#include 
> +#include 
> +
> +ENTRY(secure_cntvoff_init)
> + .arch   armv7-a
> + /*
> +  * CNTVOFF has to be initialized either from non-secure Hypervisor
> +  * mode or secure Monitor mode with SCR.NS==1. If TrustZone is enabled
> +  * then it should be handled by the secure code

This should also state that this code must not be executed if
virtualisation extensions are not present (which should be obvious)
as the mcrr instruction becomes unpredictable in that case.

> +  */
> + cps #MON_MODE
> + mrc p15, 0, r1, c1, c1, 0   /* Get Secure Config */
> + orr r0, r1, #1
> + mcr p15, 0, r0, c1, c1, 0   /* Set Non Secure bit */
> + isb
> + mov r0, #0
> + mcrrp15, 4, r0, r0, c14 /* CNTVOFF = 0 */
> + isb
> + mcr p15, 0, r1, c1, c1, 0   /* Set Secure bit */
> + isb
> + cps #SVC_MODE
> + ret lr
> +ENDPROC(secure_cntvoff_init)
> diff --git a/arch/arm/include/asm/secure_cntvoff.h 
> b/arch/arm/include/asm/secure_cntvoff.h
> new file mode 100644
> index ..1f93aee1f630
> --- /dev/null
> +++ b/arch/arm/include/asm/secure_cntvoff.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

This one conforms.

> +
> +#ifndef __ASMARM_ARCH_CNTVOFF_H
> +#define __ASMARM_ARCH_CNTVOFF_H
> +
> +extern void secure_cntvoff_init(void);
> +
> +#endif
> -- 
> 2.11.0
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Andrzej Hajda]

On 07.05.2018 15:43, Peter Rosin wrote:
> On 2018-05-07 14:59, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded.
> The step is very small IMHO. Just a device-link, which is very easy to
> remove once whatever other solution is ready.
>
>>   Do we need to go this way?
> If the drivers expect the parts to be there, and there is no other safety
> net in place if they are not, what is the (short-term) alternative?
>
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
> This patch does not contribute to any late init and any such delay is not
> affected by this. At all.
>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> That is a much bigger question than this patch/series. Conflating the
> two is not fair IMHO. You could run this very same argument for every
> driver that gets added, since any additional driver will just make it
> harder to make everything dynamic. Should we stop development right
> away?
>
> Besides, as long as the drm devices are in fact acting as big static
> drivers (built from smaller parts), 

not true

> this should be considered a bug-fix
> that will prevent dereference of stale pointers.
>
> Or will some other solution appear and magically make all bridges and
> drm drivers capable of dynamic reconfiguration in the next few weeks?
> Yeah, right...

You are not changing single driver, you are changing framework and it
affects all the drivers using it, being more cautious about such patches
seems quite natural.

Anyway, I have realized that since drm_bridge_detach will remove the
link, so with properly written dynamic bridge removal, your patch should
not be a blocker.

Regards
Andrzej

>
> Cheers,
> Peter
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>>  include/drm/drm_bridge.h |  2 ++
>>>  2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>>  #include 
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>>> struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>  
>>> +   if (encoder->dev->dev != bridge->odev) {
>>> +   bridge->link = device_link_add(encoder->dev->dev,
>>> +  bridge->odev, 0);
>>> +   if (!bridge->link) {
>>> +   dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> +   dev_name(encoder->dev->dev));
>>> +   return -EINVAL;
>>> +   }
>>> +   }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>  
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>  
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>>  }
>>>  
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>   * @list: to keep track of all added bridges
>>>   * @timings: the timing specification for the bridge, if any (may
>>>   * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>>   * @funcs: control functions
>>>   * 

Re: [PATCH v9 07/12] ARM: sunxi: Add initialization of CNTVOFF

[Marc Zyngier]

On 04/05/18 20:05, Mylène Josserand wrote:
> Add the initialization of CNTVOFF for sun8i-a83t.
> 
> For boot CPU, create a new machine that handles this
> function's call in an "init_early" callback. We need to initialize
> CNTVOFF before the arch timer's initialization otherwise, it will
> not be taken into account and fails to boot correctly.
> Because of that, this function can't be called in SMP's early_initcall
> function which is called after timer's init.
> 
> For secondary CPUs, add this function into secondary_startup
> assembly entry.
> 
> Signed-off-by: Mylène Josserand 
> Acked-by: Maxime Ripard 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v9 06/12] ARM: smp: Add initialization of CNTVOFF

[Marc Zyngier]

On 04/05/18 20:05, Mylène Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
> 
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.
> 
> Signed-off-by: Mylène Josserand 
> Reviewed-by: Geert Uytterhoeven 
> Tested-by: Geert Uytterhoeven 

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Andrzej Hajda]

On 07.05.2018 15:53, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded. Do we need to go this way?
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
>>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> This is already the case. You currently cannot hotplug a drm_bridge,
> everything must be present.

Are you sure? DRM core is changing quite fast, so maybe I have missed
something, but AFAIK core calls bridge code only if full display
pipeline is created and connector is in connected state.
So adding and removing bridges from inactive pipelines should work if
coded properly.

>  I don't think it makes sense to change that
> until we have physically hotpluggable drm_bridges in real hardware.

But kernel core already assumes that device drivers are hot-pluggable
:), even this patch is created to solve issues regarding driver hot
unplugging.

>  I
> definitely don't want to refcount stuff to work around driver load
> bonghits on DT platforms, because refcounting is way too hard to get right
> :-)

I am not sure about bridges, but I have successfully (IMO) experimented
with hot (un)plugging panel driver, see panel-samsung-s6e8aa0.c driver
and exynos_drm_dsi.c, panel driver can be safely
plugged/unplugged/replugged without any refcounting (but with help of
mipi_dsi attach/detach callbacks, which are not available for
non-mipi-dsi drivers).

Regards
Andrzej

>
> Afaik there's out-of-tree patches to solve 99% of the driver load fun on
> DT platforms, but because it's not a 100% solution it's blocked since
> forever.
> -Daniel
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>>  include/drm/drm_bridge.h |  2 ++
>>>  2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>>  #include 
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>>> struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>  
>>> +   if (encoder->dev->dev != bridge->odev) {
>>> +   bridge->link = device_link_add(encoder->dev->dev,
>>> +  bridge->odev, 0);
>>> +   if (!bridge->link) {
>>> +   dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> +   dev_name(encoder->dev->dev));
>>> +   return -EINVAL;
>>> +   }
>>> +   }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>  
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>  
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>>  }
>>>  
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>   * @list: to keep track of all added bridges
>>>   * @timings: the timing specification for the bridge, if any (may
>>>   * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>>   * @funcs: control functions
>>>   * @driver_private: pointer to the bridge driver's internal context
>>>   */
>>> @@ -271,6