Hello Marek,
On 01/20/2017 05:08 AM, Marek Szyprowski wrote:
[snip]
>>
>> This seems to be caused by some needed clocks to access the power domains
>> to be gated, since I don't get these erros when passing clk_ignore_unused
>> as parameter in the kernel command line.
>
> I think that those
Hello Marek,
On 01/20/2017 05:08 AM, Marek Szyprowski wrote:
[snip]
>>
>> This seems to be caused by some needed clocks to access the power domains
>> to be gated, since I don't get these erros when passing clk_ignore_unused
>> as parameter in the kernel command line.
>
> I think that those
Hello,
On 01/20/2017 07:06 AM, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On 01/20/2017 05:37 AM, Marek Szyprowski wrote:
>
> [snip]
>>
>> Please send this patch instead of adding more clocks to the power domains.
>> This way we will avoid adding more dependencies to userspace (DT ABI).
Hello,
On 01/20/2017 07:06 AM, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On 01/20/2017 05:37 AM, Marek Szyprowski wrote:
>
> [snip]
>>
>> Please send this patch instead of adding more clocks to the power domains.
>> This way we will avoid adding more dependencies to userspace (DT ABI).
Hello Marek,
On 01/20/2017 05:37 AM, Marek Szyprowski wrote:
[snip]
>> I'll post a proper patch for the exynos5800.dtsi, to override the
>> clocks in the gsc_pd device node.
>>
>> I also see that the two power domains that fail to be disabled msc_pd
>> (power-domain@10044120) and isp_pd
Hello Marek,
On 01/20/2017 05:37 AM, Marek Szyprowski wrote:
[snip]
>> I'll post a proper patch for the exynos5800.dtsi, to override the
>> clocks in the gsc_pd device node.
>>
>> I also see that the two power domains that fail to be disabled msc_pd
>> (power-domain@10044120) and isp_pd
Hello Marek,
On 01/20/2017 05:08 AM, Marek Szyprowski wrote:
> Hi Javier,
>
[snip]
>> Ok, I misunderstood the relationship between runtime PM and the power domains
>> then. I thought the power domains were only powered on when the runtime PM
>> framework resumed an associated device (i.e:
Hello Marek,
On 01/20/2017 05:08 AM, Marek Szyprowski wrote:
> Hi Javier,
>
[snip]
>> Ok, I misunderstood the relationship between runtime PM and the power domains
>> then. I thought the power domains were only powered on when the runtime PM
>> framework resumed an associated device (i.e:
Hi Javier,
On 2017-01-19 18:51, Javier Martinez Canillas wrote:
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
Also when removing the exynos_gsc driver, I get the same error:
# rmmod s5p_mfc
[ 106.405972] s5p-mfc
Hi Javier,
On 2017-01-19 18:51, Javier Martinez Canillas wrote:
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
Also when removing the exynos_gsc driver, I get the same error:
# rmmod s5p_mfc
[ 106.405972] s5p-mfc
Hi Javier,
On 2017-01-19 15:56, Javier Martinez Canillas wrote:
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset")
Hi Javier,
On 2017-01-19 15:56, Javier Martinez Canillas wrote:
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset")
Hello Marek,
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
> On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
>
> Also when removing the exynos_gsc driver, I get the same error:
>
> # rmmod s5p_mfc
> [ 106.405972] s5p-mfc 1100.codec: Removing 1100.codec
> # rmmod
Hello Marek,
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
> On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
>
> Also when removing the exynos_gsc driver, I get the same error:
>
> # rmmod s5p_mfc
> [ 106.405972] s5p-mfc 1100.codec: Removing 1100.codec
> # rmmod
Hello Marek,
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2017-01-18 01:30, Javier Martinez Canillas wrote:
>> Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
>> CONFIG_PM is unset") removed the implicit dependency
Hello Marek,
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2017-01-18 01:30, Javier Martinez Canillas wrote:
>> Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
>> CONFIG_PM is unset") removed the implicit dependency
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work with !CONFIG_PM, the GSC reset logic that happens in
the runtime
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work with !CONFIG_PM, the GSC reset logic that happens in
the runtime
20 matches
Mail list logo
