Re: [PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi : > Hey Inki, > > > Inki Dae wrote: >> >> >> 2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: >>> This analyses the current layer configuration (which layers >>> are enabled, which have alpha-pixelformat, etc.) and setups >>>

Re: [PATCH 00/10] ARM: s3c64xx multiplatform

2015-11-25 Thread Mark Brown
On Wed, Nov 25, 2015 at 05:06:45PM +0100, Arnd Bergmann wrote: > I've posted the series before and we got a few people to test it > the last time, though I think the touchscreen portion is still > untested. > > I'd really like to get this merged for 4.5 and would put it into > a

[PATCH 09/10] ARM: s3c64xx: multiplatform support

2015-11-25 Thread Arnd Bergmann
After all preparation work is done, we can finally move the Kconfig option for s3c64xx into ARCH_MULTIPLATFORM. This implies allowing SAMSUNG_ATAGS for multiplatform again, but now disallowing the ADC driver below it, as that still has dependencies on header files. Signed-off-by: Arnd Bergmann

[PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support

2015-11-25 Thread Arnd Bergmann
This is another prerequisite for enabling multiplatform support, and it is the part I am least certain about. I assume it will cause the extra boot message "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated" to be printed, but otherwise work ok. This definitely needs to be tested on real

[PATCH 01/10] Input: s3c2410_ts: fix S3C_ADC dependency

2015-11-25 Thread Arnd Bergmann
S3C_ADC is only available on machines that don't do ARCH_MULTIPLATFORM, so changing the 'select' into 'depends on' here helps us move to ARCH_MULTIPLATFORM without introducing regressions. Signed-off-by: Arnd Bergmann Acked-by: Dmitry Torokhov ---

[PATCH 07/10] ARM: s3c64xx: use new adc/touchscreen driver

2015-11-25 Thread Arnd Bergmann
The old ADC and touchscreen drivers are not compatible with multiplatform support, but we can use the exynos-adc driver as a replacement. This changes the common device creation functions for s3c64xx (but not s3c24xx for now) to use the new driver. To do this, we have to pass the interrupt

Re: [PATCH 00/10] ARM: s3c64xx multiplatform

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 16:31:14 Mark Brown wrote: > On Wed, Nov 25, 2015 at 05:06:45PM +0100, Arnd Bergmann wrote: > > I've posted the series before and we got a few people to test it > > the last time, though I think the touchscreen portion is still > > untested. > > > > I'd really like

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-25 Thread Inki Dae
Hi Javier, 2015-11-24 22:19 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 11/23/2015 11:28 PM, Inki Dae wrote: >> Hi Javier, >> >> 2015년 11월 24일 03:38에 Javier Martinez Canillas 이(가) 쓴 글: >>> Hello Inki, >>> >>> On 11/23/2015 01:47 PM, Inki Dae wrote:

[PATCH 02/10] ASoC: samsung/smartq: use dynamic registration

2015-11-25 Thread Arnd Bergmann
As a prerequisite for moving s3c64xx into multiplatform configurations, we need to change the smartq audio driver to stop using hardcoded gpio numbers from the header file, and instead pass the gpio data through platform_data. In order to do that, we also move the code to use

[PATCH 03/10] gpio: samsung: move gpio-samsung driver back to platform code

2015-11-25 Thread Arnd Bergmann
The gpio-samsung driver is special in the sense that it interacts directly in multiple ways with the legacy platform code for the s3c24xx and s3c64xx platforms. In contrast, all devicetree based machines for Samsung, including the ones on those two SoC families use a different driver. The header

Re: [PATCH v2 1/5] drm/exynos: mixer: refactor layer setup

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi : > Hey Inki, > > > Inki Dae wrote: >> Hi Tobias, >> >> 2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: >>> First step in allowing a more generic way to setup complex >>> blending for the different layers. >>> >>> Signed-off-by:

Re: [PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi : > Hey Inki, > > > Inki Dae wrote: >> >> >> 2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: >>> This updates the blending setup when the layer configuration >>> changes (triggered by mixer_win_{commit,disable}). >>> >>> To avoid

[PATCH 08/10] ARM: s3c64xx: use common debug-ll implementation

2015-11-25 Thread Arnd Bergmann
The uart on s3c64xx is essentially the same as on s3c24xx, so we can share a single assembler file. However, the addresses are different, and we need to add the respective Kconfig magic to get the right addresses. Signed-off-by: Arnd Bergmann --- arch/arm/Kconfig.debug

[PATCH 04/10] ARM: s3c64xx: prepare initcalls for multiplatform

2015-11-25 Thread Arnd Bergmann
In a multiplatform kernel, each initcall is run regardless of the platform it is meant for, so it must not attempt to access SoC-specific registers. This adds 'if (soc_is_s3c64xx)' to all initcalls that are specific to the s3c64xx platform, to prevent them from breaking other platforms once we

[PATCH 06/10] iio: exynos-adc: add experimental touchscreen support

2015-11-25 Thread Arnd Bergmann
This adds support for the touchscreen on Samsung s3c64xx. The driver is completely untested but shows roughly how it could be done, following the example of the at91 driver. compared to the old plat-samsung/adc driver, there is no support for prioritizing ts over other clients, nor for

Re: [RESEND PATCH v3] dt-bindings: Consolidate SRAM bindings from all vendors

2015-11-25 Thread Rob Herring
On Thu, Nov 19, 2015 at 09:42:49AM +0900, Krzysztof Kozlowski wrote: > SRAM bindings for various SoCs, using the mmio-sram genalloc > API, are spread over different places - per SoC vendor. Since all of > these are quite similar (they depend on mmio-sram) move them to a common > place. > >

Re: [PATCH] ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3

2015-11-25 Thread Krzysztof Kozlowski
On 25.11.2015 21:11, Javier Martinez Canillas wrote: > The header is already included in the > exynos4412-odroid-common DTSI so there's no need to do it again > in the DTS file. > > Signed-off-by: Javier Martinez Canillas > > --- > >

Re: [PATCH] ARM: dts: exynos4210: Add power domain to G2D device

2015-11-25 Thread Krzysztof Kozlowski
On 25.11.2015 21:55, Marek Szyprowski wrote: > G2D device and it's SYSMMU belongs to LCD0 power domain on Exynos 4210, > so add missing power-domains property to G2D device node (G2D's SYSMMU is > already bound to LCD0 power domain). > > Signed-off-by: Marek Szyprowski

Re: [PATCH] ARM: dts: exynos4: unify g2d device node with other devices

2015-11-25 Thread Krzysztof Kozlowski
On 25.11.2015 21:59, Marek Szyprowski wrote: > G2D device is always available and doesn't depend on any external (board > specific) peripherals, so it can be unconditionally enabled. > > Signed-off-by: Marek Szyprowski > --- > arch/arm/boot/dts/exynos4210-origen.dts

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

2015-11-25 Thread Krzysztof Kozlowski
On 24.11.2015 13:32, Javier Martinez Canillas wrote: > >> least some frame buffer console on DP or HDMI (or whatever output could >> be generated... Xorg/Wayland would be better of course). You need it > > Yes, as I mentioned in the previous email, I tested display (with X) on an > Exynos5800

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Russell King - ARM Linux
On Wed, Nov 25, 2015 at 02:56:10PM +0100, Ulf Hansson wrote: > On 25 November 2015 at 14:34, Marek Szyprowski > wrote: > > Is ignoring dev_pm_domain_attach() return value a solution for you? > > That's probably better than nothing, but I wonder if it in practice > will

Re: [PATCH] PCI: designware: bail out if host_init failed

2015-11-25 Thread Bjorn Helgaas
Hi Jisheng, On Thu, Nov 12, 2015 at 09:48:45PM +0800, Jisheng Zhang wrote: > There's no reason to continue the initialization such as configure > register, scan root bus etc. if customized host_init() failed. This > patch tries to check the host_init result, bail out if failed. This patch

Re: [PATCH] ARM: dts: exynos4210: Add power domain to G2D device

2015-11-25 Thread Krzysztof Kozlowski
On 25.11.2015 21:55, Marek Szyprowski wrote: > G2D device and it's SYSMMU belongs to LCD0 power domain on Exynos 4210, > so add missing power-domains property to G2D device node (G2D's SYSMMU is > already bound to LCD0 power domain). > > Signed-off-by: Marek Szyprowski

Re: [PATCH] ARM: exynos_defconfig: Enable NFSv4 client

2015-11-25 Thread Javier Martinez Canillas
Hello Krzysztof, On 11/25/2015 01:13 AM, Krzysztof Kozlowski wrote: > NFS client is already enabled (NFS_FS) and by default it enables clients > for version 2 and 3. Enable explicitly the version 4 client to utilize > the newer protocol. > > The NFS client is especially useful for testing kernel

[PATCH] ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3

2015-11-25 Thread Javier Martinez Canillas
The header is already included in the exynos4412-odroid-common DTSI so there's no need to do it again in the DTS file. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] ARM: dts: exynos4: unify g2d device node with other devices

2015-11-25 Thread Marek Szyprowski
G2D device is always available and doesn't depend on any external (board specific) peripherals, so it can be unconditionally enabled. Signed-off-by: Marek Szyprowski --- arch/arm/boot/dts/exynos4210-origen.dts | 4 arch/arm/boot/dts/exynos4210-smdkv310.dts

[PATCH 0/2] Exynos4210: fix power domain for MDMA1 device

2015-11-25 Thread Marek Szyprowski
This patchset fixes mysterious boot hang on Exynos 4210 SoCs, when IOMMU is enabled. There is no direct dependency between IOMMU devices and MDMA1. However enabling IOMMU changes the device probe order, what results in LCD0 power domain being turned off for some time. During that time the

[PATCH 2/2] ARM: dts: exynos4210: MDMA1 device belongs to LCD0 power domain

2015-11-25 Thread Marek Szyprowski
On Exynos 4210 MDMA1 device belongs to LCD0 power domain, so add proper power-domains property. On Exynos 4x12, it belongs to TOP power domain, which is always enabled, thus require no assignment in exynos4x12.dtsi. Signed-off-by: Marek Szyprowski ---

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Russell King - ARM Linux
On Wed, Nov 25, 2015 at 01:58:09PM +0100, Marek Szyprowski wrote: > To read pid/cid registers, the probed device need to be properly turned on. > When it is inside a power domain, the bus code should ensure that the > given power domain is enabled before trying to access device's registers. > >

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Marek Szyprowski
Hello, On 2015-11-25 14:24, Russell King - ARM Linux wrote: On Wed, Nov 25, 2015 at 01:58:09PM +0100, Marek Szyprowski wrote: To read pid/cid registers, the probed device need to be properly turned on. When it is inside a power domain, the bus code should ensure that the given power domain is

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Ulf Hansson
On 25 November 2015 at 14:34, Marek Szyprowski wrote: > Hello, > > On 2015-11-25 14:24, Russell King - ARM Linux wrote: >> >> On Wed, Nov 25, 2015 at 01:58:09PM +0100, Marek Szyprowski wrote: >>> >>> To read pid/cid registers, the probed device need to be properly turned

[PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Marek Szyprowski
To read pid/cid registers, the probed device need to be properly turned on. When it is inside a power domain, the bus code should ensure that the given power domain is enabled before trying to access device's registers. Signed-off-by: Marek Szyprowski ---

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

2015-11-25 Thread Marek Szyprowski
Hello, On 2015-11-25 14:56, Ulf Hansson wrote: On 25 November 2015 at 14:34, Marek Szyprowski wrote: On 2015-11-25 14:24, Russell King - ARM Linux wrote: On Wed, Nov 25, 2015 at 01:58:09PM +0100, Marek Szyprowski wrote: To read pid/cid registers, the probed device