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
> ---
> arch/arm/boot/dts/
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 Pea
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
>
> ---
>
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 -
> 1 file c
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 | 4
> arch/arm/
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
> ---
> arch/arm/boot/dts/
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.
>
> Suggest
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 changes
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 have any effect?
If the P
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: Tobias Jakobi
>>> ---
>>> drive
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 to
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
>>> blending accordingly.
>>>
>>> We curr
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 next/multiplatform
Most of the code for the s3c64xx platform is only used when booting
with ATAGS based board files, but not when using device-tree.
This tries to identify all the s3c64xx specific code that is
unneeded when CONFIG_ATAGS is not set, so we can build a smaller
DT-only kernel if configured that way.
Al
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
---
drivers/input/touchscreen/Kconfig | 2 +-
1 fil
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 resourc
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 h
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 oversamplin
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 can
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 module_platform_drive
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 f
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
--
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 next/multiplatform branch unless there are any objections
or concerns.
Arnd Bergmann (10):
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
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 unnecesary reconfigurations we c
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:
2015-11-23 21:25 GMT+09:00 Jav
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 need to be properly turned
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
>>> on.
>>> When it is ins
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 e
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.
>
> Si
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 | 4
arch/arm/b
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
---
drivers/amba/bus.c | 7 +++
1 file c
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
---
arch/arm/boot/dts/exynos4210.dtsi | 1 +
1 file changed, 1 insertion(+)
diff
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 registrat
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
---
arch/arm/boot/dts/exynos4210.dtsi | 4
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
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 a/arch/arm/boot/dts/exynos4412-odroidu3
36 matches
Mail list logo