On Wed, 19 Mar 2014 19:51:21 +0100, Tomasz Figa wrote:
> On 19.03.2014 19:37, Grant Grundler wrote:
> > On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote:
> > ...
> >> As I said, AFAIK the trend is to get rid of ordering by initcalls and make
> >> sure that drivers can handle missing dependencie
On Wed, 19 Mar 2014 09:54:39 -0700, Grant Grundler wrote:
> On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
> ...
> >> Device driver is not only for the scholarship but also for the real use.
> >
> > Huh? I'm not sure what kind of comment is this.
>
> I'm guessing Cho meant: "This isn't an ac
On 19.03.2014 19:37, Grant Grundler wrote:
On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote:
...
As I said, AFAIK the trend is to get rid of ordering by initcalls and make
sure that drivers can handle missing dependencies properly, even for
"services" such as DMA, GPIO, clocks and so on, whi
On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote:
...
> As I said, AFAIK the trend is to get rid of ordering by initcalls and make
> sure that drivers can handle missing dependencies properly, even for
> "services" such as DMA, GPIO, clocks and so on, which after all are provided
> by normal dr
Hi Grant,
On 19.03.2014 18:03, Grant Grundler wrote:
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
...
No. Proper Linux drivers must support deferred probing mechanism and there
should be no assumptions about probing orders. Using other initcall level
than module_initcall for particular
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
...
>> Device driver is not only for the scholarship but also for the real use.
>
> Huh? I'm not sure what kind of comment is this.
I'm guessing Cho meant: "This isn't an academic exercise - I have a
real use case that requires reference countin
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
...
> No. Proper Linux drivers must support deferred probing mechanism and there
> should be no assumptions about probing orders. Using other initcall level
> than module_initcall for particular drivers is strongly discouraged.
That's true for "
On 19.03.2014 02:03, Cho KyongHo wrote:
On Tue, 18 Mar 2014 16:09:50 +0100, Tomasz Figa wrote:
On 18.03.2014 10:56, Cho KyongHo wrote:
On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
Hi KyongHo,
On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
@@ -637,11 +708,14 @@ static void exynos
On Tue, 18 Mar 2014 16:09:50 +0100, Tomasz Figa wrote:
> On 18.03.2014 10:56, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
> >> Hi KyongHo,
> >>
> >> On 14.03.2014 06:08, Cho KyongHo wrote:
>
> [snip]
>
> >>> -static bool __exynos_sysmmu_disable(struct sysmmu_drvd
On 18.03.2014 10:56, Cho KyongHo wrote:
On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
Hi KyongHo,
On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
-static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
+static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
If
On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
> Hi KyongHo,
>
> On 14.03.2014 06:08, Cho KyongHo wrote:
> > Runtime power management by exynos-iommu driver independently from
> > master H/W's runtime pm is not useful for power saving since attaching
> > master H/W in probing time turns on
Hi KyongHo,
On 14.03.2014 06:08, Cho KyongHo wrote:
Runtime power management by exynos-iommu driver independently from
master H/W's runtime pm is not useful for power saving since attaching
master H/W in probing time turns on its local power endlessly.
Thus this removes runtime pm API calls.
Run
Runtime power management by exynos-iommu driver independently from
master H/W's runtime pm is not useful for power saving since attaching
master H/W in probing time turns on its local power endlessly.
Thus this removes runtime pm API calls.
Runtime PM support is added in the following commits to ex
13 matches
Mail list logo
