Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

Hi Sergei, On Tue, Jun 7, 2016 at 12:26 AM, Sergei Shtylyov wrote: >> With regards to SMP. Have you checked to make sure CPU hotplug works >> on all CPUs? > >How to test the CPU hotplug? I've now added the SMP support and made sure > both CPUs are online

[PATCHv8 5/6] dmaengine: rcar-dmac: group slave configuration

Group slave address and transfer size in own structs for source and destination. This is in preparation for hooking up the dma-mapping API to the slave addresses. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv8 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Enable slave transfers to a device behind a IPMMU by mapping the slave addresses using the dma-mapping API. Signed-off-by: Niklas Söderlund --- drivers/dma/sh/rcar-dmac.c | 82 +- 1 file changed, 74

[PATCHv8 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops

Add methods to handle mapping of device resources from a physical address. This is needed for example to be able to map MMIO FIFO registers to a IOMMU. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart ---

[PATCHv8 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Hi, This series tries to solve the problem with DMA with device registers (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A recent patch '9575632 (dmaengine: make slave address physical)' clarifies that DMA slave address provided by clients is the physical address. This puts

[PATCHv8 4/6] arm: dma-mapping: add {map,unmap}_resource for iommu ops

Add methods to map/unmap device resources addresses for dma_map_ops that are IOMMU aware. This is needed to map a device MMIO register from a physical address. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

[PATCHv8 3/6] dma-mapping: add dma_{map,unmap}_resource

Map/Unmap a device MMIO resource from a physical address. If no dma_map_ops method is available the operation is a no-op. Signed-off-by: Niklas Söderlund --- Documentation/DMA-API.txt | 22 +- include/linux/dma-mapping.h | 36

Re: [PATCH v2 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions

Hi Geert, On 06.06.2016 14:59, Geert Uytterhoeven wrote: Hi Dirk, On Mon, Jun 6, 2016 at 2:03 PM, Dirk Behme wrote: On 30.05.2016 18:36, Dirk Behme wrote: On 30.05.2016 18:28, Geert Uytterhoeven wrote: Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as

[PATCH] ASoC: rsnd: adg :: AUDIO-CLKOUTn can synchronizes with L/R clock.

From: Kuninori Morimoto AUDIO-CLKOUTn can synchronizes with L/R clock, and Salvator board needs it. Otherwise, specific frequency sound will be noisy. Signed-off-by: Kuninori Morimoto ---

Re: [PATCH 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support

Hi Magnus, On Tue, Jun 7, 2016 at 5:39 AM, Magnus Damm wrote: > iommu/ipmmu-vmsa: Initial r8a7796 support > > [PATCH 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding > [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 > [PATCH 3/3] iommu/ipmmu-vmsa: Hook up

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote: > Several host bridge drivers (designware and all derivatives, iproc, > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port > windows they forward downstream to the PCI bus. > > That means the PCI core can't request

Re: [PATCH v2 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions

Hi Dirk, On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme wrote: > I think I just want to discuss if we have a clever idea to further improve > one detail. That is, if we have a clever idea to avoid the copy & paste > between the family members using anything like a

Re: [PATCH 0/9] clocksource/drivers/clksrc-of: Improve error handling

Hi Daniel, On Wed, Jun 1, 2016 at 10:34 AM, Daniel Lezcano wrote: > The macro CLOCKSOURCE_OF_DECLARE is widely used in the timer drivers. > > Basically, this macro is defined to insert in a table a tuple name,function. > This function is an init function called when

Re: [PATCH] ASoC: rsnd: adg :: AUDIO-CLKOUTn can synchronizes with L/R clock.

On Tue, Jun 07, 2016 at 06:21:33AM +, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > AUDIO-CLKOUTn can synchronizes with L/R clock, and Salvator board > needs it. Otherwise, specific frequency sound will be noisy. Why would a user not want these

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Hello. On 6/7/2016 6:39 AM, Magnus Damm wrote: From: Magnus Damm Bump up the maximum numbers of micro-TLBS to 48. Each IPMMU device instance get micro-TLB assignment via the "iommus" property in DT. Older SoCs tend to use a maximum number of 32 micro-TLBd per

Re: [PATCH v3 0/6] Add R8A7794/SILK sound DT support

Hello. On 6/7/2016 3:37 AM, Simon Horman wrote: Here's the set of 6 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20160509-v4.6-rc7' tag. I'm adding the sound device tree support for the R8A7794 SoC based SILK board. [1/6] ARM: dts: r8a7794: add audio clocks [2/6] ARM:

[PATCH 11/30] ARM: dts: r8a73a4: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /cache-controller@1 has a unit name, but no reg property Move the cache-controller nodes under the cpus node, and

[PATCH 05/30] ARM: dts: r8a7790: Reference both DMA controllers

From: Niklas Söderlund R-Car Gen2 have two DMA controllers, which are equivalent. Add references to both dmac0 and dmac1 so the driver can choose which one to use. Signed-off-by: Niklas Söderlund Signed-off-by: Simon

[PATCH 04/30] ARM: dts: r8a7790: Correct unit names for cpu nodes

From: Geert Uytterhoeven Make the unit names for the cpu nodes match their reg properties. Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- arch/arm/boot/dts/r8a7790.dtsi | 8 1 file

[PATCH 06/30] ARM: dts: r8a7791: Reference both DMA controllers

From: Niklas Söderlund R-Car Gen2 have two DMA controllers, which are equivalent. Add references to both dmac0 and dmac1 so the driver can choose which one to use. Signed-off-by: Niklas Söderlund Reviewed-by: Geert

[PATCH 23/30] ARM: dts: gose: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@2 has a unit name, but no

[PATCH 19/30] ARM: dts: ape6evm: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@2 has a unit name, but no

[PATCH 4/9] arm64: dts: r8a7795: Add RWDT node

From: Wolfram Sang This patch adds the RWDT device node for r8a7795. Signed-off-by: Takeshi Kihara Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Acked-by:

[PATCH 17/30] ARM: dts: r8a7794: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller@1 has a unit name, but no reg property Move the cache-controller node under the cpus node, and make its unit name and reg property match the MPIDR value. Signed-off-by: Geert Uytterhoeven

[PATCH 07/30] ARM: dts: r8a7793: Reference both DMA controllers

From: Niklas Söderlund R-Car Gen2 have two DMA controllers, which are equivalent. Add references to both dmac0 and dmac1 so the driver can choose which one to use. Signed-off-by: Niklas Söderlund Reviewed-by: Geert

[PATCH 8/9] arm64: dts: salvator-x: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@2 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@3 has a unit name, but no

[PATCH 7/9] arm64: dts: r8a7795: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /cache-controller@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node

[PATCH 9/9] arm64: dts: r8a7795: Drop 0x from unit address of gic

Drop 0x from unit address of gic as this is the desired form for a unit address. Signed-off-by: Simon Horman Acked-by: Geert Uytterhoeven --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 01/30] ARM: dts: r8a7793: Add MMCIF0

From: Ulrich Hecht Same as on r8a7791. Signed-off-by: Ulrich Hecht Acked-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- arch/arm/boot/dts/r8a7793.dtsi | 13

[PATCH 1/9] arm64: dts: salvator-x: SCIF1 supports RTS/CTS hardware flow control

From: Geert Uytterhoeven On the Salvator-X development board, the RTS and CTS pins of debug serial-1 port SCIF1 are wired to the CP2102 Serial-USB bridge. Reflect this in the DTS by adding the "uart-has-rtscts" property to the scif1 device node. Signed-off-by: Geert

Re: [PATCH] ASoC: rsnd: adg :: AUDIO-CLKOUTn can synchronizes with L/R clock.

Hi Mark > > AUDIO-CLKOUTn can synchronizes with L/R clock, and Salvator board > > needs it. Otherwise, specific frequency sound will be noisy. > > Why would a user not want these clocks to be synchronous? A lot of > CODECs will at least have better performance if their master clock is >

[PATCH 2/2] ARM: shmobile: rcar-gen2: Use ICRAM1 for jump stub on all SoCs

From: Geert Uytterhoeven Currently the different SoCs in the R-Car Gen2 family use different types of on-chip RAM for the jump stub: - R-Car H2 uses Media RAM, - R-Car M2-W uses another type of optional On-chip RAM, as it doesn't have Media RAM, - R-Car M2-N

[PATCH 1/2] ARM: shmobile: pm-rmobile: Postpone call to pm_genpd_init()

From: Geert Uytterhoeven All local setup of the generic_pm_domain structure should have been completed before calling pm_genpd_init(). Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulf Hansson Signed-off-by: Simon

Re: [PATCH v2 06/11] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus

Hi Magnus, Thank you for the patch. I agree with the comment that Geert made on v1, and I haven't seen you replying to it or addressing it. Quoting Geert, "I think this should be handled in drivers/iommu/of_iommu.c:of_iommu_init() instead, cfr. commit 3e5dd6f6e690048d ("clk: Ignore disabled

[PATCH 18/30] ARM: dts: sh73a0: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller has a reg or ranges property, but no unit name Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman ---

[PATCH 24/30] ARM: dts: koelsch: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@2 has a unit name, but no

[PATCH 08/30] ARM: dts: r8a7794: Reference both DMA controllers

From: Niklas Söderlund R-Car Gen2 have two DMA controllers, which are equivalent. Add references to both dmac0 and dmac1 so the driver can choose which one to use. Signed-off-by: Niklas Söderlund Reviewed-by: Geert

[PATCH 14/30] ARM: dts: r8a7790: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /cache-controller@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node

[PATCH 1/3] soc: renesas: rcar-sysc: Document r8a7796 support

From: Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Acked-by: Rob Herring Signed-off-by: Simon Horman ---

[PATCH 2/3] soc: renesas: Add r8a7796 SYSC PM Domain Binding Definitions

From: Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Simon Horman --- include/dt-bindings/power/r8a7796-sysc.h | 36

[PATCH 3/3] soc: renesas: rcar-sysc: Add support for R-Car M3-W power areas

From: Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Simon Horman --- drivers/soc/renesas/Makefile | 1 +

[PATCH 12/30] ARM: dts: r8a7740: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller has a reg or ranges property, but no unit name Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman ---

[PATCH 22/30] ARM: dts: genmai: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman ---

[PATCH 26/30] ARM: dts: kzm9g: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name,

[PATCH 09/30] ARM: dts: r8a7794: Remove nonexistent thermal sensor clock

From: Geert Uytterhoeven According to the latest information, there is no thermal IP block present on the r8a7794 SoC. Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman ---

[PATCH 27/30] ARM: dts: lager: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /keyboard/button@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /keyboard/button@2 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /keyboard/button@3 has a

[PATCH 29/30] ARM: dts: porter: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@2 has a unit name, but no

[PATCH 25/30] ARM: dts: kzm9d: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): Node /pfc@e0140200/serial@e103 has a unit name, but no reg property Warning (unit_address_vs_reg): Node

[PATCH 28/30] ARM: dts: marzen: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name, but no reg property Signed-off-by: Geert Uytterhoeven

[PATCH 20/30] ARM: dts: armadillo800eva: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@1 has a unit name,

[PATCH 16/30] ARM: dts: r8a7793: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /cache-controller@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /sound@ec50/rcar_sound,dvc/dvc@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node

[GIT PULL] Renesas ARM Based SoC Updates for v4.8

Hi Olof, Hi Kevin, Hi Arnd, Please consider these Renesas ARM based SoC updates for v4.8. The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at:

[GIT PULL] Renesas ARM Based SoC R-Car SYSC Updates for v4.8

Hi Olof, Hi Kevin, Hi Arnd, Please consider these Renesas ARM based SoC R-Car SYSC updates for v4.8. There are follow-up DT changes that depend on this driver which I hope will be ready to send to you in the v4.8 development cycle. The following changes since commit

[PATCH 30/30] ARM: dts: silk: Fix W=1 dtc warnings

From: Geert Uytterhoeven Warning (unit_address_vs_reg): Node /regulator@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@3 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /regulator@4 has a unit name, but no

renesas-drivers-2016-06-07-v4.7-rc2

I have pushed renesas-drivers-2016-06-07-v4.7-rc2 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging (a) the for-next branches of various subsystem trees

Re: [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

Hi Magnus, On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote: > iommu/ipmmu-vmsa: IPMMU multi-arch update V3 > > [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling > [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for > context >

Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree

On 06/07/2016 10:13 AM, Geert Uytterhoeven wrote: [...] And that the system behaves sanely on suspend/resume. I'd be thankful if you told me how to test that. :-) System suspend: echo mem > /sys/power/state Oh. I know that one! :-) System resume: You're gonna need a

[PATCH] pwm: sysfs: get return value from pwm_apply_state()

From: Ryo Kodama This patch adds to check the return value from pwm_apply_state() used in enable_store(). The error of enable_store() doesn't work if the return value doesn't received. Signed-off-by: Ryo Kodama Signed-off-by: Yoshihiro

Re: [PATCH 0/9] clocksource/drivers/clksrc-of: Improve error handling

On 06/07/2016 11:54 AM, Geert Uytterhoeven wrote: Hi Daniel, Hi Geert, [ ... ] Using "earlycon keep_bootcon" on koelsch (this doesn't help on arm64) reveals it's stuck at: clocksource_probe: no matching clocksources found sched_clock: 32 bits at 100 Hz, resolution 1000ns,

[PATCH v2 11/20] drm: sti: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 15/20] drm: virtgpu: Rely on the default ->best_encoder() behavior

The virtgpu output exposes a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 09/20] drm: rcar-du: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 08/20] drm: msm: Rely on the default ->best_encoder() behavior where appropriate

For all outputs except DSI we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 07/20] drm: mediatek: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 13/20] drm: tegra: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 10/20] drm: rockchip: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

On Tuesday, June 7, 2016 8:11:05 AM CEST Bjorn Helgaas wrote: > > > > What do you think is the correct behavior here, should the driver only > > request the PIO range with parent=ioport_resource, or should it also > > request the MMIO window for the I/O ports with parent=iomem_resource? > > In

[PATCH v2 18/20] drm/bridge: ptn3460: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 20/20] drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder()

We have a 1:1 relationship between connectors and encoders, which means we can rely on the drm_atomic_helper_best_encoder() behavior. We still have to explicitly assign ->best_encoder() to drm_atomic_helper_best_encoder(), because the automated fallback to drm_atomic_helper_best_encoder() when

[PATCH v2 03/20] drm: atmel-hlcdc: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 04/20] drm: exynos: Rely on the default ->best_encoder() behavior

We have 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 05/20] drm: fsl-dcu: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 00/20] drm/atomic: Provide default ->best_encoder() behavior

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making

[PATCH v2 12/20] drm: sun4i: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 19/20] drm/bridge: ps8622: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 17/20] drm/bridge: anx78xx: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders, and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder(), and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon ---

[PATCH v2 14/20] drm: vc4: Rely on the default ->best_encoder() behavior

All outputs have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementations and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

[PATCH v2 16/20] drm: omap: Rely on the default ->best_encoder() behavior

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

On Tue, Jun 07, 2016 at 10:21:36AM +0200, Arnd Bergmann wrote: > On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote: > > Several host bridge drivers (designware and all derivatives, iproc, > > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port > > windows they forward

Re: [PATCH v2 01/20] drm/atomic: Fix remaining places where !funcs->best_encoder is valid

On Tue, Jun 07, 2016 at 01:47:56PM +0200, Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know they want > to use

[PATCH] pinctrl: sh-pfc: fix warnings by include core.h

Fix warnings about emev2_pinmux_info and r8a7779_pinmux_info by using core.h instead of sh_pfc.h in these files. This gives the declarations of the two structures and removes the following warnings: drivers/pinctrl/sh-pfc/pfc-emev2.c:1695:30: warning: symbol 'emev2_pinmux_info' was not declared.