simplefb: add clock handling

simplefb: add clock handling

[Luc Verhaegen]

This is needed for the sunxi platform, where the u-boot initialized display 
engine gets disabled by the clocks framework if certain clocks are not 
claimed. Once these clocks are disabled, register content is lost, and there
is no turning back unless a full display driver is loaded, which kind of
beats the purpose of having simplefb running.

The lack of clock handling should plague more hardware, but so far rpi is the 
best known user of simplefb, and its stepmotherly handling of the arm core
has kept these sort of issues from the kernel.

The sunxi u-boot side code can be found here:
https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY

Patch 3 might be controversial, as this does not achieve anything real today,
since the status property in dt is only really evaluated when dealing with a
nodes memory. It still seems like a good idea to at least flag this memory or
node as disabled, as we really have no way back when the clocks get disabled.

Luc Verhaegen.

simplefb: add clock handling

[Luc Verhaegen]

This is needed for the sunxi platform, where the u-boot initialized display 
engine gets disabled by the clocks framework if certain clocks are not 
claimed. Once these clocks are disabled, register content is lost, and there
is no turning back unless a full display driver is loaded, which kind of
beats the purpose of having simplefb running.

The lack of clock handling should plague more hardware, but so far rpi is the 
best known user of simplefb, and its stepmotherly handling of the arm core
has kept these sort of issues from the kernel.

The sunxi u-boot side code can be found here:
https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY

Patch 3 might be controversial, as this does not achieve anything real today,
since the status property in dt is only really evaluated when dealing with a
nodes memory. It still seems like a good idea to at least flag this memory or
node as disabled, as we really have no way back when the clocks get disabled.

Luc Verhaegen.

[PATCH 1/4] simplefb: formalize pseudo palette handling

[Luc Verhaegen]

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 210f3a0..32be590 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
 	.vmode		= FB_VMODE_NONINTERLACED,
 };
 
+#define PSEUDO_PALETTE_SIZE 16
+
 static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 			      u_int transp, struct fb_info *info)
 {
@@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 	u32 cb = blue >> (16 - info->var.blue.length);
 	u32 value;
 
-	if (regno >= 16)
+	if (regno >= PSEUDO_PALETTE_SIZE)
 		return -EINVAL;
 
 	value = (cr << info->var.red.offset) |
@@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
 	return 0;
 }
 
+struct simplefb_par {
+	u32 palette[PSEUDO_PALETTE_SIZE];
+};
+
 static int simplefb_probe(struct platform_device *pdev)
 {
 	int ret;
 	struct simplefb_params params;
 	struct fb_info *info;
+	struct simplefb_par *par;
 	struct resource *mem;
 
 	if (fb_get_options("simplefb", NULL))
@@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
+	info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
 	if (!info)
 		return -ENOMEM;
 	platform_set_drvdata(pdev, info);
 
+	par = info->par;
+
 	info->fix = simplefb_fix;
 	info->fix.smem_start = mem->start;
 	info->fix.smem_len = resource_size(mem);
@@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
 		framebuffer_release(info);
 		return -ENODEV;
 	}
-	info->pseudo_palette = (void *)(info + 1);
+	info->pseudo_palette = (void *) par->palette;
 
 	dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
 			     info->fix.smem_start, info->fix.smem_len,
-- 
1.7.7

[PATCH 1/4] simplefb: formalize pseudo palette handling

[Luc Verhaegen]

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   15 ++++++++++++---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 210f3a0..32be590 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
 	.vmode		= FB_VMODE_NONINTERLACED,
 };
 
+#define PSEUDO_PALETTE_SIZE 16
+
 static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 			      u_int transp, struct fb_info *info)
 {
@@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 	u32 cb = blue >> (16 - info->var.blue.length);
 	u32 value;
 
-	if (regno >= 16)
+	if (regno >= PSEUDO_PALETTE_SIZE)
 		return -EINVAL;
 
 	value = (cr << info->var.red.offset) |
@@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
 	return 0;
 }
 
+struct simplefb_par {
+	u32 palette[PSEUDO_PALETTE_SIZE];
+};
+
 static int simplefb_probe(struct platform_device *pdev)
 {
 	int ret;
 	struct simplefb_params params;
 	struct fb_info *info;
+	struct simplefb_par *par;
 	struct resource *mem;
 
 	if (fb_get_options("simplefb", NULL))
@@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
+	info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
 	if (!info)
 		return -ENOMEM;
 	platform_set_drvdata(pdev, info);
 
+	par = info->par;
+
 	info->fix = simplefb_fix;
 	info->fix.smem_start = mem->start;
 	info->fix.smem_len = resource_size(mem);
@@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
 		framebuffer_release(info);
 		return -ENODEV;
 	}
-	info->pseudo_palette = (void *)(info + 1);
+	info->pseudo_palette = (void *) par->palette;
 
 	dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
 			     info->fix.smem_start, info->fix.smem_len,
-- 
1.7.7

Re: [PATCH 1/4] simplefb: formalize pseudo palette handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>
> ---
>  drivers/video/fbdev/simplefb.c |   15 ++++++++++++---
>  1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 210f3a0..32be590 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
>         .vmode          = FB_VMODE_NONINTERLACED,
>  };
>
> +#define PSEUDO_PALETTE_SIZE 16
> +
>  static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
>                               u_int transp, struct fb_info *info)
>  {
> @@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
>         u32 cb = blue >> (16 - info->var.blue.length);
>         u32 value;
>
> -       if (regno >= 16)
> +       if (regno >= PSEUDO_PALETTE_SIZE)
>                 return -EINVAL;
>
>         value = (cr << info->var.red.offset) |
> @@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
>         return 0;
>  }
>
> +struct simplefb_par {
> +       u32 palette[PSEUDO_PALETTE_SIZE];
> +};
> +

I'd move that definition to the top of the file.

>  static int simplefb_probe(struct platform_device *pdev)
>  {
>         int ret;
>         struct simplefb_params params;
>         struct fb_info *info;
> +       struct simplefb_par *par;
>         struct resource *mem;
>
>         if (fb_get_options("simplefb", NULL))
> @@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
>                 return -EINVAL;
>         }
>
> -       info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
> +       info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
>         if (!info)
>                 return -ENOMEM;
>         platform_set_drvdata(pdev, info);
>
> +       par = info->par;
> +
>         info->fix = simplefb_fix;
>         info->fix.smem_start = mem->start;
>         info->fix.smem_len = resource_size(mem);
> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>                 framebuffer_release(info);
>                 return -ENODEV;
>         }
> -       info->pseudo_palette = (void *)(info + 1);
> +       info->pseudo_palette = (void *) par->palette;

I think coding-style is this (i.e., no whitespace):
    info->pseudo_palette = (void*)par->palette;

Patch is fine with me:
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

>
>         dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
>                              info->fix.smem_start, info->fix.smem_len,
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] simplefb: formalize pseudo palette handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>
> ---
>  drivers/video/fbdev/simplefb.c |   15 ++++++++++++---
>  1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 210f3a0..32be590 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -41,6 +41,8 @@ static struct fb_var_screeninfo simplefb_var = {
>         .vmode          = FB_VMODE_NONINTERLACED,
>  };
>
> +#define PSEUDO_PALETTE_SIZE 16
> +
>  static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
>                               u_int transp, struct fb_info *info)
>  {
> @@ -50,7 +52,7 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
>         u32 cb = blue >> (16 - info->var.blue.length);
>         u32 value;
>
> -       if (regno >= 16)
> +       if (regno >= PSEUDO_PALETTE_SIZE)
>                 return -EINVAL;
>
>         value = (cr << info->var.red.offset) |
> @@ -163,11 +165,16 @@ static int simplefb_parse_pd(struct platform_device *pdev,
>         return 0;
>  }
>
> +struct simplefb_par {
> +       u32 palette[PSEUDO_PALETTE_SIZE];
> +};
> +

I'd move that definition to the top of the file.

>  static int simplefb_probe(struct platform_device *pdev)
>  {
>         int ret;
>         struct simplefb_params params;
>         struct fb_info *info;
> +       struct simplefb_par *par;
>         struct resource *mem;
>
>         if (fb_get_options("simplefb", NULL))
> @@ -188,11 +195,13 @@ static int simplefb_probe(struct platform_device *pdev)
>                 return -EINVAL;
>         }
>
> -       info = framebuffer_alloc(sizeof(u32) * 16, &pdev->dev);
> +       info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
>         if (!info)
>                 return -ENOMEM;
>         platform_set_drvdata(pdev, info);
>
> +       par = info->par;
> +
>         info->fix = simplefb_fix;
>         info->fix.smem_start = mem->start;
>         info->fix.smem_len = resource_size(mem);
> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>                 framebuffer_release(info);
>                 return -ENODEV;
>         }
> -       info->pseudo_palette = (void *)(info + 1);
> +       info->pseudo_palette = (void *) par->palette;

I think coding-style is this (i.e., no whitespace):
    info->pseudo_palette = (void*)par->palette;

Patch is fine with me:
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

>
>         dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
>                              info->fix.smem_start, info->fix.smem_len,
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] simplefb: formalize pseudo palette handling

[Geert Uytterhoeven]

On Wed, Aug 13, 2014 at 9:25 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>>                 framebuffer_release(info);
>>                 return -ENODEV;
>>         }
>> -       info->pseudo_palette = (void *)(info + 1);
>> +       info->pseudo_palette = (void *) par->palette;
>
> I think coding-style is this (i.e., no whitespace):
>     info->pseudo_palette = (void*)par->palette;

<casts-are-evil>
Is this cast even needed?
</casts-are-evil>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 1/4] simplefb: formalize pseudo palette handling

[Geert Uytterhoeven]

On Wed, Aug 13, 2014 at 9:25 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>>                 framebuffer_release(info);
>>                 return -ENODEV;
>>         }
>> -       info->pseudo_palette = (void *)(info + 1);
>> +       info->pseudo_palette = (void *) par->palette;
>
> I think coding-style is this (i.e., no whitespace):
>     info->pseudo_palette = (void*)par->palette;

<casts-are-evil>
Is this cast even needed?
</casts-are-evil>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/4] simplefb: formalize pseudo palette handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 10:46 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Aug 13, 2014 at 9:25 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>>>                 framebuffer_release(info);
>>>                 return -ENODEV;
>>>         }
>>> -       info->pseudo_palette = (void *)(info + 1);
>>> +       info->pseudo_palette = (void *) par->palette;
>>
>> I think coding-style is this (i.e., no whitespace):
>>     info->pseudo_palette = (void*)par->palette;
>
> <casts-are-evil>
> Is this cast even needed?
> </casts-are-evil>

"pseudo_palette" is "void*", so not at all.

Thanks
David

[PATCH 1/4] simplefb: formalize pseudo palette handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 10:46 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Aug 13, 2014 at 9:25 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> @@ -225,7 +234,7 @@ static int simplefb_probe(struct platform_device *pdev)
>>>                 framebuffer_release(info);
>>>                 return -ENODEV;
>>>         }
>>> -       info->pseudo_palette = (void *)(info + 1);
>>> +       info->pseudo_palette = (void *) par->palette;
>>
>> I think coding-style is this (i.e., no whitespace):
>>     info->pseudo_palette = (void*)par->palette;
>
> <casts-are-evil>
> Is this cast even needed?
> </casts-are-evil>

"pseudo_palette" is "void*", so not at all.

Thanks
David

Re: [PATCH 1/4] simplefb: formalize pseudo palette handling

[Stephen Warren]

On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>

Patch description?

Assuming any comments anyone else had are addressed, patches 1 and 2 both,
Acked-by: Stephen Warren <swarren@nvidia.com>

[PATCH 1/4] simplefb: formalize pseudo palette handling

[Stephen Warren]

On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>

Patch description?

Assuming any comments anyone else had are addressed, patches 1 and 2 both,
Acked-by: Stephen Warren <swarren@nvidia.com>

[PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 32be590..72a4f20 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
 
 	info->apertures = alloc_apertures(1);
 	if (!info->apertures) {
-		framebuffer_release(info);
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto error_fb_release;
 	}
 	info->apertures->ranges[0].base = info->fix.smem_start;
 	info->apertures->ranges[0].size = info->fix.smem_len;
@@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
 	info->screen_base = ioremap_wc(info->fix.smem_start,
 				       info->fix.smem_len);
 	if (!info->screen_base) {
-		framebuffer_release(info);
-		return -ENODEV;
+		ret = -ENODEV;
+		goto error_fb_release;
 	}
 	info->pseudo_palette = (void *) par->palette;
 
@@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
 	ret = register_framebuffer(info);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
-		iounmap(info->screen_base);
-		framebuffer_release(info);
-		return ret;
+		goto error_unmap;
 	}
 
 	dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
 
 	return 0;
+
+ error_unmap:
+	iounmap(info->screen_base);
+
+ error_fb_release:
+	framebuffer_release(info);
+
+	return ret;
 }
 
 static int simplefb_remove(struct platform_device *pdev)
-- 
1.7.7

[PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 32be590..72a4f20 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
 
 	info->apertures = alloc_apertures(1);
 	if (!info->apertures) {
-		framebuffer_release(info);
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto error_fb_release;
 	}
 	info->apertures->ranges[0].base = info->fix.smem_start;
 	info->apertures->ranges[0].size = info->fix.smem_len;
@@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
 	info->screen_base = ioremap_wc(info->fix.smem_start,
 				       info->fix.smem_len);
 	if (!info->screen_base) {
-		framebuffer_release(info);
-		return -ENODEV;
+		ret = -ENODEV;
+		goto error_fb_release;
 	}
 	info->pseudo_palette = (void *) par->palette;
 
@@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
 	ret = register_framebuffer(info);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
-		iounmap(info->screen_base);
-		framebuffer_release(info);
-		return ret;
+		goto error_unmap;
 	}
 
 	dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
 
 	return 0;
+
+ error_unmap:
+	iounmap(info->screen_base);
+
+ error_fb_release:
+	framebuffer_release(info);
+
+	return ret;
 }
 
 static int simplefb_remove(struct platform_device *pdev)
-- 
1.7.7

Re: [PATCH 2/4] simplefb: add goto error path to probe

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>
> ---
>  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
>  1 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 32be590..72a4f20 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
>         info->apertures = alloc_apertures(1);
>         if (!info->apertures) {
> -               framebuffer_release(info);
> -               return -ENOMEM;
> +               ret = -ENOMEM;
> +               goto error_fb_release;
>         }
>         info->apertures->ranges[0].base = info->fix.smem_start;
>         info->apertures->ranges[0].size = info->fix.smem_len;
> @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
>         info->screen_base = ioremap_wc(info->fix.smem_start,
>                                        info->fix.smem_len);
>         if (!info->screen_base) {
> -               framebuffer_release(info);
> -               return -ENODEV;
> +               ret = -ENODEV;
> +               goto error_fb_release;
>         }
>         info->pseudo_palette = (void *) par->palette;
>
> @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
>         ret = register_framebuffer(info);
>         if (ret < 0) {
>                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> -               iounmap(info->screen_base);
> -               framebuffer_release(info);
> -               return ret;
> +               goto error_unmap;
>         }
>
>         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>
>         return 0;
> +
> + error_unmap:
> +       iounmap(info->screen_base);
> +
> + error_fb_release:
> +       framebuffer_release(info);
> +
> +       return ret;

Again, I'd use different coding-style, but I will leave that to
Stephen and Tomi:

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

>  }
>
>  static int simplefb_remove(struct platform_device *pdev)
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] simplefb: add goto error path to probe

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> Signed-off-by: Luc Verhaegen <libv@skynet.be>
> ---
>  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
>  1 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 32be590..72a4f20 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
>         info->apertures = alloc_apertures(1);
>         if (!info->apertures) {
> -               framebuffer_release(info);
> -               return -ENOMEM;
> +               ret = -ENOMEM;
> +               goto error_fb_release;
>         }
>         info->apertures->ranges[0].base = info->fix.smem_start;
>         info->apertures->ranges[0].size = info->fix.smem_len;
> @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
>         info->screen_base = ioremap_wc(info->fix.smem_start,
>                                        info->fix.smem_len);
>         if (!info->screen_base) {
> -               framebuffer_release(info);
> -               return -ENODEV;
> +               ret = -ENODEV;
> +               goto error_fb_release;
>         }
>         info->pseudo_palette = (void *) par->palette;
>
> @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
>         ret = register_framebuffer(info);
>         if (ret < 0) {
>                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> -               iounmap(info->screen_base);
> -               framebuffer_release(info);
> -               return ret;
> +               goto error_unmap;
>         }
>
>         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>
>         return 0;
> +
> + error_unmap:
> +       iounmap(info->screen_base);
> +
> + error_fb_release:
> +       framebuffer_release(info);
> +
> +       return ret;

Again, I'd use different coding-style, but I will leave that to
Stephen and Tomi:

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

>  }
>
>  static int simplefb_remove(struct platform_device *pdev)
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:27:46AM +0200, David Herrmann wrote:
> Hi
> 
> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> > Signed-off-by: Luc Verhaegen <libv@skynet.be>
> > ---
> >  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
> >  1 files changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> > index 32be590..72a4f20 100644
> > --- a/drivers/video/fbdev/simplefb.c
> > +++ b/drivers/video/fbdev/simplefb.c
> > @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
> >
> >         info->apertures = alloc_apertures(1);
> >         if (!info->apertures) {
> > -               framebuffer_release(info);
> > -               return -ENOMEM;
> > +               ret = -ENOMEM;
> > +               goto error_fb_release;
> >         }
> >         info->apertures->ranges[0].base = info->fix.smem_start;
> >         info->apertures->ranges[0].size = info->fix.smem_len;
> > @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
> >         info->screen_base = ioremap_wc(info->fix.smem_start,
> >                                        info->fix.smem_len);
> >         if (!info->screen_base) {
> > -               framebuffer_release(info);
> > -               return -ENODEV;
> > +               ret = -ENODEV;
> > +               goto error_fb_release;
> >         }
> >         info->pseudo_palette = (void *) par->palette;
> >
> > @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
> >         ret = register_framebuffer(info);
> >         if (ret < 0) {
> >                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> > -               iounmap(info->screen_base);
> > -               framebuffer_release(info);
> > -               return ret;
> > +               goto error_unmap;
> >         }
> >
> >         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
> >
> >         return 0;
> > +
> > + error_unmap:
> > +       iounmap(info->screen_base);
> > +
> > + error_fb_release:
> > +       framebuffer_release(info);
> > +
> > +       return ret;
> 
> Again, I'd use different coding-style, but I will leave that to
> Stephen and Tomi:
> 
> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

While the discussion about the last two patches rages on, can you state 
what coding style changes you would like to see here, as i am not clear 
as to what exactly is off with the above code.

Luc Verhaegen.

[PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:27:46AM +0200, David Herrmann wrote:
> Hi
> 
> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> > Signed-off-by: Luc Verhaegen <libv@skynet.be>
> > ---
> >  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
> >  1 files changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> > index 32be590..72a4f20 100644
> > --- a/drivers/video/fbdev/simplefb.c
> > +++ b/drivers/video/fbdev/simplefb.c
> > @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
> >
> >         info->apertures = alloc_apertures(1);
> >         if (!info->apertures) {
> > -               framebuffer_release(info);
> > -               return -ENOMEM;
> > +               ret = -ENOMEM;
> > +               goto error_fb_release;
> >         }
> >         info->apertures->ranges[0].base = info->fix.smem_start;
> >         info->apertures->ranges[0].size = info->fix.smem_len;
> > @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
> >         info->screen_base = ioremap_wc(info->fix.smem_start,
> >                                        info->fix.smem_len);
> >         if (!info->screen_base) {
> > -               framebuffer_release(info);
> > -               return -ENODEV;
> > +               ret = -ENODEV;
> > +               goto error_fb_release;
> >         }
> >         info->pseudo_palette = (void *) par->palette;
> >
> > @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
> >         ret = register_framebuffer(info);
> >         if (ret < 0) {
> >                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> > -               iounmap(info->screen_base);
> > -               framebuffer_release(info);
> > -               return ret;
> > +               goto error_unmap;
> >         }
> >
> >         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
> >
> >         return 0;
> > +
> > + error_unmap:
> > +       iounmap(info->screen_base);
> > +
> > + error_fb_release:
> > +       framebuffer_release(info);
> > +
> > +       return ret;
> 
> Again, I'd use different coding-style, but I will leave that to
> Stephen and Tomi:
> 
> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

While the discussion about the last two patches rages on, can you state 
what coding style changes you would like to see here, as i am not clear 
as to what exactly is off with the above code.

Luc Verhaegen.

Re: [PATCH 2/4] simplefb: add goto error path to probe

[David Herrmann]

Hi

On Thu, Aug 14, 2014 at 12:29 PM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 09:27:46AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> > Signed-off-by: Luc Verhaegen <libv@skynet.be>
>> > ---
>> >  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
>> >  1 files changed, 13 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
>> > index 32be590..72a4f20 100644
>> > --- a/drivers/video/fbdev/simplefb.c
>> > +++ b/drivers/video/fbdev/simplefb.c
>> > @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
>> >
>> >         info->apertures = alloc_apertures(1);
>> >         if (!info->apertures) {
>> > -               framebuffer_release(info);
>> > -               return -ENOMEM;
>> > +               ret = -ENOMEM;
>> > +               goto error_fb_release;
>> >         }
>> >         info->apertures->ranges[0].base = info->fix.smem_start;
>> >         info->apertures->ranges[0].size = info->fix.smem_len;
>> > @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
>> >         info->screen_base = ioremap_wc(info->fix.smem_start,
>> >                                        info->fix.smem_len);
>> >         if (!info->screen_base) {
>> > -               framebuffer_release(info);
>> > -               return -ENODEV;
>> > +               ret = -ENODEV;
>> > +               goto error_fb_release;
>> >         }
>> >         info->pseudo_palette = (void *) par->palette;
>> >
>> > @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
>> >         ret = register_framebuffer(info);
>> >         if (ret < 0) {
>> >                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
>> > -               iounmap(info->screen_base);
>> > -               framebuffer_release(info);
>> > -               return ret;
>> > +               goto error_unmap;
>> >         }
>> >
>> >         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>> >
>> >         return 0;
>> > +
>> > + error_unmap:
>> > +       iounmap(info->screen_base);
>> > +
>> > + error_fb_release:
>> > +       framebuffer_release(info);
>> > +
>> > +       return ret;
>>
>> Again, I'd use different coding-style, but I will leave that to
>> Stephen and Tomi:
>>
>> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
>
> While the discussion about the last two patches rages on, can you state
> what coding style changes you would like to see here, as i am not clear
> as to what exactly is off with the above code.

I'd skip the leading whitespace and the newlines, like this:

+error_unmap:
+        iounmap(info->screen_base);
+error_fb_release:
+        framebuffer_release(info);
+        return ret;

at least that's my conception how we format error paths in drivers/video/.

Thanks
David

[PATCH 2/4] simplefb: add goto error path to probe

[David Herrmann]

Hi

On Thu, Aug 14, 2014 at 12:29 PM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 09:27:46AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> > Signed-off-by: Luc Verhaegen <libv@skynet.be>
>> > ---
>> >  drivers/video/fbdev/simplefb.c |   20 +++++++++++++-------
>> >  1 files changed, 13 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
>> > index 32be590..72a4f20 100644
>> > --- a/drivers/video/fbdev/simplefb.c
>> > +++ b/drivers/video/fbdev/simplefb.c
>> > @@ -220,8 +220,8 @@ static int simplefb_probe(struct platform_device *pdev)
>> >
>> >         info->apertures = alloc_apertures(1);
>> >         if (!info->apertures) {
>> > -               framebuffer_release(info);
>> > -               return -ENOMEM;
>> > +               ret = -ENOMEM;
>> > +               goto error_fb_release;
>> >         }
>> >         info->apertures->ranges[0].base = info->fix.smem_start;
>> >         info->apertures->ranges[0].size = info->fix.smem_len;
>> > @@ -231,8 +231,8 @@ static int simplefb_probe(struct platform_device *pdev)
>> >         info->screen_base = ioremap_wc(info->fix.smem_start,
>> >                                        info->fix.smem_len);
>> >         if (!info->screen_base) {
>> > -               framebuffer_release(info);
>> > -               return -ENODEV;
>> > +               ret = -ENODEV;
>> > +               goto error_fb_release;
>> >         }
>> >         info->pseudo_palette = (void *) par->palette;
>> >
>> > @@ -247,14 +247,20 @@ static int simplefb_probe(struct platform_device *pdev)
>> >         ret = register_framebuffer(info);
>> >         if (ret < 0) {
>> >                 dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
>> > -               iounmap(info->screen_base);
>> > -               framebuffer_release(info);
>> > -               return ret;
>> > +               goto error_unmap;
>> >         }
>> >
>> >         dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>> >
>> >         return 0;
>> > +
>> > + error_unmap:
>> > +       iounmap(info->screen_base);
>> > +
>> > + error_fb_release:
>> > +       framebuffer_release(info);
>> > +
>> > +       return ret;
>>
>> Again, I'd use different coding-style, but I will leave that to
>> Stephen and Tomi:
>>
>> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
>
> While the discussion about the last two patches rages on, can you state
> what coding style changes you would like to see here, as i am not clear
> as to what exactly is off with the above code.

I'd skip the leading whitespace and the newlines, like this:

+error_unmap:
+        iounmap(info->screen_base);
+error_fb_release:
+        framebuffer_release(info);
+        return ret;

at least that's my conception how we format error paths in drivers/video/.

Thanks
David

Re: [PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

On Thu, Aug 14, 2014 at 12:33:55PM +0200, David Herrmann wrote:
> Hi
> 
> I'd skip the leading whitespace and the newlines, like this:
> 
> +error_unmap:
> +        iounmap(info->screen_base);
> +error_fb_release:
> +        framebuffer_release(info);
> +        return ret;
> 
> at least that's my conception how we format error paths in drivers/video/.

Will do. Thanks.

Luc Verhaegen.

[PATCH 2/4] simplefb: add goto error path to probe

[Luc Verhaegen]

On Thu, Aug 14, 2014 at 12:33:55PM +0200, David Herrmann wrote:
> Hi
> 
> I'd skip the leading whitespace and the newlines, like this:
> 
> +error_unmap:
> +        iounmap(info->screen_base);
> +error_fb_release:
> +        framebuffer_release(info);
> +        return ret;
> 
> at least that's my conception how we format error paths in drivers/video/.

Will do. Thanks.

Luc Verhaegen.

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

The next commit will handle clocks correctly, so that these do not get
automatically disabled on certain SoC simplefb implementations. As a
result, the removal of this simplefb driver, and the release of the
clocks, is rather final, and only a full display driver can work after
this. So, it makes sense to also flag the dt node as disabled, even
though it has no real value today.

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   43 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 72a4f20..74c4b2a 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -138,6 +138,32 @@ static int simplefb_parse_dt(struct platform_device *pdev,
 	return 0;
 }
 
+/*
+ * Make sure that nothing tries to inadvertedly re-use this node...
+ */
+static int
+simplefb_dt_disable(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct property *property;
+	int ret;
+
+	property = kzalloc(sizeof(struct property), GFP_KERNEL);
+	if (!property)
+		return -ENOMEM;
+
+	property->name = "status";
+	property->value = "disabled";
+	property->length = strlen(property->value) + 1;
+
+	ret = of_update_property(np, property);
+	if (ret)
+		dev_err(&pdev->dev, "%s: failed to update property: %d\n",
+			__func__, ret);
+
+	return ret;
+}
+
 static int simplefb_parse_pd(struct platform_device *pdev,
 			     struct simplefb_params *params)
 {
@@ -187,17 +213,20 @@ static int simplefb_probe(struct platform_device *pdev)
 		ret = simplefb_parse_dt(pdev, &params);
 
 	if (ret)
-		return ret;
+		goto error_dt_disable;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!mem) {
 		dev_err(&pdev->dev, "No memory resource\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto error_dt_disable;
 	}
 
 	info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
-	if (!info)
-		return -ENOMEM;
+	if (!info) {
+		ret = -ENOMEM;
+		goto error_dt_disable;
+	}
 	platform_set_drvdata(pdev, info);
 
 	par = info->par;
@@ -260,6 +289,10 @@ static int simplefb_probe(struct platform_device *pdev)
  error_fb_release:
 	framebuffer_release(info);
 
+ error_dt_disable:
+	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
+		simplefb_dt_disable(pdev);
+
 	return ret;
 }
 
@@ -269,6 +302,8 @@ static int simplefb_remove(struct platform_device *pdev)
 
 	unregister_framebuffer(info);
 	framebuffer_release(info);
+	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
+		simplefb_dt_disable(pdev);
 
 	return 0;
 }
-- 
1.7.7

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

The next commit will handle clocks correctly, so that these do not get
automatically disabled on certain SoC simplefb implementations. As a
result, the removal of this simplefb driver, and the release of the
clocks, is rather final, and only a full display driver can work after
this. So, it makes sense to also flag the dt node as disabled, even
though it has no real value today.

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |   43 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 72a4f20..74c4b2a 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -138,6 +138,32 @@ static int simplefb_parse_dt(struct platform_device *pdev,
 	return 0;
 }
 
+/*
+ * Make sure that nothing tries to inadvertedly re-use this node...
+ */
+static int
+simplefb_dt_disable(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct property *property;
+	int ret;
+
+	property = kzalloc(sizeof(struct property), GFP_KERNEL);
+	if (!property)
+		return -ENOMEM;
+
+	property->name = "status";
+	property->value = "disabled";
+	property->length = strlen(property->value) + 1;
+
+	ret = of_update_property(np, property);
+	if (ret)
+		dev_err(&pdev->dev, "%s: failed to update property: %d\n",
+			__func__, ret);
+
+	return ret;
+}
+
 static int simplefb_parse_pd(struct platform_device *pdev,
 			     struct simplefb_params *params)
 {
@@ -187,17 +213,20 @@ static int simplefb_probe(struct platform_device *pdev)
 		ret = simplefb_parse_dt(pdev, &params);
 
 	if (ret)
-		return ret;
+		goto error_dt_disable;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!mem) {
 		dev_err(&pdev->dev, "No memory resource\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto error_dt_disable;
 	}
 
 	info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
-	if (!info)
-		return -ENOMEM;
+	if (!info) {
+		ret = -ENOMEM;
+		goto error_dt_disable;
+	}
 	platform_set_drvdata(pdev, info);
 
 	par = info->par;
@@ -260,6 +289,10 @@ static int simplefb_probe(struct platform_device *pdev)
  error_fb_release:
 	framebuffer_release(info);
 
+ error_dt_disable:
+	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
+		simplefb_dt_disable(pdev);
+
 	return ret;
 }
 
@@ -269,6 +302,8 @@ static int simplefb_remove(struct platform_device *pdev)
 
 	unregister_framebuffer(info);
 	framebuffer_release(info);
+	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
+		simplefb_dt_disable(pdev);
 
 	return 0;
 }
-- 
1.7.7

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> The next commit will handle clocks correctly, so that these do not get
> automatically disabled on certain SoC simplefb implementations. As a
> result, the removal of this simplefb driver, and the release of the
> clocks, is rather final, and only a full display driver can work after
> this. So, it makes sense to also flag the dt node as disabled, even
> though it has no real value today.
>
> Signed-off-by: Luc Verhaegen <libv@skynet.be>

Please, no.

Drivers should not be modifying the device tree without and
exceptionally good reason for doing so. Drivers are to treat the DT as
immutable.

* the exception is an overlay driver which add new devices to the
kernel. Definitely not the case here.

g.

> ---
>  drivers/video/fbdev/simplefb.c |   43 ++++++++++++++++++++++++++++++++++++---
>  1 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 72a4f20..74c4b2a 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -138,6 +138,32 @@ static int simplefb_parse_dt(struct platform_device *pdev,
>         return 0;
>  }
>
> +/*
> + * Make sure that nothing tries to inadvertedly re-use this node...
> + */
> +static int
> +simplefb_dt_disable(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       struct property *property;
> +       int ret;
> +
> +       property = kzalloc(sizeof(struct property), GFP_KERNEL);
> +       if (!property)
> +               return -ENOMEM;
> +
> +       property->name = "status";
> +       property->value = "disabled";
> +       property->length = strlen(property->value) + 1;
> +
> +       ret = of_update_property(np, property);
> +       if (ret)
> +               dev_err(&pdev->dev, "%s: failed to update property: %d\n",
> +                       __func__, ret);
> +
> +       return ret;
> +}
> +
>  static int simplefb_parse_pd(struct platform_device *pdev,
>                              struct simplefb_params *params)
>  {
> @@ -187,17 +213,20 @@ static int simplefb_probe(struct platform_device *pdev)
>                 ret = simplefb_parse_dt(pdev, &params);
>
>         if (ret)
> -               return ret;
> +               goto error_dt_disable;
>
>         mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         if (!mem) {
>                 dev_err(&pdev->dev, "No memory resource\n");
> -               return -EINVAL;
> +               ret = -EINVAL;
> +               goto error_dt_disable;
>         }
>
>         info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
> -       if (!info)
> -               return -ENOMEM;
> +       if (!info) {
> +               ret = -ENOMEM;
> +               goto error_dt_disable;
> +       }
>         platform_set_drvdata(pdev, info);
>
>         par = info->par;
> @@ -260,6 +289,10 @@ static int simplefb_probe(struct platform_device *pdev)
>   error_fb_release:
>         framebuffer_release(info);
>
> + error_dt_disable:
> +       if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
> +               simplefb_dt_disable(pdev);
> +
>         return ret;
>  }
>
> @@ -269,6 +302,8 @@ static int simplefb_remove(struct platform_device *pdev)
>
>         unregister_framebuffer(info);
>         framebuffer_release(info);
> +       if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
> +               simplefb_dt_disable(pdev);
>
>         return 0;
>  }
> --
> 1.7.7
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> The next commit will handle clocks correctly, so that these do not get
> automatically disabled on certain SoC simplefb implementations. As a
> result, the removal of this simplefb driver, and the release of the
> clocks, is rather final, and only a full display driver can work after
> this. So, it makes sense to also flag the dt node as disabled, even
> though it has no real value today.
>
> Signed-off-by: Luc Verhaegen <libv@skynet.be>

Please, no.

Drivers should not be modifying the device tree without and
exceptionally good reason for doing so. Drivers are to treat the DT as
immutable.

* the exception is an overlay driver which add new devices to the
kernel. Definitely not the case here.

g.

> ---
>  drivers/video/fbdev/simplefb.c |   43 ++++++++++++++++++++++++++++++++++++---
>  1 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 72a4f20..74c4b2a 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -138,6 +138,32 @@ static int simplefb_parse_dt(struct platform_device *pdev,
>         return 0;
>  }
>
> +/*
> + * Make sure that nothing tries to inadvertedly re-use this node...
> + */
> +static int
> +simplefb_dt_disable(struct platform_device *pdev)
> +{
> +       struct device_node *np = pdev->dev.of_node;
> +       struct property *property;
> +       int ret;
> +
> +       property = kzalloc(sizeof(struct property), GFP_KERNEL);
> +       if (!property)
> +               return -ENOMEM;
> +
> +       property->name = "status";
> +       property->value = "disabled";
> +       property->length = strlen(property->value) + 1;
> +
> +       ret = of_update_property(np, property);
> +       if (ret)
> +               dev_err(&pdev->dev, "%s: failed to update property: %d\n",
> +                       __func__, ret);
> +
> +       return ret;
> +}
> +
>  static int simplefb_parse_pd(struct platform_device *pdev,
>                              struct simplefb_params *params)
>  {
> @@ -187,17 +213,20 @@ static int simplefb_probe(struct platform_device *pdev)
>                 ret = simplefb_parse_dt(pdev, &params);
>
>         if (ret)
> -               return ret;
> +               goto error_dt_disable;
>
>         mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         if (!mem) {
>                 dev_err(&pdev->dev, "No memory resource\n");
> -               return -EINVAL;
> +               ret = -EINVAL;
> +               goto error_dt_disable;
>         }
>
>         info = framebuffer_alloc(sizeof(struct simplefb_par), &pdev->dev);
> -       if (!info)
> -               return -ENOMEM;
> +       if (!info) {
> +               ret = -ENOMEM;
> +               goto error_dt_disable;
> +       }
>         platform_set_drvdata(pdev, info);
>
>         par = info->par;
> @@ -260,6 +289,10 @@ static int simplefb_probe(struct platform_device *pdev)
>   error_fb_release:
>         framebuffer_release(info);
>
> + error_dt_disable:
> +       if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
> +               simplefb_dt_disable(pdev);
> +
>         return ret;
>  }
>
> @@ -269,6 +302,8 @@ static int simplefb_remove(struct platform_device *pdev)
>
>         unregister_framebuffer(info);
>         framebuffer_release(info);
> +       if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
> +               simplefb_dt_disable(pdev);
>
>         return 0;
>  }
> --
> 1.7.7
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> The next commit will handle clocks correctly, so that these do not get
>> automatically disabled on certain SoC simplefb implementations. As a
>> result, the removal of this simplefb driver, and the release of the
>> clocks, is rather final, and only a full display driver can work after
>> this. So, it makes sense to also flag the dt node as disabled, even
>> though it has no real value today.
>>
>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>
> Please, no.
>
> Drivers should not be modifying the device tree without and
> exceptionally good reason for doing so. Drivers are to treat the DT as
> immutable.
>
> * the exception is an overlay driver which add new devices to the
> kernel. Definitely not the case here.

Why? I think we have exactly that case:
 * DT describes the real hw properly and those parts are immutable
 * Additionally, bootloaders create firmware-framebuffers and
   create simple-framebuffer devices for them. Those are
   valid as long as no driver reconfigured the real hw.
 * Once a real hw-driver loads, it might destroy the existing
   framebuffers, thus, it should also destroy the platform device.
 * If the real hw-driver is unloaded, it might re-create the FB
   and thus create a new (or enable the old) platform device.

Or, in a nutshell: A "simple-framebuffer" device is basically a
platform-device for framebuffers. Framebuffers can be created and
destroyed during runtime. The reason we create platform-devices for
them, is to allow dummy drivers to be probed. Real hw-drivers
obviously bind to the parent bus device.

Other ideas are obviously welcome, but so far all of the other ideas
sounded like big hacks (like remove_conflicting_framebuffers() so
far..).

Thanks
David

[PATCH 3/4] simplefb: disable dt node upon remove

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> The next commit will handle clocks correctly, so that these do not get
>> automatically disabled on certain SoC simplefb implementations. As a
>> result, the removal of this simplefb driver, and the release of the
>> clocks, is rather final, and only a full display driver can work after
>> this. So, it makes sense to also flag the dt node as disabled, even
>> though it has no real value today.
>>
>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>
> Please, no.
>
> Drivers should not be modifying the device tree without and
> exceptionally good reason for doing so. Drivers are to treat the DT as
> immutable.
>
> * the exception is an overlay driver which add new devices to the
> kernel. Definitely not the case here.

Why? I think we have exactly that case:
 * DT describes the real hw properly and those parts are immutable
 * Additionally, bootloaders create firmware-framebuffers and
   create simple-framebuffer devices for them. Those are
   valid as long as no driver reconfigured the real hw.
 * Once a real hw-driver loads, it might destroy the existing
   framebuffers, thus, it should also destroy the platform device.
 * If the real hw-driver is unloaded, it might re-create the FB
   and thus create a new (or enable the old) platform device.

Or, in a nutshell: A "simple-framebuffer" device is basically a
platform-device for framebuffers. Framebuffers can be created and
destroyed during runtime. The reason we create platform-devices for
them, is to allow dummy drivers to be probed. Real hw-drivers
obviously bind to the parent bus device.

Other ideas are obviously welcome, but so far all of the other ideas
sounded like big hacks (like remove_conflicting_framebuffers() so
far..).

Thanks
David

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> The next commit will handle clocks correctly, so that these do not get
>>> automatically disabled on certain SoC simplefb implementations. As a
>>> result, the removal of this simplefb driver, and the release of the
>>> clocks, is rather final, and only a full display driver can work after
>>> this. So, it makes sense to also flag the dt node as disabled, even
>>> though it has no real value today.
>>>
>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>
>> Please, no.
>>
>> Drivers should not be modifying the device tree without and
>> exceptionally good reason for doing so. Drivers are to treat the DT as
>> immutable.
>>
>> * the exception is an overlay driver which add new devices to the
>> kernel. Definitely not the case here.
>
> Why?

The majority of the DT code is based on the assumption of a static
tree. Pantelis has been working on being able to modify it at runtime
with overlays, but he has had to go through a lot of rework because it
is not a trivial task. When you get into modifying the DT, you need to
have a lot more understanding of the side effects to changing the
tree. The DT structure also has a lifecycle that can go beyond the
current lifecycle of the kernel. The kexec tool will extract the
current tree from the kernel, make the appropriate modifications, and
use that to boot the next kernel. Allowing any driver to modify the
tree has side effects beyond just the current kernel.

In this specific case, it will interact badly with the work Pantelis
is doing to make platform devices work with overlays. Modifying the
status property will cause the associated struct device to get removed
in the middle of probing a driver for that device! That will most
likely cause an oops.

Besides, Luc straight out *said*: "...even though it has no real value
today". In what circumstance is that justification for modifying the
tree?

> I think we have exactly that case:
>  * DT describes the real hw properly and those parts are immutable
>  * Additionally, bootloaders create firmware-framebuffers and
>    create simple-framebuffer devices for them. Those are
>    valid as long as no driver reconfigured the real hw.
>  * Once a real hw-driver loads, it might destroy the existing
>    framebuffers, thus, it should also destroy the platform device.
>  * If the real hw-driver is unloaded, it might re-create the FB
>    and thus create a new (or enable the old) platform device.
>
> Or, in a nutshell: A "simple-framebuffer" device is basically a
> platform-device for framebuffers. Framebuffers can be created and
> destroyed during runtime. The reason we create platform-devices for
> them, is to allow dummy drivers to be probed. Real hw-drivers
> obviously bind to the parent bus device.
>
> Other ideas are obviously welcome, but so far all of the other ideas
> sounded like big hacks (like remove_conflicting_framebuffers() so
> far..).
>
> Thanks
> David

[PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> The next commit will handle clocks correctly, so that these do not get
>>> automatically disabled on certain SoC simplefb implementations. As a
>>> result, the removal of this simplefb driver, and the release of the
>>> clocks, is rather final, and only a full display driver can work after
>>> this. So, it makes sense to also flag the dt node as disabled, even
>>> though it has no real value today.
>>>
>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>
>> Please, no.
>>
>> Drivers should not be modifying the device tree without and
>> exceptionally good reason for doing so. Drivers are to treat the DT as
>> immutable.
>>
>> * the exception is an overlay driver which add new devices to the
>> kernel. Definitely not the case here.
>
> Why?

The majority of the DT code is based on the assumption of a static
tree. Pantelis has been working on being able to modify it at runtime
with overlays, but he has had to go through a lot of rework because it
is not a trivial task. When you get into modifying the DT, you need to
have a lot more understanding of the side effects to changing the
tree. The DT structure also has a lifecycle that can go beyond the
current lifecycle of the kernel. The kexec tool will extract the
current tree from the kernel, make the appropriate modifications, and
use that to boot the next kernel. Allowing any driver to modify the
tree has side effects beyond just the current kernel.

In this specific case, it will interact badly with the work Pantelis
is doing to make platform devices work with overlays. Modifying the
status property will cause the associated struct device to get removed
in the middle of probing a driver for that device! That will most
likely cause an oops.

Besides, Luc straight out *said*: "...even though it has no real value
today". In what circumstance is that justification for modifying the
tree?

> I think we have exactly that case:
>  * DT describes the real hw properly and those parts are immutable
>  * Additionally, bootloaders create firmware-framebuffers and
>    create simple-framebuffer devices for them. Those are
>    valid as long as no driver reconfigured the real hw.
>  * Once a real hw-driver loads, it might destroy the existing
>    framebuffers, thus, it should also destroy the platform device.
>  * If the real hw-driver is unloaded, it might re-create the FB
>    and thus create a new (or enable the old) platform device.
>
> Or, in a nutshell: A "simple-framebuffer" device is basically a
> platform-device for framebuffers. Framebuffers can be created and
> destroyed during runtime. The reason we create platform-devices for
> them, is to allow dummy drivers to be probed. Real hw-drivers
> obviously bind to the parent bus device.
>
> Other ideas are obviously welcome, but so far all of the other ideas
> sounded like big hacks (like remove_conflicting_framebuffers() so
> far..).
>
> Thanks
> David

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 11:23 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> * the exception is an overlay driver which add new devices to the
>>> kernel. Definitely not the case here.
>>
>> Why?
>
> The majority of the DT code is based on the assumption of a static
> tree. Pantelis has been working on being able to modify it at runtime
> with overlays, but he has had to go through a lot of rework because it
> is not a trivial task. When you get into modifying the DT, you need to
> have a lot more understanding of the side effects to changing the
> tree. The DT structure also has a lifecycle that can go beyond the
> current lifecycle of the kernel. The kexec tool will extract the
> current tree from the kernel, make the appropriate modifications, and
> use that to boot the next kernel. Allowing any driver to modify the
> tree has side effects beyond just the current kernel.

Ok, fair enough. So we leave the DT untouched. That still allows
calling device_add() / device_del() on platform-devices, right?

> In this specific case, it will interact badly with the work Pantelis
> is doing to make platform devices work with overlays. Modifying the
> status property will cause the associated struct device to get removed
> in the middle of probing a driver for that device! That will most
> likely cause an oops.
>
> Besides, Luc straight out *said*: "...even though it has no real value
> today". In what circumstance is that justification for modifying the
> tree?

Sorry, I wasn't clear enough: I'm not arguing in favor of this patch.
I just want to figure out what to do once we implement
hardware-handover for graphics devices on non-x86 (which this series
is kinda preparing for). This patch just reminded me, that we could do
this on a DT level, instead of driver-core level. But I'm fine with
avoiding that, if you warn about complications.

Thanks
David

[PATCH 3/4] simplefb: disable dt node upon remove

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 11:23 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> * the exception is an overlay driver which add new devices to the
>>> kernel. Definitely not the case here.
>>
>> Why?
>
> The majority of the DT code is based on the assumption of a static
> tree. Pantelis has been working on being able to modify it at runtime
> with overlays, but he has had to go through a lot of rework because it
> is not a trivial task. When you get into modifying the DT, you need to
> have a lot more understanding of the side effects to changing the
> tree. The DT structure also has a lifecycle that can go beyond the
> current lifecycle of the kernel. The kexec tool will extract the
> current tree from the kernel, make the appropriate modifications, and
> use that to boot the next kernel. Allowing any driver to modify the
> tree has side effects beyond just the current kernel.

Ok, fair enough. So we leave the DT untouched. That still allows
calling device_add() / device_del() on platform-devices, right?

> In this specific case, it will interact badly with the work Pantelis
> is doing to make platform devices work with overlays. Modifying the
> status property will cause the associated struct device to get removed
> in the middle of probing a driver for that device! That will most
> likely cause an oops.
>
> Besides, Luc straight out *said*: "...even though it has no real value
> today". In what circumstance is that justification for modifying the
> tree?

Sorry, I wasn't clear enough: I'm not arguing in favor of this patch.
I just want to figure out what to do once we implement
hardware-handover for graphics devices on non-x86 (which this series
is kinda preparing for). This patch just reminded me, that we could do
this on a DT level, instead of driver-core level. But I'm fine with
avoiding that, if you warn about complications.

Thanks
David

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
> 
> The majority of the DT code is based on the assumption of a static
> tree. Pantelis has been working on being able to modify it at runtime
> with overlays, but he has had to go through a lot of rework because it
> is not a trivial task. When you get into modifying the DT, you need to
> have a lot more understanding of the side effects to changing the
> tree. The DT structure also has a lifecycle that can go beyond the
> current lifecycle of the kernel. The kexec tool will extract the
> current tree from the kernel, make the appropriate modifications, and
> use that to boot the next kernel. Allowing any driver to modify the
> tree has side effects beyond just the current kernel.
> 
> In this specific case, it will interact badly with the work Pantelis
> is doing to make platform devices work with overlays. Modifying the
> status property will cause the associated struct device to get removed
> in the middle of probing a driver for that device! That will most
> likely cause an oops.
> 
> Besides, Luc straight out *said*: "...even though it has no real value
> today". In what circumstance is that justification for modifying the
> tree?

With that sentence i meant that given the current state of things, it 
has no real value.

It has no value currently as re-probing simplefb is not going to happen. 
But it's not a big leap to turn simplefb into a proper module. Not that 
that makes much sense, but that's never stopped anyone.

To me it seemed simple, dt is what drives simplefb, so dt then also 
becomes responsible for making sure that simplefb or another driver does 
not attempt to blindly use this info again. The way this is implemented 
i do not care for in any way, i just knew that i could not do nothing 
here, given the catastrophic effect disabling the clocks has on simplefb 
on sunxi. Given the discussion that errupted here, i'd say that this 
does need some resolution, and altering the dt is going to have to be 
part of the solution.

In any case, i will gladly drop this patch, as it is not absolutely 
necessary. But it should be very clear that there is no going back on 
this dt node after the clocks were released once.

Luc Verhaegen.

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
> 
> The majority of the DT code is based on the assumption of a static
> tree. Pantelis has been working on being able to modify it at runtime
> with overlays, but he has had to go through a lot of rework because it
> is not a trivial task. When you get into modifying the DT, you need to
> have a lot more understanding of the side effects to changing the
> tree. The DT structure also has a lifecycle that can go beyond the
> current lifecycle of the kernel. The kexec tool will extract the
> current tree from the kernel, make the appropriate modifications, and
> use that to boot the next kernel. Allowing any driver to modify the
> tree has side effects beyond just the current kernel.
> 
> In this specific case, it will interact badly with the work Pantelis
> is doing to make platform devices work with overlays. Modifying the
> status property will cause the associated struct device to get removed
> in the middle of probing a driver for that device! That will most
> likely cause an oops.
> 
> Besides, Luc straight out *said*: "...even though it has no real value
> today". In what circumstance is that justification for modifying the
> tree?

With that sentence i meant that given the current state of things, it 
has no real value.

It has no value currently as re-probing simplefb is not going to happen. 
But it's not a big leap to turn simplefb into a proper module. Not that 
that makes much sense, but that's never stopped anyone.

To me it seemed simple, dt is what drives simplefb, so dt then also 
becomes responsible for making sure that simplefb or another driver does 
not attempt to blindly use this info again. The way this is implemented 
i do not care for in any way, i just knew that i could not do nothing 
here, given the catastrophic effect disabling the clocks has on simplefb 
on sunxi. Given the discussion that errupted here, i'd say that this 
does need some resolution, and altering the dt is going to have to be 
part of the solution.

In any case, i will gladly drop this patch, as it is not absolutely 
necessary. But it should be very clear that there is no going back on 
this dt node after the clocks were released once.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
> > 
> > The majority of the DT code is based on the assumption of a static
> > tree. Pantelis has been working on being able to modify it at runtime
> > with overlays, but he has had to go through a lot of rework because it
> > is not a trivial task. When you get into modifying the DT, you need to
> > have a lot more understanding of the side effects to changing the
> > tree. The DT structure also has a lifecycle that can go beyond the
> > current lifecycle of the kernel. The kexec tool will extract the
> > current tree from the kernel, make the appropriate modifications, and
> > use that to boot the next kernel. Allowing any driver to modify the
> > tree has side effects beyond just the current kernel.
> > 
> > In this specific case, it will interact badly with the work Pantelis
> > is doing to make platform devices work with overlays. Modifying the
> > status property will cause the associated struct device to get removed
> > in the middle of probing a driver for that device! That will most
> > likely cause an oops.
> > 
> > Besides, Luc straight out *said*: "...even though it has no real value
> > today". In what circumstance is that justification for modifying the
> > tree?
> 
> With that sentence i meant that given the current state of things, it 
> has no real value.
> 
> It has no value currently as re-probing simplefb is not going to happen. 
> But it's not a big leap to turn simplefb into a proper module. Not that 
> that makes much sense, but that's never stopped anyone.
> 
> To me it seemed simple, dt is what drives simplefb, so dt then also 
> becomes responsible for making sure that simplefb or another driver does 
> not attempt to blindly use this info again. The way this is implemented 
> i do not care for in any way, i just knew that i could not do nothing 
> here, given the catastrophic effect disabling the clocks has on simplefb 
> on sunxi. Given the discussion that errupted here, i'd say that this 
> does need some resolution, and altering the dt is going to have to be 
> part of the solution.
> 
> In any case, i will gladly drop this patch, as it is not absolutely 
> necessary. But it should be very clear that there is no going back on 
> this dt node after the clocks were released once.
> 
> Luc Verhaegen.

What about approaching this from the other end? U-Boot could add a 
property named "once-only" or so.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
> > 
> > The majority of the DT code is based on the assumption of a static
> > tree. Pantelis has been working on being able to modify it at runtime
> > with overlays, but he has had to go through a lot of rework because it
> > is not a trivial task. When you get into modifying the DT, you need to
> > have a lot more understanding of the side effects to changing the
> > tree. The DT structure also has a lifecycle that can go beyond the
> > current lifecycle of the kernel. The kexec tool will extract the
> > current tree from the kernel, make the appropriate modifications, and
> > use that to boot the next kernel. Allowing any driver to modify the
> > tree has side effects beyond just the current kernel.
> > 
> > In this specific case, it will interact badly with the work Pantelis
> > is doing to make platform devices work with overlays. Modifying the
> > status property will cause the associated struct device to get removed
> > in the middle of probing a driver for that device! That will most
> > likely cause an oops.
> > 
> > Besides, Luc straight out *said*: "...even though it has no real value
> > today". In what circumstance is that justification for modifying the
> > tree?
> 
> With that sentence i meant that given the current state of things, it 
> has no real value.
> 
> It has no value currently as re-probing simplefb is not going to happen. 
> But it's not a big leap to turn simplefb into a proper module. Not that 
> that makes much sense, but that's never stopped anyone.
> 
> To me it seemed simple, dt is what drives simplefb, so dt then also 
> becomes responsible for making sure that simplefb or another driver does 
> not attempt to blindly use this info again. The way this is implemented 
> i do not care for in any way, i just knew that i could not do nothing 
> here, given the catastrophic effect disabling the clocks has on simplefb 
> on sunxi. Given the discussion that errupted here, i'd say that this 
> does need some resolution, and altering the dt is going to have to be 
> part of the solution.
> 
> In any case, i will gladly drop this patch, as it is not absolutely 
> necessary. But it should be very clear that there is no going back on 
> this dt node after the clocks were released once.
> 
> Luc Verhaegen.

What about approaching this from the other end? U-Boot could add a 
property named "once-only" or so.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>> >
>> > The majority of the DT code is based on the assumption of a static
>> > tree. Pantelis has been working on being able to modify it at runtime
>> > with overlays, but he has had to go through a lot of rework because it
>> > is not a trivial task. When you get into modifying the DT, you need to
>> > have a lot more understanding of the side effects to changing the
>> > tree. The DT structure also has a lifecycle that can go beyond the
>> > current lifecycle of the kernel. The kexec tool will extract the
>> > current tree from the kernel, make the appropriate modifications, and
>> > use that to boot the next kernel. Allowing any driver to modify the
>> > tree has side effects beyond just the current kernel.
>> >
>> > In this specific case, it will interact badly with the work Pantelis
>> > is doing to make platform devices work with overlays. Modifying the
>> > status property will cause the associated struct device to get removed
>> > in the middle of probing a driver for that device! That will most
>> > likely cause an oops.
>> >
>> > Besides, Luc straight out *said*: "...even though it has no real value
>> > today". In what circumstance is that justification for modifying the
>> > tree?
>>
>> With that sentence i meant that given the current state of things, it
>> has no real value.
>>
>> It has no value currently as re-probing simplefb is not going to happen.
>> But it's not a big leap to turn simplefb into a proper module. Not that
>> that makes much sense, but that's never stopped anyone.
>>
>> To me it seemed simple, dt is what drives simplefb, so dt then also
>> becomes responsible for making sure that simplefb or another driver does
>> not attempt to blindly use this info again. The way this is implemented
>> i do not care for in any way, i just knew that i could not do nothing
>> here, given the catastrophic effect disabling the clocks has on simplefb
>> on sunxi. Given the discussion that errupted here, i'd say that this
>> does need some resolution, and altering the dt is going to have to be
>> part of the solution.
>>
>> In any case, i will gladly drop this patch, as it is not absolutely
>> necessary. But it should be very clear that there is no going back on
>> this dt node after the clocks were released once.
>>
>> Luc Verhaegen.
>
> What about approaching this from the other end? U-Boot could add a
> property named "once-only" or so.

Device tree is supposed to be a static description of the hardware
usable on all operating systems. It is the wrong mechanism for
communicating between uboot and the kernel. Use something like atags
or the kernel command line to tell the kernel that the console has
already been set up.

The switch over from simple to KMS should not be done via a node
add/del to the device tree either.  No one has removed the device from
the system, the device tree should not be changing.

Some Linux mechanism inside the kernel needs to handle that
transition. Somehow simple needs to hang onto the clocks, let go of
the device, load KMS, then exit?



>
> Luc Verhaegen.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>> >
>> > The majority of the DT code is based on the assumption of a static
>> > tree. Pantelis has been working on being able to modify it at runtime
>> > with overlays, but he has had to go through a lot of rework because it
>> > is not a trivial task. When you get into modifying the DT, you need to
>> > have a lot more understanding of the side effects to changing the
>> > tree. The DT structure also has a lifecycle that can go beyond the
>> > current lifecycle of the kernel. The kexec tool will extract the
>> > current tree from the kernel, make the appropriate modifications, and
>> > use that to boot the next kernel. Allowing any driver to modify the
>> > tree has side effects beyond just the current kernel.
>> >
>> > In this specific case, it will interact badly with the work Pantelis
>> > is doing to make platform devices work with overlays. Modifying the
>> > status property will cause the associated struct device to get removed
>> > in the middle of probing a driver for that device! That will most
>> > likely cause an oops.
>> >
>> > Besides, Luc straight out *said*: "...even though it has no real value
>> > today". In what circumstance is that justification for modifying the
>> > tree?
>>
>> With that sentence i meant that given the current state of things, it
>> has no real value.
>>
>> It has no value currently as re-probing simplefb is not going to happen.
>> But it's not a big leap to turn simplefb into a proper module. Not that
>> that makes much sense, but that's never stopped anyone.
>>
>> To me it seemed simple, dt is what drives simplefb, so dt then also
>> becomes responsible for making sure that simplefb or another driver does
>> not attempt to blindly use this info again. The way this is implemented
>> i do not care for in any way, i just knew that i could not do nothing
>> here, given the catastrophic effect disabling the clocks has on simplefb
>> on sunxi. Given the discussion that errupted here, i'd say that this
>> does need some resolution, and altering the dt is going to have to be
>> part of the solution.
>>
>> In any case, i will gladly drop this patch, as it is not absolutely
>> necessary. But it should be very clear that there is no going back on
>> this dt node after the clocks were released once.
>>
>> Luc Verhaegen.
>
> What about approaching this from the other end? U-Boot could add a
> property named "once-only" or so.

Device tree is supposed to be a static description of the hardware
usable on all operating systems. It is the wrong mechanism for
communicating between uboot and the kernel. Use something like atags
or the kernel command line to tell the kernel that the console has
already been set up.

The switch over from simple to KMS should not be done via a node
add/del to the device tree either.  No one has removed the device from
the system, the device tree should not be changing.

Some Linux mechanism inside the kernel needs to handle that
transition. Somehow simple needs to hang onto the clocks, let go of
the device, load KMS, then exit?



>
> Luc Verhaegen.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>> >
>>> > The majority of the DT code is based on the assumption of a static
>>> > tree. Pantelis has been working on being able to modify it at runtime
>>> > with overlays, but he has had to go through a lot of rework because it
>>> > is not a trivial task. When you get into modifying the DT, you need to
>>> > have a lot more understanding of the side effects to changing the
>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>> > current lifecycle of the kernel. The kexec tool will extract the
>>> > current tree from the kernel, make the appropriate modifications, and
>>> > use that to boot the next kernel. Allowing any driver to modify the
>>> > tree has side effects beyond just the current kernel.
>>> >
>>> > In this specific case, it will interact badly with the work Pantelis
>>> > is doing to make platform devices work with overlays. Modifying the
>>> > status property will cause the associated struct device to get removed
>>> > in the middle of probing a driver for that device! That will most
>>> > likely cause an oops.
>>> >
>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>> > today". In what circumstance is that justification for modifying the
>>> > tree?
>>>
>>> With that sentence i meant that given the current state of things, it
>>> has no real value.
>>>
>>> It has no value currently as re-probing simplefb is not going to happen.
>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>> that makes much sense, but that's never stopped anyone.
>>>
>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>> becomes responsible for making sure that simplefb or another driver does
>>> not attempt to blindly use this info again. The way this is implemented
>>> i do not care for in any way, i just knew that i could not do nothing
>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>> does need some resolution, and altering the dt is going to have to be
>>> part of the solution.
>>>
>>> In any case, i will gladly drop this patch, as it is not absolutely
>>> necessary. But it should be very clear that there is no going back on
>>> this dt node after the clocks were released once.
>>>
>>> Luc Verhaegen.
>>
>> What about approaching this from the other end? U-Boot could add a
>> property named "once-only" or so.
>
> Device tree is supposed to be a static description of the hardware
> usable on all operating systems. It is the wrong mechanism for
> communicating between uboot and the kernel. Use something like atags
> or the kernel command line to tell the kernel that the console has
> already been set up.

Not accurate. While it is primarily hardware description, it is also
used for firmware communication. There is loads of precedence for
this. The /chosen node is the most significant example, but there are
other places where the tree is used to provide state. For example, the
current-speed property on UART nodes.

> The switch over from simple to KMS should not be done via a node
> add/del to the device tree either.  No one has removed the device from
> the system, the device tree should not be changing.

The simple-framebuffer binding appears to be insufficient in this
regard in that it doesn't have any linkage with the actual device
providing the framebuffer. Ideally, I would put the simple framebuffer
state directly into the video device node and use the chosen node to
point to the stdout device (probably with the stdout-path property).
Then the driver already knows it can just ignore the simple properties
because it owns the device node when it binds.

That said, simple-framebuffer as it stands is in use so we're not
going to deprecate it. I would like to see an addition that specifies
how a controller can be associated with a simple framebuffer node.

BTW, Is anyone currently using the simple framebuffer for early
console? For early console we would want to start using it well before
setting up platform devices.

g.

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>> >
>>> > The majority of the DT code is based on the assumption of a static
>>> > tree. Pantelis has been working on being able to modify it at runtime
>>> > with overlays, but he has had to go through a lot of rework because it
>>> > is not a trivial task. When you get into modifying the DT, you need to
>>> > have a lot more understanding of the side effects to changing the
>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>> > current lifecycle of the kernel. The kexec tool will extract the
>>> > current tree from the kernel, make the appropriate modifications, and
>>> > use that to boot the next kernel. Allowing any driver to modify the
>>> > tree has side effects beyond just the current kernel.
>>> >
>>> > In this specific case, it will interact badly with the work Pantelis
>>> > is doing to make platform devices work with overlays. Modifying the
>>> > status property will cause the associated struct device to get removed
>>> > in the middle of probing a driver for that device! That will most
>>> > likely cause an oops.
>>> >
>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>> > today". In what circumstance is that justification for modifying the
>>> > tree?
>>>
>>> With that sentence i meant that given the current state of things, it
>>> has no real value.
>>>
>>> It has no value currently as re-probing simplefb is not going to happen.
>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>> that makes much sense, but that's never stopped anyone.
>>>
>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>> becomes responsible for making sure that simplefb or another driver does
>>> not attempt to blindly use this info again. The way this is implemented
>>> i do not care for in any way, i just knew that i could not do nothing
>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>> does need some resolution, and altering the dt is going to have to be
>>> part of the solution.
>>>
>>> In any case, i will gladly drop this patch, as it is not absolutely
>>> necessary. But it should be very clear that there is no going back on
>>> this dt node after the clocks were released once.
>>>
>>> Luc Verhaegen.
>>
>> What about approaching this from the other end? U-Boot could add a
>> property named "once-only" or so.
>
> Device tree is supposed to be a static description of the hardware
> usable on all operating systems. It is the wrong mechanism for
> communicating between uboot and the kernel. Use something like atags
> or the kernel command line to tell the kernel that the console has
> already been set up.

Not accurate. While it is primarily hardware description, it is also
used for firmware communication. There is loads of precedence for
this. The /chosen node is the most significant example, but there are
other places where the tree is used to provide state. For example, the
current-speed property on UART nodes.

> The switch over from simple to KMS should not be done via a node
> add/del to the device tree either.  No one has removed the device from
> the system, the device tree should not be changing.

The simple-framebuffer binding appears to be insufficient in this
regard in that it doesn't have any linkage with the actual device
providing the framebuffer. Ideally, I would put the simple framebuffer
state directly into the video device node and use the chosen node to
point to the stdout device (probably with the stdout-path property).
Then the driver already knows it can just ignore the simple properties
because it owns the device node when it binds.

That said, simple-framebuffer as it stands is in use so we're not
going to deprecate it. I would like to see an addition that specifies
how a controller can be associated with a simple framebuffer node.

BTW, Is anyone currently using the simple framebuffer for early
console? For early console we would want to start using it well before
setting up platform devices.

g.

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
> 
> BTW, Is anyone currently using the simple framebuffer for early
> console? For early console we would want to start using it well before
> setting up platform devices.

The code that sets up simplefb for sunxi is primarily for providing a 
console in u-boot (using the ancient cfbconsole infrastructure). From 
what i can tell, the u-boot code for rpi is about showing a splash 
screen (using the much newer lcd infrastructure).

With u-boot showing a console, it really seemed only a small step to add 
simplefb. And quite a few people in our sunxi community are interested 
in it, primarily for u-boot and early console, and only secondarily as a 
stop-gap for a full driver.

Luc Verhaegen.

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
> 
> BTW, Is anyone currently using the simple framebuffer for early
> console? For early console we would want to start using it well before
> setting up platform devices.

The code that sets up simplefb for sunxi is primarily for providing a 
console in u-boot (using the ancient cfbconsole infrastructure). From 
what i can tell, the u-boot code for rpi is about showing a splash 
screen (using the much newer lcd infrastructure).

With u-boot showing a console, it really seemed only a small step to add 
simplefb. And quite a few people in our sunxi community are interested 
in it, primarily for u-boot and early console, and only secondarily as a 
stop-gap for a full driver.

Luc Verhaegen.

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 01:25 PM, Luc Verhaegen wrote:
> On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
>>
>> BTW, Is anyone currently using the simple framebuffer for early
>> console? For early console we would want to start using it well before
>> setting up platform devices.
>
> The code that sets up simplefb for sunxi is primarily for providing a
> console in u-boot (using the ancient cfbconsole infrastructure). From
> what i can tell, the u-boot code for rpi is about showing a splash
> screen (using the much newer lcd infrastructure).

There's no splash screen on the Pi in the upstream U-Boot code. The LCD 
displays the U-Boot console/stdout. If USB support for the Pi's USB host 
is ever sent upstream, that will allow the user to use USB/LCD for 
U-Boot control, rather than serial.

[PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 01:25 PM, Luc Verhaegen wrote:
> On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
>>
>> BTW, Is anyone currently using the simple framebuffer for early
>> console? For early console we would want to start using it well before
>> setting up platform devices.
>
> The code that sets up simplefb for sunxi is primarily for providing a
> console in u-boot (using the ancient cfbconsole infrastructure). From
> what i can tell, the u-boot code for rpi is about showing a splash
> screen (using the much newer lcd infrastructure).

There's no splash screen on the Pi in the upstream U-Boot code. The LCD 
displays the U-Boot console/stdout. If USB support for the Pi's USB host 
is ever sent upstream, that will allow the user to use USB/LCD for 
U-Boot control, rather than serial.

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 01:58:36PM -0600, Stephen Warren wrote:
> On 08/13/2014 01:25 PM, Luc Verhaegen wrote:
>>
>> The code that sets up simplefb for sunxi is primarily for providing a
>> console in u-boot (using the ancient cfbconsole infrastructure). From
>> what i can tell, the u-boot code for rpi is about showing a splash
>> screen (using the much newer lcd infrastructure).
>
> There's no splash screen on the Pi in the upstream U-Boot code. The LCD  
> displays the U-Boot console/stdout. If USB support for the Pi's USB host  
> is ever sent upstream, that will allow the user to use USB/LCD for  
> U-Boot control, rather than serial.

Ah ok, i hadn't immediately found a tie with the lcd code and cfbconsole 
code, so apparently i didn't dig down far enough.

Luc Verhaegen.

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 01:58:36PM -0600, Stephen Warren wrote:
> On 08/13/2014 01:25 PM, Luc Verhaegen wrote:
>>
>> The code that sets up simplefb for sunxi is primarily for providing a
>> console in u-boot (using the ancient cfbconsole infrastructure). From
>> what i can tell, the u-boot code for rpi is about showing a splash
>> screen (using the much newer lcd infrastructure).
>
> There's no splash screen on the Pi in the upstream U-Boot code. The LCD  
> displays the U-Boot console/stdout. If USB support for the Pi's USB host  
> is ever sent upstream, that will allow the user to use USB/LCD for  
> U-Boot control, rather than serial.

Ah ok, i hadn't immediately found a tie with the lcd code and cfbconsole 
code, so apparently i didn't dig down far enough.

Luc Verhaegen.

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 8:25 PM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
>>
>> BTW, Is anyone currently using the simple framebuffer for early
>> console? For early console we would want to start using it well before
>> setting up platform devices.
>
> The code that sets up simplefb for sunxi is primarily for providing a
> console in u-boot (using the ancient cfbconsole infrastructure). From
> what i can tell, the u-boot code for rpi is about showing a splash
> screen (using the much newer lcd infrastructure).
>
> With u-boot showing a console, it really seemed only a small step to add
> simplefb. And quite a few people in our sunxi community are interested
> in it, primarily for u-boot and early console, and only secondarily as a
> stop-gap for a full driver.

Both of which make sense and should be supported, so I agree we need
to find a solution.

The problem I think comes down to the handoff mechanism. There are a
lot of different video controllers which could all be configured for a
simple framebuffer.

I don't think the "run this only once" test is the right approach.
Sometimes the simple framebuffer will never be torn down. It is
conceivable that a simple framebuffer will get /added/ at runtime with
an overlay, or even rebound to the driver. The simple framebuffer
driver really needs to be explicitly told from outside itself that it
is being taken over since it doesn't actually have the information to
know when a framebuffer becomes invalid. Only the real video driver
can provide that information.

How does the sunxi driver currently take over from the simplefb?

g.

[PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 8:25 PM, Luc Verhaegen <libv@skynet.be> wrote:
> On Wed, Aug 13, 2014 at 08:14:37PM +0100, Grant Likely wrote:
>>
>> BTW, Is anyone currently using the simple framebuffer for early
>> console? For early console we would want to start using it well before
>> setting up platform devices.
>
> The code that sets up simplefb for sunxi is primarily for providing a
> console in u-boot (using the ancient cfbconsole infrastructure). From
> what i can tell, the u-boot code for rpi is about showing a splash
> screen (using the much newer lcd infrastructure).
>
> With u-boot showing a console, it really seemed only a small step to add
> simplefb. And quite a few people in our sunxi community are interested
> in it, primarily for u-boot and early console, and only secondarily as a
> stop-gap for a full driver.

Both of which make sense and should be supported, so I agree we need
to find a solution.

The problem I think comes down to the handoff mechanism. There are a
lot of different video controllers which could all be configured for a
simple framebuffer.

I don't think the "run this only once" test is the right approach.
Sometimes the simple framebuffer will never be torn down. It is
conceivable that a simple framebuffer will get /added/ at runtime with
an overlay, or even rebound to the driver. The simple framebuffer
driver really needs to be explicitly told from outside itself that it
is being taken over since it doesn't actually have the information to
know when a framebuffer becomes invalid. Only the real video driver
can provide that information.

How does the sunxi driver currently take over from the simplefb?

g.

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:00:07PM +0100, Grant Likely wrote:
> 
> Both of which make sense and should be supported, so I agree we need
> to find a solution.
> 
> The problem I think comes down to the handoff mechanism. There are a
> lot of different video controllers which could all be configured for a
> simple framebuffer.
> 
> I don't think the "run this only once" test is the right approach.
> Sometimes the simple framebuffer will never be torn down. It is
> conceivable that a simple framebuffer will get /added/ at runtime with
> an overlay, or even rebound to the driver. The simple framebuffer
> driver really needs to be explicitly told from outside itself that it
> is being taken over since it doesn't actually have the information to
> know when a framebuffer becomes invalid. Only the real video driver
> can provide that information.

There really are two separate issues here:
1) making sure that nothing tries to use the freshly died simplefb 
again.
2) doing a clean handover to another, usually hw specific, driver.

1 is what i hoped to superficially solve with this patch.
2 can be very smart about things as the replacement driver actually 
should know the hw.

I kind of like the idea of an "only-once" (there must be a better name 
for this) property. This allows the driver/device infrastructure to 
handle things much more cleanly, and allows me to state this from u-boot 
for sunxi, while Stephen wouldn't need to for rpi. I currently don't 
know how or where this could be handled, i just know that this smells 
like a decent solution which could solve my concern while at least 
avoiding the probe issue you mentioned earlier.

> How does the sunxi driver currently take over from the simplefb?

Not at all. A big blob of KMS code exists for our sunxi-3.4 kernel, 
where i can load the original display driver quickly and easily. This 
tree predates most of DT. I was rather hoping that the simplefb stop-gap
didn't require me to have fully engineered everything yesterday already.

Luc Verhaegen.

[PATCH 3/4] simplefb: disable dt node upon remove

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:00:07PM +0100, Grant Likely wrote:
> 
> Both of which make sense and should be supported, so I agree we need
> to find a solution.
> 
> The problem I think comes down to the handoff mechanism. There are a
> lot of different video controllers which could all be configured for a
> simple framebuffer.
> 
> I don't think the "run this only once" test is the right approach.
> Sometimes the simple framebuffer will never be torn down. It is
> conceivable that a simple framebuffer will get /added/ at runtime with
> an overlay, or even rebound to the driver. The simple framebuffer
> driver really needs to be explicitly told from outside itself that it
> is being taken over since it doesn't actually have the information to
> know when a framebuffer becomes invalid. Only the real video driver
> can provide that information.

There really are two separate issues here:
1) making sure that nothing tries to use the freshly died simplefb 
again.
2) doing a clean handover to another, usually hw specific, driver.

1 is what i hoped to superficially solve with this patch.
2 can be very smart about things as the replacement driver actually 
should know the hw.

I kind of like the idea of an "only-once" (there must be a better name 
for this) property. This allows the driver/device infrastructure to 
handle things much more cleanly, and allows me to state this from u-boot 
for sunxi, while Stephen wouldn't need to for rpi. I currently don't 
know how or where this could be handled, i just know that this smells 
like a decent solution which could solve my concern while at least 
avoiding the probe issue you mentioned earlier.

> How does the sunxi driver currently take over from the simplefb?

Not at all. A big blob of KMS code exists for our sunxi-3.4 kernel, 
where i can load the original display driver quickly and easily. This 
tree predates most of DT. I was rather hoping that the simplefb stop-gap
didn't require me to have fully engineered everything yesterday already.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>> >
>>>> > The majority of the DT code is based on the assumption of a static
>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>> > with overlays, but he has had to go through a lot of rework because it
>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>> > have a lot more understanding of the side effects to changing the
>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>> > current tree from the kernel, make the appropriate modifications, and
>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>> > tree has side effects beyond just the current kernel.
>>>> >
>>>> > In this specific case, it will interact badly with the work Pantelis
>>>> > is doing to make platform devices work with overlays. Modifying the
>>>> > status property will cause the associated struct device to get removed
>>>> > in the middle of probing a driver for that device! That will most
>>>> > likely cause an oops.
>>>> >
>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>> > today". In what circumstance is that justification for modifying the
>>>> > tree?
>>>>
>>>> With that sentence i meant that given the current state of things, it
>>>> has no real value.
>>>>
>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>> that makes much sense, but that's never stopped anyone.
>>>>
>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>> becomes responsible for making sure that simplefb or another driver does
>>>> not attempt to blindly use this info again. The way this is implemented
>>>> i do not care for in any way, i just knew that i could not do nothing
>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>> does need some resolution, and altering the dt is going to have to be
>>>> part of the solution.
>>>>
>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>> necessary. But it should be very clear that there is no going back on
>>>> this dt node after the clocks were released once.
>>>>
>>>> Luc Verhaegen.
>>>
>>> What about approaching this from the other end? U-Boot could add a
>>> property named "once-only" or so.
>>
>> Device tree is supposed to be a static description of the hardware
>> usable on all operating systems. It is the wrong mechanism for
>> communicating between uboot and the kernel. Use something like atags
>> or the kernel command line to tell the kernel that the console has
>> already been set up.
>
> Not accurate. While it is primarily hardware description, it is also
> used for firmware communication. There is loads of precedence for
> this. The /chosen node is the most significant example, but there are
> other places where the tree is used to provide state. For example, the
> current-speed property on UART nodes.

I do seem to recall you telling me a long time ago that those chosen
nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
opening to door to device trees carrying a bunch of state.  Five years
from now the DT is going to look like a Christmas tree.

>
>> The switch over from simple to KMS should not be done via a node
>> add/del to the device tree either.  No one has removed the device from
>> the system, the device tree should not be changing.
>
> The simple-framebuffer binding appears to be insufficient in this
> regard in that it doesn't have any linkage with the actual device
> providing the framebuffer. Ideally, I would put the simple framebuffer
> state directly into the video device node and use the chosen node to
> point to the stdout device (probably with the stdout-path property).
> Then the driver already knows it can just ignore the simple properties
> because it owns the device node when it binds.
>
> That said, simple-framebuffer as it stands is in use so we're not
> going to deprecate it. I would like to see an addition that specifies
> how a controller can be associated with a simple framebuffer node.
>
> BTW, Is anyone currently using the simple framebuffer for early
> console? For early console we would want to start using it well before
> setting up platform devices.
>
> g.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>> >
>>>> > The majority of the DT code is based on the assumption of a static
>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>> > with overlays, but he has had to go through a lot of rework because it
>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>> > have a lot more understanding of the side effects to changing the
>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>> > current tree from the kernel, make the appropriate modifications, and
>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>> > tree has side effects beyond just the current kernel.
>>>> >
>>>> > In this specific case, it will interact badly with the work Pantelis
>>>> > is doing to make platform devices work with overlays. Modifying the
>>>> > status property will cause the associated struct device to get removed
>>>> > in the middle of probing a driver for that device! That will most
>>>> > likely cause an oops.
>>>> >
>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>> > today". In what circumstance is that justification for modifying the
>>>> > tree?
>>>>
>>>> With that sentence i meant that given the current state of things, it
>>>> has no real value.
>>>>
>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>> that makes much sense, but that's never stopped anyone.
>>>>
>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>> becomes responsible for making sure that simplefb or another driver does
>>>> not attempt to blindly use this info again. The way this is implemented
>>>> i do not care for in any way, i just knew that i could not do nothing
>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>> does need some resolution, and altering the dt is going to have to be
>>>> part of the solution.
>>>>
>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>> necessary. But it should be very clear that there is no going back on
>>>> this dt node after the clocks were released once.
>>>>
>>>> Luc Verhaegen.
>>>
>>> What about approaching this from the other end? U-Boot could add a
>>> property named "once-only" or so.
>>
>> Device tree is supposed to be a static description of the hardware
>> usable on all operating systems. It is the wrong mechanism for
>> communicating between uboot and the kernel. Use something like atags
>> or the kernel command line to tell the kernel that the console has
>> already been set up.
>
> Not accurate. While it is primarily hardware description, it is also
> used for firmware communication. There is loads of precedence for
> this. The /chosen node is the most significant example, but there are
> other places where the tree is used to provide state. For example, the
> current-speed property on UART nodes.

I do seem to recall you telling me a long time ago that those chosen
nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
opening to door to device trees carrying a bunch of state.  Five years
from now the DT is going to look like a Christmas tree.

>
>> The switch over from simple to KMS should not be done via a node
>> add/del to the device tree either.  No one has removed the device from
>> the system, the device tree should not be changing.
>
> The simple-framebuffer binding appears to be insufficient in this
> regard in that it doesn't have any linkage with the actual device
> providing the framebuffer. Ideally, I would put the simple framebuffer
> state directly into the video device node and use the chosen node to
> point to the stdout device (probably with the stdout-path property).
> Then the driver already knows it can just ignore the simple properties
> because it owns the device node when it binds.
>
> That said, simple-framebuffer as it stands is in use so we're not
> going to deprecate it. I would like to see an addition that specifies
> how a controller can be associated with a simple framebuffer node.
>
> BTW, Is anyone currently using the simple framebuffer for early
> console? For early console we would want to start using it well before
> setting up platform devices.
>
> g.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 9:41 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>>> >
>>>>> > The majority of the DT code is based on the assumption of a static
>>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>>> > with overlays, but he has had to go through a lot of rework because it
>>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>>> > have a lot more understanding of the side effects to changing the
>>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>>> > current tree from the kernel, make the appropriate modifications, and
>>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>>> > tree has side effects beyond just the current kernel.
>>>>> >
>>>>> > In this specific case, it will interact badly with the work Pantelis
>>>>> > is doing to make platform devices work with overlays. Modifying the
>>>>> > status property will cause the associated struct device to get removed
>>>>> > in the middle of probing a driver for that device! That will most
>>>>> > likely cause an oops.
>>>>> >
>>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>>> > today". In what circumstance is that justification for modifying the
>>>>> > tree?
>>>>>
>>>>> With that sentence i meant that given the current state of things, it
>>>>> has no real value.
>>>>>
>>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>>> that makes much sense, but that's never stopped anyone.
>>>>>
>>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>>> becomes responsible for making sure that simplefb or another driver does
>>>>> not attempt to blindly use this info again. The way this is implemented
>>>>> i do not care for in any way, i just knew that i could not do nothing
>>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>>> does need some resolution, and altering the dt is going to have to be
>>>>> part of the solution.
>>>>>
>>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>>> necessary. But it should be very clear that there is no going back on
>>>>> this dt node after the clocks were released once.
>>>>>
>>>>> Luc Verhaegen.
>>>>
>>>> What about approaching this from the other end? U-Boot could add a
>>>> property named "once-only" or so.
>>>
>>> Device tree is supposed to be a static description of the hardware
>>> usable on all operating systems. It is the wrong mechanism for
>>> communicating between uboot and the kernel. Use something like atags
>>> or the kernel command line to tell the kernel that the console has
>>> already been set up.
>>
>> Not accurate. While it is primarily hardware description, it is also
>> used for firmware communication. There is loads of precedence for
>> this. The /chosen node is the most significant example, but there are
>> other places where the tree is used to provide state. For example, the
>> current-speed property on UART nodes.
>
> I do seem to recall you telling me a long time ago that those chosen
> nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
> opening to door to device trees carrying a bunch of state.  Five years
> from now the DT is going to look like a Christmas tree.

Wasn't me. Carrying state in the DT provided by firmware is perfectly
reasonable in my opinion.

g.

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Grant Likely]

On Wed, Aug 13, 2014 at 9:41 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>>> >
>>>>> > The majority of the DT code is based on the assumption of a static
>>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>>> > with overlays, but he has had to go through a lot of rework because it
>>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>>> > have a lot more understanding of the side effects to changing the
>>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>>> > current tree from the kernel, make the appropriate modifications, and
>>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>>> > tree has side effects beyond just the current kernel.
>>>>> >
>>>>> > In this specific case, it will interact badly with the work Pantelis
>>>>> > is doing to make platform devices work with overlays. Modifying the
>>>>> > status property will cause the associated struct device to get removed
>>>>> > in the middle of probing a driver for that device! That will most
>>>>> > likely cause an oops.
>>>>> >
>>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>>> > today". In what circumstance is that justification for modifying the
>>>>> > tree?
>>>>>
>>>>> With that sentence i meant that given the current state of things, it
>>>>> has no real value.
>>>>>
>>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>>> that makes much sense, but that's never stopped anyone.
>>>>>
>>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>>> becomes responsible for making sure that simplefb or another driver does
>>>>> not attempt to blindly use this info again. The way this is implemented
>>>>> i do not care for in any way, i just knew that i could not do nothing
>>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>>> does need some resolution, and altering the dt is going to have to be
>>>>> part of the solution.
>>>>>
>>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>>> necessary. But it should be very clear that there is no going back on
>>>>> this dt node after the clocks were released once.
>>>>>
>>>>> Luc Verhaegen.
>>>>
>>>> What about approaching this from the other end? U-Boot could add a
>>>> property named "once-only" or so.
>>>
>>> Device tree is supposed to be a static description of the hardware
>>> usable on all operating systems. It is the wrong mechanism for
>>> communicating between uboot and the kernel. Use something like atags
>>> or the kernel command line to tell the kernel that the console has
>>> already been set up.
>>
>> Not accurate. While it is primarily hardware description, it is also
>> used for firmware communication. There is loads of precedence for
>> this. The /chosen node is the most significant example, but there are
>> other places where the tree is used to provide state. For example, the
>> current-speed property on UART nodes.
>
> I do seem to recall you telling me a long time ago that those chosen
> nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
> opening to door to device trees carrying a bunch of state.  Five years
> from now the DT is going to look like a Christmas tree.

Wasn't me. Carrying state in the DT provided by firmware is perfectly
reasonable in my opinion.

g.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Thu, Aug 14, 2014 at 6:15 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 9:41 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>>>> >
>>>>>> > The majority of the DT code is based on the assumption of a static
>>>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>>>> > with overlays, but he has had to go through a lot of rework because it
>>>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>>>> > have a lot more understanding of the side effects to changing the
>>>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>>>> > current tree from the kernel, make the appropriate modifications, and
>>>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>>>> > tree has side effects beyond just the current kernel.
>>>>>> >
>>>>>> > In this specific case, it will interact badly with the work Pantelis
>>>>>> > is doing to make platform devices work with overlays. Modifying the
>>>>>> > status property will cause the associated struct device to get removed
>>>>>> > in the middle of probing a driver for that device! That will most
>>>>>> > likely cause an oops.
>>>>>> >
>>>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>>>> > today". In what circumstance is that justification for modifying the
>>>>>> > tree?
>>>>>>
>>>>>> With that sentence i meant that given the current state of things, it
>>>>>> has no real value.
>>>>>>
>>>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>>>> that makes much sense, but that's never stopped anyone.
>>>>>>
>>>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>>>> becomes responsible for making sure that simplefb or another driver does
>>>>>> not attempt to blindly use this info again. The way this is implemented
>>>>>> i do not care for in any way, i just knew that i could not do nothing
>>>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>>>> does need some resolution, and altering the dt is going to have to be
>>>>>> part of the solution.
>>>>>>
>>>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>>>> necessary. But it should be very clear that there is no going back on
>>>>>> this dt node after the clocks were released once.
>>>>>>
>>>>>> Luc Verhaegen.
>>>>>
>>>>> What about approaching this from the other end? U-Boot could add a
>>>>> property named "once-only" or so.
>>>>
>>>> Device tree is supposed to be a static description of the hardware
>>>> usable on all operating systems. It is the wrong mechanism for
>>>> communicating between uboot and the kernel. Use something like atags
>>>> or the kernel command line to tell the kernel that the console has
>>>> already been set up.
>>>
>>> Not accurate. While it is primarily hardware description, it is also
>>> used for firmware communication. There is loads of precedence for
>>> this. The /chosen node is the most significant example, but there are
>>> other places where the tree is used to provide state. For example, the
>>> current-speed property on UART nodes.
>>
>> I do seem to recall you telling me a long time ago that those chosen
>> nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
>> opening to door to device trees carrying a bunch of state.  Five years
>> from now the DT is going to look like a Christmas tree.
>
> Wasn't me. Carrying state in the DT provided by firmware is perfectly
> reasonable in my opinion.

So what are the rules going to be? Once the OS is up and starts
changing things the state in the DT and the OS are going to diverge.
How does this get handled for a kernel driver that can load/unload?
Should the kernel remove those state nodes as soon as it alters the
state?

>
> g.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Thu, Aug 14, 2014 at 6:15 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Aug 13, 2014 at 9:41 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 3:14 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Wed, Aug 13, 2014 at 1:54 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Wed, Aug 13, 2014 at 6:19 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>> On Wed, Aug 13, 2014 at 11:45:24AM +0200, Luc Verhaegen wrote:
>>>>>> On Wed, Aug 13, 2014 at 10:23:14AM +0100, Grant Likely wrote:
>>>>>> >
>>>>>> > The majority of the DT code is based on the assumption of a static
>>>>>> > tree. Pantelis has been working on being able to modify it at runtime
>>>>>> > with overlays, but he has had to go through a lot of rework because it
>>>>>> > is not a trivial task. When you get into modifying the DT, you need to
>>>>>> > have a lot more understanding of the side effects to changing the
>>>>>> > tree. The DT structure also has a lifecycle that can go beyond the
>>>>>> > current lifecycle of the kernel. The kexec tool will extract the
>>>>>> > current tree from the kernel, make the appropriate modifications, and
>>>>>> > use that to boot the next kernel. Allowing any driver to modify the
>>>>>> > tree has side effects beyond just the current kernel.
>>>>>> >
>>>>>> > In this specific case, it will interact badly with the work Pantelis
>>>>>> > is doing to make platform devices work with overlays. Modifying the
>>>>>> > status property will cause the associated struct device to get removed
>>>>>> > in the middle of probing a driver for that device! That will most
>>>>>> > likely cause an oops.
>>>>>> >
>>>>>> > Besides, Luc straight out *said*: "...even though it has no real value
>>>>>> > today". In what circumstance is that justification for modifying the
>>>>>> > tree?
>>>>>>
>>>>>> With that sentence i meant that given the current state of things, it
>>>>>> has no real value.
>>>>>>
>>>>>> It has no value currently as re-probing simplefb is not going to happen.
>>>>>> But it's not a big leap to turn simplefb into a proper module. Not that
>>>>>> that makes much sense, but that's never stopped anyone.
>>>>>>
>>>>>> To me it seemed simple, dt is what drives simplefb, so dt then also
>>>>>> becomes responsible for making sure that simplefb or another driver does
>>>>>> not attempt to blindly use this info again. The way this is implemented
>>>>>> i do not care for in any way, i just knew that i could not do nothing
>>>>>> here, given the catastrophic effect disabling the clocks has on simplefb
>>>>>> on sunxi. Given the discussion that errupted here, i'd say that this
>>>>>> does need some resolution, and altering the dt is going to have to be
>>>>>> part of the solution.
>>>>>>
>>>>>> In any case, i will gladly drop this patch, as it is not absolutely
>>>>>> necessary. But it should be very clear that there is no going back on
>>>>>> this dt node after the clocks were released once.
>>>>>>
>>>>>> Luc Verhaegen.
>>>>>
>>>>> What about approaching this from the other end? U-Boot could add a
>>>>> property named "once-only" or so.
>>>>
>>>> Device tree is supposed to be a static description of the hardware
>>>> usable on all operating systems. It is the wrong mechanism for
>>>> communicating between uboot and the kernel. Use something like atags
>>>> or the kernel command line to tell the kernel that the console has
>>>> already been set up.
>>>
>>> Not accurate. While it is primarily hardware description, it is also
>>> used for firmware communication. There is loads of precedence for
>>> this. The /chosen node is the most significant example, but there are
>>> other places where the tree is used to provide state. For example, the
>>> current-speed property on UART nodes.
>>
>> I do seem to recall you telling me a long time ago that those chosen
>> nodes were a mistake (or maybe it was Matt Sealey). I'm pretty wary of
>> opening to door to device trees carrying a bunch of state.  Five years
>> from now the DT is going to look like a Christmas tree.
>
> Wasn't me. Carrying state in the DT provided by firmware is perfectly
> reasonable in my opinion.

So what are the rules going to be? Once the OS is up and starts
changing things the state in the DT and the OS are going to diverge.
How does this get handled for a kernel driver that can load/unload?
Should the kernel remove those state nodes as soon as it alters the
state?

>
> g.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Henrik Nordström]

tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl@gmail.com:

> So what are the rules going to be? Once the OS is up and starts
> changing things the state in the DT and the OS are going to diverge.
> How does this get handled for a kernel driver that can load/unload?
> Should the kernel remove those state nodes as soon as it alters the
> state?

hardware that is no longer there should also not be represented/active
in DT.

A simple fb that have been torn down is no more, no different from never
having been there. It can be argued that it never was in the first place
(i.e. that it is not actually hardware) but that it another can of worms
and both have their benefits and drawbacks. One thing is certain
however, as far as simplefb is concerned it is hardware, not really any
different from a persistent framebuffer with hardwired settings in
hardware.

Regarding kexec, it's the responsibility of the kernel doing kexec to
make sure DT and hardware matches for the next started kernel. With
hardware that can be reconfigured it is not safe to assume that the DT
can be passed as-is from before the kernel reconfigured hardware. If the
currently running kernel wants to set up a framebuffer for simplefb use
by the next kernel than it's free to do so, but in either case it needs
to provide the right information to next kernel.

If it was given a simplefb node, but then killed the simplefb then no
simplefb node should be provided to the next kernel. If it was not given
a simplefb node, but have configured the hardware suitable for simplefb
node then it may provide a simplefb node.

A UART that have changed rate no longer have that rate.

Same applies to numerous other items as well. If a kernel remaps IRQs,
bus addresses, or whatever in hardware aspects where such changes is
possible then DT needs to be updated as well. A bit less common than a
simplefb being destroyed by driver reconfiguring the framebuffer, but if
you look at it from a little distance then the problem is exactly the
same. Hardware is not 100% static, and therefore hardware description
also can not be 100% static. And hardware is getting more and more
dynamically reconfigurable.

A DT that contains false information is generally worse than no DT / not
having that information at all.

Regards
Henrik

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Henrik Nordström]

tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:

> So what are the rules going to be? Once the OS is up and starts
> changing things the state in the DT and the OS are going to diverge.
> How does this get handled for a kernel driver that can load/unload?
> Should the kernel remove those state nodes as soon as it alters the
> state?

hardware that is no longer there should also not be represented/active
in DT.

A simple fb that have been torn down is no more, no different from never
having been there. It can be argued that it never was in the first place
(i.e. that it is not actually hardware) but that it another can of worms
and both have their benefits and drawbacks. One thing is certain
however, as far as simplefb is concerned it is hardware, not really any
different from a persistent framebuffer with hardwired settings in
hardware.

Regarding kexec, it's the responsibility of the kernel doing kexec to
make sure DT and hardware matches for the next started kernel. With
hardware that can be reconfigured it is not safe to assume that the DT
can be passed as-is from before the kernel reconfigured hardware. If the
currently running kernel wants to set up a framebuffer for simplefb use
by the next kernel than it's free to do so, but in either case it needs
to provide the right information to next kernel.

If it was given a simplefb node, but then killed the simplefb then no
simplefb node should be provided to the next kernel. If it was not given
a simplefb node, but have configured the hardware suitable for simplefb
node then it may provide a simplefb node.

A UART that have changed rate no longer have that rate.

Same applies to numerous other items as well. If a kernel remaps IRQs,
bus addresses, or whatever in hardware aspects where such changes is
possible then DT needs to be updated as well. A bit less common than a
simplefb being destroyed by driver reconfiguring the framebuffer, but if
you look at it from a little distance then the problem is exactly the
same. Hardware is not 100% static, and therefore hardware description
also can not be 100% static. And hardware is getting more and more
dynamically reconfigurable.

A DT that contains false information is generally worse than no DT / not
having that information at all.

Regards
Henrik

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordström
<henrik@henriknordstrom.net> wrote:
> tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl@gmail.com:
>
>> So what are the rules going to be? Once the OS is up and starts
>> changing things the state in the DT and the OS are going to diverge.
>> How does this get handled for a kernel driver that can load/unload?
>> Should the kernel remove those state nodes as soon as it alters the
>> state?
>
> hardware that is no longer there should also not be represented/active
> in DT.
>
> A simple fb that have been torn down is no more, no different from never
> having been there. It can be argued that it never was in the first place
> (i.e. that it is not actually hardware) but that it another can of worms
> and both have their benefits and drawbacks. One thing is certain
> however, as far as simplefb is concerned it is hardware, not really any
> different from a persistent framebuffer with hardwired settings in
> hardware.

How does the kernel know what clocks to protect? A list in the
simplefb node?  This list of clocks is a reason for adding simplefb to
the compatible list for the real hardware.  That way it won't be
duplicated.

The issues with parameter conflicts between simplefb and the real
hardware can be dealt with.  If the real hardware wants to add the
simplefb compatible field it will need to get its parameters sorted
out so that they don't conflict. Clock syntax is standardized in the
DTS so it shouldn't be a problem.

You can also argue that simplefb should never occur in a DTS file. It
is something that uboot will add. And then the kernel will remove when
simplefb loads KMS.

That logic should apply to all of these dynamic fields. You don't want
stale state data in the DT.

>
> Regarding kexec, it's the responsibility of the kernel doing kexec to
> make sure DT and hardware matches for the next started kernel. With
> hardware that can be reconfigured it is not safe to assume that the DT
> can be passed as-is from before the kernel reconfigured hardware. If the
> currently running kernel wants to set up a framebuffer for simplefb use
> by the next kernel than it's free to do so, but in either case it needs
> to provide the right information to next kernel.
>
> If it was given a simplefb node, but then killed the simplefb then no
> simplefb node should be provided to the next kernel. If it was not given
> a simplefb node, but have configured the hardware suitable for simplefb
> node then it may provide a simplefb node.
>
> A UART that have changed rate no longer have that rate.
>
> Same applies to numerous other items as well. If a kernel remaps IRQs,
> bus addresses, or whatever in hardware aspects where such changes is
> possible then DT needs to be updated as well. A bit less common than a
> simplefb being destroyed by driver reconfiguring the framebuffer, but if
> you look at it from a little distance then the problem is exactly the
> same. Hardware is not 100% static, and therefore hardware description
> also can not be 100% static. And hardware is getting more and more
> dynamically reconfigurable.
>
> A DT that contains false information is generally worse than no DT / not
> having that information at all.
>
> Regards
> Henrik
>



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordstr?m
<henrik@henriknordstrom.net> wrote:
> tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:
>
>> So what are the rules going to be? Once the OS is up and starts
>> changing things the state in the DT and the OS are going to diverge.
>> How does this get handled for a kernel driver that can load/unload?
>> Should the kernel remove those state nodes as soon as it alters the
>> state?
>
> hardware that is no longer there should also not be represented/active
> in DT.
>
> A simple fb that have been torn down is no more, no different from never
> having been there. It can be argued that it never was in the first place
> (i.e. that it is not actually hardware) but that it another can of worms
> and both have their benefits and drawbacks. One thing is certain
> however, as far as simplefb is concerned it is hardware, not really any
> different from a persistent framebuffer with hardwired settings in
> hardware.

How does the kernel know what clocks to protect? A list in the
simplefb node?  This list of clocks is a reason for adding simplefb to
the compatible list for the real hardware.  That way it won't be
duplicated.

The issues with parameter conflicts between simplefb and the real
hardware can be dealt with.  If the real hardware wants to add the
simplefb compatible field it will need to get its parameters sorted
out so that they don't conflict. Clock syntax is standardized in the
DTS so it shouldn't be a problem.

You can also argue that simplefb should never occur in a DTS file. It
is something that uboot will add. And then the kernel will remove when
simplefb loads KMS.

That logic should apply to all of these dynamic fields. You don't want
stale state data in the DT.

>
> Regarding kexec, it's the responsibility of the kernel doing kexec to
> make sure DT and hardware matches for the next started kernel. With
> hardware that can be reconfigured it is not safe to assume that the DT
> can be passed as-is from before the kernel reconfigured hardware. If the
> currently running kernel wants to set up a framebuffer for simplefb use
> by the next kernel than it's free to do so, but in either case it needs
> to provide the right information to next kernel.
>
> If it was given a simplefb node, but then killed the simplefb then no
> simplefb node should be provided to the next kernel. If it was not given
> a simplefb node, but have configured the hardware suitable for simplefb
> node then it may provide a simplefb node.
>
> A UART that have changed rate no longer have that rate.
>
> Same applies to numerous other items as well. If a kernel remaps IRQs,
> bus addresses, or whatever in hardware aspects where such changes is
> possible then DT needs to be updated as well. A bit less common than a
> simplefb being destroyed by driver reconfiguring the framebuffer, but if
> you look at it from a little distance then the problem is exactly the
> same. Hardware is not 100% static, and therefore hardware description
> also can not be 100% static. And hardware is getting more and more
> dynamically reconfigurable.
>
> A DT that contains false information is generally worse than no DT / not
> having that information at all.
>
> Regards
> Henrik
>



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

On Thu, Aug 14, 2014 at 09:27:14PM -0400, jonsmirl@gmail.com wrote:
> On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordström
> <henrik@henriknordstrom.net> wrote:
> > tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl@gmail.com:
> >
> >> So what are the rules going to be? Once the OS is up and starts
> >> changing things the state in the DT and the OS are going to diverge.
> >> How does this get handled for a kernel driver that can load/unload?
> >> Should the kernel remove those state nodes as soon as it alters the
> >> state?
> >
> > hardware that is no longer there should also not be represented/active
> > in DT.
> >
> > A simple fb that have been torn down is no more, no different from never
> > having been there. It can be argued that it never was in the first place
> > (i.e. that it is not actually hardware) but that it another can of worms
> > and both have their benefits and drawbacks. One thing is certain
> > however, as far as simplefb is concerned it is hardware, not really any
> > different from a persistent framebuffer with hardwired settings in
> > hardware.
> 
> How does the kernel know what clocks to protect? A list in the
> simplefb node?  This list of clocks is a reason for adding simplefb to
> the compatible list for the real hardware.  That way it won't be
> duplicated.
> 
> The issues with parameter conflicts between simplefb and the real
> hardware can be dealt with.  If the real hardware wants to add the
> simplefb compatible field it will need to get its parameters sorted
> out so that they don't conflict. Clock syntax is standardized in the
> DTS so it shouldn't be a problem.

It shouldn't be, but apparently, some disagree.

Anyway, I'm not sure having the simplefb compatible would work in this
use-case, mainly for two reasons:
  - Most likely, the bindings are going to be very different. Not only
    about which properties you'll have, but also what you will place
    in these properties. reg for example have the memory address of
    the buffer in the simplefb case, while in the KMS driver case, it
    would have the memory address of the registers.
  - There's will be a single driver probed. So if you want to go down
    the hand over road (which is a bit premature at this point if you
    ask me, but anyway), you will have no driver probed to hand over
    to.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Maxime Ripard]

On Thu, Aug 14, 2014 at 09:27:14PM -0400, jonsmirl at gmail.com wrote:
> On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordstr?m
> <henrik@henriknordstrom.net> wrote:
> > tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:
> >
> >> So what are the rules going to be? Once the OS is up and starts
> >> changing things the state in the DT and the OS are going to diverge.
> >> How does this get handled for a kernel driver that can load/unload?
> >> Should the kernel remove those state nodes as soon as it alters the
> >> state?
> >
> > hardware that is no longer there should also not be represented/active
> > in DT.
> >
> > A simple fb that have been torn down is no more, no different from never
> > having been there. It can be argued that it never was in the first place
> > (i.e. that it is not actually hardware) but that it another can of worms
> > and both have their benefits and drawbacks. One thing is certain
> > however, as far as simplefb is concerned it is hardware, not really any
> > different from a persistent framebuffer with hardwired settings in
> > hardware.
> 
> How does the kernel know what clocks to protect? A list in the
> simplefb node?  This list of clocks is a reason for adding simplefb to
> the compatible list for the real hardware.  That way it won't be
> duplicated.
> 
> The issues with parameter conflicts between simplefb and the real
> hardware can be dealt with.  If the real hardware wants to add the
> simplefb compatible field it will need to get its parameters sorted
> out so that they don't conflict. Clock syntax is standardized in the
> DTS so it shouldn't be a problem.

It shouldn't be, but apparently, some disagree.

Anyway, I'm not sure having the simplefb compatible would work in this
use-case, mainly for two reasons:
  - Most likely, the bindings are going to be very different. Not only
    about which properties you'll have, but also what you will place
    in these properties. reg for example have the memory address of
    the buffer in the simplefb case, while in the KMS driver case, it
    would have the memory address of the registers.
  - There's will be a single driver probed. So if you want to go down
    the hand over road (which is a bit premature at this point if you
    ask me, but anyway), you will have no driver probed to hand over
    to.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140815/3cb2347d/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Fri, Aug 15, 2014 at 2:43 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Aug 14, 2014 at 09:27:14PM -0400, jonsmirl@gmail.com wrote:
>> On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordström
>> <henrik@henriknordstrom.net> wrote:
>> > tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl@gmail.com:
>> >
>> >> So what are the rules going to be? Once the OS is up and starts
>> >> changing things the state in the DT and the OS are going to diverge.
>> >> How does this get handled for a kernel driver that can load/unload?
>> >> Should the kernel remove those state nodes as soon as it alters the
>> >> state?
>> >
>> > hardware that is no longer there should also not be represented/active
>> > in DT.
>> >
>> > A simple fb that have been torn down is no more, no different from never
>> > having been there. It can be argued that it never was in the first place
>> > (i.e. that it is not actually hardware) but that it another can of worms
>> > and both have their benefits and drawbacks. One thing is certain
>> > however, as far as simplefb is concerned it is hardware, not really any
>> > different from a persistent framebuffer with hardwired settings in
>> > hardware.
>>
>> How does the kernel know what clocks to protect? A list in the
>> simplefb node?  This list of clocks is a reason for adding simplefb to
>> the compatible list for the real hardware.  That way it won't be
>> duplicated.
>>
>> The issues with parameter conflicts between simplefb and the real
>> hardware can be dealt with.  If the real hardware wants to add the
>> simplefb compatible field it will need to get its parameters sorted
>> out so that they don't conflict. Clock syntax is standardized in the
>> DTS so it shouldn't be a problem.
>
> It shouldn't be, but apparently, some disagree.
>
> Anyway, I'm not sure having the simplefb compatible would work in this
> use-case, mainly for two reasons:
>   - Most likely, the bindings are going to be very different. Not only
>     about which properties you'll have, but also what you will place
>     in these properties. reg for example have the memory address of
>     the buffer in the simplefb case, while in the KMS driver case, it
>     would have the memory address of the registers.
>   - There's will be a single driver probed. So if you want to go down
>     the hand over road (which is a bit premature at this point if you
>     ask me, but anyway), you will have no driver probed to hand over
>     to.

The graphic drivers have already been down this road before. Simplefb
should be a driver library not a driver. DRM is also a driver library.

So to implement simplefb whip up a real skeleton driver for the video
hardware that parses the DT and then pokes the appropriate info into
the simplefb library. Initially that driver will just include the
calls out to the simplefb library. Later on it can get KMS
implemented.  This real driver will get bound to the hardware and have
a dependency that loads the simplefb driver library.

Now there is no handover problem. Only a single driver is ever
attached to the hardware. When it wants to go into KMS mode it makes a
call into the simplefb library to shut down whatever it is doing.

But you still need a mechanism for uboot to signal that it has set up
simplefb. Adding a dynamic node like this might work...

video0: video@01c21800 {
   compatible = "allwinner,sun4i-a10-video";
   clocks = <&apb0_gates 6>, <&ir0_clk>;
   clock-names = "apb", "video";
   interrupts = <0 5 4>;
   reg = <0x01c21800 0x40>;
   status = "enabled";
   simplefb {
       new namespace for simplefb parameters
   }
};

I would have suggested a driver library earlier but it has been a
while since I worked on DRM and I forgot about it.



>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Fri, Aug 15, 2014 at 2:43 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Aug 14, 2014 at 09:27:14PM -0400, jonsmirl at gmail.com wrote:
>> On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordstr?m
>> <henrik@henriknordstrom.net> wrote:
>> > tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:
>> >
>> >> So what are the rules going to be? Once the OS is up and starts
>> >> changing things the state in the DT and the OS are going to diverge.
>> >> How does this get handled for a kernel driver that can load/unload?
>> >> Should the kernel remove those state nodes as soon as it alters the
>> >> state?
>> >
>> > hardware that is no longer there should also not be represented/active
>> > in DT.
>> >
>> > A simple fb that have been torn down is no more, no different from never
>> > having been there. It can be argued that it never was in the first place
>> > (i.e. that it is not actually hardware) but that it another can of worms
>> > and both have their benefits and drawbacks. One thing is certain
>> > however, as far as simplefb is concerned it is hardware, not really any
>> > different from a persistent framebuffer with hardwired settings in
>> > hardware.
>>
>> How does the kernel know what clocks to protect? A list in the
>> simplefb node?  This list of clocks is a reason for adding simplefb to
>> the compatible list for the real hardware.  That way it won't be
>> duplicated.
>>
>> The issues with parameter conflicts between simplefb and the real
>> hardware can be dealt with.  If the real hardware wants to add the
>> simplefb compatible field it will need to get its parameters sorted
>> out so that they don't conflict. Clock syntax is standardized in the
>> DTS so it shouldn't be a problem.
>
> It shouldn't be, but apparently, some disagree.
>
> Anyway, I'm not sure having the simplefb compatible would work in this
> use-case, mainly for two reasons:
>   - Most likely, the bindings are going to be very different. Not only
>     about which properties you'll have, but also what you will place
>     in these properties. reg for example have the memory address of
>     the buffer in the simplefb case, while in the KMS driver case, it
>     would have the memory address of the registers.
>   - There's will be a single driver probed. So if you want to go down
>     the hand over road (which is a bit premature at this point if you
>     ask me, but anyway), you will have no driver probed to hand over
>     to.

The graphic drivers have already been down this road before. Simplefb
should be a driver library not a driver. DRM is also a driver library.

So to implement simplefb whip up a real skeleton driver for the video
hardware that parses the DT and then pokes the appropriate info into
the simplefb library. Initially that driver will just include the
calls out to the simplefb library. Later on it can get KMS
implemented.  This real driver will get bound to the hardware and have
a dependency that loads the simplefb driver library.

Now there is no handover problem. Only a single driver is ever
attached to the hardware. When it wants to go into KMS mode it makes a
call into the simplefb library to shut down whatever it is doing.

But you still need a mechanism for uboot to signal that it has set up
simplefb. Adding a dynamic node like this might work...

video0: video at 01c21800 {
   compatible = "allwinner,sun4i-a10-video";
   clocks = <&apb0_gates 6>, <&ir0_clk>;
   clock-names = "apb", "video";
   interrupts = <0 5 4>;
   reg = <0x01c21800 0x40>;
   status = "enabled";
   simplefb {
       new namespace for simplefb parameters
   }
};

I would have suggested a driver library earlier but it has been a
while since I worked on DRM and I forgot about it.



>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 02:49 AM, David Herrmann wrote:
> Hi
>
> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> The next commit will handle clocks correctly, so that these do not get
>>> automatically disabled on certain SoC simplefb implementations. As a
>>> result, the removal of this simplefb driver, and the release of the
>>> clocks, is rather final, and only a full display driver can work after
>>> this. So, it makes sense to also flag the dt node as disabled, even
>>> though it has no real value today.
>>>
>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>
>> Please, no.
>>
>> Drivers should not be modifying the device tree without and
>> exceptionally good reason for doing so. Drivers are to treat the DT as
>> immutable.
>>
>> * the exception is an overlay driver which add new devices to the
>> kernel. Definitely not the case here.
>
> Why? I think we have exactly that case:
>   * DT describes the real hw properly and those parts are immutable
>   * Additionally, bootloaders create firmware-framebuffers and
>     create simple-framebuffer devices for them. Those are
>     valid as long as no driver reconfigured the real hw.
>   * Once a real hw-driver loads, it might destroy the existing
>     framebuffers, thus, it should also destroy the platform device.
>   * If the real hw-driver is unloaded, it might re-create the FB
>     and thus create a new (or enable the old) platform device.

My intention was always that a bootloader's addition of a simplefb node 
to the DT would be user-configurable or driven by the original DT 
content. As such, there shouldn't ever be both a DT node describing the 
"real" HW and simplefb. In other words, if the DT already has the "real" 
DT node, the bootloader should automatically (or under user command) not 
add the simpefb node.

[PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 02:49 AM, David Herrmann wrote:
> Hi
>
> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> The next commit will handle clocks correctly, so that these do not get
>>> automatically disabled on certain SoC simplefb implementations. As a
>>> result, the removal of this simplefb driver, and the release of the
>>> clocks, is rather final, and only a full display driver can work after
>>> this. So, it makes sense to also flag the dt node as disabled, even
>>> though it has no real value today.
>>>
>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>
>> Please, no.
>>
>> Drivers should not be modifying the device tree without and
>> exceptionally good reason for doing so. Drivers are to treat the DT as
>> immutable.
>>
>> * the exception is an overlay driver which add new devices to the
>> kernel. Definitely not the case here.
>
> Why? I think we have exactly that case:
>   * DT describes the real hw properly and those parts are immutable
>   * Additionally, bootloaders create firmware-framebuffers and
>     create simple-framebuffer devices for them. Those are
>     valid as long as no driver reconfigured the real hw.
>   * Once a real hw-driver loads, it might destroy the existing
>     framebuffers, thus, it should also destroy the platform device.
>   * If the real hw-driver is unloaded, it might re-create the FB
>     and thus create a new (or enable the old) platform device.

My intention was always that a bootloader's addition of a simplefb node 
to the DT would be user-configurable or driven by the original DT 
content. As such, there shouldn't ever be both a DT node describing the 
"real" HW and simplefb. In other words, if the DT already has the "real" 
DT node, the bootloader should automatically (or under user command) not 
add the simpefb node.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>
>> Hi
>>
>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>>
>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>
>>>> The next commit will handle clocks correctly, so that these do not get
>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>> result, the removal of this simplefb driver, and the release of the
>>>> clocks, is rather final, and only a full display driver can work after
>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>> though it has no real value today.
>>>>
>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>
>>>
>>> Please, no.
>>>
>>> Drivers should not be modifying the device tree without and
>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>> immutable.
>>>
>>> * the exception is an overlay driver which add new devices to the
>>> kernel. Definitely not the case here.
>>
>>
>> Why? I think we have exactly that case:
>>   * DT describes the real hw properly and those parts are immutable
>>   * Additionally, bootloaders create firmware-framebuffers and
>>     create simple-framebuffer devices for them. Those are
>>     valid as long as no driver reconfigured the real hw.
>>   * Once a real hw-driver loads, it might destroy the existing
>>     framebuffers, thus, it should also destroy the platform device.
>>   * If the real hw-driver is unloaded, it might re-create the FB
>>     and thus create a new (or enable the old) platform device.
>
>
> My intention was always that a bootloader's addition of a simplefb node to
> the DT would be user-configurable or driven by the original DT content. As
> such, there shouldn't ever be both a DT node describing the "real" HW and
> simplefb. In other words, if the DT already has the "real" DT node, the
> bootloader should automatically (or under user command) not add the simpefb
> node.

DT is just the wrong mechanism to signal this, use an ATAG or kernel
command line parameter.

real hardware has compatible = "real-hardware-name, simplefb"

simplefb is built into kernel. It will attach to the device because of
the compatible string. Then it can look at the command line and see if
the bootloader also supported simplefb and already set things up.

Then some mechanism will have to be designed to arrange a handoff
between simplefb and the chip specific KMS driver. But that's a Linux
problem, not a DT one.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>
>> Hi
>>
>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>>
>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>
>>>> The next commit will handle clocks correctly, so that these do not get
>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>> result, the removal of this simplefb driver, and the release of the
>>>> clocks, is rather final, and only a full display driver can work after
>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>> though it has no real value today.
>>>>
>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>
>>>
>>> Please, no.
>>>
>>> Drivers should not be modifying the device tree without and
>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>> immutable.
>>>
>>> * the exception is an overlay driver which add new devices to the
>>> kernel. Definitely not the case here.
>>
>>
>> Why? I think we have exactly that case:
>>   * DT describes the real hw properly and those parts are immutable
>>   * Additionally, bootloaders create firmware-framebuffers and
>>     create simple-framebuffer devices for them. Those are
>>     valid as long as no driver reconfigured the real hw.
>>   * Once a real hw-driver loads, it might destroy the existing
>>     framebuffers, thus, it should also destroy the platform device.
>>   * If the real hw-driver is unloaded, it might re-create the FB
>>     and thus create a new (or enable the old) platform device.
>
>
> My intention was always that a bootloader's addition of a simplefb node to
> the DT would be user-configurable or driven by the original DT content. As
> such, there shouldn't ever be both a DT node describing the "real" HW and
> simplefb. In other words, if the DT already has the "real" DT node, the
> bootloader should automatically (or under user command) not add the simpefb
> node.

DT is just the wrong mechanism to signal this, use an ATAG or kernel
command line parameter.

real hardware has compatible = "real-hardware-name, simplefb"

simplefb is built into kernel. It will attach to the device because of
the compatible string. Then it can look at the command line and see if
the bootloader also supported simplefb and already set things up.

Then some mechanism will have to be designed to arrange a handoff
between simplefb and the chip specific KMS driver. But that's a Linux
problem, not a DT one.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 11:26 AM, jonsmirl@gmail.com wrote:
> On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>>
>>> Hi
>>>
>>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>>> <grant.likely@secretlab.ca> wrote:
>>>>
>>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>>
>>>>> The next commit will handle clocks correctly, so that these do not get
>>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>>> result, the removal of this simplefb driver, and the release of the
>>>>> clocks, is rather final, and only a full display driver can work after
>>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>>> though it has no real value today.
>>>>>
>>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>>
>>>>
>>>> Please, no.
>>>>
>>>> Drivers should not be modifying the device tree without and
>>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>>> immutable.
>>>>
>>>> * the exception is an overlay driver which add new devices to the
>>>> kernel. Definitely not the case here.
>>>
>>>
>>> Why? I think we have exactly that case:
>>>    * DT describes the real hw properly and those parts are immutable
>>>    * Additionally, bootloaders create firmware-framebuffers and
>>>      create simple-framebuffer devices for them. Those are
>>>      valid as long as no driver reconfigured the real hw.
>>>    * Once a real hw-driver loads, it might destroy the existing
>>>      framebuffers, thus, it should also destroy the platform device.
>>>    * If the real hw-driver is unloaded, it might re-create the FB
>>>      and thus create a new (or enable the old) platform device.
>>
>>
>> My intention was always that a bootloader's addition of a simplefb node to
>> the DT would be user-configurable or driven by the original DT content. As
>> such, there shouldn't ever be both a DT node describing the "real" HW and
>> simplefb. In other words, if the DT already has the "real" DT node, the
>> bootloader should automatically (or under user command) not add the simpefb
>> node.
>
> DT is just the wrong mechanism to signal this, use an ATAG or kernel
> command line parameter.
>
> real hardware has compatible = "real-hardware-name, simplefb"
>
> simplefb is built into kernel. It will attach to the device because of
> the compatible string. Then it can look at the command line and see if
> the bootloader also supported simplefb and already set things up.
>
> Then some mechanism will have to be designed to arrange a handoff
> between simplefb and the chip specific KMS driver. But that's a Linux
> problem, not a DT one.

Having a single DT node that conforms to both the binding for 
"real-hardware-name" and "simplefb" doesn't seem like a good approach. 
What if the properties required by the two bindings conflict in some 
way? The approach you advocate certainly hasn't ever been used AFAIK.

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[Stephen Warren]

On 08/13/2014 11:26 AM, jonsmirl at gmail.com wrote:
> On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>>
>>> Hi
>>>
>>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>>> <grant.likely@secretlab.ca> wrote:
>>>>
>>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>>
>>>>> The next commit will handle clocks correctly, so that these do not get
>>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>>> result, the removal of this simplefb driver, and the release of the
>>>>> clocks, is rather final, and only a full display driver can work after
>>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>>> though it has no real value today.
>>>>>
>>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>>
>>>>
>>>> Please, no.
>>>>
>>>> Drivers should not be modifying the device tree without and
>>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>>> immutable.
>>>>
>>>> * the exception is an overlay driver which add new devices to the
>>>> kernel. Definitely not the case here.
>>>
>>>
>>> Why? I think we have exactly that case:
>>>    * DT describes the real hw properly and those parts are immutable
>>>    * Additionally, bootloaders create firmware-framebuffers and
>>>      create simple-framebuffer devices for them. Those are
>>>      valid as long as no driver reconfigured the real hw.
>>>    * Once a real hw-driver loads, it might destroy the existing
>>>      framebuffers, thus, it should also destroy the platform device.
>>>    * If the real hw-driver is unloaded, it might re-create the FB
>>>      and thus create a new (or enable the old) platform device.
>>
>>
>> My intention was always that a bootloader's addition of a simplefb node to
>> the DT would be user-configurable or driven by the original DT content. As
>> such, there shouldn't ever be both a DT node describing the "real" HW and
>> simplefb. In other words, if the DT already has the "real" DT node, the
>> bootloader should automatically (or under user command) not add the simpefb
>> node.
>
> DT is just the wrong mechanism to signal this, use an ATAG or kernel
> command line parameter.
>
> real hardware has compatible = "real-hardware-name, simplefb"
>
> simplefb is built into kernel. It will attach to the device because of
> the compatible string. Then it can look at the command line and see if
> the bootloader also supported simplefb and already set things up.
>
> Then some mechanism will have to be designed to arrange a handoff
> between simplefb and the chip specific KMS driver. But that's a Linux
> problem, not a DT one.

Having a single DT node that conforms to both the binding for 
"real-hardware-name" and "simplefb" doesn't seem like a good approach. 
What if the properties required by the two bindings conflict in some 
way? The approach you advocate certainly hasn't ever been used AFAIK.

Re: [linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl]

On Wed, Aug 13, 2014 at 1:34 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/13/2014 11:26 AM, jonsmirl@gmail.com wrote:
>>
>> On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>>>
>>>>
>>>> Hi
>>>>
>>>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>>>> <grant.likely@secretlab.ca> wrote:
>>>>>
>>>>>
>>>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>>>
>>>>>>
>>>>>> The next commit will handle clocks correctly, so that these do not get
>>>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>>>> result, the removal of this simplefb driver, and the release of the
>>>>>> clocks, is rather final, and only a full display driver can work after
>>>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>>>> though it has no real value today.
>>>>>>
>>>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>>>
>>>>>
>>>>>
>>>>> Please, no.
>>>>>
>>>>> Drivers should not be modifying the device tree without and
>>>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>>>> immutable.
>>>>>
>>>>> * the exception is an overlay driver which add new devices to the
>>>>> kernel. Definitely not the case here.
>>>>
>>>>
>>>>
>>>> Why? I think we have exactly that case:
>>>>    * DT describes the real hw properly and those parts are immutable
>>>>    * Additionally, bootloaders create firmware-framebuffers and
>>>>      create simple-framebuffer devices for them. Those are
>>>>      valid as long as no driver reconfigured the real hw.
>>>>    * Once a real hw-driver loads, it might destroy the existing
>>>>      framebuffers, thus, it should also destroy the platform device.
>>>>    * If the real hw-driver is unloaded, it might re-create the FB
>>>>      and thus create a new (or enable the old) platform device.
>>>
>>>
>>>
>>> My intention was always that a bootloader's addition of a simplefb node
>>> to
>>> the DT would be user-configurable or driven by the original DT content.
>>> As
>>> such, there shouldn't ever be both a DT node describing the "real" HW and
>>> simplefb. In other words, if the DT already has the "real" DT node, the
>>> bootloader should automatically (or under user command) not add the
>>> simpefb
>>> node.
>>
>>
>> DT is just the wrong mechanism to signal this, use an ATAG or kernel
>> command line parameter.
>>
>> real hardware has compatible = "real-hardware-name, simplefb"
>>
>> simplefb is built into kernel. It will attach to the device because of
>> the compatible string. Then it can look at the command line and see if
>> the bootloader also supported simplefb and already set things up.
>>
>> Then some mechanism will have to be designed to arrange a handoff
>> between simplefb and the chip specific KMS driver. But that's a Linux
>> problem, not a DT one.
>
>
> Having a single DT node that conforms to both the binding for
> "real-hardware-name" and "simplefb" doesn't seem like a good approach. What
> if the properties required by the two bindings conflict in some way? The
> approach you advocate certainly hasn't ever been used AFAIK.

I believe we do have something like this - SPI core implements a lot
of core DT functions. All SPI nodes use this core. Then hardware
specific attributes are added.

The conflicts would need to get sorted out. That's why we should have
a schema in place for device tree. Then the properties for specific
video hardware would inherit from the properties for simplefb.

-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 3/4] simplefb: disable dt node upon remove

[jonsmirl at gmail.com]

On Wed, Aug 13, 2014 at 1:34 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/13/2014 11:26 AM, jonsmirl at gmail.com wrote:
>>
>> On Wed, Aug 13, 2014 at 12:44 PM, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> On 08/13/2014 02:49 AM, David Herrmann wrote:
>>>>
>>>>
>>>> Hi
>>>>
>>>> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
>>>> <grant.likely@secretlab.ca> wrote:
>>>>>
>>>>>
>>>>> On Wed, Aug 13, 2014 at 8:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>>>
>>>>>>
>>>>>> The next commit will handle clocks correctly, so that these do not get
>>>>>> automatically disabled on certain SoC simplefb implementations. As a
>>>>>> result, the removal of this simplefb driver, and the release of the
>>>>>> clocks, is rather final, and only a full display driver can work after
>>>>>> this. So, it makes sense to also flag the dt node as disabled, even
>>>>>> though it has no real value today.
>>>>>>
>>>>>> Signed-off-by: Luc Verhaegen <libv@skynet.be>
>>>>>
>>>>>
>>>>>
>>>>> Please, no.
>>>>>
>>>>> Drivers should not be modifying the device tree without and
>>>>> exceptionally good reason for doing so. Drivers are to treat the DT as
>>>>> immutable.
>>>>>
>>>>> * the exception is an overlay driver which add new devices to the
>>>>> kernel. Definitely not the case here.
>>>>
>>>>
>>>>
>>>> Why? I think we have exactly that case:
>>>>    * DT describes the real hw properly and those parts are immutable
>>>>    * Additionally, bootloaders create firmware-framebuffers and
>>>>      create simple-framebuffer devices for them. Those are
>>>>      valid as long as no driver reconfigured the real hw.
>>>>    * Once a real hw-driver loads, it might destroy the existing
>>>>      framebuffers, thus, it should also destroy the platform device.
>>>>    * If the real hw-driver is unloaded, it might re-create the FB
>>>>      and thus create a new (or enable the old) platform device.
>>>
>>>
>>>
>>> My intention was always that a bootloader's addition of a simplefb node
>>> to
>>> the DT would be user-configurable or driven by the original DT content.
>>> As
>>> such, there shouldn't ever be both a DT node describing the "real" HW and
>>> simplefb. In other words, if the DT already has the "real" DT node, the
>>> bootloader should automatically (or under user command) not add the
>>> simpefb
>>> node.
>>
>>
>> DT is just the wrong mechanism to signal this, use an ATAG or kernel
>> command line parameter.
>>
>> real hardware has compatible = "real-hardware-name, simplefb"
>>
>> simplefb is built into kernel. It will attach to the device because of
>> the compatible string. Then it can look at the command line and see if
>> the bootloader also supported simplefb and already set things up.
>>
>> Then some mechanism will have to be designed to arrange a handoff
>> between simplefb and the chip specific KMS driver. But that's a Linux
>> problem, not a DT one.
>
>
> Having a single DT node that conforms to both the binding for
> "real-hardware-name" and "simplefb" doesn't seem like a good approach. What
> if the properties required by the two bindings conflict in some way? The
> approach you advocate certainly hasn't ever been used AFAIK.

I believe we do have something like this - SPI core implements a lot
of core DT functions. All SPI nodes use this core. Then hardware
specific attributes are added.

The conflicts would need to get sorted out. That's why we should have
a schema in place for device tree. Then the properties for specific
video hardware would inherit from the properties for simplefb.

-- 
Jon Smirl
jonsmirl at gmail.com

[PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

This claims and enables clocks listed in the simple framebuffer dt node.
This is needed so that the display engine, in case the required clocks
are known by the kernel code and are described in the dt, will remain
properly enabled.

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |  103 +++++++++++++++++++++++++++++++++++++++-
 1 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 74c4b2a..481dbfd 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -26,6 +26,7 @@
 #include <linux/module.h>
 #include <linux/platform_data/simplefb.h>
 #include <linux/platform_device.h>
+#include <linux/clk-provider.h>
 
 static struct fb_fix_screeninfo simplefb_fix = {
 	.id		= "simple",
@@ -191,8 +192,101 @@ static int simplefb_parse_pd(struct platform_device *pdev,
 	return 0;
 }
 
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ */
+struct simplefb_clock {
+	struct list_head list;
+	struct clk *clock;
+};
+
+/*
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static void
+simplefb_clocks_init(struct platform_device *pdev, struct list_head *list)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int clock_count, i;
+
+	INIT_LIST_HEAD(list);
+
+	if (dev_get_platdata(&pdev->dev) || !np)
+		return;
+
+	clock_count = of_clk_get_parent_count(np);
+	for (i = 0; i < clock_count; i++) {
+		struct simplefb_clock *entry;
+		struct clk *clock = of_clk_get(np, i);
+		int ret;
+
+		if (IS_ERR(clock)) {
+			dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
+			       __func__, i, PTR_ERR(clock));
+			continue;
+		}
+
+		ret = clk_prepare_enable(clock);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"%s: failed to enable clock %d: %d\n",
+			       __func__, i, ret);
+			clk_put(clock);
+			continue;
+		}
+
+		entry = kzalloc(sizeof(struct simplefb_clock), GFP_KERNEL);
+		if (!entry) {
+			dev_err(&pdev->dev,
+				"%s: failed to alloc clock %d list entry.\n",
+			       __func__, i);
+			clk_disable_unprepare(clock);
+			clk_put(clock);
+			continue;
+		}
+
+		entry->clock = clock;
+		/*
+		 * add to the front of the list, so we disable clocks in the
+		 * correct order.
+		 */
+		list_add(&entry->list, list);
+	}
+}
+
+static void
+simplefb_clocks_destroy(struct list_head *list)
+{
+	struct list_head *pos, *n;
+
+	list_for_each_safe(pos, n, list) {
+		struct simplefb_clock *entry +			container_of(pos, struct simplefb_clock, list);
+
+		list_del(&entry->list);
+
+		clk_disable_unprepare(entry->clock);
+		clk_put(entry->clock);
+		kfree(entry);
+	}
+}
+
 struct simplefb_par {
 	u32 palette[PSEUDO_PALETTE_SIZE];
+	struct list_head clock_list[1];
 };
 
 static int simplefb_probe(struct platform_device *pdev)
@@ -265,6 +359,8 @@ static int simplefb_probe(struct platform_device *pdev)
 	}
 	info->pseudo_palette = (void *) par->palette;
 
+	simplefb_clocks_init(pdev, par->clock_list);
+
 	dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
 			     info->fix.smem_start, info->fix.smem_len,
 			     info->screen_base);
@@ -276,14 +372,15 @@ static int simplefb_probe(struct platform_device *pdev)
 	ret = register_framebuffer(info);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
-		goto error_unmap;
+		goto error_clocks;
 	}
 
 	dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
 
 	return 0;
 
- error_unmap:
+ error_clocks:
+	simplefb_clocks_destroy(par->clock_list);
 	iounmap(info->screen_base);
 
  error_fb_release:
@@ -299,8 +396,10 @@ static int simplefb_probe(struct platform_device *pdev)
 static int simplefb_remove(struct platform_device *pdev)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
+	struct simplefb_par *par = info->par;
 
 	unregister_framebuffer(info);
+	simplefb_clocks_destroy(par->clock_list);
 	framebuffer_release(info);
 	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
 		simplefb_dt_disable(pdev);
-- 
1.7.7

[PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

This claims and enables clocks listed in the simple framebuffer dt node.
This is needed so that the display engine, in case the required clocks
are known by the kernel code and are described in the dt, will remain
properly enabled.

Signed-off-by: Luc Verhaegen <libv@skynet.be>
---
 drivers/video/fbdev/simplefb.c |  103 +++++++++++++++++++++++++++++++++++++++-
 1 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 74c4b2a..481dbfd 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -26,6 +26,7 @@
 #include <linux/module.h>
 #include <linux/platform_data/simplefb.h>
 #include <linux/platform_device.h>
+#include <linux/clk-provider.h>
 
 static struct fb_fix_screeninfo simplefb_fix = {
 	.id		= "simple",
@@ -191,8 +192,101 @@ static int simplefb_parse_pd(struct platform_device *pdev,
 	return 0;
 }
 
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ */
+struct simplefb_clock {
+	struct list_head list;
+	struct clk *clock;
+};
+
+/*
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static void
+simplefb_clocks_init(struct platform_device *pdev, struct list_head *list)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int clock_count, i;
+
+	INIT_LIST_HEAD(list);
+
+	if (dev_get_platdata(&pdev->dev) || !np)
+		return;
+
+	clock_count = of_clk_get_parent_count(np);
+	for (i = 0; i < clock_count; i++) {
+		struct simplefb_clock *entry;
+		struct clk *clock = of_clk_get(np, i);
+		int ret;
+
+		if (IS_ERR(clock)) {
+			dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
+			       __func__, i, PTR_ERR(clock));
+			continue;
+		}
+
+		ret = clk_prepare_enable(clock);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"%s: failed to enable clock %d: %d\n",
+			       __func__, i, ret);
+			clk_put(clock);
+			continue;
+		}
+
+		entry = kzalloc(sizeof(struct simplefb_clock), GFP_KERNEL);
+		if (!entry) {
+			dev_err(&pdev->dev,
+				"%s: failed to alloc clock %d list entry.\n",
+			       __func__, i);
+			clk_disable_unprepare(clock);
+			clk_put(clock);
+			continue;
+		}
+
+		entry->clock = clock;
+		/*
+		 * add to the front of the list, so we disable clocks in the
+		 * correct order.
+		 */
+		list_add(&entry->list, list);
+	}
+}
+
+static void
+simplefb_clocks_destroy(struct list_head *list)
+{
+	struct list_head *pos, *n;
+
+	list_for_each_safe(pos, n, list) {
+		struct simplefb_clock *entry =
+			container_of(pos, struct simplefb_clock, list);
+
+		list_del(&entry->list);
+
+		clk_disable_unprepare(entry->clock);
+		clk_put(entry->clock);
+		kfree(entry);
+	}
+}
+
 struct simplefb_par {
 	u32 palette[PSEUDO_PALETTE_SIZE];
+	struct list_head clock_list[1];
 };
 
 static int simplefb_probe(struct platform_device *pdev)
@@ -265,6 +359,8 @@ static int simplefb_probe(struct platform_device *pdev)
 	}
 	info->pseudo_palette = (void *) par->palette;
 
+	simplefb_clocks_init(pdev, par->clock_list);
+
 	dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
 			     info->fix.smem_start, info->fix.smem_len,
 			     info->screen_base);
@@ -276,14 +372,15 @@ static int simplefb_probe(struct platform_device *pdev)
 	ret = register_framebuffer(info);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
-		goto error_unmap;
+		goto error_clocks;
 	}
 
 	dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
 
 	return 0;
 
- error_unmap:
+ error_clocks:
+	simplefb_clocks_destroy(par->clock_list);
 	iounmap(info->screen_base);
 
  error_fb_release:
@@ -299,8 +396,10 @@ static int simplefb_probe(struct platform_device *pdev)
 static int simplefb_remove(struct platform_device *pdev)
 {
 	struct fb_info *info = platform_get_drvdata(pdev);
+	struct simplefb_par *par = info->par;
 
 	unregister_framebuffer(info);
+	simplefb_clocks_destroy(par->clock_list);
 	framebuffer_release(info);
 	if (!dev_get_platdata(&pdev->dev) && pdev->dev.of_node)
 		simplefb_dt_disable(pdev);
-- 
1.7.7

Re: [PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> This claims and enables clocks listed in the simple framebuffer dt node.
> This is needed so that the display engine, in case the required clocks
> are known by the kernel code and are described in the dt, will remain
> properly enabled.

I think this make simplefb not simple any more, which rather goes 
against the whole point of it.

I specifically conceived simplefb to know about nothing more than the 
memory address and pixel layout of the memory buffer. I certainly don't 
like the idea of expanding simplefb to anything beyond that, and IIRC 
*not* extending is was a condition agreed when it was first merged. If 
more knowledge than that is required, then there needs to be a 
HW-specific driver to manage any clocks/resets/video registers, etc.

The correct way to handle this without a complete DRM/KMS/... driver is 
to avoid the clocks in question being turned off at boot. I thought 
there was a per-clock flag to prevent disabling an unused clock? If not, 
perhaps the clock driver should force the clock to be enabled (perhaps 
only if the DRM/KMS driver isn't enabled?). For example, the Tegra clock 
driver has a clock initialization table which IIRC was used for this 
purpose before we got a DRM/KMS driver. That way, all the details are 
kept inside the kernel code, and don't end up influencing the DT 
representation of simplefb.

[PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> This claims and enables clocks listed in the simple framebuffer dt node.
> This is needed so that the display engine, in case the required clocks
> are known by the kernel code and are described in the dt, will remain
> properly enabled.

I think this make simplefb not simple any more, which rather goes 
against the whole point of it.

I specifically conceived simplefb to know about nothing more than the 
memory address and pixel layout of the memory buffer. I certainly don't 
like the idea of expanding simplefb to anything beyond that, and IIRC 
*not* extending is was a condition agreed when it was first merged. If 
more knowledge than that is required, then there needs to be a 
HW-specific driver to manage any clocks/resets/video registers, etc.

The correct way to handle this without a complete DRM/KMS/... driver is 
to avoid the clocks in question being turned off at boot. I thought 
there was a per-clock flag to prevent disabling an unused clock? If not, 
perhaps the clock driver should force the clock to be enabled (perhaps 
only if the DRM/KMS driver isn't enabled?). For example, the Tegra clock 
driver has a clock initialization table which IIRC was used for this 
purpose before we got a DRM/KMS driver. That way, all the details are 
kept inside the kernel code, and don't end up influencing the DT 
representation of simplefb.

Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>
> I think this make simplefb not simple any more, which rather goes  
> against the whole point of it.
>
> I specifically conceived simplefb to know about nothing more than the  
> memory address and pixel layout of the memory buffer. I certainly don't  
> like the idea of expanding simplefb to anything beyond that, and IIRC  
> *not* extending is was a condition agreed when it was first merged. If  
> more knowledge than that is required, then there needs to be a  
> HW-specific driver to manage any clocks/resets/video registers, etc.

Yes. Simplefb quickly becomes anything but, doesn't it. Perhaps DenialFB 
would've been a better name for it ;p

> The correct way to handle this without a complete DRM/KMS/... driver is  
> to avoid the clocks in question being turned off at boot. I thought  
> there was a per-clock flag to prevent disabling an unused clock? If not,  
> perhaps the clock driver should force the clock to be enabled (perhaps  
> only if the DRM/KMS driver isn't enabled?). For example, the Tegra clock  
> driver has a clock initialization table which IIRC was used for this  
> purpose before we got a DRM/KMS driver. That way, all the details are  
> kept inside the kernel code, and don't end up influencing the DT  
> representation of simplefb.

How was simplefb handled on tegra? Where is the code for that? I didn't 
see anything in u-boot for instance.

But the code for handling clocks where they are supposed to be handled 
is pretty generic from where i sit.

Luc Verhaegen.

[PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>
> I think this make simplefb not simple any more, which rather goes  
> against the whole point of it.
>
> I specifically conceived simplefb to know about nothing more than the  
> memory address and pixel layout of the memory buffer. I certainly don't  
> like the idea of expanding simplefb to anything beyond that, and IIRC  
> *not* extending is was a condition agreed when it was first merged. If  
> more knowledge than that is required, then there needs to be a  
> HW-specific driver to manage any clocks/resets/video registers, etc.

Yes. Simplefb quickly becomes anything but, doesn't it. Perhaps DenialFB 
would've been a better name for it ;p

> The correct way to handle this without a complete DRM/KMS/... driver is  
> to avoid the clocks in question being turned off at boot. I thought  
> there was a per-clock flag to prevent disabling an unused clock? If not,  
> perhaps the clock driver should force the clock to be enabled (perhaps  
> only if the DRM/KMS driver isn't enabled?). For example, the Tegra clock  
> driver has a clock initialization table which IIRC was used for this  
> purpose before we got a DRM/KMS driver. That way, all the details are  
> kept inside the kernel code, and don't end up influencing the DT  
> representation of simplefb.

How was simplefb handled on tegra? Where is the code for that? I didn't 
see anything in u-boot for instance.

But the code for handling clocks where they are supposed to be handled 
is pretty generic from where i sit.

Luc Verhaegen.

Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> >This claims and enables clocks listed in the simple framebuffer dt node.
> >This is needed so that the display engine, in case the required clocks
> >are known by the kernel code and are described in the dt, will remain
> >properly enabled.
> 
> I think this make simplefb not simple any more, which rather goes
> against the whole point of it.
> 
> I specifically conceived simplefb to know about nothing more than
> the memory address and pixel layout of the memory buffer. I
> certainly don't like the idea of expanding simplefb to anything
> beyond that, and IIRC *not* extending is was a condition agreed when
> it was first merged. If more knowledge than that is required, then
> there needs to be a HW-specific driver to manage any
> clocks/resets/video registers, etc.

I'm sorry, but how is that not simple? clocks enabling is step 1 in a
driver in order to communicate somehow with the controller. Reset is a
different story, because arguably, if simplefb is there, the
controller is already out of reset.

And I don't see why video registers are coming into the discussion
here. The code Luc posted doesn't access any register, at all. It just
makes sure the needed controller keep going.

> The correct way to handle this without a complete DRM/KMS/... driver
> is to avoid the clocks in question being turned off at boot.

Which is exactly what this code does, using the generic DT bindings to
express dependency for a given clock. How is this wrong?

> I thought there was a per-clock flag to prevent disabling an unused
> clock?

No, last time I heard, Mike Turquette was against it.

> If not, perhaps the clock driver should force the clock to be
> enabled (perhaps only if the DRM/KMS driver isn't enabled?).

I'm sorry, but I'm not going to take any code that will do that in our
clock driver.

I'm not going to have a huge list of ifdef depending on configuration
options to know which clock to enable, especially when clk_get should
have the consumer device as an argument.

> For example, the Tegra clock driver has a clock initialization table
> which IIRC was used for this purpose before we got a DRM/KMS driver.
> That way, all the details are kept inside the kernel code, and don't
> end up influencing the DT representation of simplefb.

I don't really see how the optional usage of a generic property
influences badly the DT representation of simplefb.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
> >This claims and enables clocks listed in the simple framebuffer dt node.
> >This is needed so that the display engine, in case the required clocks
> >are known by the kernel code and are described in the dt, will remain
> >properly enabled.
> 
> I think this make simplefb not simple any more, which rather goes
> against the whole point of it.
> 
> I specifically conceived simplefb to know about nothing more than
> the memory address and pixel layout of the memory buffer. I
> certainly don't like the idea of expanding simplefb to anything
> beyond that, and IIRC *not* extending is was a condition agreed when
> it was first merged. If more knowledge than that is required, then
> there needs to be a HW-specific driver to manage any
> clocks/resets/video registers, etc.

I'm sorry, but how is that not simple? clocks enabling is step 1 in a
driver in order to communicate somehow with the controller. Reset is a
different story, because arguably, if simplefb is there, the
controller is already out of reset.

And I don't see why video registers are coming into the discussion
here. The code Luc posted doesn't access any register, at all. It just
makes sure the needed controller keep going.

> The correct way to handle this without a complete DRM/KMS/... driver
> is to avoid the clocks in question being turned off at boot.

Which is exactly what this code does, using the generic DT bindings to
express dependency for a given clock. How is this wrong?

> I thought there was a per-clock flag to prevent disabling an unused
> clock?

No, last time I heard, Mike Turquette was against it.

> If not, perhaps the clock driver should force the clock to be
> enabled (perhaps only if the DRM/KMS driver isn't enabled?).

I'm sorry, but I'm not going to take any code that will do that in our
clock driver.

I'm not going to have a huge list of ifdef depending on configuration
options to know which clock to enable, especially when clk_get should
have the consumer device as an argument.

> For example, the Tegra clock driver has a clock initialization table
> which IIRC was used for this purpose before we got a DRM/KMS driver.
> That way, all the details are kept inside the kernel code, and don't
> end up influencing the DT representation of simplefb.

I don't really see how the optional usage of a generic property
influences badly the DT representation of simplefb.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140813/a2333ac8/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/13/2014 07:01 PM, Maxime Ripard wrote:
> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>> This is needed so that the display engine, in case the required clocks
>>> are known by the kernel code and are described in the dt, will remain
>>> properly enabled.
>>
>> I think this make simplefb not simple any more, which rather goes
>> against the whole point of it.
>>
>> I specifically conceived simplefb to know about nothing more than
>> the memory address and pixel layout of the memory buffer. I
>> certainly don't like the idea of expanding simplefb to anything
>> beyond that, and IIRC *not* extending is was a condition agreed when
>> it was first merged. If more knowledge than that is required, then
>> there needs to be a HW-specific driver to manage any
>> clocks/resets/video registers, etc.
> 
> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
> driver in order to communicate somehow with the controller. Reset is a
> different story, because arguably, if simplefb is there, the
> controller is already out of reset.
> 
> And I don't see why video registers are coming into the discussion
> here. The code Luc posted doesn't access any register, at all. It just
> makes sure the needed controller keep going.
> 
>> The correct way to handle this without a complete DRM/KMS/... driver
>> is to avoid the clocks in question being turned off at boot.
> 
> Which is exactly what this code does, using the generic DT bindings to
> express dependency for a given clock. How is this wrong?
> 
>> I thought there was a per-clock flag to prevent disabling an unused
>> clock?
> 
> No, last time I heard, Mike Turquette was against it.
> 
>> If not, perhaps the clock driver should force the clock to be
>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> 
> I'm sorry, but I'm not going to take any code that will do that in our
> clock driver.
> 
> I'm not going to have a huge list of ifdef depending on configuration
> options to know which clock to enable, especially when clk_get should
> have the consumer device as an argument.
> 
>> For example, the Tegra clock driver has a clock initialization table
>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>> That way, all the details are kept inside the kernel code, and don't
>> end up influencing the DT representation of simplefb.
> 
> I don't really see how the optional usage of a generic property
> influences badly the DT representation of simplefb.

+1 to all that Maxime said.

Also as can be seen in other discussion on this patch set, simplefb
should not be seen as something orthogonal to having a full kms driver.

So just write a full kms driver is not the answer IMHO. What we want
is for a bootloader setup console to be available through simplefb
bindings so that the kernel can show output without depending on
module loading, and thus can show errors if things go bad before
a kms driver gets loaded.

And no build kms into the kernel is not the answer. We've all been
working hard to be able to build more generic kernels, so as to get
generic distro support. And generic distros will build kms as modules,
as there are simply to many different kms drivers to build them all
in.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/13/2014 07:01 PM, Maxime Ripard wrote:
> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>> This is needed so that the display engine, in case the required clocks
>>> are known by the kernel code and are described in the dt, will remain
>>> properly enabled.
>>
>> I think this make simplefb not simple any more, which rather goes
>> against the whole point of it.
>>
>> I specifically conceived simplefb to know about nothing more than
>> the memory address and pixel layout of the memory buffer. I
>> certainly don't like the idea of expanding simplefb to anything
>> beyond that, and IIRC *not* extending is was a condition agreed when
>> it was first merged. If more knowledge than that is required, then
>> there needs to be a HW-specific driver to manage any
>> clocks/resets/video registers, etc.
> 
> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
> driver in order to communicate somehow with the controller. Reset is a
> different story, because arguably, if simplefb is there, the
> controller is already out of reset.
> 
> And I don't see why video registers are coming into the discussion
> here. The code Luc posted doesn't access any register, at all. It just
> makes sure the needed controller keep going.
> 
>> The correct way to handle this without a complete DRM/KMS/... driver
>> is to avoid the clocks in question being turned off at boot.
> 
> Which is exactly what this code does, using the generic DT bindings to
> express dependency for a given clock. How is this wrong?
> 
>> I thought there was a per-clock flag to prevent disabling an unused
>> clock?
> 
> No, last time I heard, Mike Turquette was against it.
> 
>> If not, perhaps the clock driver should force the clock to be
>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> 
> I'm sorry, but I'm not going to take any code that will do that in our
> clock driver.
> 
> I'm not going to have a huge list of ifdef depending on configuration
> options to know which clock to enable, especially when clk_get should
> have the consumer device as an argument.
> 
>> For example, the Tegra clock driver has a clock initialization table
>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>> That way, all the details are kept inside the kernel code, and don't
>> end up influencing the DT representation of simplefb.
> 
> I don't really see how the optional usage of a generic property
> influences badly the DT representation of simplefb.

+1 to all that Maxime said.

Also as can be seen in other discussion on this patch set, simplefb
should not be seen as something orthogonal to having a full kms driver.

So just write a full kms driver is not the answer IMHO. What we want
is for a bootloader setup console to be available through simplefb
bindings so that the kernel can show output without depending on
module loading, and thus can show errors if things go bad before
a kms driver gets loaded.

And no build kms into the kernel is not the answer. We've all been
working hard to be able to build more generic kernels, so as to get
generic distro support. And generic distros will build kms as modules,
as there are simply to many different kms drivers to build them all
in.

Regards,

Hans

Re: [linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Koen Kooi]

Op 14 aug. 2014, om 11:37 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:

> Hi,
> 
> On 08/13/2014 07:01 PM, Maxime Ripard wrote:
>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>>> This is needed so that the display engine, in case the required clocks
>>>> are known by the kernel code and are described in the dt, will remain
>>>> properly enabled.
>>> 
>>> I think this make simplefb not simple any more, which rather goes
>>> against the whole point of it.
>>> 
>>> I specifically conceived simplefb to know about nothing more than
>>> the memory address and pixel layout of the memory buffer. I
>>> certainly don't like the idea of expanding simplefb to anything
>>> beyond that, and IIRC *not* extending is was a condition agreed when
>>> it was first merged. If more knowledge than that is required, then
>>> there needs to be a HW-specific driver to manage any
>>> clocks/resets/video registers, etc.
>> 
>> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
>> driver in order to communicate somehow with the controller. Reset is a
>> different story, because arguably, if simplefb is there, the
>> controller is already out of reset.
>> 
>> And I don't see why video registers are coming into the discussion
>> here. The code Luc posted doesn't access any register, at all. It just
>> makes sure the needed controller keep going.
>> 
>>> The correct way to handle this without a complete DRM/KMS/... driver
>>> is to avoid the clocks in question being turned off at boot.
>> 
>> Which is exactly what this code does, using the generic DT bindings to
>> express dependency for a given clock. How is this wrong?
>> 
>>> I thought there was a per-clock flag to prevent disabling an unused
>>> clock?
>> 
>> No, last time I heard, Mike Turquette was against it.
>> 
>>> If not, perhaps the clock driver should force the clock to be
>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> 
>> I'm sorry, but I'm not going to take any code that will do that in our
>> clock driver.
>> 
>> I'm not going to have a huge list of ifdef depending on configuration
>> options to know which clock to enable, especially when clk_get should
>> have the consumer device as an argument.
>> 
>>> For example, the Tegra clock driver has a clock initialization table
>>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>>> That way, all the details are kept inside the kernel code, and don't
>>> end up influencing the DT representation of simplefb.
>> 
>> I don't really see how the optional usage of a generic property
>> influences badly the DT representation of simplefb.
> 
> +1 to all that Maxime said.
> 
> Also as can be seen in other discussion on this patch set, simplefb
> should not be seen as something orthogonal to having a full kms driver.
> 
> So just write a full kms driver is not the answer IMHO. What we want
> is for a bootloader setup console to be available through simplefb
> bindings so that the kernel can show output without depending on
> module loading, and thus can show errors if things go bad before
> a kms driver gets loaded.
> 
> And no build kms into the kernel is not the answer. We've all been
> working hard to be able to build more generic kernels, so as to get
> generic distro support. And generic distros will build kms as modules,
> as there are simply to many different kms drivers to build them all
> in.

How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.

regards,

Koen

[linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Koen Kooi]

Op 14 aug. 2014, om 11:37 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:

> Hi,
> 
> On 08/13/2014 07:01 PM, Maxime Ripard wrote:
>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>>> This is needed so that the display engine, in case the required clocks
>>>> are known by the kernel code and are described in the dt, will remain
>>>> properly enabled.
>>> 
>>> I think this make simplefb not simple any more, which rather goes
>>> against the whole point of it.
>>> 
>>> I specifically conceived simplefb to know about nothing more than
>>> the memory address and pixel layout of the memory buffer. I
>>> certainly don't like the idea of expanding simplefb to anything
>>> beyond that, and IIRC *not* extending is was a condition agreed when
>>> it was first merged. If more knowledge than that is required, then
>>> there needs to be a HW-specific driver to manage any
>>> clocks/resets/video registers, etc.
>> 
>> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
>> driver in order to communicate somehow with the controller. Reset is a
>> different story, because arguably, if simplefb is there, the
>> controller is already out of reset.
>> 
>> And I don't see why video registers are coming into the discussion
>> here. The code Luc posted doesn't access any register, at all. It just
>> makes sure the needed controller keep going.
>> 
>>> The correct way to handle this without a complete DRM/KMS/... driver
>>> is to avoid the clocks in question being turned off at boot.
>> 
>> Which is exactly what this code does, using the generic DT bindings to
>> express dependency for a given clock. How is this wrong?
>> 
>>> I thought there was a per-clock flag to prevent disabling an unused
>>> clock?
>> 
>> No, last time I heard, Mike Turquette was against it.
>> 
>>> If not, perhaps the clock driver should force the clock to be
>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> 
>> I'm sorry, but I'm not going to take any code that will do that in our
>> clock driver.
>> 
>> I'm not going to have a huge list of ifdef depending on configuration
>> options to know which clock to enable, especially when clk_get should
>> have the consumer device as an argument.
>> 
>>> For example, the Tegra clock driver has a clock initialization table
>>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>>> That way, all the details are kept inside the kernel code, and don't
>>> end up influencing the DT representation of simplefb.
>> 
>> I don't really see how the optional usage of a generic property
>> influences badly the DT representation of simplefb.
> 
> +1 to all that Maxime said.
> 
> Also as can be seen in other discussion on this patch set, simplefb
> should not be seen as something orthogonal to having a full kms driver.
> 
> So just write a full kms driver is not the answer IMHO. What we want
> is for a bootloader setup console to be available through simplefb
> bindings so that the kernel can show output without depending on
> module loading, and thus can show errors if things go bad before
> a kms driver gets loaded.
> 
> And no build kms into the kernel is not the answer. We've all been
> working hard to be able to build more generic kernels, so as to get
> generic distro support. And generic distros will build kms as modules,
> as there are simply to many different kms drivers to build them all
> in.

How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.

regards,

Koen

Re: [linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Thu, Aug 14, 2014 at 12:31:50PM +0200, Koen Kooi wrote:
> 
> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
> Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.
> 
> regards,
> 
> Koen

A quick check tells me that my current sunxi-3.4 sunxi_drm.ko measures 
1.7MB, for currently about 8kloc (the binary seems excessively big 
though), which is just display. This still lacks many key features (lcd 
gpio, backlight pwm, lvds, ints), so it will grow ~1kloc still.

Also, i constantly am re-loading this (how else does one develop any 
sizable amount of code?), so it does that cleanly and correctly, which 
seems quite contrary to your experience with ARM drm drivers.

Luc Verhaegen.

[linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Thu, Aug 14, 2014 at 12:31:50PM +0200, Koen Kooi wrote:
> 
> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
> Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.
> 
> regards,
> 
> Koen

A quick check tells me that my current sunxi-3.4 sunxi_drm.ko measures 
1.7MB, for currently about 8kloc (the binary seems excessively big 
though), which is just display. This still lacks many key features (lcd 
gpio, backlight pwm, lvds, ints), so it will grow ~1kloc still.

Also, i constantly am re-loading this (how else does one develop any 
sizable amount of code?), so it does that cleanly and correctly, which 
seems quite contrary to your experience with ARM drm drivers.

Luc Verhaegen.

Re: [linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/14/2014 12:57 PM, Luc Verhaegen wrote:
> On Thu, Aug 14, 2014 at 12:31:50PM +0200, Koen Kooi wrote:
>>
>> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
>> Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.
>>
>> regards,
>>
>> Koen
> 
> A quick check tells me that my current sunxi-3.4 sunxi_drm.ko measures 
> 1.7MB

That likely is with debug-info, try running "strip --strip-debug" on the .ko
file. Note don't use plain "strip" that ruins kernel modules.

Regards,

Hans

p.s.

I'm leaving home (and the internet) for vacation tomorrow. I'll be back
on Mon Aug 25.

[linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/14/2014 12:57 PM, Luc Verhaegen wrote:
> On Thu, Aug 14, 2014 at 12:31:50PM +0200, Koen Kooi wrote:
>>
>> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel? I know from experience that it's not possible on x86 especially with efifb in the mix, but I wonder what the situation on ARM is. I only have TI, sunxi and exynos boards to test on and building in both TI drm drivers and the exynos one seems to work. 
>> Note that I'm not talking about the non-DRM abortions that maskerade as graphics drivers for ARM SoCs, only proper DRM ones.
>>
>> regards,
>>
>> Koen
> 
> A quick check tells me that my current sunxi-3.4 sunxi_drm.ko measures 
> 1.7MB

That likely is with debug-info, try running "strip --strip-debug" on the .ko
file. Note don't use plain "strip" that ruins kernel modules.

Regards,

Hans

p.s.

I'm leaving home (and the internet) for vacation tomorrow. I'll be back
on Mon Aug 25.

Re: [linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/14/2014 12:31 PM, Koen Kooi wrote:
> 
> Op 14 aug. 2014, om 11:37 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:
> 
>> Hi,
>>
>> On 08/13/2014 07:01 PM, Maxime Ripard wrote:
>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>>>> This is needed so that the display engine, in case the required clocks
>>>>> are known by the kernel code and are described in the dt, will remain
>>>>> properly enabled.
>>>>
>>>> I think this make simplefb not simple any more, which rather goes
>>>> against the whole point of it.
>>>>
>>>> I specifically conceived simplefb to know about nothing more than
>>>> the memory address and pixel layout of the memory buffer. I
>>>> certainly don't like the idea of expanding simplefb to anything
>>>> beyond that, and IIRC *not* extending is was a condition agreed when
>>>> it was first merged. If more knowledge than that is required, then
>>>> there needs to be a HW-specific driver to manage any
>>>> clocks/resets/video registers, etc.
>>>
>>> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
>>> driver in order to communicate somehow with the controller. Reset is a
>>> different story, because arguably, if simplefb is there, the
>>> controller is already out of reset.
>>>
>>> And I don't see why video registers are coming into the discussion
>>> here. The code Luc posted doesn't access any register, at all. It just
>>> makes sure the needed controller keep going.
>>>
>>>> The correct way to handle this without a complete DRM/KMS/... driver
>>>> is to avoid the clocks in question being turned off at boot.
>>>
>>> Which is exactly what this code does, using the generic DT bindings to
>>> express dependency for a given clock. How is this wrong?
>>>
>>>> I thought there was a per-clock flag to prevent disabling an unused
>>>> clock?
>>>
>>> No, last time I heard, Mike Turquette was against it.
>>>
>>>> If not, perhaps the clock driver should force the clock to be
>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>
>>> I'm sorry, but I'm not going to take any code that will do that in our
>>> clock driver.
>>>
>>> I'm not going to have a huge list of ifdef depending on configuration
>>> options to know which clock to enable, especially when clk_get should
>>> have the consumer device as an argument.
>>>
>>>> For example, the Tegra clock driver has a clock initialization table
>>>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>>>> That way, all the details are kept inside the kernel code, and don't
>>>> end up influencing the DT representation of simplefb.
>>>
>>> I don't really see how the optional usage of a generic property
>>> influences badly the DT representation of simplefb.
>>
>> +1 to all that Maxime said.
>>
>> Also as can be seen in other discussion on this patch set, simplefb
>> should not be seen as something orthogonal to having a full kms driver.
>>
>> So just write a full kms driver is not the answer IMHO. What we want
>> is for a bootloader setup console to be available through simplefb
>> bindings so that the kernel can show output without depending on
>> module loading, and thus can show errors if things go bad before
>> a kms driver gets loaded.
>>
>> And no build kms into the kernel is not the answer. We've all been
>> working hard to be able to build more generic kernels, so as to get
>> generic distro support. And generic distros will build kms as modules,
>> as there are simply to many different kms drivers to build them all
>> in.
> 
> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel?

I don't know how many we've today, but I do know that we will have
twice as more next year, and 4x as more the year after that, etc.

IOW this does not scale.

Regards,

Hans

[linux-sunxi] [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/14/2014 12:31 PM, Koen Kooi wrote:
> 
> Op 14 aug. 2014, om 11:37 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:
> 
>> Hi,
>>
>> On 08/13/2014 07:01 PM, Maxime Ripard wrote:
>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>> On 08/13/2014 01:17 AM, Luc Verhaegen wrote:
>>>>> This claims and enables clocks listed in the simple framebuffer dt node.
>>>>> This is needed so that the display engine, in case the required clocks
>>>>> are known by the kernel code and are described in the dt, will remain
>>>>> properly enabled.
>>>>
>>>> I think this make simplefb not simple any more, which rather goes
>>>> against the whole point of it.
>>>>
>>>> I specifically conceived simplefb to know about nothing more than
>>>> the memory address and pixel layout of the memory buffer. I
>>>> certainly don't like the idea of expanding simplefb to anything
>>>> beyond that, and IIRC *not* extending is was a condition agreed when
>>>> it was first merged. If more knowledge than that is required, then
>>>> there needs to be a HW-specific driver to manage any
>>>> clocks/resets/video registers, etc.
>>>
>>> I'm sorry, but how is that not simple? clocks enabling is step 1 in a
>>> driver in order to communicate somehow with the controller. Reset is a
>>> different story, because arguably, if simplefb is there, the
>>> controller is already out of reset.
>>>
>>> And I don't see why video registers are coming into the discussion
>>> here. The code Luc posted doesn't access any register, at all. It just
>>> makes sure the needed controller keep going.
>>>
>>>> The correct way to handle this without a complete DRM/KMS/... driver
>>>> is to avoid the clocks in question being turned off at boot.
>>>
>>> Which is exactly what this code does, using the generic DT bindings to
>>> express dependency for a given clock. How is this wrong?
>>>
>>>> I thought there was a per-clock flag to prevent disabling an unused
>>>> clock?
>>>
>>> No, last time I heard, Mike Turquette was against it.
>>>
>>>> If not, perhaps the clock driver should force the clock to be
>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>
>>> I'm sorry, but I'm not going to take any code that will do that in our
>>> clock driver.
>>>
>>> I'm not going to have a huge list of ifdef depending on configuration
>>> options to know which clock to enable, especially when clk_get should
>>> have the consumer device as an argument.
>>>
>>>> For example, the Tegra clock driver has a clock initialization table
>>>> which IIRC was used for this purpose before we got a DRM/KMS driver.
>>>> That way, all the details are kept inside the kernel code, and don't
>>>> end up influencing the DT representation of simplefb.
>>>
>>> I don't really see how the optional usage of a generic property
>>> influences badly the DT representation of simplefb.
>>
>> +1 to all that Maxime said.
>>
>> Also as can be seen in other discussion on this patch set, simplefb
>> should not be seen as something orthogonal to having a full kms driver.
>>
>> So just write a full kms driver is not the answer IMHO. What we want
>> is for a bootloader setup console to be available through simplefb
>> bindings so that the kernel can show output without depending on
>> module loading, and thus can show errors if things go bad before
>> a kms driver gets loaded.
>>
>> And no build kms into the kernel is not the answer. We've all been
>> working hard to be able to build more generic kernels, so as to get
>> generic distro support. And generic distros will build kms as modules,
>> as there are simply to many different kms drivers to build them all
>> in.
> 
> How many DRM drivers are there on ARM and what's the size impact of building them all into the kernel?

I don't know how many we've today, but I do know that we will have
twice as more next year, and 4x as more the year after that, etc.

IOW this does not scale.

Regards,

Hans

Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
[...]
> > If not, perhaps the clock driver should force the clock to be
> > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> 
> I'm sorry, but I'm not going to take any code that will do that in our
> clock driver.
> 
> I'm not going to have a huge list of ifdef depending on configuration
> options to know which clock to enable, especially when clk_get should
> have the consumer device as an argument.

Are you saying is that you want to solve a platform-specific problem by
pushing code into simple, generic drivers so that your platform code can
stay "clean"?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
[...]
> > If not, perhaps the clock driver should force the clock to be
> > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> 
> I'm sorry, but I'm not going to take any code that will do that in our
> clock driver.
> 
> I'm not going to have a huge list of ifdef depending on configuration
> options to know which clock to enable, especially when clk_get should
> have the consumer device as an argument.

Are you saying is that you want to solve a platform-specific problem by
pushing code into simple, generic drivers so that your platform code can
stay "clean"?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/ea172bb2/attachment.sig>

Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> [...]
> > > If not, perhaps the clock driver should force the clock to be
> > > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > 
> > I'm sorry, but I'm not going to take any code that will do that in our
> > clock driver.
> > 
> > I'm not going to have a huge list of ifdef depending on configuration
> > options to know which clock to enable, especially when clk_get should
> > have the consumer device as an argument.
> 
> Are you saying is that you want to solve a platform-specific problem by
> pushing code into simple, generic drivers so that your platform code can
> stay "clean"?

Are you saying that this driver would become "dirty" with such a patch?

If so, we really have an issue in the kernel.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> [...]
> > > If not, perhaps the clock driver should force the clock to be
> > > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > 
> > I'm sorry, but I'm not going to take any code that will do that in our
> > clock driver.
> > 
> > I'm not going to have a huge list of ifdef depending on configuration
> > options to know which clock to enable, especially when clk_get should
> > have the consumer device as an argument.
> 
> Are you saying is that you want to solve a platform-specific problem by
> pushing code into simple, generic drivers so that your platform code can
> stay "clean"?

Are you saying that this driver would become "dirty" with such a patch?

If so, we really have an issue in the kernel.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/4c060f75/attachment.sig>

Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > [...]
> > > > If not, perhaps the clock driver should force the clock to be
> > > > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > 
> > > I'm sorry, but I'm not going to take any code that will do that in our
> > > clock driver.
> > > 
> > > I'm not going to have a huge list of ifdef depending on configuration
> > > options to know which clock to enable, especially when clk_get should
> > > have the consumer device as an argument.
> > 
> > Are you saying is that you want to solve a platform-specific problem by
> > pushing code into simple, generic drivers so that your platform code can
> > stay "clean"?
> 
> Are you saying that this driver would become "dirty" with such a patch?

Yes. Others have said the same and even provided alternative solutions
on how to solve what's seemingly a platform-specific problem in a
platform-specific way.

> If so, we really have an issue in the kernel.

Can you elaborate?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > [...]
> > > > If not, perhaps the clock driver should force the clock to be
> > > > enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > 
> > > I'm sorry, but I'm not going to take any code that will do that in our
> > > clock driver.
> > > 
> > > I'm not going to have a huge list of ifdef depending on configuration
> > > options to know which clock to enable, especially when clk_get should
> > > have the consumer device as an argument.
> > 
> > Are you saying is that you want to solve a platform-specific problem by
> > pushing code into simple, generic drivers so that your platform code can
> > stay "clean"?
> 
> Are you saying that this driver would become "dirty" with such a patch?

Yes. Others have said the same and even provided alternative solutions
on how to solve what's seemingly a platform-specific problem in a
platform-specific way.

> If so, we really have an issue in the kernel.

Can you elaborate?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/68317adf/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 03:39 PM, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>> [...]
>>>>> If not, perhaps the clock driver should force the clock to be
>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>
>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>> clock driver.
>>>>
>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>> options to know which clock to enable, especially when clk_get should
>>>> have the consumer device as an argument.
>>>
>>> Are you saying is that you want to solve a platform-specific problem by
>>> pushing code into simple, generic drivers so that your platform code can
>>> stay "clean"?
>>
>> Are you saying that this driver would become "dirty" with such a patch?
> 
> Yes. Others have said the same and even provided alternative solutions
> on how to solve what's seemingly a platform-specific problem in a
> platform-specific way.

This is not platform specific, any platform with a complete clock driver
will suffer from the same problem (the clock driver disabling unclaimed
ahb gates, and thus killing the video output) if it wants to use simplefb
for early console support.

I can only assume that this problem was never hit on tegra because when
kms support (and thus also a clock driver for the video plls) was introduced
simplefb support was dropped at the same time, or the gates are not being
disabled for some other reason.

As for the suggestion to simply never disable the plls / ahb gates by blocking
them from ever being disabled in the sunxi clock driver, that is not really
a solution either, as we want to be able to turn these things off to safe
power on screen blank once control has been turned over to the kms driver.

And while at it let me also tackle the don't use simplefb only use kms argument,
that means that the clocks will be turned off until the kms module loads, which
will cause noticable screen flicker / video output resync, something which we've
been trying to get rid of for years now.

And no, build in the kms driver is not an answer either. That works nicely for
firmware, but not for generic Linux distributions supporting a wide range
of boards.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 03:39 PM, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>> [...]
>>>>> If not, perhaps the clock driver should force the clock to be
>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>
>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>> clock driver.
>>>>
>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>> options to know which clock to enable, especially when clk_get should
>>>> have the consumer device as an argument.
>>>
>>> Are you saying is that you want to solve a platform-specific problem by
>>> pushing code into simple, generic drivers so that your platform code can
>>> stay "clean"?
>>
>> Are you saying that this driver would become "dirty" with such a patch?
> 
> Yes. Others have said the same and even provided alternative solutions
> on how to solve what's seemingly a platform-specific problem in a
> platform-specific way.

This is not platform specific, any platform with a complete clock driver
will suffer from the same problem (the clock driver disabling unclaimed
ahb gates, and thus killing the video output) if it wants to use simplefb
for early console support.

I can only assume that this problem was never hit on tegra because when
kms support (and thus also a clock driver for the video plls) was introduced
simplefb support was dropped at the same time, or the gates are not being
disabled for some other reason.

As for the suggestion to simply never disable the plls / ahb gates by blocking
them from ever being disabled in the sunxi clock driver, that is not really
a solution either, as we want to be able to turn these things off to safe
power on screen blank once control has been turned over to the kms driver.

And while at it let me also tackle the don't use simplefb only use kms argument,
that means that the clocks will be turned off until the kms module loads, which
will cause noticable screen flicker / video output resync, something which we've
been trying to get rid of for years now.

And no, build in the kms driver is not an answer either. That works nicely for
firmware, but not for generic Linux distributions supporting a wide range
of boards.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2939 bytes --]

On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>> [...]
> >>>>> If not, perhaps the clock driver should force the clock to be
> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>
> >>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>> clock driver.
> >>>>
> >>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>> options to know which clock to enable, especially when clk_get should
> >>>> have the consumer device as an argument.
> >>>
> >>> Are you saying is that you want to solve a platform-specific problem by
> >>> pushing code into simple, generic drivers so that your platform code can
> >>> stay "clean"?
> >>
> >> Are you saying that this driver would become "dirty" with such a patch?
> > 
> > Yes. Others have said the same and even provided alternative solutions
> > on how to solve what's seemingly a platform-specific problem in a
> > platform-specific way.
> 
> This is not platform specific, any platform with a complete clock driver
> will suffer from the same problem (the clock driver disabling unclaimed
> ahb gates, and thus killing the video output) if it wants to use simplefb
> for early console support.

It is platform specific in that your platform may require certain clocks
to remain on. The next platform may require power domains to remain on
during boot and yet another one may rely on regulators to stay on during
boot. By your argument simplefb will need to be taught to handle pretty
much every type of resource that the kernel has.

> As for the suggestion to simply never disable the plls / ahb gates by blocking
> them from ever being disabled in the sunxi clock driver, that is not really
> a solution either, as we want to be able to turn these things off to safe
> power on screen blank once control has been turned over to the kms driver.

Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
should involve marking PLLs or "gates" as properly managed.

> And while at it let me also tackle the don't use simplefb only use kms argument,
> that means that the clocks will be turned off until the kms module loads, which
> will cause noticable screen flicker / video output resync, something which we've
> been trying to get rid of for years now.
> 
> And no, build in the kms driver is not an answer either. That works nicely for
> firmware, but not for generic Linux distributions supporting a wide range
> of boards.

Odd... I didn't offer any of those two as solutions to the problem.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>> [...]
> >>>>> If not, perhaps the clock driver should force the clock to be
> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>
> >>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>> clock driver.
> >>>>
> >>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>> options to know which clock to enable, especially when clk_get should
> >>>> have the consumer device as an argument.
> >>>
> >>> Are you saying is that you want to solve a platform-specific problem by
> >>> pushing code into simple, generic drivers so that your platform code can
> >>> stay "clean"?
> >>
> >> Are you saying that this driver would become "dirty" with such a patch?
> > 
> > Yes. Others have said the same and even provided alternative solutions
> > on how to solve what's seemingly a platform-specific problem in a
> > platform-specific way.
> 
> This is not platform specific, any platform with a complete clock driver
> will suffer from the same problem (the clock driver disabling unclaimed
> ahb gates, and thus killing the video output) if it wants to use simplefb
> for early console support.

It is platform specific in that your platform may require certain clocks
to remain on. The next platform may require power domains to remain on
during boot and yet another one may rely on regulators to stay on during
boot. By your argument simplefb will need to be taught to handle pretty
much every type of resource that the kernel has.

> As for the suggestion to simply never disable the plls / ahb gates by blocking
> them from ever being disabled in the sunxi clock driver, that is not really
> a solution either, as we want to be able to turn these things off to safe
> power on screen blank once control has been turned over to the kms driver.

Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
should involve marking PLLs or "gates" as properly managed.

> And while at it let me also tackle the don't use simplefb only use kms argument,
> that means that the clocks will be turned off until the kms module loads, which
> will cause noticable screen flicker / video output resync, something which we've
> been trying to get rid of for years now.
> 
> And no, build in the kms driver is not an answer either. That works nicely for
> firmware, but not for generic Linux distributions supporting a wide range
> of boards.

Odd... I didn't offer any of those two as solutions to the problem.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/5a2fa3c4/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>> [...]
>> >>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>
>> >>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>> clock driver.
>> >>>>
>> >>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>> options to know which clock to enable, especially when clk_get should
>> >>>> have the consumer device as an argument.
>> >>>
>> >>> Are you saying is that you want to solve a platform-specific problem by
>> >>> pushing code into simple, generic drivers so that your platform code can
>> >>> stay "clean"?
>> >>
>> >> Are you saying that this driver would become "dirty" with such a patch?
>> >
>> > Yes. Others have said the same and even provided alternative solutions
>> > on how to solve what's seemingly a platform-specific problem in a
>> > platform-specific way.
>>
>> This is not platform specific, any platform with a complete clock driver
>> will suffer from the same problem (the clock driver disabling unclaimed
>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> for early console support.
>
> It is platform specific in that your platform may require certain clocks
> to remain on. The next platform may require power domains to remain on
> during boot and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle pretty
> much every type of resource that the kernel has.

Why can't simplefb be a driver library that is called from a device
specific device driver that only claims the clocks (or regulators)?
Then build all of these device specific drivers into the generic ARM
kernel. They will be quite small since all they do is claim the clocks
(or regulator).  Maybe we can even figure out some protocol for
removing the unused ones from memory later.

Later during the boot process the device specific driver can load its
KMS code which has also been implemented as a driver library. Maybe
use E_PROBE_DEFER to do this. Match on the device ID, claim the
clocks, defer until the full KMS library can be loaded.


>
>> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> them from ever being disabled in the sunxi clock driver, that is not really
>> a solution either, as we want to be able to turn these things off to safe
>> power on screen blank once control has been turned over to the kms driver.
>
> Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> should involve marking PLLs or "gates" as properly managed.
>
>> And while at it let me also tackle the don't use simplefb only use kms argument,
>> that means that the clocks will be turned off until the kms module loads, which
>> will cause noticable screen flicker / video output resync, something which we've
>> been trying to get rid of for years now.
>>
>> And no, build in the kms driver is not an answer either. That works nicely for
>> firmware, but not for generic Linux distributions supporting a wide range
>> of boards.
>
> Odd... I didn't offer any of those two as solutions to the problem.
>
> Thierry



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>> [...]
>> >>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>
>> >>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>> clock driver.
>> >>>>
>> >>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>> options to know which clock to enable, especially when clk_get should
>> >>>> have the consumer device as an argument.
>> >>>
>> >>> Are you saying is that you want to solve a platform-specific problem by
>> >>> pushing code into simple, generic drivers so that your platform code can
>> >>> stay "clean"?
>> >>
>> >> Are you saying that this driver would become "dirty" with such a patch?
>> >
>> > Yes. Others have said the same and even provided alternative solutions
>> > on how to solve what's seemingly a platform-specific problem in a
>> > platform-specific way.
>>
>> This is not platform specific, any platform with a complete clock driver
>> will suffer from the same problem (the clock driver disabling unclaimed
>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> for early console support.
>
> It is platform specific in that your platform may require certain clocks
> to remain on. The next platform may require power domains to remain on
> during boot and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle pretty
> much every type of resource that the kernel has.

Why can't simplefb be a driver library that is called from a device
specific device driver that only claims the clocks (or regulators)?
Then build all of these device specific drivers into the generic ARM
kernel. They will be quite small since all they do is claim the clocks
(or regulator).  Maybe we can even figure out some protocol for
removing the unused ones from memory later.

Later during the boot process the device specific driver can load its
KMS code which has also been implemented as a driver library. Maybe
use E_PROBE_DEFER to do this. Match on the device ID, claim the
clocks, defer until the full KMS library can be loaded.


>
>> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> them from ever being disabled in the sunxi clock driver, that is not really
>> a solution either, as we want to be able to turn these things off to safe
>> power on screen blank once control has been turned over to the kms driver.
>
> Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> should involve marking PLLs or "gates" as properly managed.
>
>> And while at it let me also tackle the don't use simplefb only use kms argument,
>> that means that the clocks will be turned off until the kms module loads, which
>> will cause noticable screen flicker / video output resync, something which we've
>> been trying to get rid of for years now.
>>
>> And no, build in the kms driver is not an answer either. That works nicely for
>> firmware, but not for generic Linux distributions supporting a wide range
>> of boards.
>
> Odd... I didn't offer any of those two as solutions to the problem.
>
> Thierry



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 04:23 PM, jonsmirl@gmail.com wrote:
> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>> [...]
>>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>>
>>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>>> clock driver.
>>>>>>>
>>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>>> have the consumer device as an argument.
>>>>>>
>>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>>> stay "clean"?
>>>>>
>>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>>
>>>> Yes. Others have said the same and even provided alternative solutions
>>>> on how to solve what's seemingly a platform-specific problem in a
>>>> platform-specific way.
>>>
>>> This is not platform specific, any platform with a complete clock driver
>>> will suffer from the same problem (the clock driver disabling unclaimed
>>> ahb gates, and thus killing the video output) if it wants to use simplefb
>>> for early console support.
>>
>> It is platform specific in that your platform may require certain clocks
>> to remain on. The next platform may require power domains to remain on
>> during boot and yet another one may rely on regulators to stay on during
>> boot. By your argument simplefb will need to be taught to handle pretty
>> much every type of resource that the kernel has.
> 
> Why can't simplefb be a driver library that is called from a device
> specific device driver that only claims the clocks (or regulators)?
> Then build all of these device specific drivers into the generic ARM
> kernel. They will be quite small since all they do is claim the clocks
> (or regulator).  Maybe we can even figure out some protocol for
> removing the unused ones from memory later.
> 
> Later during the boot process the device specific driver can load its
> KMS code which has also been implemented as a driver library. Maybe
> use E_PROBE_DEFER to do this. Match on the device ID, claim the
> clocks, defer until the full KMS library can be loaded.

There is no need for all this complexity, all that is needed is for the
simplefb driver to be thought to claim + enable any clocks listed in
its dt node.

Then once we want to do a handover, all is needed is a single simplefb
unregister call, at which point simplefb will disable the clocks and
release them. Note that this will be a nop as they should already be
claimed and enabled by the kms driver at this time.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 04:23 PM, jonsmirl at gmail.com wrote:
> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>> [...]
>>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>>
>>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>>> clock driver.
>>>>>>>
>>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>>> have the consumer device as an argument.
>>>>>>
>>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>>> stay "clean"?
>>>>>
>>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>>
>>>> Yes. Others have said the same and even provided alternative solutions
>>>> on how to solve what's seemingly a platform-specific problem in a
>>>> platform-specific way.
>>>
>>> This is not platform specific, any platform with a complete clock driver
>>> will suffer from the same problem (the clock driver disabling unclaimed
>>> ahb gates, and thus killing the video output) if it wants to use simplefb
>>> for early console support.
>>
>> It is platform specific in that your platform may require certain clocks
>> to remain on. The next platform may require power domains to remain on
>> during boot and yet another one may rely on regulators to stay on during
>> boot. By your argument simplefb will need to be taught to handle pretty
>> much every type of resource that the kernel has.
> 
> Why can't simplefb be a driver library that is called from a device
> specific device driver that only claims the clocks (or regulators)?
> Then build all of these device specific drivers into the generic ARM
> kernel. They will be quite small since all they do is claim the clocks
> (or regulator).  Maybe we can even figure out some protocol for
> removing the unused ones from memory later.
> 
> Later during the boot process the device specific driver can load its
> KMS code which has also been implemented as a driver library. Maybe
> use E_PROBE_DEFER to do this. Match on the device ID, claim the
> clocks, defer until the full KMS library can be loaded.

There is no need for all this complexity, all that is needed is for the
simplefb driver to be thought to claim + enable any clocks listed in
its dt node.

Then once we want to do a handover, all is needed is a single simplefb
unregister call, at which point simplefb will disable the clocks and
release them. Note that this will be a nop as they should already be
claimed and enabled by the kms driver at this time.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]

On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/25/2014 04:23 PM, jonsmirl@gmail.com wrote:
> > On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
> >> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>>> [...]
> >>>>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>>>>
> >>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>>>>> clock driver.
> >>>>>>>
> >>>>>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>>>>> options to know which clock to enable, especially when clk_get should
> >>>>>>> have the consumer device as an argument.
> >>>>>>
> >>>>>> Are you saying is that you want to solve a platform-specific problem by
> >>>>>> pushing code into simple, generic drivers so that your platform code can
> >>>>>> stay "clean"?
> >>>>>
> >>>>> Are you saying that this driver would become "dirty" with such a patch?
> >>>>
> >>>> Yes. Others have said the same and even provided alternative solutions
> >>>> on how to solve what's seemingly a platform-specific problem in a
> >>>> platform-specific way.
> >>>
> >>> This is not platform specific, any platform with a complete clock driver
> >>> will suffer from the same problem (the clock driver disabling unclaimed
> >>> ahb gates, and thus killing the video output) if it wants to use simplefb
> >>> for early console support.
> >>
> >> It is platform specific in that your platform may require certain clocks
> >> to remain on. The next platform may require power domains to remain on
> >> during boot and yet another one may rely on regulators to stay on during
> >> boot. By your argument simplefb will need to be taught to handle pretty
> >> much every type of resource that the kernel has.
> > 
> > Why can't simplefb be a driver library that is called from a device
> > specific device driver that only claims the clocks (or regulators)?
> > Then build all of these device specific drivers into the generic ARM
> > kernel. They will be quite small since all they do is claim the clocks
> > (or regulator).  Maybe we can even figure out some protocol for
> > removing the unused ones from memory later.
> > 
> > Later during the boot process the device specific driver can load its
> > KMS code which has also been implemented as a driver library. Maybe
> > use E_PROBE_DEFER to do this. Match on the device ID, claim the
> > clocks, defer until the full KMS library can be loaded.
> 
> There is no need for all this complexity, all that is needed is for the
> simplefb driver to be thought to claim + enable any clocks listed in
> its dt node.

Out of curiosity, how does this work in practice? How does the
bootloader create this entry? Does it scan the DT to see which clocks
the real hardware device references and then simply copies them to the
simplefb node?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/25/2014 04:23 PM, jonsmirl at gmail.com wrote:
> > On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
> >> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>>> [...]
> >>>>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>>>>
> >>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>>>>> clock driver.
> >>>>>>>
> >>>>>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>>>>> options to know which clock to enable, especially when clk_get should
> >>>>>>> have the consumer device as an argument.
> >>>>>>
> >>>>>> Are you saying is that you want to solve a platform-specific problem by
> >>>>>> pushing code into simple, generic drivers so that your platform code can
> >>>>>> stay "clean"?
> >>>>>
> >>>>> Are you saying that this driver would become "dirty" with such a patch?
> >>>>
> >>>> Yes. Others have said the same and even provided alternative solutions
> >>>> on how to solve what's seemingly a platform-specific problem in a
> >>>> platform-specific way.
> >>>
> >>> This is not platform specific, any platform with a complete clock driver
> >>> will suffer from the same problem (the clock driver disabling unclaimed
> >>> ahb gates, and thus killing the video output) if it wants to use simplefb
> >>> for early console support.
> >>
> >> It is platform specific in that your platform may require certain clocks
> >> to remain on. The next platform may require power domains to remain on
> >> during boot and yet another one may rely on regulators to stay on during
> >> boot. By your argument simplefb will need to be taught to handle pretty
> >> much every type of resource that the kernel has.
> > 
> > Why can't simplefb be a driver library that is called from a device
> > specific device driver that only claims the clocks (or regulators)?
> > Then build all of these device specific drivers into the generic ARM
> > kernel. They will be quite small since all they do is claim the clocks
> > (or regulator).  Maybe we can even figure out some protocol for
> > removing the unused ones from memory later.
> > 
> > Later during the boot process the device specific driver can load its
> > KMS code which has also been implemented as a driver library. Maybe
> > use E_PROBE_DEFER to do this. Match on the device ID, claim the
> > clocks, defer until the full KMS library can be loaded.
> 
> There is no need for all this complexity, all that is needed is for the
> simplefb driver to be thought to claim + enable any clocks listed in
> its dt node.

Out of curiosity, how does this work in practice? How does the
bootloader create this entry? Does it scan the DT to see which clocks
the real hardware device references and then simply copies them to the
simplefb node?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/8917c9ee/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> 
> Out of curiosity, how does this work in practice? How does the
> bootloader create this entry? Does it scan the DT to see which clocks
> the real hardware device references and then simply copies them to the
> simplefb node?
> 
> Thierry

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06619.html

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> 
> Out of curiosity, how does this work in practice? How does the
> bootloader create this entry? Does it scan the DT to see which clocks
> the real hardware device references and then simply copies them to the
> simplefb node?
> 
> Thierry

https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06619.html

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > 
> > Out of curiosity, how does this work in practice? How does the
> > bootloader create this entry? Does it scan the DT to see which clocks
> > the real hardware device references and then simply copies them to the
> > simplefb node?
> > 
> > Thierry
> 
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06619.html

That looks like a royal pain. Again, I think it'd be much simpler (but
not less code, unfortunately) to do this on a per-resource basis. That
way these low-level firmware drivers in the kernel can stay trivial,
keeping the real complexity where they belong: in hardware-specific
drivers such as DRM/KMS.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > 
> > Out of curiosity, how does this work in practice? How does the
> > bootloader create this entry? Does it scan the DT to see which clocks
> > the real hardware device references and then simply copies them to the
> > simplefb node?
> > 
> > Thierry
> 
> https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06619.html

That looks like a royal pain. Again, I think it'd be much simpler (but
not less code, unfortunately) to do this on a per-resource basis. That
way these low-level firmware drivers in the kernel can stay trivial,
keeping the real complexity where they belong: in hardware-specific
drivers such as DRM/KMS.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/6bf72076/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Tue, Aug 26, 2014 at 10:40:27AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> > On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > > 
> > > Out of curiosity, how does this work in practice? How does the
> > > bootloader create this entry? Does it scan the DT to see which clocks
> > > the real hardware device references and then simply copies them to the
> > > simplefb node?
> > > 
> > > Thierry
> > 
> > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06619.html
> 
> That looks like a royal pain. Again, I think it'd be much simpler (but
> not less code, unfortunately) to do this on a per-resource basis. That
> way these low-level firmware drivers in the kernel can stay trivial,
> keeping the real complexity where they belong: in hardware-specific
> drivers such as DRM/KMS.

So we have to write a DRM/KMS driver in order to have display working
while waiting for a DRM/KMS driver to be worked on? Come on...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Aug 26, 2014 at 10:40:27AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> > On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > > 
> > > Out of curiosity, how does this work in practice? How does the
> > > bootloader create this entry? Does it scan the DT to see which clocks
> > > the real hardware device references and then simply copies them to the
> > > simplefb node?
> > > 
> > > Thierry
> > 
> > https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06619.html
> 
> That looks like a royal pain. Again, I think it'd be much simpler (but
> not less code, unfortunately) to do this on a per-resource basis. That
> way these low-level firmware drivers in the kernel can stay trivial,
> keeping the real complexity where they belong: in hardware-specific
> drivers such as DRM/KMS.

So we have to write a DRM/KMS driver in order to have display working
while waiting for a DRM/KMS driver to be worked on? Come on...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/9ce87b4d/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On Tue, Aug 26, 2014 at 03:22:07PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 10:40:27AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> > > On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > > > 
> > > > Out of curiosity, how does this work in practice? How does the
> > > > bootloader create this entry? Does it scan the DT to see which clocks
> > > > the real hardware device references and then simply copies them to the
> > > > simplefb node?
> > > > 
> > > > Thierry
> > > 
> > > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06619.html
> > 
> > That looks like a royal pain. Again, I think it'd be much simpler (but
> > not less code, unfortunately) to do this on a per-resource basis. That
> > way these low-level firmware drivers in the kernel can stay trivial,
> > keeping the real complexity where they belong: in hardware-specific
> > drivers such as DRM/KMS.
> 
> So we have to write a DRM/KMS driver in order to have display working
> while waiting for a DRM/KMS driver to be worked on? Come on...

Perhaps you should go and read this thread again. That's not at all what
I've been saying.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 03:22:07PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 10:40:27AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:18:22PM +0200, Luc Verhaegen wrote:
> > > On Mon, Aug 25, 2014 at 05:12:58PM +0200, Thierry Reding wrote:
> > > > 
> > > > Out of curiosity, how does this work in practice? How does the
> > > > bootloader create this entry? Does it scan the DT to see which clocks
> > > > the real hardware device references and then simply copies them to the
> > > > simplefb node?
> > > > 
> > > > Thierry
> > > 
> > > https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06619.html
> > 
> > That looks like a royal pain. Again, I think it'd be much simpler (but
> > not less code, unfortunately) to do this on a per-resource basis. That
> > way these low-level firmware drivers in the kernel can stay trivial,
> > keeping the real complexity where they belong: in hardware-specific
> > drivers such as DRM/KMS.
> 
> So we have to write a DRM/KMS driver in order to have display working
> while waiting for a DRM/KMS driver to be worked on? Come on...

Perhaps you should go and read this thread again. That's not at all what
I've been saying.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/55aeadd6/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Mon, Aug 25, 2014 at 11:12 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/25/2014 04:23 PM, jonsmirl@gmail.com wrote:
>> > On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
>> > <thierry.reding@gmail.com> wrote:
>> >> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> >>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> >>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>>>>> [...]
>> >>>>>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>>>>
>> >>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>>>>> clock driver.
>> >>>>>>>
>> >>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>>>>> options to know which clock to enable, especially when clk_get should
>> >>>>>>> have the consumer device as an argument.
>> >>>>>>
>> >>>>>> Are you saying is that you want to solve a platform-specific problem by
>> >>>>>> pushing code into simple, generic drivers so that your platform code can
>> >>>>>> stay "clean"?
>> >>>>>
>> >>>>> Are you saying that this driver would become "dirty" with such a patch?
>> >>>>
>> >>>> Yes. Others have said the same and even provided alternative solutions
>> >>>> on how to solve what's seemingly a platform-specific problem in a
>> >>>> platform-specific way.
>> >>>
>> >>> This is not platform specific, any platform with a complete clock driver
>> >>> will suffer from the same problem (the clock driver disabling unclaimed
>> >>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> >>> for early console support.
>> >>
>> >> It is platform specific in that your platform may require certain clocks
>> >> to remain on. The next platform may require power domains to remain on
>> >> during boot and yet another one may rely on regulators to stay on during
>> >> boot. By your argument simplefb will need to be taught to handle pretty
>> >> much every type of resource that the kernel has.
>> >
>> > Why can't simplefb be a driver library that is called from a device
>> > specific device driver that only claims the clocks (or regulators)?
>> > Then build all of these device specific drivers into the generic ARM
>> > kernel. They will be quite small since all they do is claim the clocks
>> > (or regulator).  Maybe we can even figure out some protocol for
>> > removing the unused ones from memory later.
>> >
>> > Later during the boot process the device specific driver can load its
>> > KMS code which has also been implemented as a driver library. Maybe
>> > use E_PROBE_DEFER to do this. Match on the device ID, claim the
>> > clocks, defer until the full KMS library can be loaded.
>>
>> There is no need for all this complexity, all that is needed is for the
>> simplefb driver to be thought to claim + enable any clocks listed in
>> its dt node.
>
> Out of curiosity, how does this work in practice? How does the
> bootloader create this entry? Does it scan the DT to see which clocks
> the real hardware device references and then simply copies them to the
> simplefb node?

That's why this is such a problem. There is a general rule in Linux -
one device, one driver.  All of the kernel device driver code is
written around this assumption. We're trying to make two drivers for
one device and the kernel is not designed to support that. There
shouldn't be an independent 'simplefb' node. That is creating two
device descriptions for a single device.

Adding 'chosen' information to the devices nodes might work.

video@1345 {
    compatible = "sunxi-a20-video";
    reg = <...>;
    clocks = <...>;
    chosen {
      compatible = "simplefb";     // dynamically added by uboot
      buffer = <0x4564>;    // dynamically added by uboot
   };
};

This will initialize the simplefb driver without attaching it to any
specific hardware.  It can then look in its parent node for clocks and
regulators and claim them.


>
> Thierry



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Mon, Aug 25, 2014 at 11:12 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/25/2014 04:23 PM, jonsmirl at gmail.com wrote:
>> > On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
>> > <thierry.reding@gmail.com> wrote:
>> >> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> >>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> >>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>>>>> [...]
>> >>>>>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>>>>
>> >>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>>>>> clock driver.
>> >>>>>>>
>> >>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>>>>> options to know which clock to enable, especially when clk_get should
>> >>>>>>> have the consumer device as an argument.
>> >>>>>>
>> >>>>>> Are you saying is that you want to solve a platform-specific problem by
>> >>>>>> pushing code into simple, generic drivers so that your platform code can
>> >>>>>> stay "clean"?
>> >>>>>
>> >>>>> Are you saying that this driver would become "dirty" with such a patch?
>> >>>>
>> >>>> Yes. Others have said the same and even provided alternative solutions
>> >>>> on how to solve what's seemingly a platform-specific problem in a
>> >>>> platform-specific way.
>> >>>
>> >>> This is not platform specific, any platform with a complete clock driver
>> >>> will suffer from the same problem (the clock driver disabling unclaimed
>> >>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> >>> for early console support.
>> >>
>> >> It is platform specific in that your platform may require certain clocks
>> >> to remain on. The next platform may require power domains to remain on
>> >> during boot and yet another one may rely on regulators to stay on during
>> >> boot. By your argument simplefb will need to be taught to handle pretty
>> >> much every type of resource that the kernel has.
>> >
>> > Why can't simplefb be a driver library that is called from a device
>> > specific device driver that only claims the clocks (or regulators)?
>> > Then build all of these device specific drivers into the generic ARM
>> > kernel. They will be quite small since all they do is claim the clocks
>> > (or regulator).  Maybe we can even figure out some protocol for
>> > removing the unused ones from memory later.
>> >
>> > Later during the boot process the device specific driver can load its
>> > KMS code which has also been implemented as a driver library. Maybe
>> > use E_PROBE_DEFER to do this. Match on the device ID, claim the
>> > clocks, defer until the full KMS library can be loaded.
>>
>> There is no need for all this complexity, all that is needed is for the
>> simplefb driver to be thought to claim + enable any clocks listed in
>> its dt node.
>
> Out of curiosity, how does this work in practice? How does the
> bootloader create this entry? Does it scan the DT to see which clocks
> the real hardware device references and then simply copies them to the
> simplefb node?

That's why this is such a problem. There is a general rule in Linux -
one device, one driver.  All of the kernel device driver code is
written around this assumption. We're trying to make two drivers for
one device and the kernel is not designed to support that. There
shouldn't be an independent 'simplefb' node. That is creating two
device descriptions for a single device.

Adding 'chosen' information to the devices nodes might work.

video at 1345 {
    compatible = "sunxi-a20-video";
    reg = <...>;
    clocks = <...>;
    chosen {
      compatible = "simplefb";     // dynamically added by uboot
      buffer = <0x4564>;    // dynamically added by uboot
   };
};

This will initialize the simplefb driver without attaching it to any
specific hardware.  It can then look in its parent node for clocks and
regulators and claim them.


>
> Thierry



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 05:49 PM, jonsmirl@gmail.com wrote:
> On Mon, Aug 25, 2014 at 11:12 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 08/25/2014 04:23 PM, jonsmirl@gmail.com wrote:
>>>> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
>>>> <thierry.reding@gmail.com> wrote:
>>>>> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>>>>>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>>>>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>>>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>>>>> [...]
>>>>>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>>>>>
>>>>>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>>>>>> clock driver.
>>>>>>>>>>
>>>>>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>>>>>> have the consumer device as an argument.
>>>>>>>>>
>>>>>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>>>>>> stay "clean"?
>>>>>>>>
>>>>>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>>>>>
>>>>>>> Yes. Others have said the same and even provided alternative solutions
>>>>>>> on how to solve what's seemingly a platform-specific problem in a
>>>>>>> platform-specific way.
>>>>>>
>>>>>> This is not platform specific, any platform with a complete clock driver
>>>>>> will suffer from the same problem (the clock driver disabling unclaimed
>>>>>> ahb gates, and thus killing the video output) if it wants to use simplefb
>>>>>> for early console support.
>>>>>
>>>>> It is platform specific in that your platform may require certain clocks
>>>>> to remain on. The next platform may require power domains to remain on
>>>>> during boot and yet another one may rely on regulators to stay on during
>>>>> boot. By your argument simplefb will need to be taught to handle pretty
>>>>> much every type of resource that the kernel has.
>>>>
>>>> Why can't simplefb be a driver library that is called from a device
>>>> specific device driver that only claims the clocks (or regulators)?
>>>> Then build all of these device specific drivers into the generic ARM
>>>> kernel. They will be quite small since all they do is claim the clocks
>>>> (or regulator).  Maybe we can even figure out some protocol for
>>>> removing the unused ones from memory later.
>>>>
>>>> Later during the boot process the device specific driver can load its
>>>> KMS code which has also been implemented as a driver library. Maybe
>>>> use E_PROBE_DEFER to do this. Match on the device ID, claim the
>>>> clocks, defer until the full KMS library can be loaded.
>>>
>>> There is no need for all this complexity, all that is needed is for the
>>> simplefb driver to be thought to claim + enable any clocks listed in
>>> its dt node.
>>
>> Out of curiosity, how does this work in practice? How does the
>> bootloader create this entry? Does it scan the DT to see which clocks
>> the real hardware device references and then simply copies them to the
>> simplefb node?
> 
> That's why this is such a problem. There is a general rule in Linux -
> one device, one driver.

A general rule with exceptions such as, drumroll ... , video devices,
e.g. efifb vs kms drivers are the exact same thing, or good old
vgacon vs kms drivers.

Or any other special firmware interfaces for early output (be it serial
or video) vs a later loaded / initialized more complete hardware specific
driver.

Also in the usb world there are quite a few examples where your once
device one driver rule does not hold either, but that is not really
relevant.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 05:49 PM, jonsmirl at gmail.com wrote:
> On Mon, Aug 25, 2014 at 11:12 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>> On Mon, Aug 25, 2014 at 04:27:04PM +0200, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 08/25/2014 04:23 PM, jonsmirl at gmail.com wrote:
>>>> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
>>>> <thierry.reding@gmail.com> wrote:
>>>>> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>>>>>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>>>>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>>>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>>>>> [...]
>>>>>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>>>>>
>>>>>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>>>>>> clock driver.
>>>>>>>>>>
>>>>>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>>>>>> have the consumer device as an argument.
>>>>>>>>>
>>>>>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>>>>>> stay "clean"?
>>>>>>>>
>>>>>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>>>>>
>>>>>>> Yes. Others have said the same and even provided alternative solutions
>>>>>>> on how to solve what's seemingly a platform-specific problem in a
>>>>>>> platform-specific way.
>>>>>>
>>>>>> This is not platform specific, any platform with a complete clock driver
>>>>>> will suffer from the same problem (the clock driver disabling unclaimed
>>>>>> ahb gates, and thus killing the video output) if it wants to use simplefb
>>>>>> for early console support.
>>>>>
>>>>> It is platform specific in that your platform may require certain clocks
>>>>> to remain on. The next platform may require power domains to remain on
>>>>> during boot and yet another one may rely on regulators to stay on during
>>>>> boot. By your argument simplefb will need to be taught to handle pretty
>>>>> much every type of resource that the kernel has.
>>>>
>>>> Why can't simplefb be a driver library that is called from a device
>>>> specific device driver that only claims the clocks (or regulators)?
>>>> Then build all of these device specific drivers into the generic ARM
>>>> kernel. They will be quite small since all they do is claim the clocks
>>>> (or regulator).  Maybe we can even figure out some protocol for
>>>> removing the unused ones from memory later.
>>>>
>>>> Later during the boot process the device specific driver can load its
>>>> KMS code which has also been implemented as a driver library. Maybe
>>>> use E_PROBE_DEFER to do this. Match on the device ID, claim the
>>>> clocks, defer until the full KMS library can be loaded.
>>>
>>> There is no need for all this complexity, all that is needed is for the
>>> simplefb driver to be thought to claim + enable any clocks listed in
>>> its dt node.
>>
>> Out of curiosity, how does this work in practice? How does the
>> bootloader create this entry? Does it scan the DT to see which clocks
>> the real hardware device references and then simply copies them to the
>> simplefb node?
> 
> That's why this is such a problem. There is a general rule in Linux -
> one device, one driver.

A general rule with exceptions such as, drumroll ... , video devices,
e.g. efifb vs kms drivers are the exact same thing, or good old
vgacon vs kms drivers.

Or any other special firmware interfaces for early output (be it serial
or video) vs a later loaded / initialized more complete hardware specific
driver.

Also in the usb world there are quite a few examples where your once
device one driver rule does not hold either, but that is not really
relevant.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3567 bytes --]

On Mon, Aug 25, 2014 at 10:23:26AM -0400, jonsmirl@gmail.com wrote:
> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >> >>> [...]
> >> >>>>> If not, perhaps the clock driver should force the clock to be
> >> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >> >>>>
> >> >>>> I'm sorry, but I'm not going to take any code that will do that in our
> >> >>>> clock driver.
> >> >>>>
> >> >>>> I'm not going to have a huge list of ifdef depending on configuration
> >> >>>> options to know which clock to enable, especially when clk_get should
> >> >>>> have the consumer device as an argument.
> >> >>>
> >> >>> Are you saying is that you want to solve a platform-specific problem by
> >> >>> pushing code into simple, generic drivers so that your platform code can
> >> >>> stay "clean"?
> >> >>
> >> >> Are you saying that this driver would become "dirty" with such a patch?
> >> >
> >> > Yes. Others have said the same and even provided alternative solutions
> >> > on how to solve what's seemingly a platform-specific problem in a
> >> > platform-specific way.
> >>
> >> This is not platform specific, any platform with a complete clock driver
> >> will suffer from the same problem (the clock driver disabling unclaimed
> >> ahb gates, and thus killing the video output) if it wants to use simplefb
> >> for early console support.
> >
> > It is platform specific in that your platform may require certain clocks
> > to remain on. The next platform may require power domains to remain on
> > during boot and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle pretty
> > much every type of resource that the kernel has.
> 
> Why can't simplefb be a driver library that is called from a device
> specific device driver that only claims the clocks (or regulators)?
> Then build all of these device specific drivers into the generic ARM
> kernel. They will be quite small since all they do is claim the clocks
> (or regulator).  Maybe we can even figure out some protocol for
> removing the unused ones from memory later.
> 
> Later during the boot process the device specific driver can load its
> KMS code which has also been implemented as a driver library. Maybe
> use E_PROBE_DEFER to do this. Match on the device ID, claim the
> clocks, defer until the full KMS library can be loaded.

That sounds like the most scalable solution so far. On the other hand,
as I understand it, the simplefb driver was designed to take over the
framebuffer set up by firmware, so it's somewhat odd that the driver
would have to deal with resources in the first place. If we push the
resource problem into the respective subsystems we keep the simplefb
driver completely hardware agnostic.

And we'll also be solving this problem for other types of drivers at the
same time. Firmware may after all initialize clocks and other resources
for other types of devices too. Handling resources in the drivers would
therefore imply that every driver needs to cope with this.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 10:23:26AM -0400, jonsmirl at gmail.com wrote:
> On Mon, Aug 25, 2014 at 10:16 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >> > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >> >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >> >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >> >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >> >>> [...]
> >> >>>>> If not, perhaps the clock driver should force the clock to be
> >> >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >> >>>>
> >> >>>> I'm sorry, but I'm not going to take any code that will do that in our
> >> >>>> clock driver.
> >> >>>>
> >> >>>> I'm not going to have a huge list of ifdef depending on configuration
> >> >>>> options to know which clock to enable, especially when clk_get should
> >> >>>> have the consumer device as an argument.
> >> >>>
> >> >>> Are you saying is that you want to solve a platform-specific problem by
> >> >>> pushing code into simple, generic drivers so that your platform code can
> >> >>> stay "clean"?
> >> >>
> >> >> Are you saying that this driver would become "dirty" with such a patch?
> >> >
> >> > Yes. Others have said the same and even provided alternative solutions
> >> > on how to solve what's seemingly a platform-specific problem in a
> >> > platform-specific way.
> >>
> >> This is not platform specific, any platform with a complete clock driver
> >> will suffer from the same problem (the clock driver disabling unclaimed
> >> ahb gates, and thus killing the video output) if it wants to use simplefb
> >> for early console support.
> >
> > It is platform specific in that your platform may require certain clocks
> > to remain on. The next platform may require power domains to remain on
> > during boot and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle pretty
> > much every type of resource that the kernel has.
> 
> Why can't simplefb be a driver library that is called from a device
> specific device driver that only claims the clocks (or regulators)?
> Then build all of these device specific drivers into the generic ARM
> kernel. They will be quite small since all they do is claim the clocks
> (or regulator).  Maybe we can even figure out some protocol for
> removing the unused ones from memory later.
> 
> Later during the boot process the device specific driver can load its
> KMS code which has also been implemented as a driver library. Maybe
> use E_PROBE_DEFER to do this. Match on the device ID, claim the
> clocks, defer until the full KMS library can be loaded.

That sounds like the most scalable solution so far. On the other hand,
as I understand it, the simplefb driver was designed to take over the
framebuffer set up by firmware, so it's somewhat odd that the driver
would have to deal with resources in the first place. If we push the
resource problem into the respective subsystems we keep the simplefb
driver completely hardware agnostic.

And we'll also be solving this problem for other types of drivers at the
same time. Firmware may after all initialize clocks and other resources
for other types of devices too. Handling resources in the drivers would
therefore imply that every driver needs to cope with this.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/15f8788c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 04:16 PM, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>> [...]
>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>
>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>> clock driver.
>>>>>>
>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>> have the consumer device as an argument.
>>>>>
>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>> stay "clean"?
>>>>
>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>
>>> Yes. Others have said the same and even provided alternative solutions
>>> on how to solve what's seemingly a platform-specific problem in a
>>> platform-specific way.
>>
>> This is not platform specific, any platform with a complete clock driver
>> will suffer from the same problem (the clock driver disabling unclaimed
>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> for early console support.
> 
> It is platform specific in that your platform may require certain clocks
> to remain on. The next platform may require power domains to remain on
> during boot and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle pretty
> much every type of resource that the kernel has.
> 
>> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> them from ever being disabled in the sunxi clock driver, that is not really
>> a solution either, as we want to be able to turn these things off to safe
>> power on screen blank once control has been turned over to the kms driver.
> 
> Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> should involve marking PLLs or "gates" as properly managed.

And by your earlier argument also power domains, regulators, etc. So now we need
to add code to each of the clock core, power-domain core, regulator core, etc. to
have them now about this initially unmanaged state thing you're introducing, as
well as modify all involved clock / regulator / etc. drivers to mark certain
resources as unmanaged.

Or we add a single simple and clean patch to the simplefb driver for dealing
with clocks, and worry about all the other hypothetical problems later...

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/25/2014 04:16 PM, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>> [...]
>>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>>>>>>
>>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>>>>>> clock driver.
>>>>>>
>>>>>> I'm not going to have a huge list of ifdef depending on configuration
>>>>>> options to know which clock to enable, especially when clk_get should
>>>>>> have the consumer device as an argument.
>>>>>
>>>>> Are you saying is that you want to solve a platform-specific problem by
>>>>> pushing code into simple, generic drivers so that your platform code can
>>>>> stay "clean"?
>>>>
>>>> Are you saying that this driver would become "dirty" with such a patch?
>>>
>>> Yes. Others have said the same and even provided alternative solutions
>>> on how to solve what's seemingly a platform-specific problem in a
>>> platform-specific way.
>>
>> This is not platform specific, any platform with a complete clock driver
>> will suffer from the same problem (the clock driver disabling unclaimed
>> ahb gates, and thus killing the video output) if it wants to use simplefb
>> for early console support.
> 
> It is platform specific in that your platform may require certain clocks
> to remain on. The next platform may require power domains to remain on
> during boot and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle pretty
> much every type of resource that the kernel has.
> 
>> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> them from ever being disabled in the sunxi clock driver, that is not really
>> a solution either, as we want to be able to turn these things off to safe
>> power on screen blank once control has been turned over to the kms driver.
> 
> Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> should involve marking PLLs or "gates" as properly managed.

And by your earlier argument also power domains, regulators, etc. So now we need
to add code to each of the clock core, power-domain core, regulator core, etc. to
have them now about this initially unmanaged state thing you're introducing, as
well as modify all involved clock / regulator / etc. drivers to mark certain
resources as unmanaged.

Or we add a single simple and clean patch to the simplefb driver for dealing
with clocks, and worry about all the other hypothetical problems later...

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]

On Mon, Aug 25, 2014 at 04:23:59PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/25/2014 04:16 PM, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>> [...]
> >>>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>>>
> >>>>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>>>> clock driver.
> >>>>>>
> >>>>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>>>> options to know which clock to enable, especially when clk_get should
> >>>>>> have the consumer device as an argument.
> >>>>>
> >>>>> Are you saying is that you want to solve a platform-specific problem by
> >>>>> pushing code into simple, generic drivers so that your platform code can
> >>>>> stay "clean"?
> >>>>
> >>>> Are you saying that this driver would become "dirty" with such a patch?
> >>>
> >>> Yes. Others have said the same and even provided alternative solutions
> >>> on how to solve what's seemingly a platform-specific problem in a
> >>> platform-specific way.
> >>
> >> This is not platform specific, any platform with a complete clock driver
> >> will suffer from the same problem (the clock driver disabling unclaimed
> >> ahb gates, and thus killing the video output) if it wants to use simplefb
> >> for early console support.
> > 
> > It is platform specific in that your platform may require certain clocks
> > to remain on. The next platform may require power domains to remain on
> > during boot and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle pretty
> > much every type of resource that the kernel has.
> > 
> >> As for the suggestion to simply never disable the plls / ahb gates by blocking
> >> them from ever being disabled in the sunxi clock driver, that is not really
> >> a solution either, as we want to be able to turn these things off to safe
> >> power on screen blank once control has been turned over to the kms driver.
> > 
> > Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> > should involve marking PLLs or "gates" as properly managed.
> 
> And by your earlier argument also power domains, regulators, etc. So now we need
> to add code to each of the clock core, power-domain core, regulator core, etc. to
> have them now about this initially unmanaged state thing you're introducing, as
> well as modify all involved clock / regulator / etc. drivers to mark certain
> resources as unmanaged.

Hmm... that's true. But we already have a way to deal with exactly this
situation for regulators. There's a property called regulator-boot-on
which a bootloader should set whet it has enabled a given regulator. It
can of course also be set statically in a DTS if it's know upfront that
a bootloader will always enable it. Perhaps what we need is a similar
property for clocks so that the clock framework will not inadvertently
turn off a clock that's still being used.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 04:23:59PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/25/2014 04:16 PM, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>> [...]
> >>>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> >>>>>>
> >>>>>> I'm sorry, but I'm not going to take any code that will do that in our
> >>>>>> clock driver.
> >>>>>>
> >>>>>> I'm not going to have a huge list of ifdef depending on configuration
> >>>>>> options to know which clock to enable, especially when clk_get should
> >>>>>> have the consumer device as an argument.
> >>>>>
> >>>>> Are you saying is that you want to solve a platform-specific problem by
> >>>>> pushing code into simple, generic drivers so that your platform code can
> >>>>> stay "clean"?
> >>>>
> >>>> Are you saying that this driver would become "dirty" with such a patch?
> >>>
> >>> Yes. Others have said the same and even provided alternative solutions
> >>> on how to solve what's seemingly a platform-specific problem in a
> >>> platform-specific way.
> >>
> >> This is not platform specific, any platform with a complete clock driver
> >> will suffer from the same problem (the clock driver disabling unclaimed
> >> ahb gates, and thus killing the video output) if it wants to use simplefb
> >> for early console support.
> > 
> > It is platform specific in that your platform may require certain clocks
> > to remain on. The next platform may require power domains to remain on
> > during boot and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle pretty
> > much every type of resource that the kernel has.
> > 
> >> As for the suggestion to simply never disable the plls / ahb gates by blocking
> >> them from ever being disabled in the sunxi clock driver, that is not really
> >> a solution either, as we want to be able to turn these things off to safe
> >> power on screen blank once control has been turned over to the kms driver.
> > 
> > Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
> > should involve marking PLLs or "gates" as properly managed.
> 
> And by your earlier argument also power domains, regulators, etc. So now we need
> to add code to each of the clock core, power-domain core, regulator core, etc. to
> have them now about this initially unmanaged state thing you're introducing, as
> well as modify all involved clock / regulator / etc. drivers to mark certain
> resources as unmanaged.

Hmm... that's true. But we already have a way to deal with exactly this
situation for regulators. There's a property called regulator-boot-on
which a bootloader should set whet it has enabled a given regulator. It
can of course also be set statically in a DTS if it's know upfront that
a bootloader will always enable it. Perhaps what we need is a similar
property for clocks so that the clock framework will not inadvertently
turn off a clock that's still being used.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/c50267c3/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Mon, Aug 25, 2014 at 04:53:06PM +0200, Thierry Reding wrote:
> Hmm... that's true. But we already have a way to deal with exactly this
> situation for regulators. There's a property called regulator-boot-on
> which a bootloader should set whet it has enabled a given regulator. It
> can of course also be set statically in a DTS if it's know upfront that
> a bootloader will always enable it. Perhaps what we need is a similar
> property for clocks so that the clock framework will not inadvertently
> turn off a clock that's still being used.

Except that such a property won't work either. Regulators with
regulator-boot-on will still be disabled if there's no one to claim
it. Just like what happens currently for the clocks.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Aug 25, 2014 at 04:53:06PM +0200, Thierry Reding wrote:
> Hmm... that's true. But we already have a way to deal with exactly this
> situation for regulators. There's a property called regulator-boot-on
> which a bootloader should set whet it has enabled a given regulator. It
> can of course also be set statically in a DTS if it's know upfront that
> a bootloader will always enable it. Perhaps what we need is a similar
> property for clocks so that the clock framework will not inadvertently
> turn off a clock that's still being used.

Except that such a property won't work either. Regulators with
regulator-boot-on will still be disabled if there's no one to claim
it. Just like what happens currently for the clocks.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/69496455/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 04:53:06PM +0200, Thierry Reding wrote:
> > Hmm... that's true. But we already have a way to deal with exactly this
> > situation for regulators. There's a property called regulator-boot-on
> > which a bootloader should set whet it has enabled a given regulator. It
> > can of course also be set statically in a DTS if it's know upfront that
> > a bootloader will always enable it. Perhaps what we need is a similar
> > property for clocks so that the clock framework will not inadvertently
> > turn off a clock that's still being used.
> 
> Except that such a property won't work either.

Of course it won't work if it's designed not to work. The solution to
that is to design it in a way that it works and does exactly what we
want it to do.

> Regulators with regulator-boot-on will still be disabled if there's no
> one to claim it. Just like what happens currently for the clocks.

I was somewhat surprised by this, but it can indeed easily be verified.
It seems to me somewhat at odds with the definition of such a property.

Mark,

You've probably not read the whole backlog, but the discussion revolves
around hand-off of resources from firmware to kernel (via DT in this
case). If firmware initializes a device (display controller in this
particular case) and enables resources needed by the device to work
properly then in order to properly hand over resources from firmware to
kernel we need a way to communicate the state of these resources. For
regulators the regulator-boot-on property is specified to do exactly
that. However the implementation will automatically disable a regulator
marked boot-on if it hasn't been claimed by any driver after the
initcall stage completes.

I find that rather odd since I always assumed that a regulator marked
boot-on would not be touched by the core at all, assuming that firmware
set it up properly and that it would be required (even if not explicitly
claimed).

The issue that this causes is that we can't properly hand-off devices
initialized by firmware because the regulator will be disabled after the
initcall stage and then enabled when the driver loads. In case of
display the result will usually be flicker. The same applies to other
types of resources (in this case clocks).

Two categories of drivers have this issue: drivers built as modules (or
that defer probing) and therefore won't be probed until after initcalls
have run and generic low-level drivers that take over firmware devices
(simplefb in this case) that don't know anything about the resource that
the devices need.

Also Cc'ing Mike, perhaps he has ideas on how to solve this problem for
clocks specifically.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 04:53:06PM +0200, Thierry Reding wrote:
> > Hmm... that's true. But we already have a way to deal with exactly this
> > situation for regulators. There's a property called regulator-boot-on
> > which a bootloader should set whet it has enabled a given regulator. It
> > can of course also be set statically in a DTS if it's know upfront that
> > a bootloader will always enable it. Perhaps what we need is a similar
> > property for clocks so that the clock framework will not inadvertently
> > turn off a clock that's still being used.
> 
> Except that such a property won't work either.

Of course it won't work if it's designed not to work. The solution to
that is to design it in a way that it works and does exactly what we
want it to do.

> Regulators with regulator-boot-on will still be disabled if there's no
> one to claim it. Just like what happens currently for the clocks.

I was somewhat surprised by this, but it can indeed easily be verified.
It seems to me somewhat at odds with the definition of such a property.

Mark,

You've probably not read the whole backlog, but the discussion revolves
around hand-off of resources from firmware to kernel (via DT in this
case). If firmware initializes a device (display controller in this
particular case) and enables resources needed by the device to work
properly then in order to properly hand over resources from firmware to
kernel we need a way to communicate the state of these resources. For
regulators the regulator-boot-on property is specified to do exactly
that. However the implementation will automatically disable a regulator
marked boot-on if it hasn't been claimed by any driver after the
initcall stage completes.

I find that rather odd since I always assumed that a regulator marked
boot-on would not be touched by the core at all, assuming that firmware
set it up properly and that it would be required (even if not explicitly
claimed).

The issue that this causes is that we can't properly hand-off devices
initialized by firmware because the regulator will be disabled after the
initcall stage and then enabled when the driver loads. In case of
display the result will usually be flicker. The same applies to other
types of resources (in this case clocks).

Two categories of drivers have this issue: drivers built as modules (or
that defer probing) and therefore won't be probed until after initcalls
have run and generic low-level drivers that take over firmware devices
(simplefb in this case) that don't know anything about the resource that
the devices need.

Also Cc'ing Mike, perhaps he has ideas on how to solve this problem for
clocks specifically.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/1616b071/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Tue, Aug 26, 2014 at 10:26:27AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:

> > Regulators with regulator-boot-on will still be disabled if there's no
> > one to claim it. Just like what happens currently for the clocks.

> I was somewhat surprised by this, but it can indeed easily be verified.
> It seems to me somewhat at odds with the definition of such a property.

That depends what you think it should do - it's there for handover from
the bootloader in cases where we can't read the state.

> that. However the implementation will automatically disable a regulator
> marked boot-on if it hasn't been claimed by any driver after the
> initcall stage completes.

> I find that rather odd since I always assumed that a regulator marked
> boot-on would not be touched by the core at all, assuming that firmware
> set it up properly and that it would be required (even if not explicitly
> claimed).

No, there's a separate always-on property if we don't want to disable.
We can't assume that the "proper" setup is that the supply should be
left on.

> Two categories of drivers have this issue: drivers built as modules (or
> that defer probing) and therefore won't be probed until after initcalls

We really need a later initcall to manage handover to userspace
(probably triggered by a combination of userspace saying it's done doing
initial module enumeration and the deferred probe grinding to a halt).

> have run and generic low-level drivers that take over firmware devices
> (simplefb in this case) that don't know anything about the resource that
> the devices need.

I don't understand this use case, sorry - it sounds like a buggy system
design and/or integration.  If the firmware is managing the resource
then Linux really shouldn't be talking to it at all without coordinating
with firmware.  How can such a system work otherwise?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Aug 26, 2014 at 10:26:27AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:

> > Regulators with regulator-boot-on will still be disabled if there's no
> > one to claim it. Just like what happens currently for the clocks.

> I was somewhat surprised by this, but it can indeed easily be verified.
> It seems to me somewhat at odds with the definition of such a property.

That depends what you think it should do - it's there for handover from
the bootloader in cases where we can't read the state.

> that. However the implementation will automatically disable a regulator
> marked boot-on if it hasn't been claimed by any driver after the
> initcall stage completes.

> I find that rather odd since I always assumed that a regulator marked
> boot-on would not be touched by the core at all, assuming that firmware
> set it up properly and that it would be required (even if not explicitly
> claimed).

No, there's a separate always-on property if we don't want to disable.
We can't assume that the "proper" setup is that the supply should be
left on.

> Two categories of drivers have this issue: drivers built as modules (or
> that defer probing) and therefore won't be probed until after initcalls

We really need a later initcall to manage handover to userspace
(probably triggered by a combination of userspace saying it's done doing
initial module enumeration and the deferred probe grinding to a halt).

> have run and generic low-level drivers that take over firmware devices
> (simplefb in this case) that don't know anything about the resource that
> the devices need.

I don't understand this use case, sorry - it sounds like a buggy system
design and/or integration.  If the firmware is managing the resource
then Linux really shouldn't be talking to it at all without coordinating
with firmware.  How can such a system work otherwise?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/f6affe2b/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]

On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 10:26:27AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:
> 
> > > Regulators with regulator-boot-on will still be disabled if there's no
> > > one to claim it. Just like what happens currently for the clocks.
> 
> > I was somewhat surprised by this, but it can indeed easily be verified.
> > It seems to me somewhat at odds with the definition of such a property.
> 
> That depends what you think it should do - it's there for handover from
> the bootloader in cases where we can't read the state.

True. The description leaves a lot of room for interpretation, though.

	- regulator-boot-on: bootloader/firmware enabled regulator

> > that. However the implementation will automatically disable a regulator
> > marked boot-on if it hasn't been claimed by any driver after the
> > initcall stage completes.
> 
> > I find that rather odd since I always assumed that a regulator marked
> > boot-on would not be touched by the core at all, assuming that firmware
> > set it up properly and that it would be required (even if not explicitly
> > claimed).
> 
> No, there's a separate always-on property if we don't want to disable.

But always-on means that it can't ever be disabled. In this case what
we'd need is a "don't disable automatically because it's needed, but we
may want to switch it off at a later point to save power."

> We can't assume that the "proper" setup is that the supply should be
> left on.

Right, we can't assume it, but if we're given appropriate hints I think
it's fair to keep resources set up by firmware untouched.

> > Two categories of drivers have this issue: drivers built as modules (or
> > that defer probing) and therefore won't be probed until after initcalls
> 
> We really need a later initcall to manage handover to userspace
> (probably triggered by a combination of userspace saying it's done doing
> initial module enumeration and the deferred probe grinding to a halt).

Yes, perhaps that would be another option.

> > have run and generic low-level drivers that take over firmware devices
> > (simplefb in this case) that don't know anything about the resource that
> > the devices need.
> 
> I don't understand this use case, sorry - it sounds like a buggy system
> design and/or integration.  If the firmware is managing the resource
> then Linux really shouldn't be talking to it at all without coordinating
> with firmware.  How can such a system work otherwise?

The firmware isn't really managing resources. It's setting up state that
the kernel shouldn't be modifying. Currently the kernel assumes that no
firmware exists and just disables everything that's not being used. That
is a reasonable default, but it also limits what we can do. I think if
we provided a good interface to communicate state between firmware and
kernel then we could easily do this kind of hand-off.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 10:26:27AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:07:05PM +0200, Maxime Ripard wrote:
> 
> > > Regulators with regulator-boot-on will still be disabled if there's no
> > > one to claim it. Just like what happens currently for the clocks.
> 
> > I was somewhat surprised by this, but it can indeed easily be verified.
> > It seems to me somewhat at odds with the definition of such a property.
> 
> That depends what you think it should do - it's there for handover from
> the bootloader in cases where we can't read the state.

True. The description leaves a lot of room for interpretation, though.

	- regulator-boot-on: bootloader/firmware enabled regulator

> > that. However the implementation will automatically disable a regulator
> > marked boot-on if it hasn't been claimed by any driver after the
> > initcall stage completes.
> 
> > I find that rather odd since I always assumed that a regulator marked
> > boot-on would not be touched by the core at all, assuming that firmware
> > set it up properly and that it would be required (even if not explicitly
> > claimed).
> 
> No, there's a separate always-on property if we don't want to disable.

But always-on means that it can't ever be disabled. In this case what
we'd need is a "don't disable automatically because it's needed, but we
may want to switch it off at a later point to save power."

> We can't assume that the "proper" setup is that the supply should be
> left on.

Right, we can't assume it, but if we're given appropriate hints I think
it's fair to keep resources set up by firmware untouched.

> > Two categories of drivers have this issue: drivers built as modules (or
> > that defer probing) and therefore won't be probed until after initcalls
> 
> We really need a later initcall to manage handover to userspace
> (probably triggered by a combination of userspace saying it's done doing
> initial module enumeration and the deferred probe grinding to a halt).

Yes, perhaps that would be another option.

> > have run and generic low-level drivers that take over firmware devices
> > (simplefb in this case) that don't know anything about the resource that
> > the devices need.
> 
> I don't understand this use case, sorry - it sounds like a buggy system
> design and/or integration.  If the firmware is managing the resource
> then Linux really shouldn't be talking to it at all without coordinating
> with firmware.  How can such a system work otherwise?

The firmware isn't really managing resources. It's setting up state that
the kernel shouldn't be modifying. Currently the kernel assumes that no
firmware exists and just disables everything that's not being used. That
is a reasonable default, but it also limits what we can do. I think if
we provided a good interface to communicate state between firmware and
kernel then we could easily do this kind of hand-off.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/0dfb00f3/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:

> > > I find that rather odd since I always assumed that a regulator marked
> > > boot-on would not be touched by the core at all, assuming that firmware
> > > set it up properly and that it would be required (even if not explicitly
> > > claimed).

> > No, there's a separate always-on property if we don't want to disable.

> But always-on means that it can't ever be disabled. In this case what
> we'd need is a "don't disable automatically because it's needed, but we
> may want to switch it off at a later point to save power."

Such a property wouldn't make much sense, it should also apply to the
driver at which point it's just the same as always-on.

> > We can't assume that the "proper" setup is that the supply should be
> > left on.

> Right, we can't assume it, but if we're given appropriate hints I think
> it's fair to keep resources set up by firmware untouched.

I really can't see any sensible way to do that in an OS neutral thing
like DT.

> > > have run and generic low-level drivers that take over firmware devices
> > > (simplefb in this case) that don't know anything about the resource that
> > > the devices need.

> > I don't understand this use case, sorry - it sounds like a buggy system
> > design and/or integration.  If the firmware is managing the resource
> > then Linux really shouldn't be talking to it at all without coordinating
> > with firmware.  How can such a system work otherwise?

> The firmware isn't really managing resources. It's setting up state that
> the kernel shouldn't be modifying. Currently the kernel assumes that no
> firmware exists and just disables everything that's not being used. That
> is a reasonable default, but it also limits what we can do. I think if
> we provided a good interface to communicate state between firmware and
> kernel then we could easily do this kind of hand-off.

I'm afraid that's confusing me even further.  If the "firmware devices"
don't know anything about the resources as you say then presumably they
need to be always on since they obviously won't be able to control them
and there is going to be no handoff?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:

> > > I find that rather odd since I always assumed that a regulator marked
> > > boot-on would not be touched by the core at all, assuming that firmware
> > > set it up properly and that it would be required (even if not explicitly
> > > claimed).

> > No, there's a separate always-on property if we don't want to disable.

> But always-on means that it can't ever be disabled. In this case what
> we'd need is a "don't disable automatically because it's needed, but we
> may want to switch it off at a later point to save power."

Such a property wouldn't make much sense, it should also apply to the
driver at which point it's just the same as always-on.

> > We can't assume that the "proper" setup is that the supply should be
> > left on.

> Right, we can't assume it, but if we're given appropriate hints I think
> it's fair to keep resources set up by firmware untouched.

I really can't see any sensible way to do that in an OS neutral thing
like DT.

> > > have run and generic low-level drivers that take over firmware devices
> > > (simplefb in this case) that don't know anything about the resource that
> > > the devices need.

> > I don't understand this use case, sorry - it sounds like a buggy system
> > design and/or integration.  If the firmware is managing the resource
> > then Linux really shouldn't be talking to it at all without coordinating
> > with firmware.  How can such a system work otherwise?

> The firmware isn't really managing resources. It's setting up state that
> the kernel shouldn't be modifying. Currently the kernel assumes that no
> firmware exists and just disables everything that's not being used. That
> is a reasonable default, but it also limits what we can do. I think if
> we provided a good interface to communicate state between firmware and
> kernel then we could easily do this kind of hand-off.

I'm afraid that's confusing me even further.  If the "firmware devices"
don't know anything about the resources as you say then presumably they
need to be always on since they obviously won't be able to control them
and there is going to be no handoff?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/af8f2fb5/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]

On Tue, Aug 26, 2014 at 11:06:12AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:
> 
> > > > I find that rather odd since I always assumed that a regulator marked
> > > > boot-on would not be touched by the core at all, assuming that firmware
> > > > set it up properly and that it would be required (even if not explicitly
> > > > claimed).
> 
> > > No, there's a separate always-on property if we don't want to disable.
> 
> > But always-on means that it can't ever be disabled. In this case what
> > we'd need is a "don't disable automatically because it's needed, but we
> > may want to switch it off at a later point to save power."
> 
> Such a property wouldn't make much sense, it should also apply to the
> driver at which point it's just the same as always-on.
> 
> > > We can't assume that the "proper" setup is that the supply should be
> > > left on.
> 
> > Right, we can't assume it, but if we're given appropriate hints I think
> > it's fair to keep resources set up by firmware untouched.
> 
> I really can't see any sensible way to do that in an OS neutral thing
> like DT.

It should be possible to simply define a property for this that the
firmware can add to the device tree.

There are other subsystems for example where we don't touch resources
unless they are explicitly accessed. GPIO and pinmux are two examples of
those. The reason is precisely so that we don't undo anything that the
firmware already set up and that may be needed during boot.

> > > > have run and generic low-level drivers that take over firmware devices
> > > > (simplefb in this case) that don't know anything about the resource that
> > > > the devices need.
> 
> > > I don't understand this use case, sorry - it sounds like a buggy system
> > > design and/or integration.  If the firmware is managing the resource
> > > then Linux really shouldn't be talking to it at all without coordinating
> > > with firmware.  How can such a system work otherwise?
> 
> > The firmware isn't really managing resources. It's setting up state that
> > the kernel shouldn't be modifying. Currently the kernel assumes that no
> > firmware exists and just disables everything that's not being used. That
> > is a reasonable default, but it also limits what we can do. I think if
> > we provided a good interface to communicate state between firmware and
> > kernel then we could easily do this kind of hand-off.
> 
> I'm afraid that's confusing me even further.  If the "firmware devices"
> don't know anything about the resources as you say then presumably they
> need to be always on since they obviously won't be able to control them
> and there is going to be no handoff?

How this works with simplefb is that the firmware (U-Boot for example)
sets up everything needed to scan out a framebuffer. The firmware will
typically use this for a boot splash or a console. It's akin to the
standard VGA console on x86.

Before booting the kernel it will modify the DTB and insert a node that
contains information about the framebuffer that was set up. The node
contains properties that define the resolution, the format and the
physical address of the framebuffer memory. An in-kernel driver will
then be able to use that information very early in the boot process to
show the console (to replace the serial console that's usually not
available on consumer devices). Later on when a real driver can be
loaded it should take over the resources from simplefb and remove it.

So the firmware does control the resources to a point where the display
hardware is initialized and then it will happily forget about them. The
device will keep scanning out the framebuffer and simplefb can update it
with boot messages. To prevent the console from suddenly disappearing
the kernel needs to make sure that the resources aren't inadvertently
turned off at some more or less random point in time.

The resources don't need to be always on, only as long as there isn't a
proper driver to manage them. Once that driver has requested the
resources it will likely want to control them to save power. Therefore I
think the most straightforward way would be for the kernel not to touch
any of these resources until they've been explicitly requested. Even if
we don't want to rely on firmware doing the right thing by default, I
think it's still valuable to take hints from firmware when it provides
them so rather than defaulting to not touching any resources what I
proposed is to mark resources that shouldn't be touched.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 11:06:12AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:
> 
> > > > I find that rather odd since I always assumed that a regulator marked
> > > > boot-on would not be touched by the core at all, assuming that firmware
> > > > set it up properly and that it would be required (even if not explicitly
> > > > claimed).
> 
> > > No, there's a separate always-on property if we don't want to disable.
> 
> > But always-on means that it can't ever be disabled. In this case what
> > we'd need is a "don't disable automatically because it's needed, but we
> > may want to switch it off at a later point to save power."
> 
> Such a property wouldn't make much sense, it should also apply to the
> driver at which point it's just the same as always-on.
> 
> > > We can't assume that the "proper" setup is that the supply should be
> > > left on.
> 
> > Right, we can't assume it, but if we're given appropriate hints I think
> > it's fair to keep resources set up by firmware untouched.
> 
> I really can't see any sensible way to do that in an OS neutral thing
> like DT.

It should be possible to simply define a property for this that the
firmware can add to the device tree.

There are other subsystems for example where we don't touch resources
unless they are explicitly accessed. GPIO and pinmux are two examples of
those. The reason is precisely so that we don't undo anything that the
firmware already set up and that may be needed during boot.

> > > > have run and generic low-level drivers that take over firmware devices
> > > > (simplefb in this case) that don't know anything about the resource that
> > > > the devices need.
> 
> > > I don't understand this use case, sorry - it sounds like a buggy system
> > > design and/or integration.  If the firmware is managing the resource
> > > then Linux really shouldn't be talking to it at all without coordinating
> > > with firmware.  How can such a system work otherwise?
> 
> > The firmware isn't really managing resources. It's setting up state that
> > the kernel shouldn't be modifying. Currently the kernel assumes that no
> > firmware exists and just disables everything that's not being used. That
> > is a reasonable default, but it also limits what we can do. I think if
> > we provided a good interface to communicate state between firmware and
> > kernel then we could easily do this kind of hand-off.
> 
> I'm afraid that's confusing me even further.  If the "firmware devices"
> don't know anything about the resources as you say then presumably they
> need to be always on since they obviously won't be able to control them
> and there is going to be no handoff?

How this works with simplefb is that the firmware (U-Boot for example)
sets up everything needed to scan out a framebuffer. The firmware will
typically use this for a boot splash or a console. It's akin to the
standard VGA console on x86.

Before booting the kernel it will modify the DTB and insert a node that
contains information about the framebuffer that was set up. The node
contains properties that define the resolution, the format and the
physical address of the framebuffer memory. An in-kernel driver will
then be able to use that information very early in the boot process to
show the console (to replace the serial console that's usually not
available on consumer devices). Later on when a real driver can be
loaded it should take over the resources from simplefb and remove it.

So the firmware does control the resources to a point where the display
hardware is initialized and then it will happily forget about them. The
device will keep scanning out the framebuffer and simplefb can update it
with boot messages. To prevent the console from suddenly disappearing
the kernel needs to make sure that the resources aren't inadvertently
turned off at some more or less random point in time.

The resources don't need to be always on, only as long as there isn't a
proper driver to manage them. Once that driver has requested the
resources it will likely want to control them to save power. Therefore I
think the most straightforward way would be for the kernel not to touch
any of these resources until they've been explicitly requested. Even if
we don't want to rely on firmware doing the right thing by default, I
think it's still valuable to take hints from firmware when it provides
them so rather than defaulting to not touching any resources what I
proposed is to mark resources that shouldn't be touched.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/2d0076ce/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

On Tue, Aug 26, 2014 at 12:55:06PM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:06:12AM +0100, Mark Brown wrote:
> > On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> > > On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:

> > > > We can't assume that the "proper" setup is that the supply should be
> > > > left on.

> > > Right, we can't assume it, but if we're given appropriate hints I think
> > > it's fair to keep resources set up by firmware untouched.

> > I really can't see any sensible way to do that in an OS neutral thing
> > like DT.

> It should be possible to simply define a property for this that the
> firmware can add to the device tree.

> There are other subsystems for example where we don't touch resources
> unless they are explicitly accessed. GPIO and pinmux are two examples of
> those. The reason is precisely so that we don't undo anything that the
> firmware already set up and that may be needed during boot.

GPIOs and pinmuxes are quite different in both how they get set up (you
don't typically have their configuration set in ROM and shoehorned into
the board which is what we're dealing with for a lot of PMICs) and in
the consequences of leaving them alone.

I really don't think defining a custom property to work around a timing
issue in a particular OS startup sequence is the best way forwards here
- we should solve our startup sequencing issue rather than layer on
hacks, otherwise we're adding fragility and work to the system.  The
flag would need to be explicitly added and then it means we're stuck
with the behaviour even if the system gets smarter.

> Before booting the kernel it will modify the DTB and insert a node that
> contains information about the framebuffer that was set up. The node
> contains properties that define the resolution, the format and the
> physical address of the framebuffer memory. An in-kernel driver will
> then be able to use that information very early in the boot process to
> show the console (to replace the serial console that's usually not
> available on consumer devices). Later on when a real driver can be
> loaded it should take over the resources from simplefb and remove it.

OK, so this is not meaningfully different to just loading the driver
normally - it's exactly the same scenario.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Aug 26, 2014 at 12:55:06PM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:06:12AM +0100, Mark Brown wrote:
> > On Tue, Aug 26, 2014 at 11:18:54AM +0200, Thierry Reding wrote:
> > > On Tue, Aug 26, 2014 at 10:00:35AM +0100, Mark Brown wrote:

> > > > We can't assume that the "proper" setup is that the supply should be
> > > > left on.

> > > Right, we can't assume it, but if we're given appropriate hints I think
> > > it's fair to keep resources set up by firmware untouched.

> > I really can't see any sensible way to do that in an OS neutral thing
> > like DT.

> It should be possible to simply define a property for this that the
> firmware can add to the device tree.

> There are other subsystems for example where we don't touch resources
> unless they are explicitly accessed. GPIO and pinmux are two examples of
> those. The reason is precisely so that we don't undo anything that the
> firmware already set up and that may be needed during boot.

GPIOs and pinmuxes are quite different in both how they get set up (you
don't typically have their configuration set in ROM and shoehorned into
the board which is what we're dealing with for a lot of PMICs) and in
the consequences of leaving them alone.

I really don't think defining a custom property to work around a timing
issue in a particular OS startup sequence is the best way forwards here
- we should solve our startup sequencing issue rather than layer on
hacks, otherwise we're adding fragility and work to the system.  The
flag would need to be explicitly added and then it means we're stuck
with the behaviour even if the system gets smarter.

> Before booting the kernel it will modify the DTB and insert a node that
> contains information about the framebuffer that was set up. The node
> contains properties that define the resolution, the format and the
> physical address of the framebuffer memory. An in-kernel driver will
> then be able to use that information very early in the boot process to
> show the console (to replace the serial console that's usually not
> available on consumer devices). Later on when a real driver can be
> loaded it should take over the resources from simplefb and remove it.

OK, so this is not meaningfully different to just loading the driver
normally - it's exactly the same scenario.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/57d05d8e/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

tis 2014-08-26 klockan 12:55 +0200 skrev Thierry Reding:


> So the firmware does control the resources to a point where the display
> hardware is initialized and then it will happily forget about them. The
> device will keep scanning out the framebuffer and simplefb can update it
> with boot messages. To prevent the console from suddenly disappearing
> the kernel needs to make sure that the resources aren't inadvertently
> turned off at some more or less random point in time.

Which imho is until simplefb is unbound from the device.

Separately to this there needs to be a in-kernel handover procedure
where a new driver (i.e. video kms driver) can bind to a device and take
over resources, but it's completely unrelated to who owns the hardware
resources while simplefb is the active driver for the device.

It is not clear to me where the hardware resources should be listed in
DT, being it a simplefb node or part of the actual hardware device node
properly marked as dynamic boot defaults or something else? It's
somewhere inbetween hardware and virtual device, and somewhat volatile.
As far as simplefb is concerned it is a hardware desription of the
framebuffer, but for a kms driver it's no more than firmware handover of
boottime settings and ceases to exists once the kms driver have
reconfigured the hardware.

What I can do is to list some properties that these settings need to
provide:

1. Handover of hardware settings from bootloader to kernel.

2. Hardware description for simplefb use. It's at this level not really
any different from any other hardware.

3. Volatile and removed when kms driver have reconfigured the hardware
or it's been decided that the (virtual) device should not be active.

Regarding 3 and kexec as mentioned earlier. A new set of properties may
be added again for kexec usage to describe the current framebuffer for
the new kernel but op to the system which prepares for kexec to
determine. Should be no different in mechanism from bootloader to kernel
handover (the kexecing kernel is the bootloader in kexec case).


Regards
Henrik

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

tis 2014-08-26 klockan 12:55 +0200 skrev Thierry Reding:


> So the firmware does control the resources to a point where the display
> hardware is initialized and then it will happily forget about them. The
> device will keep scanning out the framebuffer and simplefb can update it
> with boot messages. To prevent the console from suddenly disappearing
> the kernel needs to make sure that the resources aren't inadvertently
> turned off at some more or less random point in time.

Which imho is until simplefb is unbound from the device.

Separately to this there needs to be a in-kernel handover procedure
where a new driver (i.e. video kms driver) can bind to a device and take
over resources, but it's completely unrelated to who owns the hardware
resources while simplefb is the active driver for the device.

It is not clear to me where the hardware resources should be listed in
DT, being it a simplefb node or part of the actual hardware device node
properly marked as dynamic boot defaults or something else? It's
somewhere inbetween hardware and virtual device, and somewhat volatile.
As far as simplefb is concerned it is a hardware desription of the
framebuffer, but for a kms driver it's no more than firmware handover of
boottime settings and ceases to exists once the kms driver have
reconfigured the hardware.

What I can do is to list some properties that these settings need to
provide:

1. Handover of hardware settings from bootloader to kernel.

2. Hardware description for simplefb use. It's at this level not really
any different from any other hardware.

3. Volatile and removed when kms driver have reconfigured the hardware
or it's been decided that the (virtual) device should not be active.

Regarding 3 and kexec as mentioned earlier. A new set of properties may
be added again for kexec usage to describe the current framebuffer for
the new kernel but op to the system which prepares for kexec to
determine. Should be no different in mechanism from bootloader to kernel
handover (the kexecing kernel is the bootloader in kexec case).


Regards
Henrik

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:

> It is not clear to me where the hardware resources should be listed in
> DT, being it a simplefb node or part of the actual hardware device node
> properly marked as dynamic boot defaults or something else? It's
> somewhere inbetween hardware and virtual device, and somewhat volatile.
> As far as simplefb is concerned it is a hardware desription of the
> framebuffer, but for a kms driver it's no more than firmware handover of
> boottime settings and ceases to exists once the kms driver have
> reconfigured the hardware.

Is simplefb something that should be in the device tree distinctly in
the first place - shouldn't it be a subset of the functionality of the
video nodes?  It's the same hardware being driven differently.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:

> It is not clear to me where the hardware resources should be listed in
> DT, being it a simplefb node or part of the actual hardware device node
> properly marked as dynamic boot defaults or something else? It's
> somewhere inbetween hardware and virtual device, and somewhat volatile.
> As far as simplefb is concerned it is a hardware desription of the
> framebuffer, but for a kms driver it's no more than firmware handover of
> boottime settings and ceases to exists once the kms driver have
> reconfigured the hardware.

Is simplefb something that should be in the device tree distinctly in
the first place - shouldn't it be a subset of the functionality of the
video nodes?  It's the same hardware being driven differently.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/b867ffed/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
> 
> > It is not clear to me where the hardware resources should be listed in
> > DT, being it a simplefb node or part of the actual hardware device node
> > properly marked as dynamic boot defaults or something else? It's
> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> > As far as simplefb is concerned it is a hardware desription of the
> > framebuffer, but for a kms driver it's no more than firmware handover of
> > boottime settings and ceases to exists once the kms driver have
> > reconfigured the hardware.
> 
> Is simplefb something that should be in the device tree distinctly in
> the first place - shouldn't it be a subset of the functionality of the
> video nodes?  It's the same hardware being driven differently.

Therorically, yes, but that would mean knowing beforehand what the
final binding will look like, even before submitting the driver. Since
the bindings are always reviewed, and most of the time changed
slightly, that wouldn't work very well with the DT as a stable ABI
policy I guess.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
> 
> > It is not clear to me where the hardware resources should be listed in
> > DT, being it a simplefb node or part of the actual hardware device node
> > properly marked as dynamic boot defaults or something else? It's
> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> > As far as simplefb is concerned it is a hardware desription of the
> > framebuffer, but for a kms driver it's no more than firmware handover of
> > boottime settings and ceases to exists once the kms driver have
> > reconfigured the hardware.
> 
> Is simplefb something that should be in the device tree distinctly in
> the first place - shouldn't it be a subset of the functionality of the
> video nodes?  It's the same hardware being driven differently.

Therorically, yes, but that would mean knowing beforehand what the
final binding will look like, even before submitting the driver. Since
the bindings are always reviewed, and most of the time changed
slightly, that wouldn't work very well with the DT as a stable ABI
policy I guess.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/5c253fd7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
>>
>> > It is not clear to me where the hardware resources should be listed in
>> > DT, being it a simplefb node or part of the actual hardware device node
>> > properly marked as dynamic boot defaults or something else? It's
>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
>> > As far as simplefb is concerned it is a hardware desription of the
>> > framebuffer, but for a kms driver it's no more than firmware handover of
>> > boottime settings and ceases to exists once the kms driver have
>> > reconfigured the hardware.
>>
>> Is simplefb something that should be in the device tree distinctly in
>> the first place - shouldn't it be a subset of the functionality of the
>> video nodes?  It's the same hardware being driven differently.
>
> Therorically, yes, but that would mean knowing beforehand what the
> final binding will look like, even before submitting the driver. Since
> the bindings are always reviewed, and most of the time changed
> slightly, that wouldn't work very well with the DT as a stable ABI
> policy I guess.

If you don't know how the bindings for a device will look like at the time of
writing your DTS, you're always screwed, whether you add a simpefb
node or not.

If you know how the bindings look like, just add the device, with an extra
"linux,simplefb" compatibility value.
If you don't know how the bindings look like, do your utter best in
guessing. Your DTS must be amended later anyway, either because
you guessed wrong[*] (in case you added a node to have simplefb
working), or because you have to add a real device node (in case you
didn't add one for simplefb).

[*] Actually you may have guessed right, in which case it'll continue
    working as-is, and everybody will be happy.
    Whether you want to keep backwards-compatibility in your future driver
    with the "guessed wrong" node is up to you.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
>>
>> > It is not clear to me where the hardware resources should be listed in
>> > DT, being it a simplefb node or part of the actual hardware device node
>> > properly marked as dynamic boot defaults or something else? It's
>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
>> > As far as simplefb is concerned it is a hardware desription of the
>> > framebuffer, but for a kms driver it's no more than firmware handover of
>> > boottime settings and ceases to exists once the kms driver have
>> > reconfigured the hardware.
>>
>> Is simplefb something that should be in the device tree distinctly in
>> the first place - shouldn't it be a subset of the functionality of the
>> video nodes?  It's the same hardware being driven differently.
>
> Therorically, yes, but that would mean knowing beforehand what the
> final binding will look like, even before submitting the driver. Since
> the bindings are always reviewed, and most of the time changed
> slightly, that wouldn't work very well with the DT as a stable ABI
> policy I guess.

If you don't know how the bindings for a device will look like at the time of
writing your DTS, you're always screwed, whether you add a simpefb
node or not.

If you know how the bindings look like, just add the device, with an extra
"linux,simplefb" compatibility value.
If you don't know how the bindings look like, do your utter best in
guessing. Your DTS must be amended later anyway, either because
you guessed wrong[*] (in case you added a node to have simplefb
working), or because you have to add a real device node (in case you
didn't add one for simplefb).

[*] Actually you may have guessed right, in which case it'll continue
    working as-is, and everybody will be happy.
    Whether you want to keep backwards-compatibility in your future driver
    with the "guessed wrong" node is up to you.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

Hi!

On Wed, Aug 27, 2014 at 10:37:36AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> >> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
> >>
> >> > It is not clear to me where the hardware resources should be listed in
> >> > DT, being it a simplefb node or part of the actual hardware device node
> >> > properly marked as dynamic boot defaults or something else? It's
> >> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> >> > As far as simplefb is concerned it is a hardware desription of the
> >> > framebuffer, but for a kms driver it's no more than firmware handover of
> >> > boottime settings and ceases to exists once the kms driver have
> >> > reconfigured the hardware.
> >>
> >> Is simplefb something that should be in the device tree distinctly in
> >> the first place - shouldn't it be a subset of the functionality of the
> >> video nodes?  It's the same hardware being driven differently.
> >
> > Therorically, yes, but that would mean knowing beforehand what the
> > final binding will look like, even before submitting the driver. Since
> > the bindings are always reviewed, and most of the time changed
> > slightly, that wouldn't work very well with the DT as a stable ABI
> > policy I guess.
> 
> If you don't know how the bindings for a device will look like at the time of
> writing your DTS, you're always screwed, whether you add a simpefb
> node or not.
> 
> If you know how the bindings look like, just add the device, with an extra
> "linux,simplefb" compatibility value.
> If you don't know how the bindings look like, do your utter best in
> guessing. Your DTS must be amended later anyway, either because
> you guessed wrong[*] (in case you added a node to have simplefb
> working), or because you have to add a real device node (in case you
> didn't add one for simplefb).

Let's be conservative and consider the case where we would guess
wrong.

If we just rely on a simplefb node, when reviewing and integrating the
"new" bindings to describe accureately the various IPs involved in the
display path, we would obviously create new compatibles for
them. Since it's new compatibles, we can come up with any binding we'd
like, without have to consider the backward compatibility, since it's
a new binding.

Then, we just remove the simplefb, all is good.

If we were to try to create our bindings for all the IPs involved, and
were not pleased with the binding anymore when merging the driver,
then we would have to break the bindings, since we don't introduce a
new compatible anymore, but modifying an existing one.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

Hi!

On Wed, Aug 27, 2014 at 10:37:36AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> >> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
> >>
> >> > It is not clear to me where the hardware resources should be listed in
> >> > DT, being it a simplefb node or part of the actual hardware device node
> >> > properly marked as dynamic boot defaults or something else? It's
> >> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> >> > As far as simplefb is concerned it is a hardware desription of the
> >> > framebuffer, but for a kms driver it's no more than firmware handover of
> >> > boottime settings and ceases to exists once the kms driver have
> >> > reconfigured the hardware.
> >>
> >> Is simplefb something that should be in the device tree distinctly in
> >> the first place - shouldn't it be a subset of the functionality of the
> >> video nodes?  It's the same hardware being driven differently.
> >
> > Therorically, yes, but that would mean knowing beforehand what the
> > final binding will look like, even before submitting the driver. Since
> > the bindings are always reviewed, and most of the time changed
> > slightly, that wouldn't work very well with the DT as a stable ABI
> > policy I guess.
> 
> If you don't know how the bindings for a device will look like at the time of
> writing your DTS, you're always screwed, whether you add a simpefb
> node or not.
> 
> If you know how the bindings look like, just add the device, with an extra
> "linux,simplefb" compatibility value.
> If you don't know how the bindings look like, do your utter best in
> guessing. Your DTS must be amended later anyway, either because
> you guessed wrong[*] (in case you added a node to have simplefb
> working), or because you have to add a real device node (in case you
> didn't add one for simplefb).

Let's be conservative and consider the case where we would guess
wrong.

If we just rely on a simplefb node, when reviewing and integrating the
"new" bindings to describe accureately the various IPs involved in the
display path, we would obviously create new compatibles for
them. Since it's new compatibles, we can come up with any binding we'd
like, without have to consider the backward compatibility, since it's
a new binding.

Then, we just remove the simplefb, all is good.

If we were to try to create our bindings for all the IPs involved, and
were not pleased with the binding anymore when merging the driver,
then we would have to break the bindings, since we don't introduce a
new compatible anymore, but modifying an existing one.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/c3b72ee2/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Wed, Aug 27, 2014 at 10:55 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>> >> Is simplefb something that should be in the device tree distinctly in
>> >> the first place - shouldn't it be a subset of the functionality of the
>> >> video nodes?  It's the same hardware being driven differently.
>> >
>> > Therorically, yes, but that would mean knowing beforehand what the
>> > final binding will look like, even before submitting the driver. Since
>> > the bindings are always reviewed, and most of the time changed
>> > slightly, that wouldn't work very well with the DT as a stable ABI
>> > policy I guess.
>>
>> If you don't know how the bindings for a device will look like at the time of
>> writing your DTS, you're always screwed, whether you add a simpefb
>> node or not.
>>
>> If you know how the bindings look like, just add the device, with an extra
>> "linux,simplefb" compatibility value.
>> If you don't know how the bindings look like, do your utter best in
>> guessing. Your DTS must be amended later anyway, either because
>> you guessed wrong[*] (in case you added a node to have simplefb
>> working), or because you have to add a real device node (in case you
>> didn't add one for simplefb).
>
> Let's be conservative and consider the case where we would guess
> wrong.
>
> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.
>
> Then, we just remove the simplefb, all is good.

I would keep the simplefb compatible value. Else you break compatibility
with old kernels that don't have your new driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Wed, Aug 27, 2014 at 10:55 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>> >> Is simplefb something that should be in the device tree distinctly in
>> >> the first place - shouldn't it be a subset of the functionality of the
>> >> video nodes?  It's the same hardware being driven differently.
>> >
>> > Therorically, yes, but that would mean knowing beforehand what the
>> > final binding will look like, even before submitting the driver. Since
>> > the bindings are always reviewed, and most of the time changed
>> > slightly, that wouldn't work very well with the DT as a stable ABI
>> > policy I guess.
>>
>> If you don't know how the bindings for a device will look like at the time of
>> writing your DTS, you're always screwed, whether you add a simpefb
>> node or not.
>>
>> If you know how the bindings look like, just add the device, with an extra
>> "linux,simplefb" compatibility value.
>> If you don't know how the bindings look like, do your utter best in
>> guessing. Your DTS must be amended later anyway, either because
>> you guessed wrong[*] (in case you added a node to have simplefb
>> working), or because you have to add a real device node (in case you
>> didn't add one for simplefb).
>
> Let's be conservative and consider the case where we would guess
> wrong.
>
> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.
>
> Then, we just remove the simplefb, all is good.

I would keep the simplefb compatible value. Else you break compatibility
with old kernels that don't have your new driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

On Wed, Aug 27, 2014 at 11:05:29AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 27, 2014 at 10:55 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> >> >> Is simplefb something that should be in the device tree distinctly in
> >> >> the first place - shouldn't it be a subset of the functionality of the
> >> >> video nodes?  It's the same hardware being driven differently.
> >> >
> >> > Therorically, yes, but that would mean knowing beforehand what the
> >> > final binding will look like, even before submitting the driver. Since
> >> > the bindings are always reviewed, and most of the time changed
> >> > slightly, that wouldn't work very well with the DT as a stable ABI
> >> > policy I guess.
> >>
> >> If you don't know how the bindings for a device will look like at the time of
> >> writing your DTS, you're always screwed, whether you add a simpefb
> >> node or not.
> >>
> >> If you know how the bindings look like, just add the device, with an extra
> >> "linux,simplefb" compatibility value.
> >> If you don't know how the bindings look like, do your utter best in
> >> guessing. Your DTS must be amended later anyway, either because
> >> you guessed wrong[*] (in case you added a node to have simplefb
> >> working), or because you have to add a real device node (in case you
> >> didn't add one for simplefb).
> >
> > Let's be conservative and consider the case where we would guess
> > wrong.
> >
> > If we just rely on a simplefb node, when reviewing and integrating the
> > "new" bindings to describe accureately the various IPs involved in the
> > display path, we would obviously create new compatibles for
> > them. Since it's new compatibles, we can come up with any binding we'd
> > like, without have to consider the backward compatibility, since it's
> > a new binding.
> >
> > Then, we just remove the simplefb, all is good.
> 
> I would keep the simplefb compatible value. Else you break compatibility
> with old kernels that don't have your new driver.

Yes, true. Since the simplefb will be injected by u-boot, it will be
there anyway.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 27, 2014 at 11:05:29AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 27, 2014 at 10:55 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> >> >> Is simplefb something that should be in the device tree distinctly in
> >> >> the first place - shouldn't it be a subset of the functionality of the
> >> >> video nodes?  It's the same hardware being driven differently.
> >> >
> >> > Therorically, yes, but that would mean knowing beforehand what the
> >> > final binding will look like, even before submitting the driver. Since
> >> > the bindings are always reviewed, and most of the time changed
> >> > slightly, that wouldn't work very well with the DT as a stable ABI
> >> > policy I guess.
> >>
> >> If you don't know how the bindings for a device will look like at the time of
> >> writing your DTS, you're always screwed, whether you add a simpefb
> >> node or not.
> >>
> >> If you know how the bindings look like, just add the device, with an extra
> >> "linux,simplefb" compatibility value.
> >> If you don't know how the bindings look like, do your utter best in
> >> guessing. Your DTS must be amended later anyway, either because
> >> you guessed wrong[*] (in case you added a node to have simplefb
> >> working), or because you have to add a real device node (in case you
> >> didn't add one for simplefb).
> >
> > Let's be conservative and consider the case where we would guess
> > wrong.
> >
> > If we just rely on a simplefb node, when reviewing and integrating the
> > "new" bindings to describe accureately the various IPs involved in the
> > display path, we would obviously create new compatibles for
> > them. Since it's new compatibles, we can come up with any binding we'd
> > like, without have to consider the backward compatibility, since it's
> > a new binding.
> >
> > Then, we just remove the simplefb, all is good.
> 
> I would keep the simplefb compatible value. Else you break compatibility
> with old kernels that don't have your new driver.

Yes, true. Since the simplefb will be injected by u-boot, it will be
there anyway.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/f1cfe555/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]

On Wed, Aug 27, 2014 at 10:55:38AM +0200, Maxime Ripard wrote:
> Hi!
> 
> On Wed, Aug 27, 2014 at 10:37:36AM +0200, Geert Uytterhoeven wrote:
> > Hi Maxime,
> > 
> > On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> > >> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
> > >>
> > >> > It is not clear to me where the hardware resources should be listed in
> > >> > DT, being it a simplefb node or part of the actual hardware device node
> > >> > properly marked as dynamic boot defaults or something else? It's
> > >> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> > >> > As far as simplefb is concerned it is a hardware desription of the
> > >> > framebuffer, but for a kms driver it's no more than firmware handover of
> > >> > boottime settings and ceases to exists once the kms driver have
> > >> > reconfigured the hardware.
> > >>
> > >> Is simplefb something that should be in the device tree distinctly in
> > >> the first place - shouldn't it be a subset of the functionality of the
> > >> video nodes?  It's the same hardware being driven differently.
> > >
> > > Therorically, yes, but that would mean knowing beforehand what the
> > > final binding will look like, even before submitting the driver. Since
> > > the bindings are always reviewed, and most of the time changed
> > > slightly, that wouldn't work very well with the DT as a stable ABI
> > > policy I guess.
> > 
> > If you don't know how the bindings for a device will look like at the time of
> > writing your DTS, you're always screwed, whether you add a simpefb
> > node or not.
> > 
> > If you know how the bindings look like, just add the device, with an extra
> > "linux,simplefb" compatibility value.
> > If you don't know how the bindings look like, do your utter best in
> > guessing. Your DTS must be amended later anyway, either because
> > you guessed wrong[*] (in case you added a node to have simplefb
> > working), or because you have to add a real device node (in case you
> > didn't add one for simplefb).
> 
> Let's be conservative and consider the case where we would guess
> wrong.
> 
> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.
> 
> Then, we just remove the simplefb, all is good.
> 
> If we were to try to create our bindings for all the IPs involved, and
> were not pleased with the binding anymore when merging the driver,
> then we would have to break the bindings, since we don't introduce a
> new compatible anymore, but modifying an existing one.

It's usually a bad idea to merge a binding without an appropriate
implementation thereof in a driver. It's been done in the past and very
often has resulted in bindings that turned out unusable.

You could start out small and only describe the various individual IP
blocks that exist in the hardware with reg, interrupts, clock, etc.
properties, most of which should be known up front. Then you could try
to find out where simplefb fits best.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 10:55:38AM +0200, Maxime Ripard wrote:
> Hi!
> 
> On Wed, Aug 27, 2014 at 10:37:36AM +0200, Geert Uytterhoeven wrote:
> > Hi Maxime,
> > 
> > On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> > >> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
> > >>
> > >> > It is not clear to me where the hardware resources should be listed in
> > >> > DT, being it a simplefb node or part of the actual hardware device node
> > >> > properly marked as dynamic boot defaults or something else? It's
> > >> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> > >> > As far as simplefb is concerned it is a hardware desription of the
> > >> > framebuffer, but for a kms driver it's no more than firmware handover of
> > >> > boottime settings and ceases to exists once the kms driver have
> > >> > reconfigured the hardware.
> > >>
> > >> Is simplefb something that should be in the device tree distinctly in
> > >> the first place - shouldn't it be a subset of the functionality of the
> > >> video nodes?  It's the same hardware being driven differently.
> > >
> > > Therorically, yes, but that would mean knowing beforehand what the
> > > final binding will look like, even before submitting the driver. Since
> > > the bindings are always reviewed, and most of the time changed
> > > slightly, that wouldn't work very well with the DT as a stable ABI
> > > policy I guess.
> > 
> > If you don't know how the bindings for a device will look like at the time of
> > writing your DTS, you're always screwed, whether you add a simpefb
> > node or not.
> > 
> > If you know how the bindings look like, just add the device, with an extra
> > "linux,simplefb" compatibility value.
> > If you don't know how the bindings look like, do your utter best in
> > guessing. Your DTS must be amended later anyway, either because
> > you guessed wrong[*] (in case you added a node to have simplefb
> > working), or because you have to add a real device node (in case you
> > didn't add one for simplefb).
> 
> Let's be conservative and consider the case where we would guess
> wrong.
> 
> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.
> 
> Then, we just remove the simplefb, all is good.
> 
> If we were to try to create our bindings for all the IPs involved, and
> were not pleased with the binding anymore when merging the driver,
> then we would have to break the bindings, since we don't introduce a
> new compatible anymore, but modifying an existing one.

It's usually a bad idea to merge a binding without an appropriate
implementation thereof in a driver. It's been done in the past and very
often has resulted in bindings that turned out unusable.

You could start out small and only describe the various individual IP
blocks that exist in the hardware with reg, interrupts, clock, etc.
properties, most of which should be known up front. Then you could try
to find out where simplefb fits best.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/3c54a330/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

ons 2014-08-27 klockan 10:55 +0200 skrev Maxime Ripard:

> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.

My gut feeling is that the attributes needed by simplefb belong in the
actual hardware node somehow, with a standard layout so it can be
applied on all compatible video devices.

The complication is that these attributes is volatile and not really
set/defined by hardware. Similar to UART baud rate (and kernel command
line if you like).

Regards
Henrik
 

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

ons 2014-08-27 klockan 10:55 +0200 skrev Maxime Ripard:

> If we just rely on a simplefb node, when reviewing and integrating the
> "new" bindings to describe accureately the various IPs involved in the
> display path, we would obviously create new compatibles for
> them. Since it's new compatibles, we can come up with any binding we'd
> like, without have to consider the backward compatibility, since it's
> a new binding.

My gut feeling is that the attributes needed by simplefb belong in the
actual hardware node somehow, with a standard layout so it can be
applied on all compatible video devices.

The complication is that these attributes is volatile and not really
set/defined by hardware. Similar to UART baud rate (and kernel command
line if you like).

Regards
Henrik
 

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi All,

On Wed, Aug 27, 2014 at 6:37 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Maxime,
>
> On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
>>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
>>>
>>> > It is not clear to me where the hardware resources should be listed in
>>> > DT, being it a simplefb node or part of the actual hardware device node
>>> > properly marked as dynamic boot defaults or something else? It's
>>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
>>> > As far as simplefb is concerned it is a hardware desription of the
>>> > framebuffer, but for a kms driver it's no more than firmware handover of
>>> > boottime settings and ceases to exists once the kms driver have
>>> > reconfigured the hardware.
>>>
>>> Is simplefb something that should be in the device tree distinctly in
>>> the first place - shouldn't it be a subset of the functionality of the
>>> video nodes?  It's the same hardware being driven differently.
>>
>> Therorically, yes, but that would mean knowing beforehand what the
>> final binding will look like, even before submitting the driver. Since
>> the bindings are always reviewed, and most of the time changed
>> slightly, that wouldn't work very well with the DT as a stable ABI
>> policy I guess.
>
> If you don't know how the bindings for a device will look like at the time of
> writing your DTS, you're always screwed, whether you add a simpefb
> node or not.
>
> If you know how the bindings look like, just add the device, with an extra
> "linux,simplefb" compatibility value.
> If you don't know how the bindings look like, do your utter best in
> guessing. Your DTS must be amended later anyway, either because
> you guessed wrong[*] (in case you added a node to have simplefb
> working), or because you have to add a real device node (in case you
> didn't add one for simplefb).
>
> [*] Actually you may have guessed right, in which case it'll continue
>     working as-is, and everybody will be happy.
>     Whether you want to keep backwards-compatibility in your future driver
>     with the "guessed wrong" node is up to you.

I apologise if I'm stepping on anyone's toes or horribly
misrepresenting device tree's capabilities, but couldn't we start out
with something like:

disp@whatever {
    compatible = "sunxi,sun4i-disp";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
}

as our binding?

u-boot could then set up a framebuffer and mangle this to:

disp@whatever {
    compatible = "sunxi,sun4i-disp", "linux,simplefb";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // simplefb stuff
}

Hell, if we have a reserved memory driver, couldn't we then mangle
this to something like:

disp@whatever {
    compatible = "sunxi,sun4i-disp", "linux,simplefb";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // simplefb stuff
    // reserved mem stuff
}

simplefb is modified to be smart enough to grab the clocks (that's a
small amount of code that almost every DT-enabled driver has, right?)
and if we're going to use the reserved memory driver to ensure nobody
messes with it's in-memory framebuffer, it'll have to deal with that
too.

Eventually sunxi-kms gets submitted, and it takes the
"sunxi,sun4i-disp" compatible, which we've already defined, however we
need some more stuff so we just add more stuff to the binding and end
up with something like:

disp@whatever {
    compatible = "sunxi,sun4i-disp";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // sunxi-kms stuff
}

I believe there'd be no backwards compatibility issues as we're only
adding, not subtracting or modifying. We already know which clocks are
required for the display IP, right? And if not, we can add them. I
believe this minimises the mangling u-boot has to do (at least
initially) and is forward and backward compatible.

That'd work, right?

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi All,

On Wed, Aug 27, 2014 at 6:37 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Maxime,
>
> On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
>>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
>>>
>>> > It is not clear to me where the hardware resources should be listed in
>>> > DT, being it a simplefb node or part of the actual hardware device node
>>> > properly marked as dynamic boot defaults or something else? It's
>>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
>>> > As far as simplefb is concerned it is a hardware desription of the
>>> > framebuffer, but for a kms driver it's no more than firmware handover of
>>> > boottime settings and ceases to exists once the kms driver have
>>> > reconfigured the hardware.
>>>
>>> Is simplefb something that should be in the device tree distinctly in
>>> the first place - shouldn't it be a subset of the functionality of the
>>> video nodes?  It's the same hardware being driven differently.
>>
>> Therorically, yes, but that would mean knowing beforehand what the
>> final binding will look like, even before submitting the driver. Since
>> the bindings are always reviewed, and most of the time changed
>> slightly, that wouldn't work very well with the DT as a stable ABI
>> policy I guess.
>
> If you don't know how the bindings for a device will look like at the time of
> writing your DTS, you're always screwed, whether you add a simpefb
> node or not.
>
> If you know how the bindings look like, just add the device, with an extra
> "linux,simplefb" compatibility value.
> If you don't know how the bindings look like, do your utter best in
> guessing. Your DTS must be amended later anyway, either because
> you guessed wrong[*] (in case you added a node to have simplefb
> working), or because you have to add a real device node (in case you
> didn't add one for simplefb).
>
> [*] Actually you may have guessed right, in which case it'll continue
>     working as-is, and everybody will be happy.
>     Whether you want to keep backwards-compatibility in your future driver
>     with the "guessed wrong" node is up to you.

I apologise if I'm stepping on anyone's toes or horribly
misrepresenting device tree's capabilities, but couldn't we start out
with something like:

disp at whatever {
    compatible = "sunxi,sun4i-disp";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
}

as our binding?

u-boot could then set up a framebuffer and mangle this to:

disp at whatever {
    compatible = "sunxi,sun4i-disp", "linux,simplefb";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // simplefb stuff
}

Hell, if we have a reserved memory driver, couldn't we then mangle
this to something like:

disp at whatever {
    compatible = "sunxi,sun4i-disp", "linux,simplefb";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // simplefb stuff
    // reserved mem stuff
}

simplefb is modified to be smart enough to grab the clocks (that's a
small amount of code that almost every DT-enabled driver has, right?)
and if we're going to use the reserved memory driver to ensure nobody
messes with it's in-memory framebuffer, it'll have to deal with that
too.

Eventually sunxi-kms gets submitted, and it takes the
"sunxi,sun4i-disp" compatible, which we've already defined, however we
need some more stuff so we just add more stuff to the binding and end
up with something like:

disp at whatever {
    compatible = "sunxi,sun4i-disp";
    clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;
    // sunxi-kms stuff
}

I believe there'd be no backwards compatibility issues as we're only
adding, not subtracting or modifying. We already know which clocks are
required for the display IP, right? And if not, we can add them. I
believe this minimises the mangling u-boot has to do (at least
initially) and is forward and backward compatible.

That'd work, right?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]

Hi Julian,

On Wed, Aug 27, 2014 at 10:45:14PM +1000, Julian Calaby wrote:
> Hi All,
> 
> On Wed, Aug 27, 2014 at 6:37 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Hi Maxime,
> >
> > On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> >>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordström wrote:
> >>>
> >>> > It is not clear to me where the hardware resources should be listed in
> >>> > DT, being it a simplefb node or part of the actual hardware device node
> >>> > properly marked as dynamic boot defaults or something else? It's
> >>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> >>> > As far as simplefb is concerned it is a hardware desription of the
> >>> > framebuffer, but for a kms driver it's no more than firmware handover of
> >>> > boottime settings and ceases to exists once the kms driver have
> >>> > reconfigured the hardware.
> >>>
> >>> Is simplefb something that should be in the device tree distinctly in
> >>> the first place - shouldn't it be a subset of the functionality of the
> >>> video nodes?  It's the same hardware being driven differently.
> >>
> >> Therorically, yes, but that would mean knowing beforehand what the
> >> final binding will look like, even before submitting the driver. Since
> >> the bindings are always reviewed, and most of the time changed
> >> slightly, that wouldn't work very well with the DT as a stable ABI
> >> policy I guess.
> >
> > If you don't know how the bindings for a device will look like at the time of
> > writing your DTS, you're always screwed, whether you add a simpefb
> > node or not.
> >
> > If you know how the bindings look like, just add the device, with an extra
> > "linux,simplefb" compatibility value.
> > If you don't know how the bindings look like, do your utter best in
> > guessing. Your DTS must be amended later anyway, either because
> > you guessed wrong[*] (in case you added a node to have simplefb
> > working), or because you have to add a real device node (in case you
> > didn't add one for simplefb).
> >
> > [*] Actually you may have guessed right, in which case it'll continue
> >     working as-is, and everybody will be happy.
> >     Whether you want to keep backwards-compatibility in your future driver
> >     with the "guessed wrong" node is up to you.
> 
> I apologise if I'm stepping on anyone's toes or horribly
> misrepresenting device tree's capabilities, but couldn't we start out
> with something like:
> 
> disp@whatever {
>     compatible = "sunxi,sun4i-disp";
>     clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;

Unfortunately, it's slightly more complicated than that, since there
is several clocks involved, that feed several different IPs that need
to stay on.

In this patch, and given the current code we have, we need to have the
gates for the HDMI controller, the LCD controller and the display
backend, which are three different IPs, with one clock each, that
would be described by three different nodes.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

Hi Julian,

On Wed, Aug 27, 2014 at 10:45:14PM +1000, Julian Calaby wrote:
> Hi All,
> 
> On Wed, Aug 27, 2014 at 6:37 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Hi Maxime,
> >
> > On Wed, Aug 27, 2014 at 10:22 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> On Wed, Aug 27, 2014 at 08:40:57AM +0100, Mark Brown wrote:
> >>> On Tue, Aug 26, 2014 at 08:40:09PM +0200, Henrik Nordstr?m wrote:
> >>>
> >>> > It is not clear to me where the hardware resources should be listed in
> >>> > DT, being it a simplefb node or part of the actual hardware device node
> >>> > properly marked as dynamic boot defaults or something else? It's
> >>> > somewhere inbetween hardware and virtual device, and somewhat volatile.
> >>> > As far as simplefb is concerned it is a hardware desription of the
> >>> > framebuffer, but for a kms driver it's no more than firmware handover of
> >>> > boottime settings and ceases to exists once the kms driver have
> >>> > reconfigured the hardware.
> >>>
> >>> Is simplefb something that should be in the device tree distinctly in
> >>> the first place - shouldn't it be a subset of the functionality of the
> >>> video nodes?  It's the same hardware being driven differently.
> >>
> >> Therorically, yes, but that would mean knowing beforehand what the
> >> final binding will look like, even before submitting the driver. Since
> >> the bindings are always reviewed, and most of the time changed
> >> slightly, that wouldn't work very well with the DT as a stable ABI
> >> policy I guess.
> >
> > If you don't know how the bindings for a device will look like at the time of
> > writing your DTS, you're always screwed, whether you add a simpefb
> > node or not.
> >
> > If you know how the bindings look like, just add the device, with an extra
> > "linux,simplefb" compatibility value.
> > If you don't know how the bindings look like, do your utter best in
> > guessing. Your DTS must be amended later anyway, either because
> > you guessed wrong[*] (in case you added a node to have simplefb
> > working), or because you have to add a real device node (in case you
> > didn't add one for simplefb).
> >
> > [*] Actually you may have guessed right, in which case it'll continue
> >     working as-is, and everybody will be happy.
> >     Whether you want to keep backwards-compatibility in your future driver
> >     with the "guessed wrong" node is up to you.
> 
> I apologise if I'm stepping on anyone's toes or horribly
> misrepresenting device tree's capabilities, but couldn't we start out
> with something like:
> 
> disp at whatever {
>     compatible = "sunxi,sun4i-disp";
>     clocks = <&stuff 1>, <&stuff 2>, <&stuff 3>;

Unfortunately, it's slightly more complicated than that, since there
is several clocks involved, that feed several different IPs that need
to stay on.

In this patch, and given the current code we have, we need to have the
gates for the HDMI controller, the LCD controller and the display
backend, which are three different IPs, with one clock each, that
would be described by three different nodes.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/a190f9d6/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Mon, Aug 25, 2014 at 10:53 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 04:23:59PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/25/2014 04:16 PM, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> >>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>>>> [...]
>> >>>>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>>>
>> >>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>>>> clock driver.
>> >>>>>>
>> >>>>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>>>> options to know which clock to enable, especially when clk_get should
>> >>>>>> have the consumer device as an argument.
>> >>>>>
>> >>>>> Are you saying is that you want to solve a platform-specific problem by
>> >>>>> pushing code into simple, generic drivers so that your platform code can
>> >>>>> stay "clean"?
>> >>>>
>> >>>> Are you saying that this driver would become "dirty" with such a patch?
>> >>>
>> >>> Yes. Others have said the same and even provided alternative solutions
>> >>> on how to solve what's seemingly a platform-specific problem in a
>> >>> platform-specific way.
>> >>
>> >> This is not platform specific, any platform with a complete clock driver
>> >> will suffer from the same problem (the clock driver disabling unclaimed
>> >> ahb gates, and thus killing the video output) if it wants to use simplefb
>> >> for early console support.
>> >
>> > It is platform specific in that your platform may require certain clocks
>> > to remain on. The next platform may require power domains to remain on
>> > during boot and yet another one may rely on regulators to stay on during
>> > boot. By your argument simplefb will need to be taught to handle pretty
>> > much every type of resource that the kernel has.
>> >
>> >> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> >> them from ever being disabled in the sunxi clock driver, that is not really
>> >> a solution either, as we want to be able to turn these things off to safe
>> >> power on screen blank once control has been turned over to the kms driver.
>> >
>> > Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
>> > should involve marking PLLs or "gates" as properly managed.
>>
>> And by your earlier argument also power domains, regulators, etc. So now we need
>> to add code to each of the clock core, power-domain core, regulator core, etc. to
>> have them now about this initially unmanaged state thing you're introducing, as
>> well as modify all involved clock / regulator / etc. drivers to mark certain
>> resources as unmanaged.
>
> Hmm... that's true. But we already have a way to deal with exactly this
> situation for regulators. There's a property called regulator-boot-on
> which a bootloader should set whet it has enabled a given regulator. It
> can of course also be set statically in a DTS if it's know upfront that
> a bootloader will always enable it. Perhaps what we need is a similar
> property for clocks so that the clock framework will not inadvertently
> turn off a clock that's still being used.

There should probably be a generic 'boot-initialized;' property that
can be added to any DT device node.   Then uboot can add that property
to the device node for anything it has turned on.

You could even use it to add more info 'boot-initialized = <"9600 8 N 1">;'

That passes the info in an OS agnostic manner.


>
> Thierry



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Mon, Aug 25, 2014 at 10:53 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 04:23:59PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 08/25/2014 04:16 PM, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> >> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> >>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> >>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> >>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> >>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> >>>>> [...]
>> >>>>>>> If not, perhaps the clock driver should force the clock to be
>> >>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> >>>>>>
>> >>>>>> I'm sorry, but I'm not going to take any code that will do that in our
>> >>>>>> clock driver.
>> >>>>>>
>> >>>>>> I'm not going to have a huge list of ifdef depending on configuration
>> >>>>>> options to know which clock to enable, especially when clk_get should
>> >>>>>> have the consumer device as an argument.
>> >>>>>
>> >>>>> Are you saying is that you want to solve a platform-specific problem by
>> >>>>> pushing code into simple, generic drivers so that your platform code can
>> >>>>> stay "clean"?
>> >>>>
>> >>>> Are you saying that this driver would become "dirty" with such a patch?
>> >>>
>> >>> Yes. Others have said the same and even provided alternative solutions
>> >>> on how to solve what's seemingly a platform-specific problem in a
>> >>> platform-specific way.
>> >>
>> >> This is not platform specific, any platform with a complete clock driver
>> >> will suffer from the same problem (the clock driver disabling unclaimed
>> >> ahb gates, and thus killing the video output) if it wants to use simplefb
>> >> for early console support.
>> >
>> > It is platform specific in that your platform may require certain clocks
>> > to remain on. The next platform may require power domains to remain on
>> > during boot and yet another one may rely on regulators to stay on during
>> > boot. By your argument simplefb will need to be taught to handle pretty
>> > much every type of resource that the kernel has.
>> >
>> >> As for the suggestion to simply never disable the plls / ahb gates by blocking
>> >> them from ever being disabled in the sunxi clock driver, that is not really
>> >> a solution either, as we want to be able to turn these things off to safe
>> >> power on screen blank once control has been turned over to the kms driver.
>> >
>> > Then perhaps part of the hand-off procedure between simplefb and DRM/KMS
>> > should involve marking PLLs or "gates" as properly managed.
>>
>> And by your earlier argument also power domains, regulators, etc. So now we need
>> to add code to each of the clock core, power-domain core, regulator core, etc. to
>> have them now about this initially unmanaged state thing you're introducing, as
>> well as modify all involved clock / regulator / etc. drivers to mark certain
>> resources as unmanaged.
>
> Hmm... that's true. But we already have a way to deal with exactly this
> situation for regulators. There's a property called regulator-boot-on
> which a bootloader should set whet it has enabled a given regulator. It
> can of course also be set statically in a DTS if it's know upfront that
> a bootloader will always enable it. Perhaps what we need is a similar
> property for clocks so that the clock framework will not inadvertently
> turn off a clock that's still being used.

There should probably be a generic 'boot-initialized;' property that
can be added to any DT device node.   Then uboot can add that property
to the device node for anything it has turned on.

You could even use it to add more info 'boot-initialized = <"9600 8 N 1">;'

That passes the info in an OS agnostic manner.


>
> Thierry



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > >>> [...]
> > >>>>> If not, perhaps the clock driver should force the clock to be
> > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > >>>>
> > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > >>>> clock driver.
> > >>>>
> > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > >>>> options to know which clock to enable, especially when clk_get should
> > >>>> have the consumer device as an argument.
> > >>>
> > >>> Are you saying is that you want to solve a platform-specific problem by
> > >>> pushing code into simple, generic drivers so that your platform code can
> > >>> stay "clean"?
> > >>
> > >> Are you saying that this driver would become "dirty" with such a patch?
> > > 
> > > Yes. Others have said the same and even provided alternative solutions
> > > on how to solve what's seemingly a platform-specific problem in a
> > > platform-specific way.
> > 
> > This is not platform specific, any platform with a complete clock driver
> > will suffer from the same problem (the clock driver disabling unclaimed
> > ahb gates, and thus killing the video output) if it wants to use simplefb
> > for early console support.
> 
> It is platform specific in that your platform may require certain clocks
> to remain on.

The platform doesn't. simplefb does. simplefb is the obvious consumer
for these clocks, and given the current API and abstraction we have,
it should be the one claiming the clocks too.

> The next platform may require power domains to remain on during boot
> and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle
> pretty much every type of resource that the kernel has.

And I wouldn't find anything wrong with that. We're already doing so
for any generic driver in the kernel (AHCI, EHCI comes to my mind
first, there's probably a lot of others). Why wouldn't we do as such
for this one?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > >>> [...]
> > >>>>> If not, perhaps the clock driver should force the clock to be
> > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > >>>>
> > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > >>>> clock driver.
> > >>>>
> > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > >>>> options to know which clock to enable, especially when clk_get should
> > >>>> have the consumer device as an argument.
> > >>>
> > >>> Are you saying is that you want to solve a platform-specific problem by
> > >>> pushing code into simple, generic drivers so that your platform code can
> > >>> stay "clean"?
> > >>
> > >> Are you saying that this driver would become "dirty" with such a patch?
> > > 
> > > Yes. Others have said the same and even provided alternative solutions
> > > on how to solve what's seemingly a platform-specific problem in a
> > > platform-specific way.
> > 
> > This is not platform specific, any platform with a complete clock driver
> > will suffer from the same problem (the clock driver disabling unclaimed
> > ahb gates, and thus killing the video output) if it wants to use simplefb
> > for early console support.
> 
> It is platform specific in that your platform may require certain clocks
> to remain on.

The platform doesn't. simplefb does. simplefb is the obvious consumer
for these clocks, and given the current API and abstraction we have,
it should be the one claiming the clocks too.

> The next platform may require power domains to remain on during boot
> and yet another one may rely on regulators to stay on during
> boot. By your argument simplefb will need to be taught to handle
> pretty much every type of resource that the kernel has.

And I wouldn't find anything wrong with that. We're already doing so
for any generic driver in the kernel (AHCI, EHCI comes to my mind
first, there's probably a lot of others). Why wouldn't we do as such
for this one?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/066f03bd/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]

On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > >>> [...]
> > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > >>>>
> > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > >>>> clock driver.
> > > >>>>
> > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > >>>> options to know which clock to enable, especially when clk_get should
> > > >>>> have the consumer device as an argument.
> > > >>>
> > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > >>> pushing code into simple, generic drivers so that your platform code can
> > > >>> stay "clean"?
> > > >>
> > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > 
> > > > Yes. Others have said the same and even provided alternative solutions
> > > > on how to solve what's seemingly a platform-specific problem in a
> > > > platform-specific way.
> > > 
> > > This is not platform specific, any platform with a complete clock driver
> > > will suffer from the same problem (the clock driver disabling unclaimed
> > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > for early console support.
> > 
> > It is platform specific in that your platform may require certain clocks
> > to remain on.
> 
> The platform doesn't. simplefb does. simplefb is the obvious consumer
> for these clocks, and given the current API and abstraction we have,
> it should be the one claiming the clocks too.

No. simplefb just wants to write to some memory that hardware has been
set up to scan out. The platform requires that the clocks be on. Other
platforms may not even allow turning off the clocks.

> > The next platform may require power domains to remain on during boot
> > and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle
> > pretty much every type of resource that the kernel has.
> 
> And I wouldn't find anything wrong with that. We're already doing so
> for any generic driver in the kernel (AHCI, EHCI comes to my mind
> first, there's probably a lot of others). Why wouldn't we do as such
> for this one?

Yes, and we've had similar discussions in those subsystems too.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > >>> [...]
> > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > >>>>
> > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > >>>> clock driver.
> > > >>>>
> > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > >>>> options to know which clock to enable, especially when clk_get should
> > > >>>> have the consumer device as an argument.
> > > >>>
> > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > >>> pushing code into simple, generic drivers so that your platform code can
> > > >>> stay "clean"?
> > > >>
> > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > 
> > > > Yes. Others have said the same and even provided alternative solutions
> > > > on how to solve what's seemingly a platform-specific problem in a
> > > > platform-specific way.
> > > 
> > > This is not platform specific, any platform with a complete clock driver
> > > will suffer from the same problem (the clock driver disabling unclaimed
> > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > for early console support.
> > 
> > It is platform specific in that your platform may require certain clocks
> > to remain on.
> 
> The platform doesn't. simplefb does. simplefb is the obvious consumer
> for these clocks, and given the current API and abstraction we have,
> it should be the one claiming the clocks too.

No. simplefb just wants to write to some memory that hardware has been
set up to scan out. The platform requires that the clocks be on. Other
platforms may not even allow turning off the clocks.

> > The next platform may require power domains to remain on during boot
> > and yet another one may rely on regulators to stay on during
> > boot. By your argument simplefb will need to be taught to handle
> > pretty much every type of resource that the kernel has.
> 
> And I wouldn't find anything wrong with that. We're already doing so
> for any generic driver in the kernel (AHCI, EHCI comes to my mind
> first, there's probably a lot of others). Why wouldn't we do as such
> for this one?

Yes, and we've had similar discussions in those subsystems too.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/32926166/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> 
> No. simplefb just wants to write to some memory that hardware has been
> set up to scan out. The platform requires that the clocks be on.

Simplefb also requires that the memory is there and is persistent. Fine 
for discrete graphics cards, fine for rpi where most things are hidden 
from the ARM core anyway, not so fine for anybody else.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> 
> No. simplefb just wants to write to some memory that hardware has been
> set up to scan out. The platform requires that the clocks be on.

Simplefb also requires that the memory is there and is persistent. Fine 
for discrete graphics cards, fine for rpi where most things are hidden 
from the ARM core anyway, not so fine for anybody else.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > 
> > No. simplefb just wants to write to some memory that hardware has been
> > set up to scan out. The platform requires that the clocks be on.
> 
> Simplefb also requires that the memory is there and is persistent. Fine 
> for discrete graphics cards, fine for rpi where most things are hidden 
> from the ARM core anyway, not so fine for anybody else.

I don't understand. This patch series isn't changing anything about the
memory aspects of the driver yet it's working for you on sunxi, isn't
it? So it can't be all that broken.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > 
> > No. simplefb just wants to write to some memory that hardware has been
> > set up to scan out. The platform requires that the clocks be on.
> 
> Simplefb also requires that the memory is there and is persistent. Fine 
> for discrete graphics cards, fine for rpi where most things are hidden 
> from the ARM core anyway, not so fine for anybody else.

I don't understand. This patch series isn't changing anything about the
memory aspects of the driver yet it's working for you on sunxi, isn't
it? So it can't be all that broken.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/9b9b9f75/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > 
> > > No. simplefb just wants to write to some memory that hardware has been
> > > set up to scan out. The platform requires that the clocks be on.
> > 
> > Simplefb also requires that the memory is there and is persistent. Fine 
> > for discrete graphics cards, fine for rpi where most things are hidden 
> > from the ARM core anyway, not so fine for anybody else.
> 
> I don't understand. This patch series isn't changing anything about the
> memory aspects of the driver yet it's working for you on sunxi, isn't
> it? So it can't be all that broken.
> 
> Thierry

Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
which the kernel never gets told about. A nice throwback to x86 IGP 
bioses, a past i had thought i had left behind forgood.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > 
> > > No. simplefb just wants to write to some memory that hardware has been
> > > set up to scan out. The platform requires that the clocks be on.
> > 
> > Simplefb also requires that the memory is there and is persistent. Fine 
> > for discrete graphics cards, fine for rpi where most things are hidden 
> > from the ARM core anyway, not so fine for anybody else.
> 
> I don't understand. This patch series isn't changing anything about the
> memory aspects of the driver yet it's working for you on sunxi, isn't
> it? So it can't be all that broken.
> 
> Thierry

Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
which the kernel never gets told about. A nice throwback to x86 IGP 
bioses, a past i had thought i had left behind forgood.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > 
> > > > No. simplefb just wants to write to some memory that hardware has been
> > > > set up to scan out. The platform requires that the clocks be on.
> > > 
> > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > from the ARM core anyway, not so fine for anybody else.
> > 
> > I don't understand. This patch series isn't changing anything about the
> > memory aspects of the driver yet it's working for you on sunxi, isn't
> > it? So it can't be all that broken.
> > 
> > Thierry
> 
> Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> which the kernel never gets told about. A nice throwback to x86 IGP 
> bioses, a past i had thought i had left behind forgood.

Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
in the kernel)? I think that's the generally accepted way to do this
with DT.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > 
> > > > No. simplefb just wants to write to some memory that hardware has been
> > > > set up to scan out. The platform requires that the clocks be on.
> > > 
> > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > from the ARM core anyway, not so fine for anybody else.
> > 
> > I don't understand. This patch series isn't changing anything about the
> > memory aspects of the driver yet it's working for you on sunxi, isn't
> > it? So it can't be all that broken.
> > 
> > Thierry
> 
> Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> which the kernel never gets told about. A nice throwback to x86 IGP 
> bioses, a past i had thought i had left behind forgood.

Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
in the kernel)? I think that's the generally accepted way to do this
with DT.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/18f0c06c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Tue, Aug 26, 2014 at 02:21:16PM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> > On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > > 
> > > > > No. simplefb just wants to write to some memory that hardware has been
> > > > > set up to scan out. The platform requires that the clocks be on.
> > > > 
> > > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > > from the ARM core anyway, not so fine for anybody else.
> > > 
> > > I don't understand. This patch series isn't changing anything about the
> > > memory aspects of the driver yet it's working for you on sunxi, isn't
> > > it? So it can't be all that broken.
> > > 
> > > Thierry
> > 
> > Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> > which the kernel never gets told about. A nice throwback to x86 IGP 
> > bioses, a past i had thought i had left behind forgood.
> 
> Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
> in the kernel)? I think that's the generally accepted way to do this
> with DT.
> 
> Thierry

It was mentioned to me, and I probably could do that, but this seemed 
even more DT wrangling from within u-boot, and it didn't seem finished 
yet. Plus, all of this already was way more wrangling than i bargained 
for, especially with the promise of "simple"-fb. Then there is the 
really awkward way in which one gets to define clocks outside of a 
dts/compiler (you've seen the code, right?), i really did not feel like 
repeating something like that.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Tue, Aug 26, 2014 at 02:21:16PM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> > On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > > 
> > > > > No. simplefb just wants to write to some memory that hardware has been
> > > > > set up to scan out. The platform requires that the clocks be on.
> > > > 
> > > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > > from the ARM core anyway, not so fine for anybody else.
> > > 
> > > I don't understand. This patch series isn't changing anything about the
> > > memory aspects of the driver yet it's working for you on sunxi, isn't
> > > it? So it can't be all that broken.
> > > 
> > > Thierry
> > 
> > Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> > which the kernel never gets told about. A nice throwback to x86 IGP 
> > bioses, a past i had thought i had left behind forgood.
> 
> Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
> in the kernel)? I think that's the generally accepted way to do this
> with DT.
> 
> Thierry

It was mentioned to me, and I probably could do that, but this seemed 
even more DT wrangling from within u-boot, and it didn't seem finished 
yet. Plus, all of this already was way more wrangling than i bargained 
for, especially with the promise of "simple"-fb. Then there is the 
really awkward way in which one gets to define clocks outside of a 
dts/compiler (you've seen the code, right?), i really did not feel like 
repeating something like that.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

On Tue, Aug 26, 2014 at 02:33:57PM +0200, Luc Verhaegen wrote:
> On Tue, Aug 26, 2014 at 02:21:16PM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> > > On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > > > 
> > > > > > No. simplefb just wants to write to some memory that hardware has been
> > > > > > set up to scan out. The platform requires that the clocks be on.
> > > > > 
> > > > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > > > from the ARM core anyway, not so fine for anybody else.
> > > > 
> > > > I don't understand. This patch series isn't changing anything about the
> > > > memory aspects of the driver yet it's working for you on sunxi, isn't
> > > > it? So it can't be all that broken.
> > > > 
> > > > Thierry
> > > 
> > > Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> > > which the kernel never gets told about. A nice throwback to x86 IGP 
> > > bioses, a past i had thought i had left behind forgood.
> > 
> > Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
> > in the kernel)? I think that's the generally accepted way to do this
> > with DT.
> > 
> > Thierry
> 
> It was mentioned to me, and I probably could do that, but this seemed 
> even more DT wrangling from within u-boot, and it didn't seem finished 
> yet. Plus, all of this already was way more wrangling than i bargained 
> for, especially with the promise of "simple"-fb. Then there is the 
> really awkward way in which one gets to define clocks outside of a 
> dts/compiler (you've seen the code, right?), i really did not feel like 
> repeating something like that.

It could most probably be turned into fairly generic and reusable code
so that others can use it. And it would give you a way of recovering
those 8 MiB of memory that you'd otherwise loose.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 02:33:57PM +0200, Luc Verhaegen wrote:
> On Tue, Aug 26, 2014 at 02:21:16PM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 02:02:58PM +0200, Luc Verhaegen wrote:
> > > On Tue, Aug 26, 2014 at 09:52:49AM +0200, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 05:09:00PM +0200, Luc Verhaegen wrote:
> > > > > On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > > > > > 
> > > > > > No. simplefb just wants to write to some memory that hardware has been
> > > > > > set up to scan out. The platform requires that the clocks be on.
> > > > > 
> > > > > Simplefb also requires that the memory is there and is persistent. Fine 
> > > > > for discrete graphics cards, fine for rpi where most things are hidden 
> > > > > from the ARM core anyway, not so fine for anybody else.
> > > > 
> > > > I don't understand. This patch series isn't changing anything about the
> > > > memory aspects of the driver yet it's working for you on sunxi, isn't
> > > > it? So it can't be all that broken.
> > > > 
> > > > Thierry
> > > 
> > > Oh, i had to go wrestle with UBoot options and reserve 8MB off the top, 
> > > which the kernel never gets told about. A nice throwback to x86 IGP 
> > > bioses, a past i had thought i had left behind forgood.
> > 
> > Can you not use the reserved memory code (drivers/of/of_reserved_mem.c
> > in the kernel)? I think that's the generally accepted way to do this
> > with DT.
> > 
> > Thierry
> 
> It was mentioned to me, and I probably could do that, but this seemed 
> even more DT wrangling from within u-boot, and it didn't seem finished 
> yet. Plus, all of this already was way more wrangling than i bargained 
> for, especially with the promise of "simple"-fb. Then there is the 
> really awkward way in which one gets to define clocks outside of a 
> dts/compiler (you've seen the code, right?), i really did not feel like 
> repeating something like that.

It could most probably be turned into fairly generic and reusable code
so that others can use it. And it would give you a way of recovering
those 8 MiB of memory that you'd otherwise loose.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/b66e355c/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3587 bytes --]

On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > > >>> [...]
> > > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > > >>>>
> > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > > >>>> clock driver.
> > > > >>>>
> > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > > >>>> options to know which clock to enable, especially when clk_get should
> > > > >>>> have the consumer device as an argument.
> > > > >>>
> > > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > > >>> pushing code into simple, generic drivers so that your platform code can
> > > > >>> stay "clean"?
> > > > >>
> > > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > > 
> > > > > Yes. Others have said the same and even provided alternative solutions
> > > > > on how to solve what's seemingly a platform-specific problem in a
> > > > > platform-specific way.
> > > > 
> > > > This is not platform specific, any platform with a complete clock driver
> > > > will suffer from the same problem (the clock driver disabling unclaimed
> > > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > > for early console support.
> > > 
> > > It is platform specific in that your platform may require certain clocks
> > > to remain on.
> > 
> > The platform doesn't. simplefb does. simplefb is the obvious consumer
> > for these clocks, and given the current API and abstraction we have,
> > it should be the one claiming the clocks too.
> 
> No. simplefb just wants to write to some memory that hardware has been
> set up to scan out. The platform requires that the clocks be on. Other
> platforms may not even allow turning off the clocks.

Like what? the rpi? Come on. Just because the videocore is some black
box we know nothing about doesn't mean we should use it as an example.

Any decent enough SoC, with a decent support in the kernel will have
clocks for this, and I really wonder how simplefb will behave once its
clocks will be turned off...

> > > The next platform may require power domains to remain on during boot
> > > and yet another one may rely on regulators to stay on during
> > > boot. By your argument simplefb will need to be taught to handle
> > > pretty much every type of resource that the kernel has.
> > 
> > And I wouldn't find anything wrong with that. We're already doing so
> > for any generic driver in the kernel (AHCI, EHCI comes to my mind
> > first, there's probably a lot of others). Why wouldn't we do as such
> > for this one?
> 
> Yes, and we've had similar discussions in those subsystems too.

Similar discussion, with different outcomes it seems.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > > >>> [...]
> > > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > > >>>>
> > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > > >>>> clock driver.
> > > > >>>>
> > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > > >>>> options to know which clock to enable, especially when clk_get should
> > > > >>>> have the consumer device as an argument.
> > > > >>>
> > > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > > >>> pushing code into simple, generic drivers so that your platform code can
> > > > >>> stay "clean"?
> > > > >>
> > > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > > 
> > > > > Yes. Others have said the same and even provided alternative solutions
> > > > > on how to solve what's seemingly a platform-specific problem in a
> > > > > platform-specific way.
> > > > 
> > > > This is not platform specific, any platform with a complete clock driver
> > > > will suffer from the same problem (the clock driver disabling unclaimed
> > > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > > for early console support.
> > > 
> > > It is platform specific in that your platform may require certain clocks
> > > to remain on.
> > 
> > The platform doesn't. simplefb does. simplefb is the obvious consumer
> > for these clocks, and given the current API and abstraction we have,
> > it should be the one claiming the clocks too.
> 
> No. simplefb just wants to write to some memory that hardware has been
> set up to scan out. The platform requires that the clocks be on. Other
> platforms may not even allow turning off the clocks.

Like what? the rpi? Come on. Just because the videocore is some black
box we know nothing about doesn't mean we should use it as an example.

Any decent enough SoC, with a decent support in the kernel will have
clocks for this, and I really wonder how simplefb will behave once its
clocks will be turned off...

> > > The next platform may require power domains to remain on during boot
> > > and yet another one may rely on regulators to stay on during
> > > boot. By your argument simplefb will need to be taught to handle
> > > pretty much every type of resource that the kernel has.
> > 
> > And I wouldn't find anything wrong with that. We're already doing so
> > for any generic driver in the kernel (AHCI, EHCI comes to my mind
> > first, there's probably a lot of others). Why wouldn't we do as such
> > for this one?
> 
> Yes, and we've had similar discussions in those subsystems too.

Similar discussion, with different outcomes it seems.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140825/cef297d9/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]

On Mon, Aug 25, 2014 at 05:22:32PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> > > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > > > >>> [...]
> > > > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > > > >>>>
> > > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > > > >>>> clock driver.
> > > > > >>>>
> > > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > > > >>>> options to know which clock to enable, especially when clk_get should
> > > > > >>>> have the consumer device as an argument.
> > > > > >>>
> > > > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > > > >>> pushing code into simple, generic drivers so that your platform code can
> > > > > >>> stay "clean"?
> > > > > >>
> > > > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > > > 
> > > > > > Yes. Others have said the same and even provided alternative solutions
> > > > > > on how to solve what's seemingly a platform-specific problem in a
> > > > > > platform-specific way.
> > > > > 
> > > > > This is not platform specific, any platform with a complete clock driver
> > > > > will suffer from the same problem (the clock driver disabling unclaimed
> > > > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > > > for early console support.
> > > > 
> > > > It is platform specific in that your platform may require certain clocks
> > > > to remain on.
> > > 
> > > The platform doesn't. simplefb does. simplefb is the obvious consumer
> > > for these clocks, and given the current API and abstraction we have,
> > > it should be the one claiming the clocks too.
> > 
> > No. simplefb just wants to write to some memory that hardware has been
> > set up to scan out. The platform requires that the clocks be on. Other
> > platforms may not even allow turning off the clocks.
> 
> Like what? the rpi? Come on. Just because the videocore is some black
> box we know nothing about doesn't mean we should use it as an example.

You make it sound like the Raspberry Pi is somehow less important than
sunxi.

> Any decent enough SoC, with a decent support in the kernel will have
> clocks for this, and I really wonder how simplefb will behave once its
> clocks will be turned off...

There are other devices besides ARM SoCs that may want to use this
driver and that don't have clock support.

But you're missing my point. What I'm saying is that the simplefb driver
is meant to serve as a way to take over whatever framebuffer a firmware
set up. Therefore I think it makes the most sense to assume that nothing
needs to be controlled in any way since already been set up by firmware.
Eventually there should be a driver that takes over from simplefb that
knows how to properly handle the device's specifics, but that's not
simplefb.

The goal of this patch series is to keep clocks from being turned off.
But that's not what it does. What it does is turn clocks on to prevent
them from being turned off. In my opinion that's a workaround for a
deficiency in the kernel (and the firmware/kernel interface) and I think
it should be fixed at the root. So a much better solution would be to
establish a way for firmware to communicate to the kernel that a given
resource has been enabled by firmware and shouldn't be disabled. Such a
solution can be implement for all types of resources and can be reused
by all drivers since they don't have to worry about these details.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Aug 25, 2014 at 05:22:32PM +0200, Maxime Ripard wrote:
> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
> > On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
> > > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
> > > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
> > > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> > > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> > > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> > > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> > > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> > > > > >>> [...]
> > > > > >>>>> If not, perhaps the clock driver should force the clock to be
> > > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> > > > > >>>>
> > > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
> > > > > >>>> clock driver.
> > > > > >>>>
> > > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
> > > > > >>>> options to know which clock to enable, especially when clk_get should
> > > > > >>>> have the consumer device as an argument.
> > > > > >>>
> > > > > >>> Are you saying is that you want to solve a platform-specific problem by
> > > > > >>> pushing code into simple, generic drivers so that your platform code can
> > > > > >>> stay "clean"?
> > > > > >>
> > > > > >> Are you saying that this driver would become "dirty" with such a patch?
> > > > > > 
> > > > > > Yes. Others have said the same and even provided alternative solutions
> > > > > > on how to solve what's seemingly a platform-specific problem in a
> > > > > > platform-specific way.
> > > > > 
> > > > > This is not platform specific, any platform with a complete clock driver
> > > > > will suffer from the same problem (the clock driver disabling unclaimed
> > > > > ahb gates, and thus killing the video output) if it wants to use simplefb
> > > > > for early console support.
> > > > 
> > > > It is platform specific in that your platform may require certain clocks
> > > > to remain on.
> > > 
> > > The platform doesn't. simplefb does. simplefb is the obvious consumer
> > > for these clocks, and given the current API and abstraction we have,
> > > it should be the one claiming the clocks too.
> > 
> > No. simplefb just wants to write to some memory that hardware has been
> > set up to scan out. The platform requires that the clocks be on. Other
> > platforms may not even allow turning off the clocks.
> 
> Like what? the rpi? Come on. Just because the videocore is some black
> box we know nothing about doesn't mean we should use it as an example.

You make it sound like the Raspberry Pi is somehow less important than
sunxi.

> Any decent enough SoC, with a decent support in the kernel will have
> clocks for this, and I really wonder how simplefb will behave once its
> clocks will be turned off...

There are other devices besides ARM SoCs that may want to use this
driver and that don't have clock support.

But you're missing my point. What I'm saying is that the simplefb driver
is meant to serve as a way to take over whatever framebuffer a firmware
set up. Therefore I think it makes the most sense to assume that nothing
needs to be controlled in any way since already been set up by firmware.
Eventually there should be a driver that takes over from simplefb that
knows how to properly handle the device's specifics, but that's not
simplefb.

The goal of this patch series is to keep clocks from being turned off.
But that's not what it does. What it does is turn clocks on to prevent
them from being turned off. In my opinion that's a workaround for a
deficiency in the kernel (and the firmware/kernel interface) and I think
it should be fixed at the root. So a much better solution would be to
establish a way for firmware to communicate to the kernel that a given
resource has been enabled by firmware and shouldn't be disabled. Such a
solution can be implement for all types of resources and can be reused
by all drivers since they don't have to worry about these details.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/6aaaf58f/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 26 August 2014 10:04, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 05:22:32PM +0200, Maxime Ripard wrote:
>> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
>> > > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
>> > > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> > > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> > > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> > > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> > > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> > > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> > > > > >>> [...]
>> > > > > >>>>> If not, perhaps the clock driver should force the clock to be
>> > > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> > > > > >>>>
>> > > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
>> > > > > >>>> clock driver.
>> > > > > >>>>
>> > > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
>> > > > > >>>> options to know which clock to enable, especially when clk_get should
>> > > > > >>>> have the consumer device as an argument.
>> > > > > >>>
>> > > > > >>> Are you saying is that you want to solve a platform-specific problem by
>> > > > > >>> pushing code into simple, generic drivers so that your platform code can
>> > > > > >>> stay "clean"?
>> > > > > >>
>> > > > > >> Are you saying that this driver would become "dirty" with such a patch?
>> > > > > >
>> > > > > > Yes. Others have said the same and even provided alternative solutions
>> > > > > > on how to solve what's seemingly a platform-specific problem in a
>> > > > > > platform-specific way.
>> > > > >
>> > > > > This is not platform specific, any platform with a complete clock driver
>> > > > > will suffer from the same problem (the clock driver disabling unclaimed
>> > > > > ahb gates, and thus killing the video output) if it wants to use simplefb
>> > > > > for early console support.
>> > > >
>> > > > It is platform specific in that your platform may require certain clocks
>> > > > to remain on.
>> > >
>> > > The platform doesn't. simplefb does. simplefb is the obvious consumer
>> > > for these clocks, and given the current API and abstraction we have,
>> > > it should be the one claiming the clocks too.
>> >
>> > No. simplefb just wants to write to some memory that hardware has been
>> > set up to scan out. The platform requires that the clocks be on. Other
>> > platforms may not even allow turning off the clocks.
>>
>> Like what? the rpi? Come on. Just because the videocore is some black
>> box we know nothing about doesn't mean we should use it as an example.
>
> You make it sound like the Raspberry Pi is somehow less important than
> sunxi.

No. It's just bad example for driver development because on rpi you
are not in control of the hardware. Then the issue of enabling and
disabling clock becomes moot because you do not have access to clock
at all.

>
>> Any decent enough SoC, with a decent support in the kernel will have
>> clocks for this, and I really wonder how simplefb will behave once its
>> clocks will be turned off...
>
> There are other devices besides ARM SoCs that may want to use this
> driver and that don't have clock support.

Then the clock support part should be compiled out in that case. Just
like any other driver that has code that is disabled when some kernel
susbsystem is compiled out.

>
> But you're missing my point. What I'm saying is that the simplefb driver
> is meant to serve as a way to take over whatever framebuffer a firmware
> set up. Therefore I think it makes the most sense to assume that nothing
> needs to be controlled in any way since already been set up by firmware.
> Eventually there should be a driver that takes over from simplefb that
> knows how to properly handle the device's specifics, but that's not
> simplefb.

The simplefb driver is not controlling anything but is using resources
set up by firmware.

Currently DT has no way to express that state so the proposed solution
is to state in DT that simplefb controls the resources that are needed
for the framebuffer on the platform. Which resources are that is
platform specific and that platform specific is handled by the
bootloader that fills in what resources simplefb so 'controls' in its
DT node.

This way the resource is not disabled by the generic kernel framework
such as the clock framework.

>
> The goal of this patch series is to keep clocks from being turned off.
> But that's not what it does. What it does is turn clocks on to prevent
> them from being turned off. In my opinion that's a workaround for a
> deficiency in the kernel (and the firmware/kernel interface) and I think
> it should be fixed at the root. So a much better solution would be to
> establish a way for firmware to communicate to the kernel that a given
> resource has been enabled by firmware and shouldn't be disabled.

That's not the case here. If you later decide you do not want a
framebuffer you should be able to stop simplefb, disable the clock
that it claimed and reclaim the fb memory even if you do not replace
it with a full KMS driver. That way you would not need a special
'headless server bootloader' so long as you do not mind your server os
installation enables the display temporarily during boot.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 26 August 2014 10:04, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Aug 25, 2014 at 05:22:32PM +0200, Maxime Ripard wrote:
>> On Mon, Aug 25, 2014 at 05:05:04PM +0200, Thierry Reding wrote:
>> > On Mon, Aug 25, 2014 at 04:58:54PM +0200, Maxime Ripard wrote:
>> > > On Mon, Aug 25, 2014 at 04:16:29PM +0200, Thierry Reding wrote:
>> > > > On Mon, Aug 25, 2014 at 03:47:43PM +0200, Hans de Goede wrote:
>> > > > > On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> > > > > > On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>> > > > > >> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>> > > > > >>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>> > > > > >>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>> > > > > >>> [...]
>> > > > > >>>>> If not, perhaps the clock driver should force the clock to be
>> > > > > >>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
>> > > > > >>>>
>> > > > > >>>> I'm sorry, but I'm not going to take any code that will do that in our
>> > > > > >>>> clock driver.
>> > > > > >>>>
>> > > > > >>>> I'm not going to have a huge list of ifdef depending on configuration
>> > > > > >>>> options to know which clock to enable, especially when clk_get should
>> > > > > >>>> have the consumer device as an argument.
>> > > > > >>>
>> > > > > >>> Are you saying is that you want to solve a platform-specific problem by
>> > > > > >>> pushing code into simple, generic drivers so that your platform code can
>> > > > > >>> stay "clean"?
>> > > > > >>
>> > > > > >> Are you saying that this driver would become "dirty" with such a patch?
>> > > > > >
>> > > > > > Yes. Others have said the same and even provided alternative solutions
>> > > > > > on how to solve what's seemingly a platform-specific problem in a
>> > > > > > platform-specific way.
>> > > > >
>> > > > > This is not platform specific, any platform with a complete clock driver
>> > > > > will suffer from the same problem (the clock driver disabling unclaimed
>> > > > > ahb gates, and thus killing the video output) if it wants to use simplefb
>> > > > > for early console support.
>> > > >
>> > > > It is platform specific in that your platform may require certain clocks
>> > > > to remain on.
>> > >
>> > > The platform doesn't. simplefb does. simplefb is the obvious consumer
>> > > for these clocks, and given the current API and abstraction we have,
>> > > it should be the one claiming the clocks too.
>> >
>> > No. simplefb just wants to write to some memory that hardware has been
>> > set up to scan out. The platform requires that the clocks be on. Other
>> > platforms may not even allow turning off the clocks.
>>
>> Like what? the rpi? Come on. Just because the videocore is some black
>> box we know nothing about doesn't mean we should use it as an example.
>
> You make it sound like the Raspberry Pi is somehow less important than
> sunxi.

No. It's just bad example for driver development because on rpi you
are not in control of the hardware. Then the issue of enabling and
disabling clock becomes moot because you do not have access to clock
at all.

>
>> Any decent enough SoC, with a decent support in the kernel will have
>> clocks for this, and I really wonder how simplefb will behave once its
>> clocks will be turned off...
>
> There are other devices besides ARM SoCs that may want to use this
> driver and that don't have clock support.

Then the clock support part should be compiled out in that case. Just
like any other driver that has code that is disabled when some kernel
susbsystem is compiled out.

>
> But you're missing my point. What I'm saying is that the simplefb driver
> is meant to serve as a way to take over whatever framebuffer a firmware
> set up. Therefore I think it makes the most sense to assume that nothing
> needs to be controlled in any way since already been set up by firmware.
> Eventually there should be a driver that takes over from simplefb that
> knows how to properly handle the device's specifics, but that's not
> simplefb.

The simplefb driver is not controlling anything but is using resources
set up by firmware.

Currently DT has no way to express that state so the proposed solution
is to state in DT that simplefb controls the resources that are needed
for the framebuffer on the platform. Which resources are that is
platform specific and that platform specific is handled by the
bootloader that fills in what resources simplefb so 'controls' in its
DT node.

This way the resource is not disabled by the generic kernel framework
such as the clock framework.

>
> The goal of this patch series is to keep clocks from being turned off.
> But that's not what it does. What it does is turn clocks on to prevent
> them from being turned off. In my opinion that's a workaround for a
> deficiency in the kernel (and the firmware/kernel interface) and I think
> it should be fixed at the root. So a much better solution would be to
> establish a way for firmware to communicate to the kernel that a given
> resource has been enabled by firmware and shouldn't be disabled.

That's not the case here. If you later decide you do not want a
framebuffer you should be able to stop simplefb, disable the clock
that it claimed and reclaim the fb memory even if you do not replace
it with a full KMS driver. That way you would not need a special
'headless server bootloader' so long as you do not mind your server os
installation enables the display temporarily during boot.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> > > No. simplefb just wants to write to some memory that hardware has been
> > > set up to scan out. The platform requires that the clocks be on. Other
> > > platforms may not even allow turning off the clocks.
> > 
> > Like what? the rpi? Come on. Just because the videocore is some black
> > box we know nothing about doesn't mean we should use it as an example.
> 
> You make it sound like the Raspberry Pi is somehow less important than
> sunxi.

No. What I mean is that it seems like we are somehow punished, or at
least blamed, for having a better and more complete kernel support.

> > Any decent enough SoC, with a decent support in the kernel will have
> > clocks for this, and I really wonder how simplefb will behave once its
> > clocks will be turned off...
> 
> There are other devices besides ARM SoCs that may want to use this
> driver and that don't have clock support.

And in this case, with this patch, simplefb will not claim any clock,
nor will fail probing.

> But you're missing my point. What I'm saying is that the simplefb driver
> is meant to serve as a way to take over whatever framebuffer a firmware
> set up. Therefore I think it makes the most sense to assume that nothing
> needs to be controlled in any way since already been set up by firmware.
> Eventually there should be a driver that takes over from simplefb that
> knows how to properly handle the device's specifics, but that's not
> simplefb.

I guess such a hand over if it were to happen in the kernel would
involve the second driver claiming the resources before the first one
release them. How is that different in this case?

> The goal of this patch series is to keep clocks from being turned off.
> But that's not what it does. What it does is turn clocks on to prevent
> them from being turned off. In my opinion that's a workaround for a
> deficiency in the kernel (and the firmware/kernel interface) and I think
> it should be fixed at the root. So a much better solution would be to
> establish a way for firmware to communicate to the kernel that a given
> resource has been enabled by firmware and shouldn't be disabled. Such a
> solution can be implement for all types of resources and can be reused
> by all drivers since they don't have to worry about these details.

Mike Turquette repeatedly said that he was against such a DT property:
https://lkml.org/lkml/2014/5/12/693

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> > > No. simplefb just wants to write to some memory that hardware has been
> > > set up to scan out. The platform requires that the clocks be on. Other
> > > platforms may not even allow turning off the clocks.
> > 
> > Like what? the rpi? Come on. Just because the videocore is some black
> > box we know nothing about doesn't mean we should use it as an example.
> 
> You make it sound like the Raspberry Pi is somehow less important than
> sunxi.

No. What I mean is that it seems like we are somehow punished, or at
least blamed, for having a better and more complete kernel support.

> > Any decent enough SoC, with a decent support in the kernel will have
> > clocks for this, and I really wonder how simplefb will behave once its
> > clocks will be turned off...
> 
> There are other devices besides ARM SoCs that may want to use this
> driver and that don't have clock support.

And in this case, with this patch, simplefb will not claim any clock,
nor will fail probing.

> But you're missing my point. What I'm saying is that the simplefb driver
> is meant to serve as a way to take over whatever framebuffer a firmware
> set up. Therefore I think it makes the most sense to assume that nothing
> needs to be controlled in any way since already been set up by firmware.
> Eventually there should be a driver that takes over from simplefb that
> knows how to properly handle the device's specifics, but that's not
> simplefb.

I guess such a hand over if it were to happen in the kernel would
involve the second driver claiming the resources before the first one
release them. How is that different in this case?

> The goal of this patch series is to keep clocks from being turned off.
> But that's not what it does. What it does is turn clocks on to prevent
> them from being turned off. In my opinion that's a workaround for a
> deficiency in the kernel (and the firmware/kernel interface) and I think
> it should be fixed at the root. So a much better solution would be to
> establish a way for firmware to communicate to the kernel that a given
> resource has been enabled by firmware and shouldn't be disabled. Such a
> solution can be implement for all types of resources and can be reused
> by all drivers since they don't have to worry about these details.

Mike Turquette repeatedly said that he was against such a DT property:
https://lkml.org/lkml/2014/5/12/693

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/0a274db7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]

On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> > > > No. simplefb just wants to write to some memory that hardware has been
> > > > set up to scan out. The platform requires that the clocks be on. Other
> > > > platforms may not even allow turning off the clocks.
> > > 
> > > Like what? the rpi? Come on. Just because the videocore is some black
> > > box we know nothing about doesn't mean we should use it as an example.
> > 
> > You make it sound like the Raspberry Pi is somehow less important than
> > sunxi.
> 
> No. What I mean is that it seems like we are somehow punished, or at
> least blamed, for having a better and more complete kernel support.

This isn't a competition. Nobody's punishing or blaming anyone. This is
about finding the best solution for the problem at hand.

> > > Any decent enough SoC, with a decent support in the kernel will have
> > > clocks for this, and I really wonder how simplefb will behave once its
> > > clocks will be turned off...
> > 
> > There are other devices besides ARM SoCs that may want to use this
> > driver and that don't have clock support.
> 
> And in this case, with this patch, simplefb will not claim any clock,
> nor will fail probing.
> 
> > But you're missing my point. What I'm saying is that the simplefb driver
> > is meant to serve as a way to take over whatever framebuffer a firmware
> > set up. Therefore I think it makes the most sense to assume that nothing
> > needs to be controlled in any way since already been set up by firmware.
> > Eventually there should be a driver that takes over from simplefb that
> > knows how to properly handle the device's specifics, but that's not
> > simplefb.
> 
> I guess such a hand over if it were to happen in the kernel would
> involve the second driver claiming the resources before the first one
> release them. How is that different in this case?

It's different in that that driver will be hardware specific and know
exactly what clock and other resources are required. It will have a
device-specific binding.

> > The goal of this patch series is to keep clocks from being turned off.
> > But that's not what it does. What it does is turn clocks on to prevent
> > them from being turned off. In my opinion that's a workaround for a
> > deficiency in the kernel (and the firmware/kernel interface) and I think
> > it should be fixed at the root. So a much better solution would be to
> > establish a way for firmware to communicate to the kernel that a given
> > resource has been enabled by firmware and shouldn't be disabled. Such a
> > solution can be implement for all types of resources and can be reused
> > by all drivers since they don't have to worry about these details.
> 
> Mike Turquette repeatedly said that he was against such a DT property:
> https://lkml.org/lkml/2014/5/12/693

Mike says in that email that he's opposing the addition of a property
for clocks that is the equivalent of regulator-always-on. That's not
what this is about. If at all it'd be a property to mark a clock that
should not be disabled by default because it's essential.

Adding Mike on this subthread too.

Either way, Mark already suggested a different alternative in another
subthread, namely to add a new kind of checkpoint at which subsystems
can call a "disable unused" function that's called later than a late
initcall. This is not going to fix things for you immediately because
the clocks will still be switched off (only later) if you don't have
a real driver that's claiming the clocks. But you can work around that
for now by making the relevant clocks always on and remove that
workaround once a real driver is loaded that knows how to handle them
properly.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> > > > No. simplefb just wants to write to some memory that hardware has been
> > > > set up to scan out. The platform requires that the clocks be on. Other
> > > > platforms may not even allow turning off the clocks.
> > > 
> > > Like what? the rpi? Come on. Just because the videocore is some black
> > > box we know nothing about doesn't mean we should use it as an example.
> > 
> > You make it sound like the Raspberry Pi is somehow less important than
> > sunxi.
> 
> No. What I mean is that it seems like we are somehow punished, or at
> least blamed, for having a better and more complete kernel support.

This isn't a competition. Nobody's punishing or blaming anyone. This is
about finding the best solution for the problem at hand.

> > > Any decent enough SoC, with a decent support in the kernel will have
> > > clocks for this, and I really wonder how simplefb will behave once its
> > > clocks will be turned off...
> > 
> > There are other devices besides ARM SoCs that may want to use this
> > driver and that don't have clock support.
> 
> And in this case, with this patch, simplefb will not claim any clock,
> nor will fail probing.
> 
> > But you're missing my point. What I'm saying is that the simplefb driver
> > is meant to serve as a way to take over whatever framebuffer a firmware
> > set up. Therefore I think it makes the most sense to assume that nothing
> > needs to be controlled in any way since already been set up by firmware.
> > Eventually there should be a driver that takes over from simplefb that
> > knows how to properly handle the device's specifics, but that's not
> > simplefb.
> 
> I guess such a hand over if it were to happen in the kernel would
> involve the second driver claiming the resources before the first one
> release them. How is that different in this case?

It's different in that that driver will be hardware specific and know
exactly what clock and other resources are required. It will have a
device-specific binding.

> > The goal of this patch series is to keep clocks from being turned off.
> > But that's not what it does. What it does is turn clocks on to prevent
> > them from being turned off. In my opinion that's a workaround for a
> > deficiency in the kernel (and the firmware/kernel interface) and I think
> > it should be fixed at the root. So a much better solution would be to
> > establish a way for firmware to communicate to the kernel that a given
> > resource has been enabled by firmware and shouldn't be disabled. Such a
> > solution can be implement for all types of resources and can be reused
> > by all drivers since they don't have to worry about these details.
> 
> Mike Turquette repeatedly said that he was against such a DT property:
> https://lkml.org/lkml/2014/5/12/693

Mike says in that email that he's opposing the addition of a property
for clocks that is the equivalent of regulator-always-on. That's not
what this is about. If at all it'd be a property to mark a clock that
should not be disabled by default because it's essential.

Adding Mike on this subthread too.

Either way, Mark already suggested a different alternative in another
subthread, namely to add a new kind of checkpoint at which subsystems
can call a "disable unused" function that's called later than a late
initcall. This is not going to fix things for you immediately because
the clocks will still be switched off (only later) if you don't have
a real driver that's claiming the clocks. But you can work around that
for now by making the relevant clocks always on and remove that
workaround once a real driver is loaded that knows how to handle them
properly.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/587fca7a/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/26/2014 04:35 PM, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
>> On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
>>>>> No. simplefb just wants to write to some memory that hardware has been
>>>>> set up to scan out. The platform requires that the clocks be on. Other
>>>>> platforms may not even allow turning off the clocks.
>>>>
>>>> Like what? the rpi? Come on. Just because the videocore is some black
>>>> box we know nothing about doesn't mean we should use it as an example.
>>>
>>> You make it sound like the Raspberry Pi is somehow less important than
>>> sunxi.
>>
>> No. What I mean is that it seems like we are somehow punished, or at
>> least blamed, for having a better and more complete kernel support.
>
> This isn't a competition. Nobody's punishing or blaming anyone. This is
> about finding the best solution for the problem at hand.
>
>>>> Any decent enough SoC, with a decent support in the kernel will have
>>>> clocks for this, and I really wonder how simplefb will behave once its
>>>> clocks will be turned off...
>>>
>>> There are other devices besides ARM SoCs that may want to use this
>>> driver and that don't have clock support.
>>
>> And in this case, with this patch, simplefb will not claim any clock,
>> nor will fail probing.
>>
>>> But you're missing my point. What I'm saying is that the simplefb driver
>>> is meant to serve as a way to take over whatever framebuffer a firmware
>>> set up. Therefore I think it makes the most sense to assume that nothing
>>> needs to be controlled in any way since already been set up by firmware.
>>> Eventually there should be a driver that takes over from simplefb that
>>> knows how to properly handle the device's specifics, but that's not
>>> simplefb.
>>
>> I guess such a hand over if it were to happen in the kernel would
>> involve the second driver claiming the resources before the first one
>> release them. How is that different in this case?
>
> It's different in that that driver will be hardware specific and know
> exactly what clock and other resources are required. It will have a
> device-specific binding.
>
>>> The goal of this patch series is to keep clocks from being turned off.
>>> But that's not what it does. What it does is turn clocks on to prevent
>>> them from being turned off. In my opinion that's a workaround for a
>>> deficiency in the kernel (and the firmware/kernel interface) and I think
>>> it should be fixed at the root. So a much better solution would be to
>>> establish a way for firmware to communicate to the kernel that a given
>>> resource has been enabled by firmware and shouldn't be disabled. Such a
>>> solution can be implement for all types of resources and can be reused
>>> by all drivers since they don't have to worry about these details.
>>
>> Mike Turquette repeatedly said that he was against such a DT property:
>> https://lkml.org/lkml/2014/5/12/693
>
> Mike says in that email that he's opposing the addition of a property
> for clocks that is the equivalent of regulator-always-on. That's not
> what this is about. If at all it'd be a property to mark a clock that
> should not be disabled by default because it's essential.
>
> Adding Mike on this subthread too.
>
> Either way, Mark already suggested a different alternative in another
> subthread, namely to add a new kind of checkpoint at which subsystems
> can call a "disable unused" function that's called later than a late
> initcall. This is not going to fix things for you immediately because
> the clocks will still be switched off (only later) if you don't have
> a real driver that's claiming the clocks. But you can work around that
> for now by making the relevant clocks always on and remove that
> workaround once a real driver is loaded that knows how to handle them
> properly.

This will simply not work, and is a ton more complicated then
simply teaching simplefb about a clocks property, which is a really simple
and clean patch.

First of all let me explain why this won't work. When should those
subsystems call this "later then a late initcall" call ? the kms driver
may very well be a kernel module, which will be loaded by userspace,
so we would need this to be triggered by userspace, but when ?

When the initrd is done? What then if the kms driver is not in the initrd,
so maybe when udev is done enumerating devices, but what then if the kernel
is still enumerating hardware at this time? Will we just put a sleep 30
in our initscripts to make sure the kernel is done scanning all busses,
will that be long enough? Maybe we need to re-introduce the scsi_wait_done
kernel module which was added as an ugly hack to allow userspace to wait
for the kernel to have finished scanning scsi (and ata / sata) busses,
for controllers found at the time the module was load. Which never worked
reliable, because it would be possible that the controller itself still
needed to be discovered. We've spend years cleaning up userspace enough
to be able to kill scsi_wait_done. We've already been down this road of
waiting for hw enumeration to be done, and the problem is that on
modern systems *it is never done*.

So second of all, Thierry, what exactly is the technical argument against
adding support for dealing with clocks to simplefb ? I've heard a lot of
people in favor of it, and only pretty much you against it, and your
argument so far seems to boil down to "I don't like it", which is not
really a technical sound argument IMHO. Moreover all the alternatives
seem to be horribly complicated and most of them also seem to have
several issues which will make them simply not work reliable.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/26/2014 04:35 PM, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
>> On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
>>>>> No. simplefb just wants to write to some memory that hardware has been
>>>>> set up to scan out. The platform requires that the clocks be on. Other
>>>>> platforms may not even allow turning off the clocks.
>>>>
>>>> Like what? the rpi? Come on. Just because the videocore is some black
>>>> box we know nothing about doesn't mean we should use it as an example.
>>>
>>> You make it sound like the Raspberry Pi is somehow less important than
>>> sunxi.
>>
>> No. What I mean is that it seems like we are somehow punished, or at
>> least blamed, for having a better and more complete kernel support.
>
> This isn't a competition. Nobody's punishing or blaming anyone. This is
> about finding the best solution for the problem at hand.
>
>>>> Any decent enough SoC, with a decent support in the kernel will have
>>>> clocks for this, and I really wonder how simplefb will behave once its
>>>> clocks will be turned off...
>>>
>>> There are other devices besides ARM SoCs that may want to use this
>>> driver and that don't have clock support.
>>
>> And in this case, with this patch, simplefb will not claim any clock,
>> nor will fail probing.
>>
>>> But you're missing my point. What I'm saying is that the simplefb driver
>>> is meant to serve as a way to take over whatever framebuffer a firmware
>>> set up. Therefore I think it makes the most sense to assume that nothing
>>> needs to be controlled in any way since already been set up by firmware.
>>> Eventually there should be a driver that takes over from simplefb that
>>> knows how to properly handle the device's specifics, but that's not
>>> simplefb.
>>
>> I guess such a hand over if it were to happen in the kernel would
>> involve the second driver claiming the resources before the first one
>> release them. How is that different in this case?
>
> It's different in that that driver will be hardware specific and know
> exactly what clock and other resources are required. It will have a
> device-specific binding.
>
>>> The goal of this patch series is to keep clocks from being turned off.
>>> But that's not what it does. What it does is turn clocks on to prevent
>>> them from being turned off. In my opinion that's a workaround for a
>>> deficiency in the kernel (and the firmware/kernel interface) and I think
>>> it should be fixed at the root. So a much better solution would be to
>>> establish a way for firmware to communicate to the kernel that a given
>>> resource has been enabled by firmware and shouldn't be disabled. Such a
>>> solution can be implement for all types of resources and can be reused
>>> by all drivers since they don't have to worry about these details.
>>
>> Mike Turquette repeatedly said that he was against such a DT property:
>> https://lkml.org/lkml/2014/5/12/693
>
> Mike says in that email that he's opposing the addition of a property
> for clocks that is the equivalent of regulator-always-on. That's not
> what this is about. If at all it'd be a property to mark a clock that
> should not be disabled by default because it's essential.
>
> Adding Mike on this subthread too.
>
> Either way, Mark already suggested a different alternative in another
> subthread, namely to add a new kind of checkpoint at which subsystems
> can call a "disable unused" function that's called later than a late
> initcall. This is not going to fix things for you immediately because
> the clocks will still be switched off (only later) if you don't have
> a real driver that's claiming the clocks. But you can work around that
> for now by making the relevant clocks always on and remove that
> workaround once a real driver is loaded that knows how to handle them
> properly.

This will simply not work, and is a ton more complicated then
simply teaching simplefb about a clocks property, which is a really simple
and clean patch.

First of all let me explain why this won't work. When should those
subsystems call this "later then a late initcall" call ? the kms driver
may very well be a kernel module, which will be loaded by userspace,
so we would need this to be triggered by userspace, but when ?

When the initrd is done? What then if the kms driver is not in the initrd,
so maybe when udev is done enumerating devices, but what then if the kernel
is still enumerating hardware at this time? Will we just put a sleep 30
in our initscripts to make sure the kernel is done scanning all busses,
will that be long enough? Maybe we need to re-introduce the scsi_wait_done
kernel module which was added as an ugly hack to allow userspace to wait
for the kernel to have finished scanning scsi (and ata / sata) busses,
for controllers found at the time the module was load. Which never worked
reliable, because it would be possible that the controller itself still
needed to be discovered. We've spend years cleaning up userspace enough
to be able to kill scsi_wait_done. We've already been down this road of
waiting for hw enumeration to be done, and the problem is that on
modern systems *it is never done*.

So second of all, Thierry, what exactly is the technical argument against
adding support for dealing with clocks to simplefb ? I've heard a lot of
people in favor of it, and only pretty much you against it, and your
argument so far seems to boil down to "I don't like it", which is not
really a technical sound argument IMHO. Moreover all the alternatives
seem to be horribly complicated and most of them also seem to have
several issues which will make them simply not work reliable.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 8086 bytes --]

Can you please fix you mail setup. You're addressing me directly in this
email, yet I'm neither in To: nor Cc: headers. That's really annoying.

On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/26/2014 04:35 PM, Thierry Reding wrote:
> >On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
> >>On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> >>>>>No. simplefb just wants to write to some memory that hardware has been
> >>>>>set up to scan out. The platform requires that the clocks be on. Other
> >>>>>platforms may not even allow turning off the clocks.
> >>>>
> >>>>Like what? the rpi? Come on. Just because the videocore is some black
> >>>>box we know nothing about doesn't mean we should use it as an example.
> >>>
> >>>You make it sound like the Raspberry Pi is somehow less important than
> >>>sunxi.
> >>
> >>No. What I mean is that it seems like we are somehow punished, or at
> >>least blamed, for having a better and more complete kernel support.
> >
> >This isn't a competition. Nobody's punishing or blaming anyone. This is
> >about finding the best solution for the problem at hand.
> >
> >>>>Any decent enough SoC, with a decent support in the kernel will have
> >>>>clocks for this, and I really wonder how simplefb will behave once its
> >>>>clocks will be turned off...
> >>>
> >>>There are other devices besides ARM SoCs that may want to use this
> >>>driver and that don't have clock support.
> >>
> >>And in this case, with this patch, simplefb will not claim any clock,
> >>nor will fail probing.
> >>
> >>>But you're missing my point. What I'm saying is that the simplefb driver
> >>>is meant to serve as a way to take over whatever framebuffer a firmware
> >>>set up. Therefore I think it makes the most sense to assume that nothing
> >>>needs to be controlled in any way since already been set up by firmware.
> >>>Eventually there should be a driver that takes over from simplefb that
> >>>knows how to properly handle the device's specifics, but that's not
> >>>simplefb.
> >>
> >>I guess such a hand over if it were to happen in the kernel would
> >>involve the second driver claiming the resources before the first one
> >>release them. How is that different in this case?
> >
> >It's different in that that driver will be hardware specific and know
> >exactly what clock and other resources are required. It will have a
> >device-specific binding.
> >
> >>>The goal of this patch series is to keep clocks from being turned off.
> >>>But that's not what it does. What it does is turn clocks on to prevent
> >>>them from being turned off. In my opinion that's a workaround for a
> >>>deficiency in the kernel (and the firmware/kernel interface) and I think
> >>>it should be fixed at the root. So a much better solution would be to
> >>>establish a way for firmware to communicate to the kernel that a given
> >>>resource has been enabled by firmware and shouldn't be disabled. Such a
> >>>solution can be implement for all types of resources and can be reused
> >>>by all drivers since they don't have to worry about these details.
> >>
> >>Mike Turquette repeatedly said that he was against such a DT property:
> >>https://lkml.org/lkml/2014/5/12/693
> >
> >Mike says in that email that he's opposing the addition of a property
> >for clocks that is the equivalent of regulator-always-on. That's not
> >what this is about. If at all it'd be a property to mark a clock that
> >should not be disabled by default because it's essential.
> >
> >Adding Mike on this subthread too.
> >
> >Either way, Mark already suggested a different alternative in another
> >subthread, namely to add a new kind of checkpoint at which subsystems
> >can call a "disable unused" function that's called later than a late
> >initcall. This is not going to fix things for you immediately because
> >the clocks will still be switched off (only later) if you don't have
> >a real driver that's claiming the clocks. But you can work around that
> >for now by making the relevant clocks always on and remove that
> >workaround once a real driver is loaded that knows how to handle them
> >properly.
> 
> This will simply not work, and is a ton more complicated then
> simply teaching simplefb about a clocks property, which is a really simple
> and clean patch.
> 
> First of all let me explain why this won't work. When should those
> subsystems call this "later then a late initcall" call ? the kms driver
> may very well be a kernel module, which will be loaded by userspace,
> so we would need this to be triggered by userspace, but when ?
> 
> When the initrd is done? What then if the kms driver is not in the initrd,
> so maybe when udev is done enumerating devices, but what then if the kernel
> is still enumerating hardware at this time?

Usually an initrd knows how to wait for all or a given set of devices to
be probed. udev is pretty good for that.

> Will we just put a sleep 30
> in our initscripts to make sure the kernel is done scanning all busses,
> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
> kernel module which was added as an ugly hack to allow userspace to wait
> for the kernel to have finished scanning scsi (and ata / sata) busses,
> for controllers found at the time the module was load. Which never worked
> reliable, because it would be possible that the controller itself still
> needed to be discovered. We've spend years cleaning up userspace enough
> to be able to kill scsi_wait_done. We've already been down this road of
> waiting for hw enumeration to be done, and the problem is that on
> modern systems *it is never done*.

Those are mostly integration issues. If you don't load the driver from
initrd then I don't think anybody will complain when there's flicker
when it finally gets loaded. The whole point of this is to have early
access to the framebuffer and get display and graphics going as soon as
possible, so please don't pull in hypothetical scenarios where people
manually load drivers half an hour after the system has booted.

> So second of all, Thierry, what exactly is the technical argument against
> adding support for dealing with clocks to simplefb ?

I've already stated technical arguments against it. You could just go
back and read the thread again, or would you rather want me to repeat
them for your convenience?

> I've heard a lot of people in favor of it,

Of course you have, all the people in favour of it are sunxi people that
really want to see this merged because it gives them working display
after U-Boot.

> and only pretty much you against it,

At least Stephen also spoke out about it. But this quickly devolved into
the kind of thread you want to get out of as quickly as possible, so I
can't blame him for not continuing this discussion. In fact I'm very
much regretting getting into this in the first place. You clearly have
no intention to even consider any possible other solution that what was
posted, so it's pretty useless to try and convince you.

> and your argument so far seems to boil down to "I don't like it",

I'm not surprised that you think so since you seem to be very selective
in what you read (or register) and what you don't.

> is not really a technical sound argument IMHO. Moreover all the
> alternatives seem to be horribly complicated and most of them also
> seem to have several issues which will make them simply not work
> reliable.

I'm not an unreasonable person, or at least I like to think so, and if
there really isn't a better solution then I won't object to this patch
any longer. But as it stands I am not convinced that this is the best
solution, so I think we should keep the discussion going for a bit and
see if we really can't come up with something that will fix this for a
more general case rather than just your particular use-case. It's
evidently a recurring problem that others suffer from, too.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

Can you please fix you mail setup. You're addressing me directly in this
email, yet I'm neither in To: nor Cc: headers. That's really annoying.

On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/26/2014 04:35 PM, Thierry Reding wrote:
> >On Tue, Aug 26, 2014 at 03:53:41PM +0200, Maxime Ripard wrote:
> >>On Tue, Aug 26, 2014 at 10:04:33AM +0200, Thierry Reding wrote:
> >>>>>No. simplefb just wants to write to some memory that hardware has been
> >>>>>set up to scan out. The platform requires that the clocks be on. Other
> >>>>>platforms may not even allow turning off the clocks.
> >>>>
> >>>>Like what? the rpi? Come on. Just because the videocore is some black
> >>>>box we know nothing about doesn't mean we should use it as an example.
> >>>
> >>>You make it sound like the Raspberry Pi is somehow less important than
> >>>sunxi.
> >>
> >>No. What I mean is that it seems like we are somehow punished, or at
> >>least blamed, for having a better and more complete kernel support.
> >
> >This isn't a competition. Nobody's punishing or blaming anyone. This is
> >about finding the best solution for the problem at hand.
> >
> >>>>Any decent enough SoC, with a decent support in the kernel will have
> >>>>clocks for this, and I really wonder how simplefb will behave once its
> >>>>clocks will be turned off...
> >>>
> >>>There are other devices besides ARM SoCs that may want to use this
> >>>driver and that don't have clock support.
> >>
> >>And in this case, with this patch, simplefb will not claim any clock,
> >>nor will fail probing.
> >>
> >>>But you're missing my point. What I'm saying is that the simplefb driver
> >>>is meant to serve as a way to take over whatever framebuffer a firmware
> >>>set up. Therefore I think it makes the most sense to assume that nothing
> >>>needs to be controlled in any way since already been set up by firmware.
> >>>Eventually there should be a driver that takes over from simplefb that
> >>>knows how to properly handle the device's specifics, but that's not
> >>>simplefb.
> >>
> >>I guess such a hand over if it were to happen in the kernel would
> >>involve the second driver claiming the resources before the first one
> >>release them. How is that different in this case?
> >
> >It's different in that that driver will be hardware specific and know
> >exactly what clock and other resources are required. It will have a
> >device-specific binding.
> >
> >>>The goal of this patch series is to keep clocks from being turned off.
> >>>But that's not what it does. What it does is turn clocks on to prevent
> >>>them from being turned off. In my opinion that's a workaround for a
> >>>deficiency in the kernel (and the firmware/kernel interface) and I think
> >>>it should be fixed at the root. So a much better solution would be to
> >>>establish a way for firmware to communicate to the kernel that a given
> >>>resource has been enabled by firmware and shouldn't be disabled. Such a
> >>>solution can be implement for all types of resources and can be reused
> >>>by all drivers since they don't have to worry about these details.
> >>
> >>Mike Turquette repeatedly said that he was against such a DT property:
> >>https://lkml.org/lkml/2014/5/12/693
> >
> >Mike says in that email that he's opposing the addition of a property
> >for clocks that is the equivalent of regulator-always-on. That's not
> >what this is about. If at all it'd be a property to mark a clock that
> >should not be disabled by default because it's essential.
> >
> >Adding Mike on this subthread too.
> >
> >Either way, Mark already suggested a different alternative in another
> >subthread, namely to add a new kind of checkpoint at which subsystems
> >can call a "disable unused" function that's called later than a late
> >initcall. This is not going to fix things for you immediately because
> >the clocks will still be switched off (only later) if you don't have
> >a real driver that's claiming the clocks. But you can work around that
> >for now by making the relevant clocks always on and remove that
> >workaround once a real driver is loaded that knows how to handle them
> >properly.
> 
> This will simply not work, and is a ton more complicated then
> simply teaching simplefb about a clocks property, which is a really simple
> and clean patch.
> 
> First of all let me explain why this won't work. When should those
> subsystems call this "later then a late initcall" call ? the kms driver
> may very well be a kernel module, which will be loaded by userspace,
> so we would need this to be triggered by userspace, but when ?
> 
> When the initrd is done? What then if the kms driver is not in the initrd,
> so maybe when udev is done enumerating devices, but what then if the kernel
> is still enumerating hardware at this time?

Usually an initrd knows how to wait for all or a given set of devices to
be probed. udev is pretty good for that.

> Will we just put a sleep 30
> in our initscripts to make sure the kernel is done scanning all busses,
> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
> kernel module which was added as an ugly hack to allow userspace to wait
> for the kernel to have finished scanning scsi (and ata / sata) busses,
> for controllers found at the time the module was load. Which never worked
> reliable, because it would be possible that the controller itself still
> needed to be discovered. We've spend years cleaning up userspace enough
> to be able to kill scsi_wait_done. We've already been down this road of
> waiting for hw enumeration to be done, and the problem is that on
> modern systems *it is never done*.

Those are mostly integration issues. If you don't load the driver from
initrd then I don't think anybody will complain when there's flicker
when it finally gets loaded. The whole point of this is to have early
access to the framebuffer and get display and graphics going as soon as
possible, so please don't pull in hypothetical scenarios where people
manually load drivers half an hour after the system has booted.

> So second of all, Thierry, what exactly is the technical argument against
> adding support for dealing with clocks to simplefb ?

I've already stated technical arguments against it. You could just go
back and read the thread again, or would you rather want me to repeat
them for your convenience?

> I've heard a lot of people in favor of it,

Of course you have, all the people in favour of it are sunxi people that
really want to see this merged because it gives them working display
after U-Boot.

> and only pretty much you against it,

At least Stephen also spoke out about it. But this quickly devolved into
the kind of thread you want to get out of as quickly as possible, so I
can't blame him for not continuing this discussion. In fact I'm very
much regretting getting into this in the first place. You clearly have
no intention to even consider any possible other solution that what was
posted, so it's pretty useless to try and convince you.

> and your argument so far seems to boil down to "I don't like it",

I'm not surprised that you think so since you seem to be very selective
in what you read (or register) and what you don't.

> is not really a technical sound argument IMHO. Moreover all the
> alternatives seem to be horribly complicated and most of them also
> seem to have several issues which will make them simply not work
> reliable.

I'm not an unreasonable person, or at least I like to think so, and if
there really isn't a better solution then I won't object to this patch
any longer. But as it stands I am not convinced that this is the best
solution, so I think we should keep the discussion going for a bit and
see if we really can't come up with something that will fix this for a
more general case rather than just your particular use-case. It's
evidently a recurring problem that others suffer from, too.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/0eb53001/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 11:31 AM, Thierry Reding wrote:
> Can you please fix you mail setup. You're addressing me directly in this
> email, yet I'm neither in To: nor Cc: headers. That's really annoying.

Sorry, I'll pay closer attention that you're in the To when I'm directly
addressing you next time.

> On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:

<snip>

>>> Either way, Mark already suggested a different alternative in another
>>> subthread, namely to add a new kind of checkpoint at which subsystems
>>> can call a "disable unused" function that's called later than a late
>>> initcall. This is not going to fix things for you immediately because
>>> the clocks will still be switched off (only later) if you don't have
>>> a real driver that's claiming the clocks. But you can work around that
>>> for now by making the relevant clocks always on and remove that
>>> workaround once a real driver is loaded that knows how to handle them
>>> properly.
>>
>> This will simply not work, and is a ton more complicated then
>> simply teaching simplefb about a clocks property, which is a really simple
>> and clean patch.
>>
>> First of all let me explain why this won't work. When should those
>> subsystems call this "later then a late initcall" call ? the kms driver
>> may very well be a kernel module, which will be loaded by userspace,
>> so we would need this to be triggered by userspace, but when ?
>>
>> When the initrd is done? What then if the kms driver is not in the initrd,
>> so maybe when udev is done enumerating devices, but what then if the kernel
>> is still enumerating hardware at this time?
> 
> Usually an initrd knows how to wait for all or a given set of devices to
> be probed. udev is pretty good for that.

udev does not have a clue how to wait for all devices, it can be used to
wait for a specific device to show up, that is true, but this requires
adding specific logic for this (class of) device to the initrd init process,
which is really sub-optimal.

>> Will we just put a sleep 30
>> in our initscripts to make sure the kernel is done scanning all busses,
>> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
>> kernel module which was added as an ugly hack to allow userspace to wait
>> for the kernel to have finished scanning scsi (and ata / sata) busses,
>> for controllers found at the time the module was load. Which never worked
>> reliable, because it would be possible that the controller itself still
>> needed to be discovered. We've spend years cleaning up userspace enough
>> to be able to kill scsi_wait_done. We've already been down this road of
>> waiting for hw enumeration to be done, and the problem is that on
>> modern systems *it is never done*.
> 
> Those are mostly integration issues. If you don't load the driver from
> initrd then I don't think anybody will complain when there's flicker
> when it finally gets loaded. The whole point of this is to have early
> access to the framebuffer and get display and graphics going as soon as
> possible, so please don't pull in hypothetical scenarios where people
> manually load drivers half an hour after the system has booted.

In another mail in this thread you've mentioned 2 uses for simplefb:

1) Serving as *the* fb until a kms driver is present
2) Allowing for output of early kernel boot messages.

I agree that those are the 2 use-cases we're dealing with here.

Note that the whole discussion we're having hear about disabling the clocks
once hardware probing is "done", is moot for 1. One possible way mentioned
of dealing with 1. is to mark these clocks as always on for now, and then we
need to drop this hack (I cannot call this anything else then a hack), once
we get kms, meaning interdependencies between the dropping patch and the kms
adding patches, etc. All not very pretty.

For 2. We have what you call "mostly integration issues". Allow me to copy
and paste in another bit of this thread here:

>> I've been doing low level Linux development for 10 years now and I've
>> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.
>
> Ah, so this is now officially a pissing contest, is it?

No I'm merely trying to explain that I've a ton of experience with what
you seem to think of as merely integration issues, and they are a royal PITA,
and thus to be avoided at all costs. Really, please just trust me on this
one, doing the whole add some later then late init call type is a bad idea.

>> So second of all, Thierry, what exactly is the technical argument against
>> adding support for dealing with clocks to simplefb ?
> 
> I've already stated technical arguments against it. You could just go
> back and read the thread again, or would you rather want me to repeat
> them for your convenience?

It is a long thread, IIRC your main arguments against this are:

1) You don't want this kind of platform-specific knowledge in simplefb
2) That simplefb is supposed to be simple, and this is not simple

As for 1. several people have already argued that clocks as such are
an abstract concept, found one many platforms and as such are not
platform specific.

Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
ehci, etc. has ended up adding abstract support for things like clocks
(and other resources). I say abstract support here, since to all these
drivers the support was added in a way that no platform specific knowledge
is necessary, they just deal with clocks not caring about the specific
underlying clock implementation, clock names, etc.

This really is unavoidable. The framebuffer memory needed was mentioned
as another example of a resource in this thread. You suggested using the
new mem-reserve framework for this. I agree that that is the right thing
to do, but even then we still need a way to tie this reserved mem to
the simplefb, so that the kernel can know when it is no longer used
and can be added to the general memory pool.

If you look at how almost all dt bindings work, then the dt node for
a device specifies the resources needed, I don't see why simplefb would
be so special that it should be different here. I agree that it is
important to get the abstractions right here, but to me it seems that
the right abstraction is to be consistent with how all other devices
are abstracted and to add needed resources to the dt node for the
simplefb.

As for 2. Yes this will add some more code to simplefb, more code but
code which is not complicated in anyway, so the simplefb code would
become larger but still stay simple. Were as all the suggested
alternatives sofar are at least an order of magnitude more complicated,
crossing many subsystems, demanding coordination with userspace, etc.


>> I've heard a lot of people in favor of it,
> 
> Of course you have, all the people in favour of it are sunxi people that
> really want to see this merged because it gives them working display
> after U-Boot.

I don't think that that is entirely fair towards Maxime, yes Maxime is
a sunxi person, but he usually pushed back hard against anything he
considers not clean enough, even if it would enable highly desirable
functionality.

> 
>> and only pretty much you against it,
> 
> At least Stephen also spoke out about it. But this quickly devolved into
> the kind of thread you want to get out of as quickly as possible, so I
> can't blame him for not continuing this discussion. In fact I'm very
> much regretting getting into this in the first place. You clearly have
> no intention to even consider any possible other solution that what was
> posted, so it's pretty useless to try and convince you.
> 
>> and your argument so far seems to boil down to "I don't like it",
> 
> I'm not surprised that you think so since you seem to be very selective
> in what you read (or register) and what you don't.

See above, I've summarized the 2 arguments which you've made as
"I don't like it" before since to me they seem to be subjective arguments,
you say it is too platform specific, but where is the divide line for
something being _too_ platform specific ?  I realize in the end everything
is pretty much subjective. I apologize for the "I don't like it"
characterization that was not fair of me.

> 
>> is not really a technical sound argument IMHO. Moreover all the
>> alternatives seem to be horribly complicated and most of them also
>> seem to have several issues which will make them simply not work
>> reliable.
> 
> I'm not an unreasonable person, or at least I like to think so, and if
> there really isn't a better solution then I won't object to this patch
> any longer.

That is good to hear.

> But as it stands I am not convinced that this is the best solution

I'm very much open to a better solution, but so far everything suggested
is so much more complicated, that I don;t consider any of the suggestions
done so far better.

> so I think we should keep the discussion going for a bit and
> see if we really can't come up with something that will fix this for a
> more general case rather than just your particular use-case. It's
> evidently a recurring problem that others suffer from, too.

Yes needing resources despite the device being behind some generic
interface where the main driver code for that interface has no knowledge
about such resources sofar, because e.g. on PC-s this was not necessary
is a recurring problem, which has been solved already 3 times at least,
see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
was that the best solution was to simple add the resources to the dt-node,
and add code to claim and enable them.

Regards,

Hans



> 
> Thierry
> 

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 11:31 AM, Thierry Reding wrote:
> Can you please fix you mail setup. You're addressing me directly in this
> email, yet I'm neither in To: nor Cc: headers. That's really annoying.

Sorry, I'll pay closer attention that you're in the To when I'm directly
addressing you next time.

> On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:

<snip>

>>> Either way, Mark already suggested a different alternative in another
>>> subthread, namely to add a new kind of checkpoint at which subsystems
>>> can call a "disable unused" function that's called later than a late
>>> initcall. This is not going to fix things for you immediately because
>>> the clocks will still be switched off (only later) if you don't have
>>> a real driver that's claiming the clocks. But you can work around that
>>> for now by making the relevant clocks always on and remove that
>>> workaround once a real driver is loaded that knows how to handle them
>>> properly.
>>
>> This will simply not work, and is a ton more complicated then
>> simply teaching simplefb about a clocks property, which is a really simple
>> and clean patch.
>>
>> First of all let me explain why this won't work. When should those
>> subsystems call this "later then a late initcall" call ? the kms driver
>> may very well be a kernel module, which will be loaded by userspace,
>> so we would need this to be triggered by userspace, but when ?
>>
>> When the initrd is done? What then if the kms driver is not in the initrd,
>> so maybe when udev is done enumerating devices, but what then if the kernel
>> is still enumerating hardware at this time?
> 
> Usually an initrd knows how to wait for all or a given set of devices to
> be probed. udev is pretty good for that.

udev does not have a clue how to wait for all devices, it can be used to
wait for a specific device to show up, that is true, but this requires
adding specific logic for this (class of) device to the initrd init process,
which is really sub-optimal.

>> Will we just put a sleep 30
>> in our initscripts to make sure the kernel is done scanning all busses,
>> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
>> kernel module which was added as an ugly hack to allow userspace to wait
>> for the kernel to have finished scanning scsi (and ata / sata) busses,
>> for controllers found at the time the module was load. Which never worked
>> reliable, because it would be possible that the controller itself still
>> needed to be discovered. We've spend years cleaning up userspace enough
>> to be able to kill scsi_wait_done. We've already been down this road of
>> waiting for hw enumeration to be done, and the problem is that on
>> modern systems *it is never done*.
> 
> Those are mostly integration issues. If you don't load the driver from
> initrd then I don't think anybody will complain when there's flicker
> when it finally gets loaded. The whole point of this is to have early
> access to the framebuffer and get display and graphics going as soon as
> possible, so please don't pull in hypothetical scenarios where people
> manually load drivers half an hour after the system has booted.

In another mail in this thread you've mentioned 2 uses for simplefb:

1) Serving as *the* fb until a kms driver is present
2) Allowing for output of early kernel boot messages.

I agree that those are the 2 use-cases we're dealing with here.

Note that the whole discussion we're having hear about disabling the clocks
once hardware probing is "done", is moot for 1. One possible way mentioned
of dealing with 1. is to mark these clocks as always on for now, and then we
need to drop this hack (I cannot call this anything else then a hack), once
we get kms, meaning interdependencies between the dropping patch and the kms
adding patches, etc. All not very pretty.

For 2. We have what you call "mostly integration issues". Allow me to copy
and paste in another bit of this thread here:

>> I've been doing low level Linux development for 10 years now and I've
>> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.
>
> Ah, so this is now officially a pissing contest, is it?

No I'm merely trying to explain that I've a ton of experience with what
you seem to think of as merely integration issues, and they are a royal PITA,
and thus to be avoided at all costs. Really, please just trust me on this
one, doing the whole add some later then late init call type is a bad idea.

>> So second of all, Thierry, what exactly is the technical argument against
>> adding support for dealing with clocks to simplefb ?
> 
> I've already stated technical arguments against it. You could just go
> back and read the thread again, or would you rather want me to repeat
> them for your convenience?

It is a long thread, IIRC your main arguments against this are:

1) You don't want this kind of platform-specific knowledge in simplefb
2) That simplefb is supposed to be simple, and this is not simple

As for 1. several people have already argued that clocks as such are
an abstract concept, found one many platforms and as such are not
platform specific.

Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
ehci, etc. has ended up adding abstract support for things like clocks
(and other resources). I say abstract support here, since to all these
drivers the support was added in a way that no platform specific knowledge
is necessary, they just deal with clocks not caring about the specific
underlying clock implementation, clock names, etc.

This really is unavoidable. The framebuffer memory needed was mentioned
as another example of a resource in this thread. You suggested using the
new mem-reserve framework for this. I agree that that is the right thing
to do, but even then we still need a way to tie this reserved mem to
the simplefb, so that the kernel can know when it is no longer used
and can be added to the general memory pool.

If you look at how almost all dt bindings work, then the dt node for
a device specifies the resources needed, I don't see why simplefb would
be so special that it should be different here. I agree that it is
important to get the abstractions right here, but to me it seems that
the right abstraction is to be consistent with how all other devices
are abstracted and to add needed resources to the dt node for the
simplefb.

As for 2. Yes this will add some more code to simplefb, more code but
code which is not complicated in anyway, so the simplefb code would
become larger but still stay simple. Were as all the suggested
alternatives sofar are at least an order of magnitude more complicated,
crossing many subsystems, demanding coordination with userspace, etc.


>> I've heard a lot of people in favor of it,
> 
> Of course you have, all the people in favour of it are sunxi people that
> really want to see this merged because it gives them working display
> after U-Boot.

I don't think that that is entirely fair towards Maxime, yes Maxime is
a sunxi person, but he usually pushed back hard against anything he
considers not clean enough, even if it would enable highly desirable
functionality.

> 
>> and only pretty much you against it,
> 
> At least Stephen also spoke out about it. But this quickly devolved into
> the kind of thread you want to get out of as quickly as possible, so I
> can't blame him for not continuing this discussion. In fact I'm very
> much regretting getting into this in the first place. You clearly have
> no intention to even consider any possible other solution that what was
> posted, so it's pretty useless to try and convince you.
> 
>> and your argument so far seems to boil down to "I don't like it",
> 
> I'm not surprised that you think so since you seem to be very selective
> in what you read (or register) and what you don't.

See above, I've summarized the 2 arguments which you've made as
"I don't like it" before since to me they seem to be subjective arguments,
you say it is too platform specific, but where is the divide line for
something being _too_ platform specific ?  I realize in the end everything
is pretty much subjective. I apologize for the "I don't like it"
characterization that was not fair of me.

> 
>> is not really a technical sound argument IMHO. Moreover all the
>> alternatives seem to be horribly complicated and most of them also
>> seem to have several issues which will make them simply not work
>> reliable.
> 
> I'm not an unreasonable person, or at least I like to think so, and if
> there really isn't a better solution then I won't object to this patch
> any longer.

That is good to hear.

> But as it stands I am not convinced that this is the best solution

I'm very much open to a better solution, but so far everything suggested
is so much more complicated, that I don;t consider any of the suggestions
done so far better.

> so I think we should keep the discussion going for a bit and
> see if we really can't come up with something that will fix this for a
> more general case rather than just your particular use-case. It's
> evidently a recurring problem that others suffer from, too.

Yes needing resources despite the device being behind some generic
interface where the main driver code for that interface has no knowledge
about such resources sofar, because e.g. on PC-s this was not necessary
is a recurring problem, which has been solved already 3 times at least,
see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
was that the best solution was to simple add the resources to the dt-node,
and add code to claim and enable them.

Regards,

Hans



> 
> Thierry
> 

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Wed, Aug 27, 2014 at 6:35 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> On 08/27/2014 11:31 AM, Thierry Reding wrote:

snip

> In another mail in this thread you've mentioned 2 uses for simplefb:
>
> 1) Serving as *the* fb until a kms driver is present
> 2) Allowing for output of early kernel boot messages.
>
> I agree that those are the 2 use-cases we're dealing with here.
>
> Note that the whole discussion we're having hear about disabling the clocks
> once hardware probing is "done", is moot for 1. One possible way mentioned
> of dealing with 1. is to mark these clocks as always on for now, and then we
> need to drop this hack (I cannot call this anything else then a hack), once
> we get kms, meaning interdependencies between the dropping patch and the kms
> adding patches, etc. All not very pretty.
>
> For 2. We have what you call "mostly integration issues". Allow me to copy
> and paste in another bit of this thread here:

These are two independent problems.

> 1) Serving as *the* fb until a kms driver is present

Why can't we whip together a real device specific fbdev driver and
quit trying to run without a device specific driver in place? History
has shown that to be bad idea except during early boot when there
isn't a choice.

fbdev drivers are pretty simple things and you don't have to make one
that implements every feature. fbdev driver don't even have to
implement mode setting. They can just live with the mode initially
provided and refuse to change it. Communicating this initial mode info
on the kernel command line is already supported so we don't even need
a device tree change. This is the transition tool until KMS gets
written.

But it needs to be a device specific fbdev implementation, not
simplefb. That's because the device specific driver is going to claim
those clocks and regulators.

> 2) Allowing for output of early kernel boot messages.

For this to work the kernel needs to know two things - address of the
framebuffer and the x/y layout. Then just nuke this display when the
kernel finishes the boot process.

One of two things will happen.
1) the fbdev driver has been loaded. It has claimed the clocks, taken
care of memory, etc. If KMS is around, load it instead. When kernel
tries to nuke the display nothing will happen.
2) Your display goes blank because the kernel has disabled clocks and
reclaimed the memory. Take that as a hint to write a fbdev driver.

pages more snipped....

-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Aug 27, 2014 at 6:35 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> On 08/27/2014 11:31 AM, Thierry Reding wrote:

snip

> In another mail in this thread you've mentioned 2 uses for simplefb:
>
> 1) Serving as *the* fb until a kms driver is present
> 2) Allowing for output of early kernel boot messages.
>
> I agree that those are the 2 use-cases we're dealing with here.
>
> Note that the whole discussion we're having hear about disabling the clocks
> once hardware probing is "done", is moot for 1. One possible way mentioned
> of dealing with 1. is to mark these clocks as always on for now, and then we
> need to drop this hack (I cannot call this anything else then a hack), once
> we get kms, meaning interdependencies between the dropping patch and the kms
> adding patches, etc. All not very pretty.
>
> For 2. We have what you call "mostly integration issues". Allow me to copy
> and paste in another bit of this thread here:

These are two independent problems.

> 1) Serving as *the* fb until a kms driver is present

Why can't we whip together a real device specific fbdev driver and
quit trying to run without a device specific driver in place? History
has shown that to be bad idea except during early boot when there
isn't a choice.

fbdev drivers are pretty simple things and you don't have to make one
that implements every feature. fbdev driver don't even have to
implement mode setting. They can just live with the mode initially
provided and refuse to change it. Communicating this initial mode info
on the kernel command line is already supported so we don't even need
a device tree change. This is the transition tool until KMS gets
written.

But it needs to be a device specific fbdev implementation, not
simplefb. That's because the device specific driver is going to claim
those clocks and regulators.

> 2) Allowing for output of early kernel boot messages.

For this to work the kernel needs to know two things - address of the
framebuffer and the x/y layout. Then just nuke this display when the
kernel finishes the boot process.

One of two things will happen.
1) the fbdev driver has been loaded. It has claimed the clocks, taken
care of memory, etc. If KMS is around, load it instead. When kernel
tries to nuke the display nothing will happen.
2) Your display goes blank because the kernel has disabled clocks and
reclaimed the memory. Take that as a hint to write a fbdev driver.

pages more snipped....

-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 02:44 PM, jonsmirl@gmail.com wrote:

<snip>

>> 1) Serving as *the* fb until a kms driver is present
> 
> Why can't we whip together a real device specific fbdev driver and
> quit trying to run without a device specific driver in place? History
> has shown that to be bad idea except during early boot when there
> isn't a choice.

Writing a kms driver and getting it upstream is not a simple task, and
starting with a too limited implementation is dangerous as we need to get
the devicetree binding first from the get go.

IOW this is not really a realistic answer to problem 1.

<snip>

>> 2) Allowing for output of early kernel boot messages.
> 
> For this to work the kernel needs to know two things - address of the
> framebuffer and the x/y layout. Then just nuke this display when the
> kernel finishes the boot process.

Please read my earlier mails on how completely flawed it is to write
"when the kernel finishes the boot process". The problem is that there
is no way to really determine when this happens.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 02:44 PM, jonsmirl at gmail.com wrote:

<snip>

>> 1) Serving as *the* fb until a kms driver is present
> 
> Why can't we whip together a real device specific fbdev driver and
> quit trying to run without a device specific driver in place? History
> has shown that to be bad idea except during early boot when there
> isn't a choice.

Writing a kms driver and getting it upstream is not a simple task, and
starting with a too limited implementation is dangerous as we need to get
the devicetree binding first from the get go.

IOW this is not really a realistic answer to problem 1.

<snip>

>> 2) Allowing for output of early kernel boot messages.
> 
> For this to work the kernel needs to know two things - address of the
> framebuffer and the x/y layout. Then just nuke this display when the
> kernel finishes the boot process.

Please read my earlier mails on how completely flawed it is to write
"when the kernel finishes the boot process". The problem is that there
is no way to really determine when this happens.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Wed, Aug 27, 2014 at 8:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 08/27/2014 02:44 PM, jonsmirl@gmail.com wrote:
>
> <snip>
>
>>> 1) Serving as *the* fb until a kms driver is present
>>
>> Why can't we whip together a real device specific fbdev driver and
>> quit trying to run without a device specific driver in place? History
>> has shown that to be bad idea except during early boot when there
>> isn't a choice.
>
> Writing a kms driver and getting it upstream is not a simple task, and
> starting with a too limited implementation is dangerous as we need to get
> the devicetree binding first from the get go.

I didn't say write a kms driver, I said write a fbdev driver.  Look in
drivers/video/fbdev. fbdev drivers are used on many embedded systems.
Its what we used for years before kms came along.

>
> IOW this is not really a realistic answer to problem 1.
>
> <snip>
>
>>> 2) Allowing for output of early kernel boot messages.
>>
>> For this to work the kernel needs to know two things - address of the
>> framebuffer and the x/y layout. Then just nuke this display when the
>> kernel finishes the boot process.
>
> Please read my earlier mails on how completely flawed it is to write
> "when the kernel finishes the boot process". The problem is that there
> is no way to really determine when this happens.

Let me rephrase that, when the existing code in the clk system and
regulator systems decide to do their clean up the display will get
nuked.


>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Aug 27, 2014 at 8:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 08/27/2014 02:44 PM, jonsmirl at gmail.com wrote:
>
> <snip>
>
>>> 1) Serving as *the* fb until a kms driver is present
>>
>> Why can't we whip together a real device specific fbdev driver and
>> quit trying to run without a device specific driver in place? History
>> has shown that to be bad idea except during early boot when there
>> isn't a choice.
>
> Writing a kms driver and getting it upstream is not a simple task, and
> starting with a too limited implementation is dangerous as we need to get
> the devicetree binding first from the get go.

I didn't say write a kms driver, I said write a fbdev driver.  Look in
drivers/video/fbdev. fbdev drivers are used on many embedded systems.
Its what we used for years before kms came along.

>
> IOW this is not really a realistic answer to problem 1.
>
> <snip>
>
>>> 2) Allowing for output of early kernel boot messages.
>>
>> For this to work the kernel needs to know two things - address of the
>> framebuffer and the x/y layout. Then just nuke this display when the
>> kernel finishes the boot process.
>
> Please read my earlier mails on how completely flawed it is to write
> "when the kernel finishes the boot process". The problem is that there
> is no way to really determine when this happens.

Let me rephrase that, when the existing code in the clk system and
regulator systems decide to do their clean up the display will get
nuked.


>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

On Wed, Aug 27, 2014 at 02:50:18PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 02:44 PM, jonsmirl@gmail.com wrote:
> 
> <snip>
> 
> >> 1) Serving as *the* fb until a kms driver is present
> > 
> > Why can't we whip together a real device specific fbdev driver and
> > quit trying to run without a device specific driver in place? History
> > has shown that to be bad idea except during early boot when there
> > isn't a choice.
> 
> Writing a kms driver and getting it upstream is not a simple task, and
> starting with a too limited implementation is dangerous as we need to get
> the devicetree binding first from the get go.
> 
> IOW this is not really a realistic answer to problem 1.
> 
> <snip>
> 
> >> 2) Allowing for output of early kernel boot messages.
> > 
> > For this to work the kernel needs to know two things - address of the
> > framebuffer and the x/y layout. Then just nuke this display when the
> > kernel finishes the boot process.
> 
> Please read my earlier mails on how completely flawed it is to write
> "when the kernel finishes the boot process". The problem is that there
> is no way to really determine when this happens.

That doesn't mean we can't create new ways to signal this. One option
would be for userspace to signal this, another would be to have critical
subsystems broadcast such events so that things like the clock framework
can listen for those and react accordingly. The fact remains that
disabling all unused clocks unconditinally at late_initcall time is not
(always) the right thing to do.

What this really is is a policy decision and traditionally we don't like
to dictate policy in the kernel, so having something like an optional
feature that would allow userspace to notify the kernel that it's
initialized doesn't sound like a bad idea. This doesn't necessarily have
to mean that all possible devices have been probed (users could choose
to blacklist modules, etc.) but just an indication that the system is
done with essential tasks (for desktop distributions I would assume that
means the graphical login manager has started).

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 02:50:18PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 02:44 PM, jonsmirl at gmail.com wrote:
> 
> <snip>
> 
> >> 1) Serving as *the* fb until a kms driver is present
> > 
> > Why can't we whip together a real device specific fbdev driver and
> > quit trying to run without a device specific driver in place? History
> > has shown that to be bad idea except during early boot when there
> > isn't a choice.
> 
> Writing a kms driver and getting it upstream is not a simple task, and
> starting with a too limited implementation is dangerous as we need to get
> the devicetree binding first from the get go.
> 
> IOW this is not really a realistic answer to problem 1.
> 
> <snip>
> 
> >> 2) Allowing for output of early kernel boot messages.
> > 
> > For this to work the kernel needs to know two things - address of the
> > framebuffer and the x/y layout. Then just nuke this display when the
> > kernel finishes the boot process.
> 
> Please read my earlier mails on how completely flawed it is to write
> "when the kernel finishes the boot process". The problem is that there
> is no way to really determine when this happens.

That doesn't mean we can't create new ways to signal this. One option
would be for userspace to signal this, another would be to have critical
subsystems broadcast such events so that things like the clock framework
can listen for those and react accordingly. The fact remains that
disabling all unused clocks unconditinally at late_initcall time is not
(always) the right thing to do.

What this really is is a policy decision and traditionally we don't like
to dictate policy in the kernel, so having something like an optional
feature that would allow userspace to notify the kernel that it's
initialized doesn't sound like a bad idea. This doesn't necessarily have
to mean that all possible devices have been probed (users could choose
to blacklist modules, etc.) but just an indication that the system is
done with essential tasks (for desktop distributions I would assume that
means the graphical login manager has started).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/fd1a80e0/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 17631 bytes --]

On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 11:31 AM, Thierry Reding wrote:
> > Can you please fix you mail setup. You're addressing me directly in this
> > email, yet I'm neither in To: nor Cc: headers. That's really annoying.
> 
> Sorry, I'll pay closer attention that you're in the To when I'm directly
> addressing you next time.
> 
> > On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:
> 
> <snip>
> 
> >>> Either way, Mark already suggested a different alternative in another
> >>> subthread, namely to add a new kind of checkpoint at which subsystems
> >>> can call a "disable unused" function that's called later than a late
> >>> initcall. This is not going to fix things for you immediately because
> >>> the clocks will still be switched off (only later) if you don't have
> >>> a real driver that's claiming the clocks. But you can work around that
> >>> for now by making the relevant clocks always on and remove that
> >>> workaround once a real driver is loaded that knows how to handle them
> >>> properly.
> >>
> >> This will simply not work, and is a ton more complicated then
> >> simply teaching simplefb about a clocks property, which is a really simple
> >> and clean patch.
> >>
> >> First of all let me explain why this won't work. When should those
> >> subsystems call this "later then a late initcall" call ? the kms driver
> >> may very well be a kernel module, which will be loaded by userspace,
> >> so we would need this to be triggered by userspace, but when ?
> >>
> >> When the initrd is done? What then if the kms driver is not in the initrd,
> >> so maybe when udev is done enumerating devices, but what then if the kernel
> >> is still enumerating hardware at this time?
> > 
> > Usually an initrd knows how to wait for all or a given set of devices to
> > be probed. udev is pretty good for that.
> 
> udev does not have a clue how to wait for all devices, it can be used to
> wait for a specific device to show up, that is true, but this requires
> adding specific logic for this (class of) device to the initrd init process,
> which is really sub-optimal.

I thought pretty much every distribution that did anything remotely
related to early DRM/KMS like plymouth and whatnot already had this
specific logic. It's been a while since I dealt with all that, but
something roughly like this used to be present in pretty much all
distributions:

	udevadm trigger --subsystem-match=graphics \
		--subsystem-match=drm \
		--subsystem-match=tty
	udevadm settle

The effect of that being that udevadm settle would block as long as
devices were still being probed. Admittedly this was all long before
deferred probing was introduced, so I have no idea how well it plays
with it. But optimizing deferred probing is an entirely different topic
currently under discussion that should help sorting this out, too.

> >> Will we just put a sleep 30
> >> in our initscripts to make sure the kernel is done scanning all busses,
> >> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
> >> kernel module which was added as an ugly hack to allow userspace to wait
> >> for the kernel to have finished scanning scsi (and ata / sata) busses,
> >> for controllers found at the time the module was load. Which never worked
> >> reliable, because it would be possible that the controller itself still
> >> needed to be discovered. We've spend years cleaning up userspace enough
> >> to be able to kill scsi_wait_done. We've already been down this road of
> >> waiting for hw enumeration to be done, and the problem is that on
> >> modern systems *it is never done*.
> > 
> > Those are mostly integration issues. If you don't load the driver from
> > initrd then I don't think anybody will complain when there's flicker
> > when it finally gets loaded. The whole point of this is to have early
> > access to the framebuffer and get display and graphics going as soon as
> > possible, so please don't pull in hypothetical scenarios where people
> > manually load drivers half an hour after the system has booted.
> 
> In another mail in this thread you've mentioned 2 uses for simplefb:
> 
> 1) Serving as *the* fb until a kms driver is present
> 2) Allowing for output of early kernel boot messages.
> 
> I agree that those are the 2 use-cases we're dealing with here.
> 
> Note that the whole discussion we're having hear about disabling the clocks
> once hardware probing is "done", is moot for 1. One possible way mentioned
> of dealing with 1. is to mark these clocks as always on for now, and then we
> need to drop this hack (I cannot call this anything else then a hack), once
> we get kms, meaning interdependencies between the dropping patch and the kms
> adding patches, etc. All not very pretty.

I don't think it's that bad. When your real driver is merged you can
still keep the clocks always on for a release cycle if you worry about
any fallout. It's unlikely to going to be your last driver that you
merge and people aren't immediately going to build products based on it,
so it's unlikely that anyone will notice the wasted power.

> For 2. We have what you call "mostly integration issues". Allow me to copy
> and paste in another bit of this thread here:
> 
> >> I've been doing low level Linux development for 10 years now and I've
> >> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.
> >
> > Ah, so this is now officially a pissing contest, is it?
> 
> No I'm merely trying to explain that I've a ton of experience with what
> you seem to think of as merely integration issues, and they are a royal PITA,
> and thus to be avoided at all costs. Really, please just trust me on this
> one, doing the whole add some later then late init call type is a bad idea.

Well, you could equally just trust me on this one when I say adding
clock support for this driver is bad. Stalemate.

> >> So second of all, Thierry, what exactly is the technical argument against
> >> adding support for dealing with clocks to simplefb ?
> > 
> > I've already stated technical arguments against it. You could just go
> > back and read the thread again, or would you rather want me to repeat
> > them for your convenience?
> 
> It is a long thread, IIRC your main arguments against this are:
> 
> 1) You don't want this kind of platform-specific knowledge in simplefb
> 2) That simplefb is supposed to be simple, and this is not simple
> 
> As for 1. several people have already argued that clocks as such are
> an abstract concept, found one many platforms and as such are not
> platform specific.

That alone doesn't justify this patch. SoCs often have a requirement to
enable clocks in a specific order, for example. Other systems may need
to coordinate clocks with resets in a specific order or enable power
domains and such. All that is very SoC specific and if we don't make it
very clear what this driver assumes about the state of the system, then
we can't object to anybody adding support for those later on either. The
result of that is going to be a driver that needs to handle all kinds of
combinations of resources.

So while clocks themselves are fairly generic the way in which they need
to be used is highly platform-specific.

Let me also reiterate what I've said a couple of times already. The
issue here isn't that simplefb needs to manage these clocks in any way.
Firmware has already set them up so that display works. The reason why
you need this patch is so that the clock framework doesn't automatically
turn them off. With the proposed patch the driver enables these clocks,
but that's not what it needs to do, they are already on. It's a work
around to prevent the clock framework into not disabling them.

So as far as I'm concerned this points to a fundamental issue with how
the clock framework handles unused clocks. Therefore that is the problem
that should be solved, not worked around.

> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> ehci, etc. has ended up adding abstract support for things like clocks
> (and other resources). I say abstract support here, since to all these
> drivers the support was added in a way that no platform specific knowledge
> is necessary, they just deal with clocks not caring about the specific
> underlying clock implementation, clock names, etc.

Yes, I know that. You and I both had a very similar discussion not so
long ago. But the above aren't quite the same as simplefb. The devices
follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
bound to be more commonalities between them than between the various
display devices that simplefb potentially can support.

Interestingly though, if you look at what hardware really is supported
by the generic drivers that deal with embedded platforms, there isn't
all that much diversity (I've manually stripped out non-DTS occurrences
since they aren't relevant for this discussion):

	$ git grep -n generic-ohci
	arch/arm/boot/dts/sun4i-a10.dtsi:451:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
	arch/arm/boot/dts/sun4i-a10.dtsi:492:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
	arch/arm/boot/dts/sun5i-a10s.dtsi:403:          compatible = "allwinner,sun5i-a10s-ohci", "generic-ohci";
	arch/arm/boot/dts/sun5i-a13.dtsi:376:           compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:410:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:432:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:443:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun7i-a20.dtsi:535:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
	arch/arm/boot/dts/sun7i-a20.dtsi:576:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
	arch/powerpc/boot/dts/akebono.dts:144:          compatible = "ibm,476gtr-ohci", "generic-ohci";
	arch/powerpc/boot/dts/akebono.dts:151:          compatible = "ibm,476gtr-ohci", "generic-ohci";

	$ git grep -n generic-ehci
	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
	arch/arm/boot/dts/sun4i-a10.dtsi:441:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
	arch/arm/boot/dts/sun4i-a10.dtsi:482:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
	arch/arm/boot/dts/sun5i-a10s.dtsi:393:          compatible = "allwinner,sun5i-a10s-ehci", "generic-ehci";
	arch/arm/boot/dts/sun5i-a13.dtsi:366:           compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
	arch/arm/boot/dts/sun6i-a31.dtsi:399:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
	arch/arm/boot/dts/sun6i-a31.dtsi:421:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
	arch/arm/boot/dts/sun7i-a20.dtsi:525:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
	arch/arm/boot/dts/sun7i-a20.dtsi:566:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
	arch/powerpc/boot/dts/akebono.dts:130:          compatible = "ibm,476gtr-ehci", "generic-ehci";

For generic-ahci there aren't any matches, but here are a few that are
marked compatible with it using different compatible strings:

	$ git grep -n snps,spear-ahci
	arch/arm/boot/dts/spear1310.dtsi:60:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1310.dtsi:69:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1310.dtsi:78:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1340.dtsi:43:            compatible = "snps,spear-ahci";

	$ git grep -n snps,exynos5440-ahci
	arch/arm/boot/dts/exynos5440.dtsi:241:          compatible = "snps,exynos5440-ahci";

	$ git grep -n 'ibm,476gtr-ahci'
	arch/powerpc/boot/dts/akebono.dts:123:          compatible = "ibm,476gtr-ahci";

	$ git grep -n 'snps,dwc-ahci'
	arch/arm/boot/dts/dra7.dtsi:1049:               compatible = "snps,dwc-ahci";
	arch/arm/boot/dts/exynos5250.dtsi:265:          compatible = "snps,dwc-ahci";
	arch/arm/boot/dts/omap5.dtsi:919:               compatible = "snps,dwc-ahci";

That looks fairly homogenous to me. There are also things like this
(from the ahci_platform.c driver):

	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;

With more supported hardware there's bound to be more quirks like that.

So there's a couple of SoCs and boards that actually are generic enough
to work with a generic driver. And then there's a whole bunch of other
drivers for hardware that's compliant with the same standard yet needs
different drivers. To me that's a clear indication that there isn't
enough genericity to warrant a generic driver in the first place.

The commonality is in the functionality and defined by the standard
registers. But there's little to no commonality in how that interface is
glued into the SoC. Luckily the above subsystems implement the standard
hardware programming in a library, so that non-generic drivers can still
make use of most of the generic code.

> This really is unavoidable. The framebuffer memory needed was mentioned
> as another example of a resource in this thread. You suggested using the
> new mem-reserve framework for this. I agree that that is the right thing
> to do, but even then we still need a way to tie this reserved mem to
> the simplefb, so that the kernel can know when it is no longer used
> and can be added to the general memory pool.

Yes, memory handling seems like it isn't handled optimally by simplefb.
To be fair the simplefb driver predates the reserved-memory bindings. I
think it might be worthwhile to investigate on how to extend the binding
to make use of that, though. I think the assumption currently is that
the framebuffer memory will be lost forever (it needs to be carved out
of the physical memory that the kernel gets to see). I couldn't find any
code that returned reserved-memory to the kernel, but it's certainly a
feature that I think we want. Especially if the firmware framebuffer is
large (as in 1080p).

> If you look at how almost all dt bindings work, then the dt node for
> a device specifies the resources needed, I don't see why simplefb would
> be so special that it should be different here. I agree that it is
> important to get the abstractions right here, but to me it seems that
> the right abstraction is to be consistent with how all other devices
> are abstracted and to add needed resources to the dt node for the
> simplefb.

But simplefb is fundamentally different from other devices. It isn't a
physical device at all. It's a virtual device that reuses resources as
set up by some other piece of code (firmware). It implies that there's
nothing that needs to be managed. It should only create a framebuffer
with the given parameters and allow the kernel (and userspace) to render
into it.

The only way you can deal with such virtual, completely generic devices
is by being very explicit about the requirements. For simplefb the
assumptions are that firmware set everything up and passes information
about what it set up to the kernel so that it can be reused. None of the
resources need to be explicitly managed because they have all been
properly configured. For that reason, again, I think the right way is
for the kernel not to switch off any of the used resources.

If you want to equate simplefb to other drivers then it is fundamentally
broken anyway. Given only what's in the DTB the simplefb driver won't be
able to do anything useful. Consider what would happen if the firmware
didn't set up all the resources. Then the DT is missing resets, power
supplies and all that to make it work.

> As for 2. Yes this will add some more code to simplefb, more code but
> code which is not complicated in anyway, so the simplefb code would
> become larger but still stay simple. Were as all the suggested
> alternatives sofar are at least an order of magnitude more complicated,
> crossing many subsystems, demanding coordination with userspace, etc.

I'm not objecting to this patch because of the complexity, but because
it is an illusion that the code is in any way generic.

> > so I think we should keep the discussion going for a bit and
> > see if we really can't come up with something that will fix this for a
> > more general case rather than just your particular use-case. It's
> > evidently a recurring problem that others suffer from, too.
> 
> Yes needing resources despite the device being behind some generic
> interface where the main driver code for that interface has no knowledge
> about such resources sofar, because e.g. on PC-s this was not necessary
> is a recurring problem, which has been solved already 3 times at least,
> see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
> was that the best solution was to simple add the resources to the dt-node,
> and add code to claim and enable them.

And as I pointed out above in all three cases the generic platform
driver is only marginally useful because many SoCs have specific
requirements that make them incompatible with the generic driver.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 11:31 AM, Thierry Reding wrote:
> > Can you please fix you mail setup. You're addressing me directly in this
> > email, yet I'm neither in To: nor Cc: headers. That's really annoying.
> 
> Sorry, I'll pay closer attention that you're in the To when I'm directly
> addressing you next time.
> 
> > On Tue, Aug 26, 2014 at 09:59:00PM +0200, Hans de Goede wrote:
> 
> <snip>
> 
> >>> Either way, Mark already suggested a different alternative in another
> >>> subthread, namely to add a new kind of checkpoint at which subsystems
> >>> can call a "disable unused" function that's called later than a late
> >>> initcall. This is not going to fix things for you immediately because
> >>> the clocks will still be switched off (only later) if you don't have
> >>> a real driver that's claiming the clocks. But you can work around that
> >>> for now by making the relevant clocks always on and remove that
> >>> workaround once a real driver is loaded that knows how to handle them
> >>> properly.
> >>
> >> This will simply not work, and is a ton more complicated then
> >> simply teaching simplefb about a clocks property, which is a really simple
> >> and clean patch.
> >>
> >> First of all let me explain why this won't work. When should those
> >> subsystems call this "later then a late initcall" call ? the kms driver
> >> may very well be a kernel module, which will be loaded by userspace,
> >> so we would need this to be triggered by userspace, but when ?
> >>
> >> When the initrd is done? What then if the kms driver is not in the initrd,
> >> so maybe when udev is done enumerating devices, but what then if the kernel
> >> is still enumerating hardware at this time?
> > 
> > Usually an initrd knows how to wait for all or a given set of devices to
> > be probed. udev is pretty good for that.
> 
> udev does not have a clue how to wait for all devices, it can be used to
> wait for a specific device to show up, that is true, but this requires
> adding specific logic for this (class of) device to the initrd init process,
> which is really sub-optimal.

I thought pretty much every distribution that did anything remotely
related to early DRM/KMS like plymouth and whatnot already had this
specific logic. It's been a while since I dealt with all that, but
something roughly like this used to be present in pretty much all
distributions:

	udevadm trigger --subsystem-match=graphics \
		--subsystem-match=drm \
		--subsystem-match=tty
	udevadm settle

The effect of that being that udevadm settle would block as long as
devices were still being probed. Admittedly this was all long before
deferred probing was introduced, so I have no idea how well it plays
with it. But optimizing deferred probing is an entirely different topic
currently under discussion that should help sorting this out, too.

> >> Will we just put a sleep 30
> >> in our initscripts to make sure the kernel is done scanning all busses,
> >> will that be long enough? Maybe we need to re-introduce the scsi_wait_done
> >> kernel module which was added as an ugly hack to allow userspace to wait
> >> for the kernel to have finished scanning scsi (and ata / sata) busses,
> >> for controllers found at the time the module was load. Which never worked
> >> reliable, because it would be possible that the controller itself still
> >> needed to be discovered. We've spend years cleaning up userspace enough
> >> to be able to kill scsi_wait_done. We've already been down this road of
> >> waiting for hw enumeration to be done, and the problem is that on
> >> modern systems *it is never done*.
> > 
> > Those are mostly integration issues. If you don't load the driver from
> > initrd then I don't think anybody will complain when there's flicker
> > when it finally gets loaded. The whole point of this is to have early
> > access to the framebuffer and get display and graphics going as soon as
> > possible, so please don't pull in hypothetical scenarios where people
> > manually load drivers half an hour after the system has booted.
> 
> In another mail in this thread you've mentioned 2 uses for simplefb:
> 
> 1) Serving as *the* fb until a kms driver is present
> 2) Allowing for output of early kernel boot messages.
> 
> I agree that those are the 2 use-cases we're dealing with here.
> 
> Note that the whole discussion we're having hear about disabling the clocks
> once hardware probing is "done", is moot for 1. One possible way mentioned
> of dealing with 1. is to mark these clocks as always on for now, and then we
> need to drop this hack (I cannot call this anything else then a hack), once
> we get kms, meaning interdependencies between the dropping patch and the kms
> adding patches, etc. All not very pretty.

I don't think it's that bad. When your real driver is merged you can
still keep the clocks always on for a release cycle if you worry about
any fallout. It's unlikely to going to be your last driver that you
merge and people aren't immediately going to build products based on it,
so it's unlikely that anyone will notice the wasted power.

> For 2. We have what you call "mostly integration issues". Allow me to copy
> and paste in another bit of this thread here:
> 
> >> I've been doing low level Linux development for 10 years now and I've
> >> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.
> >
> > Ah, so this is now officially a pissing contest, is it?
> 
> No I'm merely trying to explain that I've a ton of experience with what
> you seem to think of as merely integration issues, and they are a royal PITA,
> and thus to be avoided at all costs. Really, please just trust me on this
> one, doing the whole add some later then late init call type is a bad idea.

Well, you could equally just trust me on this one when I say adding
clock support for this driver is bad. Stalemate.

> >> So second of all, Thierry, what exactly is the technical argument against
> >> adding support for dealing with clocks to simplefb ?
> > 
> > I've already stated technical arguments against it. You could just go
> > back and read the thread again, or would you rather want me to repeat
> > them for your convenience?
> 
> It is a long thread, IIRC your main arguments against this are:
> 
> 1) You don't want this kind of platform-specific knowledge in simplefb
> 2) That simplefb is supposed to be simple, and this is not simple
> 
> As for 1. several people have already argued that clocks as such are
> an abstract concept, found one many platforms and as such are not
> platform specific.

That alone doesn't justify this patch. SoCs often have a requirement to
enable clocks in a specific order, for example. Other systems may need
to coordinate clocks with resets in a specific order or enable power
domains and such. All that is very SoC specific and if we don't make it
very clear what this driver assumes about the state of the system, then
we can't object to anybody adding support for those later on either. The
result of that is going to be a driver that needs to handle all kinds of
combinations of resources.

So while clocks themselves are fairly generic the way in which they need
to be used is highly platform-specific.

Let me also reiterate what I've said a couple of times already. The
issue here isn't that simplefb needs to manage these clocks in any way.
Firmware has already set them up so that display works. The reason why
you need this patch is so that the clock framework doesn't automatically
turn them off. With the proposed patch the driver enables these clocks,
but that's not what it needs to do, they are already on. It's a work
around to prevent the clock framework into not disabling them.

So as far as I'm concerned this points to a fundamental issue with how
the clock framework handles unused clocks. Therefore that is the problem
that should be solved, not worked around.

> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> ehci, etc. has ended up adding abstract support for things like clocks
> (and other resources). I say abstract support here, since to all these
> drivers the support was added in a way that no platform specific knowledge
> is necessary, they just deal with clocks not caring about the specific
> underlying clock implementation, clock names, etc.

Yes, I know that. You and I both had a very similar discussion not so
long ago. But the above aren't quite the same as simplefb. The devices
follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
bound to be more commonalities between them than between the various
display devices that simplefb potentially can support.

Interestingly though, if you look at what hardware really is supported
by the generic drivers that deal with embedded platforms, there isn't
all that much diversity (I've manually stripped out non-DTS occurrences
since they aren't relevant for this discussion):

	$ git grep -n generic-ohci
	arch/arm/boot/dts/sun4i-a10.dtsi:451:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
	arch/arm/boot/dts/sun4i-a10.dtsi:492:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
	arch/arm/boot/dts/sun5i-a10s.dtsi:403:          compatible = "allwinner,sun5i-a10s-ohci", "generic-ohci";
	arch/arm/boot/dts/sun5i-a13.dtsi:376:           compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:410:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:432:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun6i-a31.dtsi:443:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
	arch/arm/boot/dts/sun7i-a20.dtsi:535:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
	arch/arm/boot/dts/sun7i-a20.dtsi:576:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
	arch/powerpc/boot/dts/akebono.dts:144:          compatible = "ibm,476gtr-ohci", "generic-ohci";
	arch/powerpc/boot/dts/akebono.dts:151:          compatible = "ibm,476gtr-ohci", "generic-ohci";

	$ git grep -n generic-ehci
	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
	arch/arm/boot/dts/sun4i-a10.dtsi:441:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
	arch/arm/boot/dts/sun4i-a10.dtsi:482:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
	arch/arm/boot/dts/sun5i-a10s.dtsi:393:          compatible = "allwinner,sun5i-a10s-ehci", "generic-ehci";
	arch/arm/boot/dts/sun5i-a13.dtsi:366:           compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
	arch/arm/boot/dts/sun6i-a31.dtsi:399:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
	arch/arm/boot/dts/sun6i-a31.dtsi:421:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
	arch/arm/boot/dts/sun7i-a20.dtsi:525:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
	arch/arm/boot/dts/sun7i-a20.dtsi:566:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
	arch/powerpc/boot/dts/akebono.dts:130:          compatible = "ibm,476gtr-ehci", "generic-ehci";

For generic-ahci there aren't any matches, but here are a few that are
marked compatible with it using different compatible strings:

	$ git grep -n snps,spear-ahci
	arch/arm/boot/dts/spear1310.dtsi:60:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1310.dtsi:69:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1310.dtsi:78:            compatible = "snps,spear-ahci";
	arch/arm/boot/dts/spear1340.dtsi:43:            compatible = "snps,spear-ahci";

	$ git grep -n snps,exynos5440-ahci
	arch/arm/boot/dts/exynos5440.dtsi:241:          compatible = "snps,exynos5440-ahci";

	$ git grep -n 'ibm,476gtr-ahci'
	arch/powerpc/boot/dts/akebono.dts:123:          compatible = "ibm,476gtr-ahci";

	$ git grep -n 'snps,dwc-ahci'
	arch/arm/boot/dts/dra7.dtsi:1049:               compatible = "snps,dwc-ahci";
	arch/arm/boot/dts/exynos5250.dtsi:265:          compatible = "snps,dwc-ahci";
	arch/arm/boot/dts/omap5.dtsi:919:               compatible = "snps,dwc-ahci";

That looks fairly homogenous to me. There are also things like this
(from the ahci_platform.c driver):

	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;

With more supported hardware there's bound to be more quirks like that.

So there's a couple of SoCs and boards that actually are generic enough
to work with a generic driver. And then there's a whole bunch of other
drivers for hardware that's compliant with the same standard yet needs
different drivers. To me that's a clear indication that there isn't
enough genericity to warrant a generic driver in the first place.

The commonality is in the functionality and defined by the standard
registers. But there's little to no commonality in how that interface is
glued into the SoC. Luckily the above subsystems implement the standard
hardware programming in a library, so that non-generic drivers can still
make use of most of the generic code.

> This really is unavoidable. The framebuffer memory needed was mentioned
> as another example of a resource in this thread. You suggested using the
> new mem-reserve framework for this. I agree that that is the right thing
> to do, but even then we still need a way to tie this reserved mem to
> the simplefb, so that the kernel can know when it is no longer used
> and can be added to the general memory pool.

Yes, memory handling seems like it isn't handled optimally by simplefb.
To be fair the simplefb driver predates the reserved-memory bindings. I
think it might be worthwhile to investigate on how to extend the binding
to make use of that, though. I think the assumption currently is that
the framebuffer memory will be lost forever (it needs to be carved out
of the physical memory that the kernel gets to see). I couldn't find any
code that returned reserved-memory to the kernel, but it's certainly a
feature that I think we want. Especially if the firmware framebuffer is
large (as in 1080p).

> If you look at how almost all dt bindings work, then the dt node for
> a device specifies the resources needed, I don't see why simplefb would
> be so special that it should be different here. I agree that it is
> important to get the abstractions right here, but to me it seems that
> the right abstraction is to be consistent with how all other devices
> are abstracted and to add needed resources to the dt node for the
> simplefb.

But simplefb is fundamentally different from other devices. It isn't a
physical device at all. It's a virtual device that reuses resources as
set up by some other piece of code (firmware). It implies that there's
nothing that needs to be managed. It should only create a framebuffer
with the given parameters and allow the kernel (and userspace) to render
into it.

The only way you can deal with such virtual, completely generic devices
is by being very explicit about the requirements. For simplefb the
assumptions are that firmware set everything up and passes information
about what it set up to the kernel so that it can be reused. None of the
resources need to be explicitly managed because they have all been
properly configured. For that reason, again, I think the right way is
for the kernel not to switch off any of the used resources.

If you want to equate simplefb to other drivers then it is fundamentally
broken anyway. Given only what's in the DTB the simplefb driver won't be
able to do anything useful. Consider what would happen if the firmware
didn't set up all the resources. Then the DT is missing resets, power
supplies and all that to make it work.

> As for 2. Yes this will add some more code to simplefb, more code but
> code which is not complicated in anyway, so the simplefb code would
> become larger but still stay simple. Were as all the suggested
> alternatives sofar are at least an order of magnitude more complicated,
> crossing many subsystems, demanding coordination with userspace, etc.

I'm not objecting to this patch because of the complexity, but because
it is an illusion that the code is in any way generic.

> > so I think we should keep the discussion going for a bit and
> > see if we really can't come up with something that will fix this for a
> > more general case rather than just your particular use-case. It's
> > evidently a recurring problem that others suffer from, too.
> 
> Yes needing resources despite the device being behind some generic
> interface where the main driver code for that interface has no knowledge
> about such resources sofar, because e.g. on PC-s this was not necessary
> is a recurring problem, which has been solved already 3 times at least,
> see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
> was that the best solution was to simple add the resources to the dt-node,
> and add code to claim and enable them.

And as I pointed out above in all three cases the generic platform
driver is only marginally useful because many SoCs have specific
requirements that make them incompatible with the generic driver.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/9be6c8a7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 02:56 PM, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:

<snip>

>>>> So second of all, Thierry, what exactly is the technical argument against
>>>> adding support for dealing with clocks to simplefb ?
>>>
>>> I've already stated technical arguments against it. You could just go
>>> back and read the thread again, or would you rather want me to repeat
>>> them for your convenience?
>>
>> It is a long thread, IIRC your main arguments against this are:
>>
>> 1) You don't want this kind of platform-specific knowledge in simplefb
>> 2) That simplefb is supposed to be simple, and this is not simple
>>
>> As for 1. several people have already argued that clocks as such are
>> an abstract concept, found one many platforms and as such are not
>> platform specific.
> 
> That alone doesn't justify this patch. SoCs often have a requirement to
> enable clocks in a specific order, for example. Other systems may need
> to coordinate clocks with resets in a specific order or enable power
> domains and such. All that is very SoC specific and if we don't make it
> very clear what this driver assumes about the state of the system, then
> we can't object to anybody adding support for those later on either. The
> result of that is going to be a driver that needs to handle all kinds of
> combinations of resources.

The problems your talking about here all have to do with ordering how
things are enabled, but what we're talking about here is keeping things
enabled which are already enabled by the bootloader, so there is no
ordering problem.

> So while clocks themselves are fairly generic the way in which they need
> to be used is highly platform-specific.
> 
> Let me also reiterate what I've said a couple of times already. The
> issue here isn't that simplefb needs to manage these clocks in any way.
> Firmware has already set them up so that display works. The reason why
> you need this patch is so that the clock framework doesn't automatically
> turn them off. With the proposed patch the driver enables these clocks,
> but that's not what it needs to do, they are already on. It's a work
> around to prevent the clock framework into not disabling them.
> 
> So as far as I'm concerned this points to a fundamental issue with how
> the clock framework handles unused clocks. Therefore that is the problem
> that should be solved, not worked around.

Hmm I see, in my mind the problem is not that the clk framework disables
unused clocks, but that no one is marking the clocks in question as used.
Someone should mark these clocks as used so that they do not get disabled.

We could add a clk_mark_in_use function and have the simplefb patch call
that instead of clk_prepare_and_enable, or maybe even better just only
claim the clks and teach the clk framework to not disable claimed clk
in its cleanup run. That would make it clear that simplefb is not enabling
anything, just claiming resource its need to avoid them getting removed
from underneath simplefb, would that work for you ?

>> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
>> ehci, etc. has ended up adding abstract support for things like clocks
>> (and other resources). I say abstract support here, since to all these
>> drivers the support was added in a way that no platform specific knowledge
>> is necessary, they just deal with clocks not caring about the specific
>> underlying clock implementation, clock names, etc.
> 
> Yes, I know that. You and I both had a very similar discussion not so
> long ago. But the above aren't quite the same as simplefb. The devices
> follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> bound to be more commonalities between them than between the various
> display devices that simplefb potentially can support.
> 
> Interestingly though, if you look at what hardware really is supported
> by the generic drivers that deal with embedded platforms, there isn't
> all that much diversity (I've manually stripped out non-DTS occurrences
> since they aren't relevant for this discussion):

That is because the generic platform drivers were only added recently
to stop the insanity where each new soc got its own ohci-soc.c /
ehci-soc.c file.

<snip>
> 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";

(offtopic) And I see that despite the recent addition, we actually already have our
first non sunxi user, good, I didn't even know the rockchip guys were using this :)

And I know that there are quite a few more in the pipeline (waiting for their
usb phy and dt patches to get merged).

<snip>

> So there's a couple of SoCs and boards that actually are generic enough
> to work with a generic driver. And then there's a whole bunch of other
> drivers for hardware that's compliant with the same standard yet needs
> different drivers.

No, there are a lot of other drivers which were written before someone
decided that having 10-20 drivers which were 90% copy and paste of each
other was a bad idea, but we're really going offtopic here.

<snip>

>> This really is unavoidable. The framebuffer memory needed was mentioned
>> as another example of a resource in this thread. You suggested using the
>> new mem-reserve framework for this. I agree that that is the right thing
>> to do, but even then we still need a way to tie this reserved mem to
>> the simplefb, so that the kernel can know when it is no longer used
>> and can be added to the general memory pool.
> 
> Yes, memory handling seems like it isn't handled optimally by simplefb.
> To be fair the simplefb driver predates the reserved-memory bindings. I
> think it might be worthwhile to investigate on how to extend the binding
> to make use of that, though. I think the assumption currently is that
> the framebuffer memory will be lost forever (it needs to be carved out
> of the physical memory that the kernel gets to see). I couldn't find any
> code that returned reserved-memory to the kernel, but it's certainly a
> feature that I think we want. Especially if the firmware framebuffer is
> large (as in 1080p).

Ack.

>> If you look at how almost all dt bindings work, then the dt node for
>> a device specifies the resources needed, I don't see why simplefb would
>> be so special that it should be different here. I agree that it is
>> important to get the abstractions right here, but to me it seems that
>> the right abstraction is to be consistent with how all other devices
>> are abstracted and to add needed resources to the dt node for the
>> simplefb.
> 
> But simplefb is fundamentally different from other devices. It isn't a
> physical device at all. It's a virtual device that reuses resources as
> set up by some other piece of code (firmware). It implies that there's
> nothing that needs to be managed. It should only create a framebuffer
> with the given parameters and allow the kernel (and userspace) to render
> into it.
> 
> The only way you can deal with such virtual, completely generic devices
> is by being very explicit about the requirements. For simplefb the
> assumptions are that firmware set everything up and passes information
> about what it set up to the kernel so that it can be reused.

> None of the resources need to be explicitly managed because they have all
> been properly configured. For that reason, again, I think the right way is
> for the kernel not to switch off any of the used resources.

The key word here is "the used resources" to me this is not about simlefb
managing resources, but marking them as used as long as it needs them, like
it will need to do for the reserved mem chunk.

<snip>

>> As for 2. Yes this will add some more code to simplefb, more code but
>> code which is not complicated in anyway, so the simplefb code would
>> become larger but still stay simple. Were as all the suggested
>> alternatives sofar are at least an order of magnitude more complicated,
>> crossing many subsystems, demanding coordination with userspace, etc.
> 
> I'm not objecting to this patch because of the complexity, but because
> it is an illusion that the code is in any way generic.

Ok.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 02:56 PM, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:

<snip>

>>>> So second of all, Thierry, what exactly is the technical argument against
>>>> adding support for dealing with clocks to simplefb ?
>>>
>>> I've already stated technical arguments against it. You could just go
>>> back and read the thread again, or would you rather want me to repeat
>>> them for your convenience?
>>
>> It is a long thread, IIRC your main arguments against this are:
>>
>> 1) You don't want this kind of platform-specific knowledge in simplefb
>> 2) That simplefb is supposed to be simple, and this is not simple
>>
>> As for 1. several people have already argued that clocks as such are
>> an abstract concept, found one many platforms and as such are not
>> platform specific.
> 
> That alone doesn't justify this patch. SoCs often have a requirement to
> enable clocks in a specific order, for example. Other systems may need
> to coordinate clocks with resets in a specific order or enable power
> domains and such. All that is very SoC specific and if we don't make it
> very clear what this driver assumes about the state of the system, then
> we can't object to anybody adding support for those later on either. The
> result of that is going to be a driver that needs to handle all kinds of
> combinations of resources.

The problems your talking about here all have to do with ordering how
things are enabled, but what we're talking about here is keeping things
enabled which are already enabled by the bootloader, so there is no
ordering problem.

> So while clocks themselves are fairly generic the way in which they need
> to be used is highly platform-specific.
> 
> Let me also reiterate what I've said a couple of times already. The
> issue here isn't that simplefb needs to manage these clocks in any way.
> Firmware has already set them up so that display works. The reason why
> you need this patch is so that the clock framework doesn't automatically
> turn them off. With the proposed patch the driver enables these clocks,
> but that's not what it needs to do, they are already on. It's a work
> around to prevent the clock framework into not disabling them.
> 
> So as far as I'm concerned this points to a fundamental issue with how
> the clock framework handles unused clocks. Therefore that is the problem
> that should be solved, not worked around.

Hmm I see, in my mind the problem is not that the clk framework disables
unused clocks, but that no one is marking the clocks in question as used.
Someone should mark these clocks as used so that they do not get disabled.

We could add a clk_mark_in_use function and have the simplefb patch call
that instead of clk_prepare_and_enable, or maybe even better just only
claim the clks and teach the clk framework to not disable claimed clk
in its cleanup run. That would make it clear that simplefb is not enabling
anything, just claiming resource its need to avoid them getting removed
from underneath simplefb, would that work for you ?

>> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
>> ehci, etc. has ended up adding abstract support for things like clocks
>> (and other resources). I say abstract support here, since to all these
>> drivers the support was added in a way that no platform specific knowledge
>> is necessary, they just deal with clocks not caring about the specific
>> underlying clock implementation, clock names, etc.
> 
> Yes, I know that. You and I both had a very similar discussion not so
> long ago. But the above aren't quite the same as simplefb. The devices
> follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> bound to be more commonalities between them than between the various
> display devices that simplefb potentially can support.
> 
> Interestingly though, if you look at what hardware really is supported
> by the generic drivers that deal with embedded platforms, there isn't
> all that much diversity (I've manually stripped out non-DTS occurrences
> since they aren't relevant for this discussion):

That is because the generic platform drivers were only added recently
to stop the insanity where each new soc got its own ohci-soc.c /
ehci-soc.c file.

<snip>
> 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";

(offtopic) And I see that despite the recent addition, we actually already have our
first non sunxi user, good, I didn't even know the rockchip guys were using this :)

And I know that there are quite a few more in the pipeline (waiting for their
usb phy and dt patches to get merged).

<snip>

> So there's a couple of SoCs and boards that actually are generic enough
> to work with a generic driver. And then there's a whole bunch of other
> drivers for hardware that's compliant with the same standard yet needs
> different drivers.

No, there are a lot of other drivers which were written before someone
decided that having 10-20 drivers which were 90% copy and paste of each
other was a bad idea, but we're really going offtopic here.

<snip>

>> This really is unavoidable. The framebuffer memory needed was mentioned
>> as another example of a resource in this thread. You suggested using the
>> new mem-reserve framework for this. I agree that that is the right thing
>> to do, but even then we still need a way to tie this reserved mem to
>> the simplefb, so that the kernel can know when it is no longer used
>> and can be added to the general memory pool.
> 
> Yes, memory handling seems like it isn't handled optimally by simplefb.
> To be fair the simplefb driver predates the reserved-memory bindings. I
> think it might be worthwhile to investigate on how to extend the binding
> to make use of that, though. I think the assumption currently is that
> the framebuffer memory will be lost forever (it needs to be carved out
> of the physical memory that the kernel gets to see). I couldn't find any
> code that returned reserved-memory to the kernel, but it's certainly a
> feature that I think we want. Especially if the firmware framebuffer is
> large (as in 1080p).

Ack.

>> If you look at how almost all dt bindings work, then the dt node for
>> a device specifies the resources needed, I don't see why simplefb would
>> be so special that it should be different here. I agree that it is
>> important to get the abstractions right here, but to me it seems that
>> the right abstraction is to be consistent with how all other devices
>> are abstracted and to add needed resources to the dt node for the
>> simplefb.
> 
> But simplefb is fundamentally different from other devices. It isn't a
> physical device at all. It's a virtual device that reuses resources as
> set up by some other piece of code (firmware). It implies that there's
> nothing that needs to be managed. It should only create a framebuffer
> with the given parameters and allow the kernel (and userspace) to render
> into it.
> 
> The only way you can deal with such virtual, completely generic devices
> is by being very explicit about the requirements. For simplefb the
> assumptions are that firmware set everything up and passes information
> about what it set up to the kernel so that it can be reused.

> None of the resources need to be explicitly managed because they have all
> been properly configured. For that reason, again, I think the right way is
> for the kernel not to switch off any of the used resources.

The key word here is "the used resources" to me this is not about simlefb
managing resources, but marking them as used as long as it needs them, like
it will need to do for the reserved mem chunk.

<snip>

>> As for 2. Yes this will add some more code to simplefb, more code but
>> code which is not complicated in anyway, so the simplefb code would
>> become larger but still stay simple. Were as all the suggested
>> alternatives sofar are at least an order of magnitude more complicated,
>> crossing many subsystems, demanding coordination with userspace, etc.
> 
> I'm not objecting to this patch because of the complexity, but because
> it is an illusion that the code is in any way generic.

Ok.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 8992 bytes --]

On Wed, Aug 27, 2014 at 03:44:46PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 02:56 PM, Thierry Reding wrote:
> > On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:
> 
> <snip>
> 
> >>>> So second of all, Thierry, what exactly is the technical argument against
> >>>> adding support for dealing with clocks to simplefb ?
> >>>
> >>> I've already stated technical arguments against it. You could just go
> >>> back and read the thread again, or would you rather want me to repeat
> >>> them for your convenience?
> >>
> >> It is a long thread, IIRC your main arguments against this are:
> >>
> >> 1) You don't want this kind of platform-specific knowledge in simplefb
> >> 2) That simplefb is supposed to be simple, and this is not simple
> >>
> >> As for 1. several people have already argued that clocks as such are
> >> an abstract concept, found one many platforms and as such are not
> >> platform specific.
> > 
> > That alone doesn't justify this patch. SoCs often have a requirement to
> > enable clocks in a specific order, for example. Other systems may need
> > to coordinate clocks with resets in a specific order or enable power
> > domains and such. All that is very SoC specific and if we don't make it
> > very clear what this driver assumes about the state of the system, then
> > we can't object to anybody adding support for those later on either. The
> > result of that is going to be a driver that needs to handle all kinds of
> > combinations of resources.
> 
> The problems your talking about here all have to do with ordering how
> things are enabled, but what we're talking about here is keeping things
> enabled which are already enabled by the bootloader, so there is no
> ordering problem.

See what I did there? I tricked you into saying what I've been saying
all along. =) It's about keeping things enabled which have been enabled
by the bootloader. That's the root of the problem.

> > So while clocks themselves are fairly generic the way in which they need
> > to be used is highly platform-specific.
> > 
> > Let me also reiterate what I've said a couple of times already. The
> > issue here isn't that simplefb needs to manage these clocks in any way.
> > Firmware has already set them up so that display works. The reason why
> > you need this patch is so that the clock framework doesn't automatically
> > turn them off. With the proposed patch the driver enables these clocks,
> > but that's not what it needs to do, they are already on. It's a work
> > around to prevent the clock framework into not disabling them.
> > 
> > So as far as I'm concerned this points to a fundamental issue with how
> > the clock framework handles unused clocks. Therefore that is the problem
> > that should be solved, not worked around.
> 
> Hmm I see, in my mind the problem is not that the clk framework disables
> unused clocks, but that no one is marking the clocks in question as used.
> Someone should mark these clocks as used so that they do not get disabled.
> 
> We could add a clk_mark_in_use function and have the simplefb patch call
> that instead of clk_prepare_and_enable, or maybe even better just only
> claim the clks and teach the clk framework to not disable claimed clk
> in its cleanup run. That would make it clear that simplefb is not enabling
> anything, just claiming resource its need to avoid them getting removed
> from underneath simplefb, would that work for you ?

That would be more accurate, but it boils down to the same problem where
we still need a driver to claim the resources in some way whereas the
problem is fundamentally one where the bootloader should be telling the
kernel not to disable it. It's in fact the bootloader that's claiming
the resources.

> >> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> >> ehci, etc. has ended up adding abstract support for things like clocks
> >> (and other resources). I say abstract support here, since to all these
> >> drivers the support was added in a way that no platform specific knowledge
> >> is necessary, they just deal with clocks not caring about the specific
> >> underlying clock implementation, clock names, etc.
> > 
> > Yes, I know that. You and I both had a very similar discussion not so
> > long ago. But the above aren't quite the same as simplefb. The devices
> > follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> > bound to be more commonalities between them than between the various
> > display devices that simplefb potentially can support.
> > 
> > Interestingly though, if you look at what hardware really is supported
> > by the generic drivers that deal with embedded platforms, there isn't
> > all that much diversity (I've manually stripped out non-DTS occurrences
> > since they aren't relevant for this discussion):
> 
> That is because the generic platform drivers were only added recently
> to stop the insanity where each new soc got its own ohci-soc.c /
> ehci-soc.c file.

Insanity is subjective.

> > 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> > 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
> 
> (offtopic) And I see that despite the recent addition, we actually already have our
> first non sunxi user, good, I didn't even know the rockchip guys were using this :)

FWIW, the rk3288 entry is broken. It should really contain an SoC
specific compatible string as well.

> And I know that there are quite a few more in the pipeline (waiting for their
> usb phy and dt patches to get merged).

As far as I'm concerned that's all a mistake (and catastrophy waiting to
happen), but hey, there's only so many hours in a day so I've got to
pick my battles.

> > So there's a couple of SoCs and boards that actually are generic enough
> > to work with a generic driver. And then there's a whole bunch of other
> > drivers for hardware that's compliant with the same standard yet needs
> > different drivers.
> 
> No, there are a lot of other drivers which were written before someone
> decided that having 10-20 drivers which were 90% copy and paste of each
> other was a bad idea, but we're really going offtopic here.

The copy and paste is for code that's platform specific. The clocks have
different names, resets are different, supplies are different. The fact
that many can currently use the same driver is likely just coincidence
rather than design and it's entirely possible that at some point they'll
add support for a more advanced feature that makes them incompatible
with the rest of the generic drivers. And then you have a big mess
because you need to add quirks all over the place.

And this isn't all that far off-topic, since simplefb also needs to deal
with this kind of situation. And what I've been arguing is that in order
to really be generic it has to make assumptions, one of which is that it
uses only resources that it doesn't need to explicitly handle.

> >> If you look at how almost all dt bindings work, then the dt node for
> >> a device specifies the resources needed, I don't see why simplefb would
> >> be so special that it should be different here. I agree that it is
> >> important to get the abstractions right here, but to me it seems that
> >> the right abstraction is to be consistent with how all other devices
> >> are abstracted and to add needed resources to the dt node for the
> >> simplefb.
> > 
> > But simplefb is fundamentally different from other devices. It isn't a
> > physical device at all. It's a virtual device that reuses resources as
> > set up by some other piece of code (firmware). It implies that there's
> > nothing that needs to be managed. It should only create a framebuffer
> > with the given parameters and allow the kernel (and userspace) to render
> > into it.
> > 
> > The only way you can deal with such virtual, completely generic devices
> > is by being very explicit about the requirements. For simplefb the
> > assumptions are that firmware set everything up and passes information
> > about what it set up to the kernel so that it can be reused.
> 
> > None of the resources need to be explicitly managed because they have all
> > been properly configured. For that reason, again, I think the right way is
> > for the kernel not to switch off any of the used resources.
> 
> The key word here is "the used resources" to me this is not about simlefb
> managing resources, but marking them as used as long as it needs them, like
> it will need to do for the reserved mem chunk.

The difference between the clocks and the memory resource is that the
driver needs to directly access the memory (it needs to map it and
provide a userspace mapping for it) whereas it doesn't need to touch the
clocks (except to workaround a Linux-specific implementation detail).

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 03:44:46PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 02:56 PM, Thierry Reding wrote:
> > On Wed, Aug 27, 2014 at 12:35:24PM +0200, Hans de Goede wrote:
> 
> <snip>
> 
> >>>> So second of all, Thierry, what exactly is the technical argument against
> >>>> adding support for dealing with clocks to simplefb ?
> >>>
> >>> I've already stated technical arguments against it. You could just go
> >>> back and read the thread again, or would you rather want me to repeat
> >>> them for your convenience?
> >>
> >> It is a long thread, IIRC your main arguments against this are:
> >>
> >> 1) You don't want this kind of platform-specific knowledge in simplefb
> >> 2) That simplefb is supposed to be simple, and this is not simple
> >>
> >> As for 1. several people have already argued that clocks as such are
> >> an abstract concept, found one many platforms and as such are not
> >> platform specific.
> > 
> > That alone doesn't justify this patch. SoCs often have a requirement to
> > enable clocks in a specific order, for example. Other systems may need
> > to coordinate clocks with resets in a specific order or enable power
> > domains and such. All that is very SoC specific and if we don't make it
> > very clear what this driver assumes about the state of the system, then
> > we can't object to anybody adding support for those later on either. The
> > result of that is going to be a driver that needs to handle all kinds of
> > combinations of resources.
> 
> The problems your talking about here all have to do with ordering how
> things are enabled, but what we're talking about here is keeping things
> enabled which are already enabled by the bootloader, so there is no
> ordering problem.

See what I did there? I tricked you into saying what I've been saying
all along. =) It's about keeping things enabled which have been enabled
by the bootloader. That's the root of the problem.

> > So while clocks themselves are fairly generic the way in which they need
> > to be used is highly platform-specific.
> > 
> > Let me also reiterate what I've said a couple of times already. The
> > issue here isn't that simplefb needs to manage these clocks in any way.
> > Firmware has already set them up so that display works. The reason why
> > you need this patch is so that the clock framework doesn't automatically
> > turn them off. With the proposed patch the driver enables these clocks,
> > but that's not what it needs to do, they are already on. It's a work
> > around to prevent the clock framework into not disabling them.
> > 
> > So as far as I'm concerned this points to a fundamental issue with how
> > the clock framework handles unused clocks. Therefore that is the problem
> > that should be solved, not worked around.
> 
> Hmm I see, in my mind the problem is not that the clk framework disables
> unused clocks, but that no one is marking the clocks in question as used.
> Someone should mark these clocks as used so that they do not get disabled.
> 
> We could add a clk_mark_in_use function and have the simplefb patch call
> that instead of clk_prepare_and_enable, or maybe even better just only
> claim the clks and teach the clk framework to not disable claimed clk
> in its cleanup run. That would make it clear that simplefb is not enabling
> anything, just claiming resource its need to avoid them getting removed
> from underneath simplefb, would that work for you ?

That would be more accurate, but it boils down to the same problem where
we still need a driver to claim the resources in some way whereas the
problem is fundamentally one where the bootloader should be telling the
kernel not to disable it. It's in fact the bootloader that's claiming
the resources.

> >> Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> >> ehci, etc. has ended up adding abstract support for things like clocks
> >> (and other resources). I say abstract support here, since to all these
> >> drivers the support was added in a way that no platform specific knowledge
> >> is necessary, they just deal with clocks not caring about the specific
> >> underlying clock implementation, clock names, etc.
> > 
> > Yes, I know that. You and I both had a very similar discussion not so
> > long ago. But the above aren't quite the same as simplefb. The devices
> > follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> > bound to be more commonalities between them than between the various
> > display devices that simplefb potentially can support.
> > 
> > Interestingly though, if you look at what hardware really is supported
> > by the generic drivers that deal with embedded platforms, there isn't
> > all that much diversity (I've manually stripped out non-DTS occurrences
> > since they aren't relevant for this discussion):
> 
> That is because the generic platform drivers were only added recently
> to stop the insanity where each new soc got its own ohci-soc.c /
> ehci-soc.c file.

Insanity is subjective.

> > 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> > 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
> 
> (offtopic) And I see that despite the recent addition, we actually already have our
> first non sunxi user, good, I didn't even know the rockchip guys were using this :)

FWIW, the rk3288 entry is broken. It should really contain an SoC
specific compatible string as well.

> And I know that there are quite a few more in the pipeline (waiting for their
> usb phy and dt patches to get merged).

As far as I'm concerned that's all a mistake (and catastrophy waiting to
happen), but hey, there's only so many hours in a day so I've got to
pick my battles.

> > So there's a couple of SoCs and boards that actually are generic enough
> > to work with a generic driver. And then there's a whole bunch of other
> > drivers for hardware that's compliant with the same standard yet needs
> > different drivers.
> 
> No, there are a lot of other drivers which were written before someone
> decided that having 10-20 drivers which were 90% copy and paste of each
> other was a bad idea, but we're really going offtopic here.

The copy and paste is for code that's platform specific. The clocks have
different names, resets are different, supplies are different. The fact
that many can currently use the same driver is likely just coincidence
rather than design and it's entirely possible that at some point they'll
add support for a more advanced feature that makes them incompatible
with the rest of the generic drivers. And then you have a big mess
because you need to add quirks all over the place.

And this isn't all that far off-topic, since simplefb also needs to deal
with this kind of situation. And what I've been arguing is that in order
to really be generic it has to make assumptions, one of which is that it
uses only resources that it doesn't need to explicitly handle.

> >> If you look at how almost all dt bindings work, then the dt node for
> >> a device specifies the resources needed, I don't see why simplefb would
> >> be so special that it should be different here. I agree that it is
> >> important to get the abstractions right here, but to me it seems that
> >> the right abstraction is to be consistent with how all other devices
> >> are abstracted and to add needed resources to the dt node for the
> >> simplefb.
> > 
> > But simplefb is fundamentally different from other devices. It isn't a
> > physical device at all. It's a virtual device that reuses resources as
> > set up by some other piece of code (firmware). It implies that there's
> > nothing that needs to be managed. It should only create a framebuffer
> > with the given parameters and allow the kernel (and userspace) to render
> > into it.
> > 
> > The only way you can deal with such virtual, completely generic devices
> > is by being very explicit about the requirements. For simplefb the
> > assumptions are that firmware set everything up and passes information
> > about what it set up to the kernel so that it can be reused.
> 
> > None of the resources need to be explicitly managed because they have all
> > been properly configured. For that reason, again, I think the right way is
> > for the kernel not to switch off any of the used resources.
> 
> The key word here is "the used resources" to me this is not about simlefb
> managing resources, but marking them as used as long as it needs them, like
> it will need to do for the reserved mem chunk.

The difference between the clocks and the memory resource is that the
driver needs to directly access the memory (it needs to map it and
provide a userspace mapping for it) whereas it doesn't need to touch the
clocks (except to workaround a Linux-specific implementation detail).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/d30e8512/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 04:16 PM, Thierry Reding wrote:

<snip>

>> The problems your talking about here all have to do with ordering how
>> things are enabled, but what we're talking about here is keeping things
>> enabled which are already enabled by the bootloader, so there is no
>> ordering problem.
> 
> See what I did there? I tricked you into saying what I've been saying
> all along. =) 

He he :)

> It's about keeping things enabled which have been enabled
> by the bootloader. That's the root of the problem.

Ok so we all seem to largely agree on most things here:

1) Somehow some clks must be marked used so as to not get disabled
2) We don't want to hardcode these clocks into the kernel (sunxi) clk
driver, instead the bootloader should tell the kernel about these clocks.

So the only point of discussion left seems to be how to do 2...

<snip>

>> Hmm I see, in my mind the problem is not that the clk framework disables
>> unused clocks, but that no one is marking the clocks in question as used.
>> Someone should mark these clocks as used so that they do not get disabled.
>>
>> We could add a clk_mark_in_use function and have the simplefb patch call
>> that instead of clk_prepare_and_enable, or maybe even better just only
>> claim the clks and teach the clk framework to not disable claimed clk
>> in its cleanup run. That would make it clear that simplefb is not enabling
>> anything, just claiming resource its need to avoid them getting removed
>> from underneath simplefb, would that work for you ?
> 
> That would be more accurate, but it boils down to the same problem where
> we still need a driver to claim the resources in some way whereas the
> problem is fundamentally one where the bootloader should be telling the
> kernel not to disable it. It's in fact the bootloader that's claiming
> the resources.

Yes, but those resources do not belong to the bootloader in a sense
that traditional bootloader / firmware claimed resources (e.g. acpi
reserved resources) do. These traditional resources are claimed for ever.

Where as these resources are claimed by the bootloader to keep the simplefb
it provides working, as soon as the simplefb is no longer used, they become
unused.

<snip off-topic generic-ehci discussion>

>> No, there are a lot of other drivers which were written before someone
>> decided that having 10-20 drivers which were 90% copy and paste of each
>> other was a bad idea, but we're really going offtopic here.
> 
> The copy and paste is for code that's platform specific. The clocks have
> different names, resets are different, supplies are different. The fact
> that many can currently use the same driver is likely just coincidence
> rather than design and it's entirely possible that at some point they'll
> add support for a more advanced feature that makes them incompatible
> with the rest of the generic drivers. And then you have a big mess
> because you need to add quirks all over the place.
> 
> And this isn't all that far off-topic, since simplefb also needs to deal
> with this kind of situation. And what I've been arguing is that in order
> to really be generic it has to make assumptions, one of which is that it
> uses only resources that it doesn't need to explicitly handle.

I can understand that you're worried about generic ?hci drivers dealing with
clocks / resets / etc. As there may be strict ordering requirements there,
but for simplefb that is not the case.

All we're asking for is for a way to communicate 2 things to the kernel:

1) These resources are in use (we are not asking the kernel to do anything
with them, rather the opposite, we're asking to leave them alone so no
ordering issues)

2) Tie these resources to simplefb so that the kernel can know when they
are no longer in use, and it may e.g. re-use the memory

To me the most logical and also most "correct" way of modelling this is to
put the resources inside the simplefb dt node.

<snip>

>> The key word here is "the used resources" to me this is not about simlefb
>> managing resources, but marking them as used as long as it needs them, like
>> it will need to do for the reserved mem chunk.
> 
> The difference between the clocks and the memory resource is that the
> driver needs to directly access the memory (it needs to map it and
> provide a userspace mapping for it) whereas it doesn't need to touch the
> clocks (except to workaround a Linux-specific implementation detail).

Erm, no, the need to map the memory and the memory being a resource
which may be released are an orthogonal problem. E.g. a system with
dedicated framebuffer memory won't need to use a reserved main-memory
chunk, nor need to worry about returning that mem when simplefb is no
longer in use.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 04:16 PM, Thierry Reding wrote:

<snip>

>> The problems your talking about here all have to do with ordering how
>> things are enabled, but what we're talking about here is keeping things
>> enabled which are already enabled by the bootloader, so there is no
>> ordering problem.
> 
> See what I did there? I tricked you into saying what I've been saying
> all along. =) 

He he :)

> It's about keeping things enabled which have been enabled
> by the bootloader. That's the root of the problem.

Ok so we all seem to largely agree on most things here:

1) Somehow some clks must be marked used so as to not get disabled
2) We don't want to hardcode these clocks into the kernel (sunxi) clk
driver, instead the bootloader should tell the kernel about these clocks.

So the only point of discussion left seems to be how to do 2...

<snip>

>> Hmm I see, in my mind the problem is not that the clk framework disables
>> unused clocks, but that no one is marking the clocks in question as used.
>> Someone should mark these clocks as used so that they do not get disabled.
>>
>> We could add a clk_mark_in_use function and have the simplefb patch call
>> that instead of clk_prepare_and_enable, or maybe even better just only
>> claim the clks and teach the clk framework to not disable claimed clk
>> in its cleanup run. That would make it clear that simplefb is not enabling
>> anything, just claiming resource its need to avoid them getting removed
>> from underneath simplefb, would that work for you ?
> 
> That would be more accurate, but it boils down to the same problem where
> we still need a driver to claim the resources in some way whereas the
> problem is fundamentally one where the bootloader should be telling the
> kernel not to disable it. It's in fact the bootloader that's claiming
> the resources.

Yes, but those resources do not belong to the bootloader in a sense
that traditional bootloader / firmware claimed resources (e.g. acpi
reserved resources) do. These traditional resources are claimed for ever.

Where as these resources are claimed by the bootloader to keep the simplefb
it provides working, as soon as the simplefb is no longer used, they become
unused.

<snip off-topic generic-ehci discussion>

>> No, there are a lot of other drivers which were written before someone
>> decided that having 10-20 drivers which were 90% copy and paste of each
>> other was a bad idea, but we're really going offtopic here.
> 
> The copy and paste is for code that's platform specific. The clocks have
> different names, resets are different, supplies are different. The fact
> that many can currently use the same driver is likely just coincidence
> rather than design and it's entirely possible that at some point they'll
> add support for a more advanced feature that makes them incompatible
> with the rest of the generic drivers. And then you have a big mess
> because you need to add quirks all over the place.
> 
> And this isn't all that far off-topic, since simplefb also needs to deal
> with this kind of situation. And what I've been arguing is that in order
> to really be generic it has to make assumptions, one of which is that it
> uses only resources that it doesn't need to explicitly handle.

I can understand that you're worried about generic ?hci drivers dealing with
clocks / resets / etc. As there may be strict ordering requirements there,
but for simplefb that is not the case.

All we're asking for is for a way to communicate 2 things to the kernel:

1) These resources are in use (we are not asking the kernel to do anything
with them, rather the opposite, we're asking to leave them alone so no
ordering issues)

2) Tie these resources to simplefb so that the kernel can know when they
are no longer in use, and it may e.g. re-use the memory

To me the most logical and also most "correct" way of modelling this is to
put the resources inside the simplefb dt node.

<snip>

>> The key word here is "the used resources" to me this is not about simlefb
>> managing resources, but marking them as used as long as it needs them, like
>> it will need to do for the reserved mem chunk.
> 
> The difference between the clocks and the memory resource is that the
> driver needs to directly access the memory (it needs to map it and
> provide a userspace mapping for it) whereas it doesn't need to touch the
> clocks (except to workaround a Linux-specific implementation detail).

Erm, no, the need to map the memory and the memory being a resource
which may be released are an orthogonal problem. E.g. a system with
dedicated framebuffer memory won't need to use a reserved main-memory
chunk, nor need to worry about returning that mem when simplefb is no
longer in use.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Aug 28, 2014 at 8:15 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
>
> <snip>
>
>>> The problems your talking about here all have to do with ordering how
>>> things are enabled, but what we're talking about here is keeping things
>>> enabled which are already enabled by the bootloader, so there is no
>>> ordering problem.
>>
>> See what I did there? I tricked you into saying what I've been saying
>> all along. =)
>
> He he :)
>
>> It's about keeping things enabled which have been enabled
>> by the bootloader. That's the root of the problem.
>
> Ok so we all seem to largely agree on most things here:
>
> 1) Somehow some clks must be marked used so as to not get disabled
> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> driver, instead the bootloader should tell the kernel about these clocks.
>
> So the only point of discussion left seems to be how to do 2...

Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
whip together a device specific driver that claims the proper
resources? And just implement the minimal about of fbdev possible?
fbdev already is a driver library.

---

An independent issue is the early printk equivalent. For that you need
an address and the x/y layout

>
> <snip>
>
>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>> unused clocks, but that no one is marking the clocks in question as used.
>>> Someone should mark these clocks as used so that they do not get disabled.
>>>
>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>> claim the clks and teach the clk framework to not disable claimed clk
>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>> anything, just claiming resource its need to avoid them getting removed
>>> from underneath simplefb, would that work for you ?
>>
>> That would be more accurate, but it boils down to the same problem where
>> we still need a driver to claim the resources in some way whereas the
>> problem is fundamentally one where the bootloader should be telling the
>> kernel not to disable it. It's in fact the bootloader that's claiming
>> the resources.
>
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.
>
> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.
>
> <snip off-topic generic-ehci discussion>
>
>>> No, there are a lot of other drivers which were written before someone
>>> decided that having 10-20 drivers which were 90% copy and paste of each
>>> other was a bad idea, but we're really going offtopic here.
>>
>> The copy and paste is for code that's platform specific. The clocks have
>> different names, resets are different, supplies are different. The fact
>> that many can currently use the same driver is likely just coincidence
>> rather than design and it's entirely possible that at some point they'll
>> add support for a more advanced feature that makes them incompatible
>> with the rest of the generic drivers. And then you have a big mess
>> because you need to add quirks all over the place.
>>
>> And this isn't all that far off-topic, since simplefb also needs to deal
>> with this kind of situation. And what I've been arguing is that in order
>> to really be generic it has to make assumptions, one of which is that it
>> uses only resources that it doesn't need to explicitly handle.
>
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
>
> All we're asking for is for a way to communicate 2 things to the kernel:
>
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)
>
> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory
>
> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.
>
> <snip>
>
>>> The key word here is "the used resources" to me this is not about simlefb
>>> managing resources, but marking them as used as long as it needs them, like
>>> it will need to do for the reserved mem chunk.
>>
>> The difference between the clocks and the memory resource is that the
>> driver needs to directly access the memory (it needs to map it and
>> provide a userspace mapping for it) whereas it doesn't need to touch the
>> clocks (except to workaround a Linux-specific implementation detail).
>
> Erm, no, the need to map the memory and the memory being a resource
> which may be released are an orthogonal problem. E.g. a system with
> dedicated framebuffer memory won't need to use a reserved main-memory
> chunk, nor need to worry about returning that mem when simplefb is no
> longer in use.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Aug 28, 2014 at 8:15 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
>
> <snip>
>
>>> The problems your talking about here all have to do with ordering how
>>> things are enabled, but what we're talking about here is keeping things
>>> enabled which are already enabled by the bootloader, so there is no
>>> ordering problem.
>>
>> See what I did there? I tricked you into saying what I've been saying
>> all along. =)
>
> He he :)
>
>> It's about keeping things enabled which have been enabled
>> by the bootloader. That's the root of the problem.
>
> Ok so we all seem to largely agree on most things here:
>
> 1) Somehow some clks must be marked used so as to not get disabled
> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> driver, instead the bootloader should tell the kernel about these clocks.
>
> So the only point of discussion left seems to be how to do 2...

Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
whip together a device specific driver that claims the proper
resources? And just implement the minimal about of fbdev possible?
fbdev already is a driver library.

---

An independent issue is the early printk equivalent. For that you need
an address and the x/y layout

>
> <snip>
>
>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>> unused clocks, but that no one is marking the clocks in question as used.
>>> Someone should mark these clocks as used so that they do not get disabled.
>>>
>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>> claim the clks and teach the clk framework to not disable claimed clk
>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>> anything, just claiming resource its need to avoid them getting removed
>>> from underneath simplefb, would that work for you ?
>>
>> That would be more accurate, but it boils down to the same problem where
>> we still need a driver to claim the resources in some way whereas the
>> problem is fundamentally one where the bootloader should be telling the
>> kernel not to disable it. It's in fact the bootloader that's claiming
>> the resources.
>
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.
>
> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.
>
> <snip off-topic generic-ehci discussion>
>
>>> No, there are a lot of other drivers which were written before someone
>>> decided that having 10-20 drivers which were 90% copy and paste of each
>>> other was a bad idea, but we're really going offtopic here.
>>
>> The copy and paste is for code that's platform specific. The clocks have
>> different names, resets are different, supplies are different. The fact
>> that many can currently use the same driver is likely just coincidence
>> rather than design and it's entirely possible that at some point they'll
>> add support for a more advanced feature that makes them incompatible
>> with the rest of the generic drivers. And then you have a big mess
>> because you need to add quirks all over the place.
>>
>> And this isn't all that far off-topic, since simplefb also needs to deal
>> with this kind of situation. And what I've been arguing is that in order
>> to really be generic it has to make assumptions, one of which is that it
>> uses only resources that it doesn't need to explicitly handle.
>
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
>
> All we're asking for is for a way to communicate 2 things to the kernel:
>
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)
>
> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory
>
> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.
>
> <snip>
>
>>> The key word here is "the used resources" to me this is not about simlefb
>>> managing resources, but marking them as used as long as it needs them, like
>>> it will need to do for the reserved mem chunk.
>>
>> The difference between the clocks and the memory resource is that the
>> driver needs to directly access the memory (it needs to map it and
>> provide a userspace mapping for it) whereas it doesn't need to touch the
>> clocks (except to workaround a Linux-specific implementation detail).
>
> Erm, no, the need to map the memory and the memory being a resource
> which may be released are an orthogonal problem. E.g. a system with
> dedicated framebuffer memory won't need to use a reserved main-memory
> chunk, nor need to worry about returning that mem when simplefb is no
> longer in use.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>> driver, instead the bootloader should tell the kernel about these clocks.
>>
>> So the only point of discussion left seems to be how to do 2...
>
> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> whip together a device specific driver that claims the proper
> resources? And just implement the minimal about of fbdev possible?
> fbdev already is a driver library.

Like... drivers/video/fbdev/offb.c?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>> driver, instead the bootloader should tell the kernel about these clocks.
>>
>> So the only point of discussion left seems to be how to do 2...
>
> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> whip together a device specific driver that claims the proper
> resources? And just implement the minimal about of fbdev possible?
> fbdev already is a driver library.

Like... drivers/video/fbdev/offb.c?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>
>>> So the only point of discussion left seems to be how to do 2...
>>
>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>> whip together a device specific driver that claims the proper
>> resources? And just implement the minimal about of fbdev possible?
>> fbdev already is a driver library.
>
> Like... drivers/video/fbdev/offb.c?

I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
and use it as a template for making device specific versions of it.

I don't see why there is so much resistance to just making device
specific fb drivers.  Whenever the KMS driver gets written just
disable the device specific fb driver in the build.


>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>
>>> So the only point of discussion left seems to be how to do 2...
>>
>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>> whip together a device specific driver that claims the proper
>> resources? And just implement the minimal about of fbdev possible?
>> fbdev already is a driver library.
>
> Like... drivers/video/fbdev/offb.c?

I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
and use it as a template for making device specific versions of it.

I don't see why there is so much resistance to just making device
specific fb drivers.  Whenever the KMS driver gets written just
disable the device specific fb driver in the build.


>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 4:33 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>
>>>> So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

I explicitly named offb, because it already supports living with the
video mode initialized by Open Firmware, which is passed to the kernel
in a device tree.

-- 
Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 4:33 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>
>>>> So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

I explicitly named offb, because it already supports living with the
video mode initialized by Open Firmware, which is passed to the kernel
in a device tree.

-- 
Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Aug 28, 2014 at 10:37 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Aug 28, 2014 at 4:33 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>
>>>>> So the only point of discussion left seems to be how to do 2...
>>>>
>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>> whip together a device specific driver that claims the proper
>>>> resources? And just implement the minimal about of fbdev possible?
>>>> fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> I explicitly named offb, because it already supports living with the
> video mode initialized by Open Firmware, which is passed to the kernel
> in a device tree.

Not sure how that works. It from a PowerMac

arch/powerpc/platforms/powermac/bootx_init.c
arch/powerpc/kernel/prom_init.c

>
> --
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Aug 28, 2014 at 10:37 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, Aug 28, 2014 at 4:33 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>
>>>>> So the only point of discussion left seems to be how to do 2...
>>>>
>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>> whip together a device specific driver that claims the proper
>>>> resources? And just implement the minimal about of fbdev possible?
>>>> fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> I explicitly named offb, because it already supports living with the
> video mode initialized by Open Firmware, which is passed to the kernel
> in a device tree.

Not sure how that works. It from a PowerMac

arch/powerpc/platforms/powermac/bootx_init.c
arch/powerpc/kernel/prom_init.c

>
> --
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>
>>>> So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

Except that is not the goal here. The simplefb or whatever replacement
is supposed to stay as a  generic driver compiled into kernel whereas
the complete platform-specific driver is supposed to be provided as
module and loaded at the init system's leasure sometime during boot.
This way you can have generic distribution kernel which supports many
devices but does not have built-in support for every graphics
hardware.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 16:33, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>
>>>> So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

Except that is not the goal here. The simplefb or whatever replacement
is supposed to stay as a  generic driver compiled into kernel whereas
the complete platform-specific driver is supposed to be provided as
module and loaded at the init system's leasure sometime during boot.
This way you can have generic distribution kernel which supports many
devices but does not have built-in support for every graphics
hardware.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>
>>>>> So the only point of discussion left seems to be how to do 2...
>>>>
>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>> whip together a device specific driver that claims the proper
>>>> resources? And just implement the minimal about of fbdev possible?
>>>> fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> Except that is not the goal here. The simplefb or whatever replacement
> is supposed to stay as a  generic driver compiled into kernel whereas

There is no generic solution to this problem as this entire thread has
illustrated. The clocks/regulators needed by each SOC vary.

So there are two solutions..
1) modify simplefb to have some kind of heuristic that tries to guess
what needs to be protected. A heuristic that is probably going to fail
on every new SOC.

2) Spend a day implementing a device specific fbdev driver that does
the correct thing all of the time. These drivers would sit in initrd
and load before the clock/regulator clean up shuts everything off. Use
the existing simplefb code as a template for doing this.


> the complete platform-specific driver is supposed to be provided as
> module and loaded at the init system's leasure sometime during boot.
> This way you can have generic distribution kernel which supports many
> devices but does not have built-in support for every graphics
> hardware.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 28 August 2014 16:33, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>
>>>>> So the only point of discussion left seems to be how to do 2...
>>>>
>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>> whip together a device specific driver that claims the proper
>>>> resources? And just implement the minimal about of fbdev possible?
>>>> fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> Except that is not the goal here. The simplefb or whatever replacement
> is supposed to stay as a  generic driver compiled into kernel whereas

There is no generic solution to this problem as this entire thread has
illustrated. The clocks/regulators needed by each SOC vary.

So there are two solutions..
1) modify simplefb to have some kind of heuristic that tries to guess
what needs to be protected. A heuristic that is probably going to fail
on every new SOC.

2) Spend a day implementing a device specific fbdev driver that does
the correct thing all of the time. These drivers would sit in initrd
and load before the clock/regulator clean up shuts everything off. Use
the existing simplefb code as a template for doing this.


> the complete platform-specific driver is supposed to be provided as
> module and loaded at the init system's leasure sometime during boot.
> This way you can have generic distribution kernel which supports many
> devices but does not have built-in support for every graphics
> hardware.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl@gmail.com wrote:
> 
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

If that finally ends this discussion, i'll more than happily do it. I'm 
sure that we've all could've done this a hundred times in the time we've
wasted here.

Good call Geert.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl at gmail.com wrote:
> 
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

If that finally ends this discussion, i'll more than happily do it. I'm 
sure that we've all could've done this a hundred times in the time we've
wasted here.

Good call Geert.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 18:34, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>>
>>>>>> So the only point of discussion left seems to be how to do 2...
>>>>>
>>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>>> whip together a device specific driver that claims the proper
>>>>> resources? And just implement the minimal about of fbdev possible?
>>>>> fbdev already is a driver library.
>>>>
>>>> Like... drivers/video/fbdev/offb.c?
>>>
>>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>>> and use it as a template for making device specific versions of it.
>>>
>>> I don't see why there is so much resistance to just making device
>>> specific fb drivers.  Whenever the KMS driver gets written just
>>> disable the device specific fb driver in the build.
>>
>> Except that is not the goal here. The simplefb or whatever replacement
>> is supposed to stay as a  generic driver compiled into kernel whereas
>
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.
>
> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.

You do not need a heuristic when the bootloader that enabled the
clocks and regulators can tell you which.

And this patch was initially about adding support to simplefb to read
from DT where u-boot fills in the clocks that are needed for HDMI
output to keep running on sunxi.

>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

But then you need to spend a day implementing such driver for every
SoC and it will not work before initrd is loaded.

In contrast simplefb with resource management support can work on any
platform where the bootloader enables framebuffer and then can be
compiled into generic kernel and work before even initrd is loaded.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 18:34, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 28 August 2014 16:33, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>>>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>>>>
>>>>>> So the only point of discussion left seems to be how to do 2...
>>>>>
>>>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>>>> whip together a device specific driver that claims the proper
>>>>> resources? And just implement the minimal about of fbdev possible?
>>>>> fbdev already is a driver library.
>>>>
>>>> Like... drivers/video/fbdev/offb.c?
>>>
>>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>>> and use it as a template for making device specific versions of it.
>>>
>>> I don't see why there is so much resistance to just making device
>>> specific fb drivers.  Whenever the KMS driver gets written just
>>> disable the device specific fb driver in the build.
>>
>> Except that is not the goal here. The simplefb or whatever replacement
>> is supposed to stay as a  generic driver compiled into kernel whereas
>
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.
>
> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.

You do not need a heuristic when the bootloader that enabled the
clocks and regulators can tell you which.

And this patch was initially about adding support to simplefb to read
from DT where u-boot fills in the clocks that are needed for HDMI
output to keep running on sunxi.

>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

But then you need to spend a day implementing such driver for every
SoC and it will not work before initrd is loaded.

In contrast simplefb with resource management support can work on any
platform where the bootloader enables framebuffer and then can be
compiled into generic kernel and work before even initrd is loaded.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl@gmail.com wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> > On 28 August 2014 16:33, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> >>>>> driver, instead the bootloader should tell the kernel about these clocks.
> >>>>>
> >>>>> So the only point of discussion left seems to be how to do 2...
> >>>>
> >>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> >>>> whip together a device specific driver that claims the proper
> >>>> resources? And just implement the minimal about of fbdev possible?
> >>>> fbdev already is a driver library.
> >>>
> >>> Like... drivers/video/fbdev/offb.c?
> >>
> >> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> >> and use it as a template for making device specific versions of it.
> >>
> >> I don't see why there is so much resistance to just making device
> >> specific fb drivers.  Whenever the KMS driver gets written just
> >> disable the device specific fb driver in the build.
> >
> > Except that is not the goal here. The simplefb or whatever replacement
> > is supposed to stay as a  generic driver compiled into kernel whereas
> 
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.

There is a generic solution. Genericity only works if you define a well
defined set of assumptions. In this case the assumptions are that some
firmware sets up display hardware to scan out from a memory region and
communicates the location, layout and format of that memory region so
that a generic driver can write into that framebuffer.

The generic solution here works because we've eliminated the platform
specificities and let firmware take care of it.

> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.
> 
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

There's a third possibility: find a way to prevent the clock framework
(and any other resource framework for that matter) from forcefully
disabling things that they shouldn't.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsmirl at gmail.com wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek <hramrach@gmail.com> wrote:
> > On 28 August 2014 16:33, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> >> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >>> On Thu, Aug 28, 2014 at 3:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> >>>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> >>>>> driver, instead the bootloader should tell the kernel about these clocks.
> >>>>>
> >>>>> So the only point of discussion left seems to be how to do 2...
> >>>>
> >>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> >>>> whip together a device specific driver that claims the proper
> >>>> resources? And just implement the minimal about of fbdev possible?
> >>>> fbdev already is a driver library.
> >>>
> >>> Like... drivers/video/fbdev/offb.c?
> >>
> >> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> >> and use it as a template for making device specific versions of it.
> >>
> >> I don't see why there is so much resistance to just making device
> >> specific fb drivers.  Whenever the KMS driver gets written just
> >> disable the device specific fb driver in the build.
> >
> > Except that is not the goal here. The simplefb or whatever replacement
> > is supposed to stay as a  generic driver compiled into kernel whereas
> 
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.

There is a generic solution. Genericity only works if you define a well
defined set of assumptions. In this case the assumptions are that some
firmware sets up display hardware to scan out from a memory region and
communicates the location, layout and format of that memory region so
that a generic driver can write into that framebuffer.

The generic solution here works because we've eliminated the platform
specificities and let firmware take care of it.

> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.
> 
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

There's a third possibility: find a way to prevent the clock framework
(and any other resource framework for that matter) from forcefully
disabling things that they shouldn't.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/e055b012/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6253 bytes --]

On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
[...]
> >> Hmm I see, in my mind the problem is not that the clk framework disables
> >> unused clocks, but that no one is marking the clocks in question as used.
> >> Someone should mark these clocks as used so that they do not get disabled.
> >>
> >> We could add a clk_mark_in_use function and have the simplefb patch call
> >> that instead of clk_prepare_and_enable, or maybe even better just only
> >> claim the clks and teach the clk framework to not disable claimed clk
> >> in its cleanup run. That would make it clear that simplefb is not enabling
> >> anything, just claiming resource its need to avoid them getting removed
> >> from underneath simplefb, would that work for you ?
> > 
> > That would be more accurate, but it boils down to the same problem where
> > we still need a driver to claim the resources in some way whereas the
> > problem is fundamentally one where the bootloader should be telling the
> > kernel not to disable it. It's in fact the bootloader that's claiming
> > the resources.
> 
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.

I thought that at least on x86 there was a way for the kernel to reclaim
memory set apart for an early framebuffer.

> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.

Right. And when simplefb goes away it is because a real driver is taking
over, in which case it will claim the resources explicitly.

> > The copy and paste is for code that's platform specific. The clocks have
> > different names, resets are different, supplies are different. The fact
> > that many can currently use the same driver is likely just coincidence
> > rather than design and it's entirely possible that at some point they'll
> > add support for a more advanced feature that makes them incompatible
> > with the rest of the generic drivers. And then you have a big mess
> > because you need to add quirks all over the place.
> > 
> > And this isn't all that far off-topic, since simplefb also needs to deal
> > with this kind of situation. And what I've been arguing is that in order
> > to really be generic it has to make assumptions, one of which is that it
> > uses only resources that it doesn't need to explicitly handle.
> 
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
> 
> All we're asking for is for a way to communicate 2 things to the kernel:
> 
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)

Right. That's the issue that needs to be solved. We still only disagree
on how it should be solved.

> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory

For the memory there shouldn't be a problem because it's already in the
DT node anyway. It has to be there so that simplefb knows where to write
to.

For all the other resources, if 1) is solved properly then 2) becomes a
non-issue.

> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.

Except that simplefb isn't a real device, so there's a hard time
justifying its existence in DT as it is. Claiming resources from a
virtual device doesn't sound correct to me at all.

> >> The key word here is "the used resources" to me this is not about simlefb
> >> managing resources, but marking them as used as long as it needs them, like
> >> it will need to do for the reserved mem chunk.
> > 
> > The difference between the clocks and the memory resource is that the
> > driver needs to directly access the memory (it needs to map it and
> > provide a userspace mapping for it) whereas it doesn't need to touch the
> > clocks (except to workaround a Linux-specific implementation detail).
> 
> Erm, no, the need to map the memory and the memory being a resource
> which may be released are an orthogonal problem. E.g. a system with
> dedicated framebuffer memory won't need to use a reserved main-memory
> chunk, nor need to worry about returning that mem when simplefb is no
> longer in use.

I would think the memory should still be reserved anyway to make sure
nothing else is writing over it. And it's in the device tree anyway
because the driver needs to know where to put framebuffer content. So
the point I was trying to make is that we can't treat the memory in the
same way as clocks because it needs to be explicitly managed. Whereas
clocks don't. The driver is simply too generic to know what to do with
the clocks. It doesn't know what frequency they should be running at or
what they're used for, so by any definition of what DT should describe
they're useless for this virtual device.

Furthermore it's fairly likely that as your kernel support progresses
you'll find that the driver all of a sudden needs to manage some other
type of resource that you just haven't needed until now because it may
default to being always on. Then you'll have a hard time keeping
backwards-compatibility and will have to resort to the kinds of hacks
that you don't want to see in the kernel.

So it really boils down to the DT needing to describe a complete device
with all the dependencies. And just clocks aren't the complete
description. But if you want the complete description then you're going
to need a complete driver as well and simplefb is out of the picture
anyway. Once again, the current, basic form of the binding allows for a
completely generic implementation of the driver because it makes
assumptions about firmware setting things up the right way so that the
driver doesn't have to.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
[...]
> >> Hmm I see, in my mind the problem is not that the clk framework disables
> >> unused clocks, but that no one is marking the clocks in question as used.
> >> Someone should mark these clocks as used so that they do not get disabled.
> >>
> >> We could add a clk_mark_in_use function and have the simplefb patch call
> >> that instead of clk_prepare_and_enable, or maybe even better just only
> >> claim the clks and teach the clk framework to not disable claimed clk
> >> in its cleanup run. That would make it clear that simplefb is not enabling
> >> anything, just claiming resource its need to avoid them getting removed
> >> from underneath simplefb, would that work for you ?
> > 
> > That would be more accurate, but it boils down to the same problem where
> > we still need a driver to claim the resources in some way whereas the
> > problem is fundamentally one where the bootloader should be telling the
> > kernel not to disable it. It's in fact the bootloader that's claiming
> > the resources.
> 
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.

I thought that at least on x86 there was a way for the kernel to reclaim
memory set apart for an early framebuffer.

> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.

Right. And when simplefb goes away it is because a real driver is taking
over, in which case it will claim the resources explicitly.

> > The copy and paste is for code that's platform specific. The clocks have
> > different names, resets are different, supplies are different. The fact
> > that many can currently use the same driver is likely just coincidence
> > rather than design and it's entirely possible that at some point they'll
> > add support for a more advanced feature that makes them incompatible
> > with the rest of the generic drivers. And then you have a big mess
> > because you need to add quirks all over the place.
> > 
> > And this isn't all that far off-topic, since simplefb also needs to deal
> > with this kind of situation. And what I've been arguing is that in order
> > to really be generic it has to make assumptions, one of which is that it
> > uses only resources that it doesn't need to explicitly handle.
> 
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
> 
> All we're asking for is for a way to communicate 2 things to the kernel:
> 
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)

Right. That's the issue that needs to be solved. We still only disagree
on how it should be solved.

> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory

For the memory there shouldn't be a problem because it's already in the
DT node anyway. It has to be there so that simplefb knows where to write
to.

For all the other resources, if 1) is solved properly then 2) becomes a
non-issue.

> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.

Except that simplefb isn't a real device, so there's a hard time
justifying its existence in DT as it is. Claiming resources from a
virtual device doesn't sound correct to me at all.

> >> The key word here is "the used resources" to me this is not about simlefb
> >> managing resources, but marking them as used as long as it needs them, like
> >> it will need to do for the reserved mem chunk.
> > 
> > The difference between the clocks and the memory resource is that the
> > driver needs to directly access the memory (it needs to map it and
> > provide a userspace mapping for it) whereas it doesn't need to touch the
> > clocks (except to workaround a Linux-specific implementation detail).
> 
> Erm, no, the need to map the memory and the memory being a resource
> which may be released are an orthogonal problem. E.g. a system with
> dedicated framebuffer memory won't need to use a reserved main-memory
> chunk, nor need to worry about returning that mem when simplefb is no
> longer in use.

I would think the memory should still be reserved anyway to make sure
nothing else is writing over it. And it's in the device tree anyway
because the driver needs to know where to put framebuffer content. So
the point I was trying to make is that we can't treat the memory in the
same way as clocks because it needs to be explicitly managed. Whereas
clocks don't. The driver is simply too generic to know what to do with
the clocks. It doesn't know what frequency they should be running at or
what they're used for, so by any definition of what DT should describe
they're useless for this virtual device.

Furthermore it's fairly likely that as your kernel support progresses
you'll find that the driver all of a sudden needs to manage some other
type of resource that you just haven't needed until now because it may
default to being always on. Then you'll have a hard time keeping
backwards-compatibility and will have to resort to the kinds of hacks
that you don't want to see in the kernel.

So it really boils down to the DT needing to describe a complete device
with all the dependencies. And just clocks aren't the complete
description. But if you want the complete description then you're going
to need a complete driver as well and simplefb is out of the picture
anyway. Once again, the current, basic form of the binding allows for a
completely generic implementation of the driver because it makes
assumptions about firmware setting things up the right way so that the
driver doesn't have to.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/29e057cd/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/29/2014 09:01 AM, Thierry Reding wrote:
> On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
>> On 08/27/2014 04:16 PM, Thierry Reding wrote:
> [...]
>>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>>> unused clocks, but that no one is marking the clocks in question as used.
>>>> Someone should mark these clocks as used so that they do not get disabled.
>>>>
>>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>>> claim the clks and teach the clk framework to not disable claimed clk
>>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>>> anything, just claiming resource its need to avoid them getting removed
>>>> from underneath simplefb, would that work for you ?
>>>
>>> That would be more accurate, but it boils down to the same problem where
>>> we still need a driver to claim the resources in some way whereas the
>>> problem is fundamentally one where the bootloader should be telling the
>>> kernel not to disable it. It's in fact the bootloader that's claiming
>>> the resources.
>>
>> Yes, but those resources do not belong to the bootloader in a sense
>> that traditional bootloader / firmware claimed resources (e.g. acpi
>> reserved resources) do. These traditional resources are claimed for ever.
> 
> I thought that at least on x86 there was a way for the kernel to reclaim
> memory set apart for an early framebuffer.
> 
>> Where as these resources are claimed by the bootloader to keep the simplefb
>> it provides working, as soon as the simplefb is no longer used, they become
>> unused.
> 
> Right. And when simplefb goes away it is because a real driver is taking
> over, in which case it will claim the resources explicitly.
> 
>>> The copy and paste is for code that's platform specific. The clocks have
>>> different names, resets are different, supplies are different. The fact
>>> that many can currently use the same driver is likely just coincidence
>>> rather than design and it's entirely possible that at some point they'll
>>> add support for a more advanced feature that makes them incompatible
>>> with the rest of the generic drivers. And then you have a big mess
>>> because you need to add quirks all over the place.
>>>
>>> And this isn't all that far off-topic, since simplefb also needs to deal
>>> with this kind of situation. And what I've been arguing is that in order
>>> to really be generic it has to make assumptions, one of which is that it
>>> uses only resources that it doesn't need to explicitly handle.
>>
>> I can understand that you're worried about generic ?hci drivers dealing with
>> clocks / resets / etc. As there may be strict ordering requirements there,
>> but for simplefb that is not the case.
>>
>> All we're asking for is for a way to communicate 2 things to the kernel:
>>
>> 1) These resources are in use (we are not asking the kernel to do anything
>> with them, rather the opposite, we're asking to leave them alone so no
>> ordering issues)
> 
> Right. That's the issue that needs to be solved. We still only disagree
> on how it should be solved.
> 
>> 2) Tie these resources to simplefb so that the kernel can know when they
>> are no longer in use, and it may e.g. re-use the memory
> 
> For the memory there shouldn't be a problem because it's already in the
> DT node anyway. It has to be there so that simplefb knows where to write
> to.

The memory information currently in the dt node is not complete enough to
reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
reg entry only describes the part actually used for the framebuffer.

> For all the other resources, if 1) is solved properly then 2) becomes a
> non-issue.
> 
>> To me the most logical and also most "correct" way of modelling this is to
>> put the resources inside the simplefb dt node.
> 
> Except that simplefb isn't a real device, so there's a hard time
> justifying its existence in DT as it is. Claiming resources from a
> virtual device doesn't sound correct to me at all.

Yet you want it to claim memory that does not seem consistent to me.

> 
>>>> The key word here is "the used resources" to me this is not about simlefb
>>>> managing resources, but marking them as used as long as it needs them, like
>>>> it will need to do for the reserved mem chunk.
>>>
>>> The difference between the clocks and the memory resource is that the
>>> driver needs to directly access the memory (it needs to map it and
>>> provide a userspace mapping for it) whereas it doesn't need to touch the
>>> clocks (except to workaround a Linux-specific implementation detail).
>>
>> Erm, no, the need to map the memory and the memory being a resource
>> which may be released are an orthogonal problem. E.g. a system with
>> dedicated framebuffer memory won't need to use a reserved main-memory
>> chunk, nor need to worry about returning that mem when simplefb is no
>> longer in use.
> 
> I would think the memory should still be reserved anyway to make sure
> nothing else is writing over it. And it's in the device tree anyway
> because the driver needs to know where to put framebuffer content.

No, the address were to write framebuffer contents currently is in the
simplefb node, not the actually backing memory info. I can fully see
some crazy hardware where a chunk of main memory is reserved for some
funky video engine, and then that chunk of memory gets accessed through
io-mem addresses for framebuffer access (e.g. the hardware may need this
to know when the fb is dirtied).

> So
> the point I was trying to make is that we can't treat the memory in the
> same way as clocks because it needs to be explicitly managed. Whereas
> clocks don't. The driver is simply too generic to know what to do with
> the clocks. It doesn't know what frequency they should be running at or
> what they're used for, so by any definition of what DT should describe
> they're useless for this virtual device.

I don't see why you keep insisting that the memory is so special, it is
just another resource which we need to claim, and tie to the simplefb node
so that it can be re-used (or disabled) when simplefb is no longer used
(it could e.g. be unbound explicitly on headless systems).

> Furthermore it's fairly likely that as your kernel support progresses
> you'll find that the driver all of a sudden needs to manage some other
> type of resource that you just haven't needed until now because it may
> default to being always on. Then you'll have a hard time keeping
> backwards-compatibility and will have to resort to the kinds of hacks
> that you don't want to see in the kernel.

kernel support? This is about u-boot's video code and the simplefb bindings.

> So it really boils down to the DT needing to describe a complete device
> with all the dependencies. And just clocks aren't the complete
> description. But if you want the complete description then you're going
> to need a complete driver as well and simplefb is out of the picture
> anyway.

Yes we eventually need a full kernel driver, with its own bindings, that
is not what this is about.

> Once again, the current, basic form of the binding allows for a
> completely generic implementation of the driver because it makes
> assumptions about firmware setting things up the right way so that the
> driver doesn't have to.

Except that it does not work because it does not claim the necessary
resources.

We seem to be at a point where this discussion is just going in circles,
and since there seems to be no reasonable alternative to the proposed
solution of adding the clocks to the simplefb node, can you please just
stop blocking progress on this?

Your objection to this has been duly noted, but no one is forcing you or
other people to actually use the clocks property in your implementation
of simplefb. So if your 101% certain that this is a bad idea, can you
please just let us (the sunxi people) make our own mistakes and learn
from those ? As we actually plan to use the clocks property, we will be
the ones which will have to deal with any issues. For the record, I
don't think this is a bad idea myself, but that just brings us full
circle again.

I'm willing to look into just marking the clocks as used, instead of
actually enabling them.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/29/2014 09:01 AM, Thierry Reding wrote:
> On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
>> On 08/27/2014 04:16 PM, Thierry Reding wrote:
> [...]
>>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>>> unused clocks, but that no one is marking the clocks in question as used.
>>>> Someone should mark these clocks as used so that they do not get disabled.
>>>>
>>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>>> claim the clks and teach the clk framework to not disable claimed clk
>>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>>> anything, just claiming resource its need to avoid them getting removed
>>>> from underneath simplefb, would that work for you ?
>>>
>>> That would be more accurate, but it boils down to the same problem where
>>> we still need a driver to claim the resources in some way whereas the
>>> problem is fundamentally one where the bootloader should be telling the
>>> kernel not to disable it. It's in fact the bootloader that's claiming
>>> the resources.
>>
>> Yes, but those resources do not belong to the bootloader in a sense
>> that traditional bootloader / firmware claimed resources (e.g. acpi
>> reserved resources) do. These traditional resources are claimed for ever.
> 
> I thought that at least on x86 there was a way for the kernel to reclaim
> memory set apart for an early framebuffer.
> 
>> Where as these resources are claimed by the bootloader to keep the simplefb
>> it provides working, as soon as the simplefb is no longer used, they become
>> unused.
> 
> Right. And when simplefb goes away it is because a real driver is taking
> over, in which case it will claim the resources explicitly.
> 
>>> The copy and paste is for code that's platform specific. The clocks have
>>> different names, resets are different, supplies are different. The fact
>>> that many can currently use the same driver is likely just coincidence
>>> rather than design and it's entirely possible that at some point they'll
>>> add support for a more advanced feature that makes them incompatible
>>> with the rest of the generic drivers. And then you have a big mess
>>> because you need to add quirks all over the place.
>>>
>>> And this isn't all that far off-topic, since simplefb also needs to deal
>>> with this kind of situation. And what I've been arguing is that in order
>>> to really be generic it has to make assumptions, one of which is that it
>>> uses only resources that it doesn't need to explicitly handle.
>>
>> I can understand that you're worried about generic ?hci drivers dealing with
>> clocks / resets / etc. As there may be strict ordering requirements there,
>> but for simplefb that is not the case.
>>
>> All we're asking for is for a way to communicate 2 things to the kernel:
>>
>> 1) These resources are in use (we are not asking the kernel to do anything
>> with them, rather the opposite, we're asking to leave them alone so no
>> ordering issues)
> 
> Right. That's the issue that needs to be solved. We still only disagree
> on how it should be solved.
> 
>> 2) Tie these resources to simplefb so that the kernel can know when they
>> are no longer in use, and it may e.g. re-use the memory
> 
> For the memory there shouldn't be a problem because it's already in the
> DT node anyway. It has to be there so that simplefb knows where to write
> to.

The memory information currently in the dt node is not complete enough to
reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
reg entry only describes the part actually used for the framebuffer.

> For all the other resources, if 1) is solved properly then 2) becomes a
> non-issue.
> 
>> To me the most logical and also most "correct" way of modelling this is to
>> put the resources inside the simplefb dt node.
> 
> Except that simplefb isn't a real device, so there's a hard time
> justifying its existence in DT as it is. Claiming resources from a
> virtual device doesn't sound correct to me at all.

Yet you want it to claim memory that does not seem consistent to me.

> 
>>>> The key word here is "the used resources" to me this is not about simlefb
>>>> managing resources, but marking them as used as long as it needs them, like
>>>> it will need to do for the reserved mem chunk.
>>>
>>> The difference between the clocks and the memory resource is that the
>>> driver needs to directly access the memory (it needs to map it and
>>> provide a userspace mapping for it) whereas it doesn't need to touch the
>>> clocks (except to workaround a Linux-specific implementation detail).
>>
>> Erm, no, the need to map the memory and the memory being a resource
>> which may be released are an orthogonal problem. E.g. a system with
>> dedicated framebuffer memory won't need to use a reserved main-memory
>> chunk, nor need to worry about returning that mem when simplefb is no
>> longer in use.
> 
> I would think the memory should still be reserved anyway to make sure
> nothing else is writing over it. And it's in the device tree anyway
> because the driver needs to know where to put framebuffer content.

No, the address were to write framebuffer contents currently is in the
simplefb node, not the actually backing memory info. I can fully see
some crazy hardware where a chunk of main memory is reserved for some
funky video engine, and then that chunk of memory gets accessed through
io-mem addresses for framebuffer access (e.g. the hardware may need this
to know when the fb is dirtied).

> So
> the point I was trying to make is that we can't treat the memory in the
> same way as clocks because it needs to be explicitly managed. Whereas
> clocks don't. The driver is simply too generic to know what to do with
> the clocks. It doesn't know what frequency they should be running at or
> what they're used for, so by any definition of what DT should describe
> they're useless for this virtual device.

I don't see why you keep insisting that the memory is so special, it is
just another resource which we need to claim, and tie to the simplefb node
so that it can be re-used (or disabled) when simplefb is no longer used
(it could e.g. be unbound explicitly on headless systems).

> Furthermore it's fairly likely that as your kernel support progresses
> you'll find that the driver all of a sudden needs to manage some other
> type of resource that you just haven't needed until now because it may
> default to being always on. Then you'll have a hard time keeping
> backwards-compatibility and will have to resort to the kinds of hacks
> that you don't want to see in the kernel.

kernel support? This is about u-boot's video code and the simplefb bindings.

> So it really boils down to the DT needing to describe a complete device
> with all the dependencies. And just clocks aren't the complete
> description. But if you want the complete description then you're going
> to need a complete driver as well and simplefb is out of the picture
> anyway.

Yes we eventually need a full kernel driver, with its own bindings, that
is not what this is about.

> Once again, the current, basic form of the binding allows for a
> completely generic implementation of the driver because it makes
> assumptions about firmware setting things up the right way so that the
> driver doesn't have to.

Except that it does not work because it does not claim the necessary
resources.

We seem to be at a point where this discussion is just going in circles,
and since there seems to be no reasonable alternative to the proposed
solution of adding the clocks to the simplefb node, can you please just
stop blocking progress on this?

Your objection to this has been duly noted, but no one is forcing you or
other people to actually use the clocks property in your implementation
of simplefb. So if your 101% certain that this is a bad idea, can you
please just let us (the sunxi people) make our own mistakes and learn
from those ? As we actually plan to use the clocks property, we will be
the ones which will have to deal with any issues. For the record, I
don't think this is a bad idea myself, but that just brings us full
circle again.

I'm willing to look into just marking the clocks as used, instead of
actually enabling them.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 8039 bytes --]

On Fri, Aug 29, 2014 at 09:23:41AM +0200, Hans de Goede wrote:
> On 08/29/2014 09:01 AM, Thierry Reding wrote:
> > On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
[...]
> >> 2) Tie these resources to simplefb so that the kernel can know when they
> >> are no longer in use, and it may e.g. re-use the memory
> > 
> > For the memory there shouldn't be a problem because it's already in the
> > DT node anyway. It has to be there so that simplefb knows where to write
> > to.
> 
> The memory information currently in the dt node is not complete enough to
> reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
> reg entry only describes the part actually used for the framebuffer.

You can easily fix that.

> >> To me the most logical and also most "correct" way of modelling this is to
> >> put the resources inside the simplefb dt node.
> > 
> > Except that simplefb isn't a real device, so there's a hard time
> > justifying its existence in DT as it is. Claiming resources from a
> > virtual device doesn't sound correct to me at all.
> 
> Yet you want it to claim memory that does not seem consistent to me.

Because it needs to explicitly access that memory. It does not need to
explicitly access the clocks.

> >>>> The key word here is "the used resources" to me this is not about simlefb
> >>>> managing resources, but marking them as used as long as it needs them, like
> >>>> it will need to do for the reserved mem chunk.
> >>>
> >>> The difference between the clocks and the memory resource is that the
> >>> driver needs to directly access the memory (it needs to map it and
> >>> provide a userspace mapping for it) whereas it doesn't need to touch the
> >>> clocks (except to workaround a Linux-specific implementation detail).
> >>
> >> Erm, no, the need to map the memory and the memory being a resource
> >> which may be released are an orthogonal problem. E.g. a system with
> >> dedicated framebuffer memory won't need to use a reserved main-memory
> >> chunk, nor need to worry about returning that mem when simplefb is no
> >> longer in use.
> > 
> > I would think the memory should still be reserved anyway to make sure
> > nothing else is writing over it. And it's in the device tree anyway
> > because the driver needs to know where to put framebuffer content.
> 
> No, the address were to write framebuffer contents currently is in the
> simplefb node, not the actually backing memory info. I can fully see
> some crazy hardware where a chunk of main memory is reserved for some
> funky video engine, and then that chunk of memory gets accessed through
> io-mem addresses for framebuffer access (e.g. the hardware may need this
> to know when the fb is dirtied).

We're drifting off into the realm of hypotheses here. Of course if you
can't make the hardware work with these simple assumptions because it's
too whacky then that's just tough luck.

> > So
> > the point I was trying to make is that we can't treat the memory in the
> > same way as clocks because it needs to be explicitly managed. Whereas
> > clocks don't. The driver is simply too generic to know what to do with
> > the clocks. It doesn't know what frequency they should be running at or
> > what they're used for, so by any definition of what DT should describe
> > they're useless for this virtual device.
> 
> I don't see why you keep insisting that the memory is so special, it is
> just another resource which we need to claim,

It's the only resource which we need to claim. Because it is the only
resource that needs to be explicitly accessed. simplefb is useless if
you don't write to that memory.

>                                               and tie to the simplefb node
> so that it can be re-used (or disabled) when simplefb is no longer used
> (it could e.g. be unbound explicitly on headless systems).

On headless systems the firmware shouldn't be setting up a framebuffer
in the first place.

> > Furthermore it's fairly likely that as your kernel support progresses
> > you'll find that the driver all of a sudden needs to manage some other
> > type of resource that you just haven't needed until now because it may
> > default to being always on. Then you'll have a hard time keeping
> > backwards-compatibility and will have to resort to the kinds of hacks
> > that you don't want to see in the kernel.
> 
> kernel support? This is about u-boot's video code and the simplefb bindings.

And the kernel doesn't need to use the simplefb bindings? Why are we
even having this conversation, then?

> > So it really boils down to the DT needing to describe a complete device
> > with all the dependencies. And just clocks aren't the complete
> > description. But if you want the complete description then you're going
> > to need a complete driver as well and simplefb is out of the picture
> > anyway.
> 
> Yes we eventually need a full kernel driver, with its own bindings, that
> is not what this is about.

It is to some degree. The whole point of simplefb is to provide a useful
graphical output until a full driver is in place. The way to achieve
that is by taking advantage of the firmware setting things up for you.
Which is what I've been saying all along. If the firmware has already
set things up for you, you shouldn't need to do anything special like
enabling clocks because they are already on.

Oh, and let me restate that that's not actually what the patch is doing.
It isn't enabling clocks at all. It's merely a workaround to keep them
running.

> > Once again, the current, basic form of the binding allows for a
> > completely generic implementation of the driver because it makes
> > assumptions about firmware setting things up the right way so that the
> > driver doesn't have to.
> 
> Except that it does not work because it does not claim the necessary
> resources.

Wrong. The reason it doesn't work is because the clock framework
disables the clocks. That's a Linux-specific implementation detail and
therefore shouldn't influence the binding in any way.

> We seem to be at a point where this discussion is just going in circles,
> and since there seems to be no reasonable alternative to the proposed
> solution of adding the clocks to the simplefb node, can you please just
> stop blocking progress on this?

A couple of different solutions to the problem were proposed during the
discussion. It's just that nobody's been willing to take a step back and
look at this from a different perspective.

> Your objection to this has been duly noted,

Right. Ignored is how I would put it.

>                                             but no one is forcing you or
> other people to actually use the clocks property in your implementation
> of simplefb. So if your 101% certain that this is a bad idea, can you
> please just let us (the sunxi people) make our own mistakes and learn
> from those ?

Ugh... This isn't just about letting you make your own mistakes. This is
about solving things in a wrong way (and device specific way) and baking
something into an ABI that really doesn't need to be there. And more
specifically if we let clocks be "managed" by simplefb we can no longer
claim that it is simple and therefore can't block adding all other sorts
of device-specific hacks to it.

> As we actually plan to use the clocks property, we will be
> the ones which will have to deal with any issues.

Wrong. Everyone that potentially wants to use the driver will have to
deal with this.

Anyway, I am getting tired of this whole discussion and as you already
said we're not making any progress. You really should repost this series
to the devicetree mailing list and give people there a chance to look at
the proposed changes. If everybody else is fine with it my objections
will be overruled anyway. I'll just have to sort out/live with the mess
when I want to use simplefb for hand-off.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 09:23:41AM +0200, Hans de Goede wrote:
> On 08/29/2014 09:01 AM, Thierry Reding wrote:
> > On Thu, Aug 28, 2014 at 02:15:40PM +0200, Hans de Goede wrote:
[...]
> >> 2) Tie these resources to simplefb so that the kernel can know when they
> >> are no longer in use, and it may e.g. re-use the memory
> > 
> > For the memory there shouldn't be a problem because it's already in the
> > DT node anyway. It has to be there so that simplefb knows where to write
> > to.
> 
> The memory information currently in the dt node is not complete enough to
> reclaim memory, e.g. the sunxi driver always reserves 8M, but the simplefb
> reg entry only describes the part actually used for the framebuffer.

You can easily fix that.

> >> To me the most logical and also most "correct" way of modelling this is to
> >> put the resources inside the simplefb dt node.
> > 
> > Except that simplefb isn't a real device, so there's a hard time
> > justifying its existence in DT as it is. Claiming resources from a
> > virtual device doesn't sound correct to me at all.
> 
> Yet you want it to claim memory that does not seem consistent to me.

Because it needs to explicitly access that memory. It does not need to
explicitly access the clocks.

> >>>> The key word here is "the used resources" to me this is not about simlefb
> >>>> managing resources, but marking them as used as long as it needs them, like
> >>>> it will need to do for the reserved mem chunk.
> >>>
> >>> The difference between the clocks and the memory resource is that the
> >>> driver needs to directly access the memory (it needs to map it and
> >>> provide a userspace mapping for it) whereas it doesn't need to touch the
> >>> clocks (except to workaround a Linux-specific implementation detail).
> >>
> >> Erm, no, the need to map the memory and the memory being a resource
> >> which may be released are an orthogonal problem. E.g. a system with
> >> dedicated framebuffer memory won't need to use a reserved main-memory
> >> chunk, nor need to worry about returning that mem when simplefb is no
> >> longer in use.
> > 
> > I would think the memory should still be reserved anyway to make sure
> > nothing else is writing over it. And it's in the device tree anyway
> > because the driver needs to know where to put framebuffer content.
> 
> No, the address were to write framebuffer contents currently is in the
> simplefb node, not the actually backing memory info. I can fully see
> some crazy hardware where a chunk of main memory is reserved for some
> funky video engine, and then that chunk of memory gets accessed through
> io-mem addresses for framebuffer access (e.g. the hardware may need this
> to know when the fb is dirtied).

We're drifting off into the realm of hypotheses here. Of course if you
can't make the hardware work with these simple assumptions because it's
too whacky then that's just tough luck.

> > So
> > the point I was trying to make is that we can't treat the memory in the
> > same way as clocks because it needs to be explicitly managed. Whereas
> > clocks don't. The driver is simply too generic to know what to do with
> > the clocks. It doesn't know what frequency they should be running at or
> > what they're used for, so by any definition of what DT should describe
> > they're useless for this virtual device.
> 
> I don't see why you keep insisting that the memory is so special, it is
> just another resource which we need to claim,

It's the only resource which we need to claim. Because it is the only
resource that needs to be explicitly accessed. simplefb is useless if
you don't write to that memory.

>                                               and tie to the simplefb node
> so that it can be re-used (or disabled) when simplefb is no longer used
> (it could e.g. be unbound explicitly on headless systems).

On headless systems the firmware shouldn't be setting up a framebuffer
in the first place.

> > Furthermore it's fairly likely that as your kernel support progresses
> > you'll find that the driver all of a sudden needs to manage some other
> > type of resource that you just haven't needed until now because it may
> > default to being always on. Then you'll have a hard time keeping
> > backwards-compatibility and will have to resort to the kinds of hacks
> > that you don't want to see in the kernel.
> 
> kernel support? This is about u-boot's video code and the simplefb bindings.

And the kernel doesn't need to use the simplefb bindings? Why are we
even having this conversation, then?

> > So it really boils down to the DT needing to describe a complete device
> > with all the dependencies. And just clocks aren't the complete
> > description. But if you want the complete description then you're going
> > to need a complete driver as well and simplefb is out of the picture
> > anyway.
> 
> Yes we eventually need a full kernel driver, with its own bindings, that
> is not what this is about.

It is to some degree. The whole point of simplefb is to provide a useful
graphical output until a full driver is in place. The way to achieve
that is by taking advantage of the firmware setting things up for you.
Which is what I've been saying all along. If the firmware has already
set things up for you, you shouldn't need to do anything special like
enabling clocks because they are already on.

Oh, and let me restate that that's not actually what the patch is doing.
It isn't enabling clocks at all. It's merely a workaround to keep them
running.

> > Once again, the current, basic form of the binding allows for a
> > completely generic implementation of the driver because it makes
> > assumptions about firmware setting things up the right way so that the
> > driver doesn't have to.
> 
> Except that it does not work because it does not claim the necessary
> resources.

Wrong. The reason it doesn't work is because the clock framework
disables the clocks. That's a Linux-specific implementation detail and
therefore shouldn't influence the binding in any way.

> We seem to be at a point where this discussion is just going in circles,
> and since there seems to be no reasonable alternative to the proposed
> solution of adding the clocks to the simplefb node, can you please just
> stop blocking progress on this?

A couple of different solutions to the problem were proposed during the
discussion. It's just that nobody's been willing to take a step back and
look at this from a different perspective.

> Your objection to this has been duly noted,

Right. Ignored is how I would put it.

>                                             but no one is forcing you or
> other people to actually use the clocks property in your implementation
> of simplefb. So if your 101% certain that this is a bad idea, can you
> please just let us (the sunxi people) make our own mistakes and learn
> from those ?

Ugh... This isn't just about letting you make your own mistakes. This is
about solving things in a wrong way (and device specific way) and baking
something into an ABI that really doesn't need to be there. And more
specifically if we let clocks be "managed" by simplefb we can no longer
claim that it is simple and therefore can't block adding all other sorts
of device-specific hacks to it.

> As we actually plan to use the clocks property, we will be
> the ones which will have to deal with any issues.

Wrong. Everyone that potentially wants to use the driver will have to
deal with this.

Anyway, I am getting tired of this whole discussion and as you already
said we're not making any progress. You really should repost this series
to the devicetree mailing list and give people there a chance to look at
the proposed changes. If everybody else is fine with it my objections
will be overruled anyway. I'll just have to sort out/live with the mess
when I want to use simplefb for hand-off.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/50c0b7e1/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> I would think the memory should still be reserved anyway to make sure
> nothing else is writing over it. And it's in the device tree anyway
> because the driver needs to know where to put framebuffer content. So
> the point I was trying to make is that we can't treat the memory in the
> same way as clocks because it needs to be explicitly managed. Whereas
> clocks don't. The driver is simply too generic to know what to do with
> the clocks.

You agreed on the fact that the only thing we need to do with the
clocks is claim them. Really, I don't find what's complicated there
(or not generic).

> It doesn't know what frequency they should be running at

We don't care about that. Just like we don't care about which
frequency is the memory bus running at. It will just run at whatever
frequency is appropriate.

> or what they're used for

And we don't care about that either. You're not interested in what
output the framebuffer is setup to use, which is pretty much the same
here, this is the same thing here.

> so by any definition of what DT should describe they're useless for
> this virtual device.
>
> Furthermore it's fairly likely that as your kernel support progresses
> you'll find that the driver all of a sudden needs to manage some other
> type of resource that you just haven't needed until now because it may
> default to being always on. Then you'll have a hard time keeping
> backwards-compatibility and will have to resort to the kinds of hacks
> that you don't want to see in the kernel.

Not such a hard time. An older DT wouldn't define the new requirements
anyway, so they wouldn't be used, and we would end up in pretty much
the current case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> I would think the memory should still be reserved anyway to make sure
> nothing else is writing over it. And it's in the device tree anyway
> because the driver needs to know where to put framebuffer content. So
> the point I was trying to make is that we can't treat the memory in the
> same way as clocks because it needs to be explicitly managed. Whereas
> clocks don't. The driver is simply too generic to know what to do with
> the clocks.

You agreed on the fact that the only thing we need to do with the
clocks is claim them. Really, I don't find what's complicated there
(or not generic).

> It doesn't know what frequency they should be running at

We don't care about that. Just like we don't care about which
frequency is the memory bus running at. It will just run at whatever
frequency is appropriate.

> or what they're used for

And we don't care about that either. You're not interested in what
output the framebuffer is setup to use, which is pretty much the same
here, this is the same thing here.

> so by any definition of what DT should describe they're useless for
> this virtual device.
>
> Furthermore it's fairly likely that as your kernel support progresses
> you'll find that the driver all of a sudden needs to manage some other
> type of resource that you just haven't needed until now because it may
> default to being always on. Then you'll have a hard time keeping
> backwards-compatibility and will have to resort to the kinds of hacks
> that you don't want to see in the kernel.

Not such a hard time. An older DT wouldn't define the new requirements
anyway, so they wouldn't be used, and we would end up in pretty much
the current case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/bd8b3639/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > I would think the memory should still be reserved anyway to make sure
> > nothing else is writing over it. And it's in the device tree anyway
> > because the driver needs to know where to put framebuffer content. So
> > the point I was trying to make is that we can't treat the memory in the
> > same way as clocks because it needs to be explicitly managed. Whereas
> > clocks don't. The driver is simply too generic to know what to do with
> > the clocks.
> 
> You agreed on the fact that the only thing we need to do with the
> clocks is claim them. Really, I don't find what's complicated there
> (or not generic).

That's not what I agreed on. What I said is that the only thing we need
to do with the clocks is nothing. They are already in the state that
they need to be.

> > It doesn't know what frequency they should be running at
> 
> We don't care about that. Just like we don't care about which
> frequency is the memory bus running at. It will just run at whatever
> frequency is appropriate.

Exactly. And you shouldn't have to care about them at all. Firmware has
already configured the clocks to run at the correct frequencies, and it
has made sure that they are enabled.

> > or what they're used for
> 
> And we don't care about that either. You're not interested in what
> output the framebuffer is setup to use, which is pretty much the same
> here, this is the same thing here.

That's precisely what I've been saying. The only thing that simplefb
cares about is the memory it should be using and the format of the
pixels (and how many of them) it writes into that memory. Everything
else is assumed to have been set up.

Including clocks.

> > so by any definition of what DT should describe they're useless for
> > this virtual device.
> >
> > Furthermore it's fairly likely that as your kernel support progresses
> > you'll find that the driver all of a sudden needs to manage some other
> > type of resource that you just haven't needed until now because it may
> > default to being always on. Then you'll have a hard time keeping
> > backwards-compatibility and will have to resort to the kinds of hacks
> > that you don't want to see in the kernel.
> 
> Not such a hard time. An older DT wouldn't define the new requirements
> anyway, so they wouldn't be used, and we would end up in pretty much
> the current case.

Except that you have firmware in the wild that sets up an incomplete
simplefb node and if you don't want to break compatibility you need to
provide fallbacks for the resources that aren't listed in the DT node.
And given that those fallbacks are all very board specific you'll need
to find ways to keep them enabled if you want to keep existing setups
working.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > I would think the memory should still be reserved anyway to make sure
> > nothing else is writing over it. And it's in the device tree anyway
> > because the driver needs to know where to put framebuffer content. So
> > the point I was trying to make is that we can't treat the memory in the
> > same way as clocks because it needs to be explicitly managed. Whereas
> > clocks don't. The driver is simply too generic to know what to do with
> > the clocks.
> 
> You agreed on the fact that the only thing we need to do with the
> clocks is claim them. Really, I don't find what's complicated there
> (or not generic).

That's not what I agreed on. What I said is that the only thing we need
to do with the clocks is nothing. They are already in the state that
they need to be.

> > It doesn't know what frequency they should be running at
> 
> We don't care about that. Just like we don't care about which
> frequency is the memory bus running at. It will just run at whatever
> frequency is appropriate.

Exactly. And you shouldn't have to care about them at all. Firmware has
already configured the clocks to run at the correct frequencies, and it
has made sure that they are enabled.

> > or what they're used for
> 
> And we don't care about that either. You're not interested in what
> output the framebuffer is setup to use, which is pretty much the same
> here, this is the same thing here.

That's precisely what I've been saying. The only thing that simplefb
cares about is the memory it should be using and the format of the
pixels (and how many of them) it writes into that memory. Everything
else is assumed to have been set up.

Including clocks.

> > so by any definition of what DT should describe they're useless for
> > this virtual device.
> >
> > Furthermore it's fairly likely that as your kernel support progresses
> > you'll find that the driver all of a sudden needs to manage some other
> > type of resource that you just haven't needed until now because it may
> > default to being always on. Then you'll have a hard time keeping
> > backwards-compatibility and will have to resort to the kinds of hacks
> > that you don't want to see in the kernel.
> 
> Not such a hard time. An older DT wouldn't define the new requirements
> anyway, so they wouldn't be used, and we would end up in pretty much
> the current case.

Except that you have firmware in the wild that sets up an incomplete
simplefb node and if you don't want to break compatibility you need to
provide fallbacks for the resources that aren't listed in the DT node.
And given that those fallbacks are all very board specific you'll need
to find ways to keep them enabled if you want to keep existing setups
working.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/d35e608e/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 August 2014 16:38, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > I would think the memory should still be reserved anyway to make sure
>> > nothing else is writing over it. And it's in the device tree anyway
>> > because the driver needs to know where to put framebuffer content. So
>> > the point I was trying to make is that we can't treat the memory in the
>> > same way as clocks because it needs to be explicitly managed. Whereas
>> > clocks don't. The driver is simply too generic to know what to do with
>> > the clocks.
>>
>> You agreed on the fact that the only thing we need to do with the
>> clocks is claim them. Really, I don't find what's complicated there
>> (or not generic).
>
> That's not what I agreed on. What I said is that the only thing we need
> to do with the clocks is nothing. They are already in the state that
> they need to be.
>
>> > It doesn't know what frequency they should be running at
>>
>> We don't care about that. Just like we don't care about which
>> frequency is the memory bus running at. It will just run at whatever
>> frequency is appropriate.
>
> Exactly. And you shouldn't have to care about them at all. Firmware has
> already configured the clocks to run at the correct frequencies, and it
> has made sure that they are enabled.
>
>> > or what they're used for
>>
>> And we don't care about that either. You're not interested in what
>> output the framebuffer is setup to use, which is pretty much the same
>> here, this is the same thing here.
>
> That's precisely what I've been saying. The only thing that simplefb
> cares about is the memory it should be using and the format of the
> pixels (and how many of them) it writes into that memory. Everything
> else is assumed to have been set up.
>
> Including clocks.

And for simplefb to work it should claim the memory and clock so that
nothing else in the kernel uses them or reclaims them as unused. That
currently the memory is reserved by excluding it from memory usable by
the kernel is a hack, not proper resource management. And so is
keeping all clocks enabled in case something used them.

>
>> > so by any definition of what DT should describe they're useless for
>> > this virtual device.
>> >
>> > Furthermore it's fairly likely that as your kernel support progresses
>> > you'll find that the driver all of a sudden needs to manage some other
>> > type of resource that you just haven't needed until now because it may
>> > default to being always on. Then you'll have a hard time keeping
>> > backwards-compatibility and will have to resort to the kinds of hacks
>> > that you don't want to see in the kernel.
>>
>> Not such a hard time. An older DT wouldn't define the new requirements
>> anyway, so they wouldn't be used, and we would end up in pretty much
>> the current case.
>
> Except that you have firmware in the wild that sets up an incomplete
> simplefb node and if you don't want to break compatibility you need to
> provide fallbacks for the resources that aren't listed in the DT node.
> And given that those fallbacks are all very board specific you'll need
> to find ways to keep them enabled if you want to keep existing setups
> working.
>

Except in this case either the simplefb does not need clocks the user
had to set up the kernel argument to not disable unused clocks so the
user of such firmware is well aware of that limitation.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 August 2014 16:38, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > I would think the memory should still be reserved anyway to make sure
>> > nothing else is writing over it. And it's in the device tree anyway
>> > because the driver needs to know where to put framebuffer content. So
>> > the point I was trying to make is that we can't treat the memory in the
>> > same way as clocks because it needs to be explicitly managed. Whereas
>> > clocks don't. The driver is simply too generic to know what to do with
>> > the clocks.
>>
>> You agreed on the fact that the only thing we need to do with the
>> clocks is claim them. Really, I don't find what's complicated there
>> (or not generic).
>
> That's not what I agreed on. What I said is that the only thing we need
> to do with the clocks is nothing. They are already in the state that
> they need to be.
>
>> > It doesn't know what frequency they should be running at
>>
>> We don't care about that. Just like we don't care about which
>> frequency is the memory bus running at. It will just run at whatever
>> frequency is appropriate.
>
> Exactly. And you shouldn't have to care about them at all. Firmware has
> already configured the clocks to run at the correct frequencies, and it
> has made sure that they are enabled.
>
>> > or what they're used for
>>
>> And we don't care about that either. You're not interested in what
>> output the framebuffer is setup to use, which is pretty much the same
>> here, this is the same thing here.
>
> That's precisely what I've been saying. The only thing that simplefb
> cares about is the memory it should be using and the format of the
> pixels (and how many of them) it writes into that memory. Everything
> else is assumed to have been set up.
>
> Including clocks.

And for simplefb to work it should claim the memory and clock so that
nothing else in the kernel uses them or reclaims them as unused. That
currently the memory is reserved by excluding it from memory usable by
the kernel is a hack, not proper resource management. And so is
keeping all clocks enabled in case something used them.

>
>> > so by any definition of what DT should describe they're useless for
>> > this virtual device.
>> >
>> > Furthermore it's fairly likely that as your kernel support progresses
>> > you'll find that the driver all of a sudden needs to manage some other
>> > type of resource that you just haven't needed until now because it may
>> > default to being always on. Then you'll have a hard time keeping
>> > backwards-compatibility and will have to resort to the kinds of hacks
>> > that you don't want to see in the kernel.
>>
>> Not such a hard time. An older DT wouldn't define the new requirements
>> anyway, so they wouldn't be used, and we would end up in pretty much
>> the current case.
>
> Except that you have firmware in the wild that sets up an incomplete
> simplefb node and if you don't want to break compatibility you need to
> provide fallbacks for the resources that aren't listed in the DT node.
> And given that those fallbacks are all very board specific you'll need
> to find ways to keep them enabled if you want to keep existing setups
> working.
>

Except in this case either the simplefb does not need clocks the user
had to set up the kernel argument to not disable unused clocks so the
user of such firmware is well aware of that limitation.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]

On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > I would think the memory should still be reserved anyway to make sure
> > > nothing else is writing over it. And it's in the device tree anyway
> > > because the driver needs to know where to put framebuffer content. So
> > > the point I was trying to make is that we can't treat the memory in the
> > > same way as clocks because it needs to be explicitly managed. Whereas
> > > clocks don't. The driver is simply too generic to know what to do with
> > > the clocks.
> > 
> > You agreed on the fact that the only thing we need to do with the
> > clocks is claim them. Really, I don't find what's complicated there
> > (or not generic).
> 
> That's not what I agreed on. What I said is that the only thing we need
> to do with the clocks is nothing. They are already in the state that
> they need to be.

Claim was probably a poor choice of words, but still. We have to keep
the clock running, and both the solution you've been giving and this
patch do so in a generic way.

> > > It doesn't know what frequency they should be running at
> > 
> > We don't care about that. Just like we don't care about which
> > frequency is the memory bus running at. It will just run at whatever
> > frequency is appropriate.
> 
> Exactly. And you shouldn't have to care about them at all. Firmware has
> already configured the clocks to run at the correct frequencies, and it
> has made sure that they are enabled.
> 
> > > or what they're used for
> > 
> > And we don't care about that either. You're not interested in what
> > output the framebuffer is setup to use, which is pretty much the same
> > here, this is the same thing here.
> 
> That's precisely what I've been saying. The only thing that simplefb
> cares about is the memory it should be using and the format of the
> pixels (and how many of them) it writes into that memory. Everything
> else is assumed to have been set up.
> 
> Including clocks.

We're really discussing in circles here.

Mike?

Your opinion would be very valuable.

> > > so by any definition of what DT should describe they're useless for
> > > this virtual device.
> > >
> > > Furthermore it's fairly likely that as your kernel support progresses
> > > you'll find that the driver all of a sudden needs to manage some other
> > > type of resource that you just haven't needed until now because it may
> > > default to being always on. Then you'll have a hard time keeping
> > > backwards-compatibility and will have to resort to the kinds of hacks
> > > that you don't want to see in the kernel.
> > 
> > Not such a hard time. An older DT wouldn't define the new requirements
> > anyway, so they wouldn't be used, and we would end up in pretty much
> > the current case.
> 
> Except that you have firmware in the wild that sets up an incomplete
> simplefb node and if you don't want to break compatibility you need to
> provide fallbacks for the resources that aren't listed in the DT node.
> And given that those fallbacks are all very board specific you'll need
> to find ways to keep them enabled if you want to keep existing setups
> working.

How would an *optional* property break those users?

If you don't need any clock to be kept running (or are hiding them
under the carpet), of course you don't need such a property.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > I would think the memory should still be reserved anyway to make sure
> > > nothing else is writing over it. And it's in the device tree anyway
> > > because the driver needs to know where to put framebuffer content. So
> > > the point I was trying to make is that we can't treat the memory in the
> > > same way as clocks because it needs to be explicitly managed. Whereas
> > > clocks don't. The driver is simply too generic to know what to do with
> > > the clocks.
> > 
> > You agreed on the fact that the only thing we need to do with the
> > clocks is claim them. Really, I don't find what's complicated there
> > (or not generic).
> 
> That's not what I agreed on. What I said is that the only thing we need
> to do with the clocks is nothing. They are already in the state that
> they need to be.

Claim was probably a poor choice of words, but still. We have to keep
the clock running, and both the solution you've been giving and this
patch do so in a generic way.

> > > It doesn't know what frequency they should be running at
> > 
> > We don't care about that. Just like we don't care about which
> > frequency is the memory bus running at. It will just run at whatever
> > frequency is appropriate.
> 
> Exactly. And you shouldn't have to care about them at all. Firmware has
> already configured the clocks to run at the correct frequencies, and it
> has made sure that they are enabled.
> 
> > > or what they're used for
> > 
> > And we don't care about that either. You're not interested in what
> > output the framebuffer is setup to use, which is pretty much the same
> > here, this is the same thing here.
> 
> That's precisely what I've been saying. The only thing that simplefb
> cares about is the memory it should be using and the format of the
> pixels (and how many of them) it writes into that memory. Everything
> else is assumed to have been set up.
> 
> Including clocks.

We're really discussing in circles here.

Mike?

Your opinion would be very valuable.

> > > so by any definition of what DT should describe they're useless for
> > > this virtual device.
> > >
> > > Furthermore it's fairly likely that as your kernel support progresses
> > > you'll find that the driver all of a sudden needs to manage some other
> > > type of resource that you just haven't needed until now because it may
> > > default to being always on. Then you'll have a hard time keeping
> > > backwards-compatibility and will have to resort to the kinds of hacks
> > > that you don't want to see in the kernel.
> > 
> > Not such a hard time. An older DT wouldn't define the new requirements
> > anyway, so they wouldn't be used, and we would end up in pretty much
> > the current case.
> 
> Except that you have firmware in the wild that sets up an incomplete
> simplefb node and if you don't want to break compatibility you need to
> provide fallbacks for the resources that aren't listed in the DT node.
> And given that those fallbacks are all very board specific you'll need
> to find ways to keep them enabled if you want to keep existing setups
> working.

How would an *optional* property break those users?

If you don't need any clock to be kept running (or are hiding them
under the carpet), of course you don't need such a property.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140902/6a77288d/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

Quoting Maxime Ripard (2014-09-02 02:25:08)
> On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > I would think the memory should still be reserved anyway to make sure
> > > > nothing else is writing over it. And it's in the device tree anyway
> > > > because the driver needs to know where to put framebuffer content. So
> > > > the point I was trying to make is that we can't treat the memory in the
> > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > clocks don't. The driver is simply too generic to know what to do with
> > > > the clocks.
> > > 
> > > You agreed on the fact that the only thing we need to do with the
> > > clocks is claim them. Really, I don't find what's complicated there
> > > (or not generic).
> > 
> > That's not what I agreed on. What I said is that the only thing we need
> > to do with the clocks is nothing. They are already in the state that
> > they need to be.
> 
> Claim was probably a poor choice of words, but still. We have to keep
> the clock running, and both the solution you've been giving and this
> patch do so in a generic way.
> 
> > > > It doesn't know what frequency they should be running at
> > > 
> > > We don't care about that. Just like we don't care about which
> > > frequency is the memory bus running at. It will just run at whatever
> > > frequency is appropriate.
> > 
> > Exactly. And you shouldn't have to care about them at all. Firmware has
> > already configured the clocks to run at the correct frequencies, and it
> > has made sure that they are enabled.
> > 
> > > > or what they're used for
> > > 
> > > And we don't care about that either. You're not interested in what
> > > output the framebuffer is setup to use, which is pretty much the same
> > > here, this is the same thing here.
> > 
> > That's precisely what I've been saying. The only thing that simplefb
> > cares about is the memory it should be using and the format of the
> > pixels (and how many of them) it writes into that memory. Everything
> > else is assumed to have been set up.
> > 
> > Including clocks.
> 
> We're really discussing in circles here.
> 
> Mike?
> 

-EHIGHLATENCYRESPONSE

I forgot about this thread. Sorry.

In an attempt to provide the least helpful answer possible, I will stay
clear of all of the stuff relating to "how simple should simplefb be"
and the related reserved memory discussion.

A few times in this thread it is stated that we can't prevent unused
clocks from being disabled. That is only partially true.

The clock framework DOES provide a flag to prevent UNUSED clocks from
being disabled at late_initcall-time by a clock "garbage collector"
mechanism. Maxime and others familiar with the clock framework are aware
of this.

What the framework doesn't do is to allow for a magic flag in DT, in
platform_data or elsewhere that says, "don't let me get turned off until
the right driver claims me". That would be an external or alternative
method for preventing a clock from being disabled. We have a method for
preventing clocks from being disabled. It is as follows:

struct clk *my_clk = clk_get(...);
clk_prepare_enable(my_clk);

That is how it should be done. Period.

With that said I think that Luc's approach is very sensible. I'm not
sure what purpose in the universe DT is supposed to serve if not for
_this_exact_case_. We have a nice abstracted driver, usable by many
people. The hardware details of how it is hooked up at the board level
can all be hidden behind stable DT bindings that everyone already uses.

What more could you want?

Regards,
Mike

> Your opinion would be very valuable.
> 
> > > > so by any definition of what DT should describe they're useless for
> > > > this virtual device.
> > > >
> > > > Furthermore it's fairly likely that as your kernel support progresses
> > > > you'll find that the driver all of a sudden needs to manage some other
> > > > type of resource that you just haven't needed until now because it may
> > > > default to being always on. Then you'll have a hard time keeping
> > > > backwards-compatibility and will have to resort to the kinds of hacks
> > > > that you don't want to see in the kernel.
> > > 
> > > Not such a hard time. An older DT wouldn't define the new requirements
> > > anyway, so they wouldn't be used, and we would end up in pretty much
> > > the current case.
> > 
> > Except that you have firmware in the wild that sets up an incomplete
> > simplefb node and if you don't want to break compatibility you need to
> > provide fallbacks for the resources that aren't listed in the DT node.
> > And given that those fallbacks are all very board specific you'll need
> > to find ways to keep them enabled if you want to keep existing setups
> > working.
> 
> How would an *optional* property break those users?
> 
> If you don't need any clock to be kept running (or are hiding them
> under the carpet), of course you don't need such a property.
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

Quoting Maxime Ripard (2014-09-02 02:25:08)
> On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > I would think the memory should still be reserved anyway to make sure
> > > > nothing else is writing over it. And it's in the device tree anyway
> > > > because the driver needs to know where to put framebuffer content. So
> > > > the point I was trying to make is that we can't treat the memory in the
> > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > clocks don't. The driver is simply too generic to know what to do with
> > > > the clocks.
> > > 
> > > You agreed on the fact that the only thing we need to do with the
> > > clocks is claim them. Really, I don't find what's complicated there
> > > (or not generic).
> > 
> > That's not what I agreed on. What I said is that the only thing we need
> > to do with the clocks is nothing. They are already in the state that
> > they need to be.
> 
> Claim was probably a poor choice of words, but still. We have to keep
> the clock running, and both the solution you've been giving and this
> patch do so in a generic way.
> 
> > > > It doesn't know what frequency they should be running at
> > > 
> > > We don't care about that. Just like we don't care about which
> > > frequency is the memory bus running at. It will just run at whatever
> > > frequency is appropriate.
> > 
> > Exactly. And you shouldn't have to care about them at all. Firmware has
> > already configured the clocks to run at the correct frequencies, and it
> > has made sure that they are enabled.
> > 
> > > > or what they're used for
> > > 
> > > And we don't care about that either. You're not interested in what
> > > output the framebuffer is setup to use, which is pretty much the same
> > > here, this is the same thing here.
> > 
> > That's precisely what I've been saying. The only thing that simplefb
> > cares about is the memory it should be using and the format of the
> > pixels (and how many of them) it writes into that memory. Everything
> > else is assumed to have been set up.
> > 
> > Including clocks.
> 
> We're really discussing in circles here.
> 
> Mike?
> 

-EHIGHLATENCYRESPONSE

I forgot about this thread. Sorry.

In an attempt to provide the least helpful answer possible, I will stay
clear of all of the stuff relating to "how simple should simplefb be"
and the related reserved memory discussion.

A few times in this thread it is stated that we can't prevent unused
clocks from being disabled. That is only partially true.

The clock framework DOES provide a flag to prevent UNUSED clocks from
being disabled at late_initcall-time by a clock "garbage collector"
mechanism. Maxime and others familiar with the clock framework are aware
of this.

What the framework doesn't do is to allow for a magic flag in DT, in
platform_data or elsewhere that says, "don't let me get turned off until
the right driver claims me". That would be an external or alternative
method for preventing a clock from being disabled. We have a method for
preventing clocks from being disabled. It is as follows:

struct clk *my_clk = clk_get(...);
clk_prepare_enable(my_clk);

That is how it should be done. Period.

With that said I think that Luc's approach is very sensible. I'm not
sure what purpose in the universe DT is supposed to serve if not for
_this_exact_case_. We have a nice abstracted driver, usable by many
people. The hardware details of how it is hooked up at the board level
can all be hidden behind stable DT bindings that everyone already uses.

What more could you want?

Regards,
Mike

> Your opinion would be very valuable.
> 
> > > > so by any definition of what DT should describe they're useless for
> > > > this virtual device.
> > > >
> > > > Furthermore it's fairly likely that as your kernel support progresses
> > > > you'll find that the driver all of a sudden needs to manage some other
> > > > type of resource that you just haven't needed until now because it may
> > > > default to being always on. Then you'll have a hard time keeping
> > > > backwards-compatibility and will have to resort to the kinds of hacks
> > > > that you don't want to see in the kernel.
> > > 
> > > Not such a hard time. An older DT wouldn't define the new requirements
> > > anyway, so they wouldn't be used, and we would end up in pretty much
> > > the current case.
> > 
> > Except that you have firmware in the wild that sets up an incomplete
> > simplefb node and if you don't want to break compatibility you need to
> > provide fallbacks for the resources that aren't listed in the DT node.
> > And given that those fallbacks are all very board specific you'll need
> > to find ways to keep them enabled if you want to keep existing setups
> > working.
> 
> How would an *optional* property break those users?
> 
> If you don't need any clock to be kept running (or are hiding them
> under the carpet), of course you don't need such a property.
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 6679 bytes --]

On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-09-02 02:25:08)
> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > I would think the memory should still be reserved anyway to make sure
> > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > because the driver needs to know where to put framebuffer content. So
> > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > the clocks.
> > > > 
> > > > You agreed on the fact that the only thing we need to do with the
> > > > clocks is claim them. Really, I don't find what's complicated there
> > > > (or not generic).
> > > 
> > > That's not what I agreed on. What I said is that the only thing we need
> > > to do with the clocks is nothing. They are already in the state that
> > > they need to be.
> > 
> > Claim was probably a poor choice of words, but still. We have to keep
> > the clock running, and both the solution you've been giving and this
> > patch do so in a generic way.
> > 
> > > > > It doesn't know what frequency they should be running at
> > > > 
> > > > We don't care about that. Just like we don't care about which
> > > > frequency is the memory bus running at. It will just run at whatever
> > > > frequency is appropriate.
> > > 
> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > already configured the clocks to run at the correct frequencies, and it
> > > has made sure that they are enabled.
> > > 
> > > > > or what they're used for
> > > > 
> > > > And we don't care about that either. You're not interested in what
> > > > output the framebuffer is setup to use, which is pretty much the same
> > > > here, this is the same thing here.
> > > 
> > > That's precisely what I've been saying. The only thing that simplefb
> > > cares about is the memory it should be using and the format of the
> > > pixels (and how many of them) it writes into that memory. Everything
> > > else is assumed to have been set up.
> > > 
> > > Including clocks.
> > 
> > We're really discussing in circles here.
> > 
> > Mike?
> > 
> 
> -EHIGHLATENCYRESPONSE
> 
> I forgot about this thread. Sorry.
> 
> In an attempt to provide the least helpful answer possible, I will stay
> clear of all of the stuff relating to "how simple should simplefb be"
> and the related reserved memory discussion.
> 
> A few times in this thread it is stated that we can't prevent unused
> clocks from being disabled. That is only partially true.
> 
> The clock framework DOES provide a flag to prevent UNUSED clocks from
> being disabled at late_initcall-time by a clock "garbage collector"
> mechanism. Maxime and others familiar with the clock framework are aware
> of this.
> 
> What the framework doesn't do is to allow for a magic flag in DT, in
> platform_data or elsewhere that says, "don't let me get turned off until
> the right driver claims me". That would be an external or alternative
> method for preventing a clock from being disabled. We have a method for
> preventing clocks from being disabled. It is as follows:
> 
> struct clk *my_clk = clk_get(...);
> clk_prepare_enable(my_clk);
> 
> That is how it should be done. Period.
> 
> With that said I think that Luc's approach is very sensible. I'm not
> sure what purpose in the universe DT is supposed to serve if not for
> _this_exact_case_. We have a nice abstracted driver, usable by many
> people. The hardware details of how it is hooked up at the board level
> can all be hidden behind stable DT bindings that everyone already uses.

simplefb doesn't deal at all with hardware details. It simply uses what
firmware has set up, which is the only reason why it will work for many
people. What is passed in via its device tree node is the minimum amount
of information needed to draw something into the framebuffer. Also note
that the simplefb device tree node is not statically added to a DTS file
but needs to be dynamically generated by firmware at runtime.

If we start extending the binding with board-level details we end up
duplicating the device tree node for the proper video device. Also note
that it won't stop at clocks. Other setups will require regulators to be
listed in this device tree node as well so that they don't get disabled
at late_initcall. And the regulator bindings don't provide a method to
list an arbitrary number of clocks in a single property in the way that
the clocks property works.

There may be also resets involved. Fortunately the reset framework is
minimalistic enough not to care about asserting all unused resets at
late_initcall. And other things like power domains may also need to be
kept on.

Passing in clock information via the device tree already requires a non-
trivial amount of code in the firmware. A similar amount of code would
be necessary for each type of resource that needs to be kept enabled. In
addition to the above some devices may also require resources that have
no generic bindings. That just doesn't scale.

The only reasonable thing for simplefb to do is not deal with any kind
of resource at all (except perhaps area that contains the framebuffer
memory).

So how about instead of requiring resources to be explicitly claimed we
introduce something like the below patch? The intention being to give
"firmware device" drivers a way of signalling to the clock framework
that they need rely on clocks set up by firmware and when they no longer
need them. This implements essentially what Mark (CC'ing again on this
subthread) suggested earlier in this thread. Basically, it will allow
drivers to determine the time when unused clocks are really unused. It
will of course only work when used correctly by drivers. For the case of
simplefb I'd expect its .probe() implementation to call the new
clk_ignore_unused() function and once it has handed over control of the
display hardware to the real driver it can call clk_unignore_unused() to
signal that all unused clocks that it cares about have now been claimed.
This is "reference counted" and can therefore be used by more than a
single driver if necessary. Similar functionality could be added for
other resource subsystems as needed.

Thierry

[-- Attachment #1.2: 0001-clk-Allow-drivers-to-reference-unused-clocks.patch --]
[-- Type: text/x-diff, Size: 5397 bytes --]

From 5e2521feab41b71fc80b1b41d4eb6ec967919eed Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Mon, 29 Sep 2014 08:10:49 +0200
Subject: [PATCH] clk: Allow drivers to reference unused clocks

Some drivers are designed to take over a virtual device set up at boot
time by firmware. This can be useful for early boot output on a display
device when no debug serial console is available or for transitioning
from firmware to the Linux kernel in a seemless way.

This type of driver relies on firmware to have set up hardware in a way
that it can scan out a framebuffer using the display hardware. Some of
the resources used by the display hardware (clocks, power supplies, ...)
will typically be turned off (at late_initcall time) by the respective
Linux kernel subsystems unless explicitly claimed by some hardware-
specific driver. However, if this driver is built as a module (loaded
from a filesystem) or defer probing, they will not claim the resources
until long after late_initcall time. This doesn't allow for a seemless
transition.

It can also happen that the hardware-specific driver is never loaded. It
may be that no such driver exists, or it fails to load. Users may even
decide not to load it on purpose, perhaps because it is buggy. Instead
of turning the display off in such cases, a better option is to keep
running with the existing framebuffer, which may also be helpful in
diagnosing why the real driver wasn't loaded.

This patch provides a way for drivers that make use of clocks set up by
firmware to prevent clocks from being automatically disabled. Similarly
a way is provided to signal that they no longer need the clocks (when
the hardware-specific driver has taken over for example).

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/clk/clk.c   | 58 +++++++++++++++++++++++++++++++++++------------------
 include/linux/clk.h | 26 ++++++++++++++++++++++++
 2 files changed, 65 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 52d58279a612..2007f10e244c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -486,38 +486,58 @@ out:
 	return;
 }
 
-static bool clk_ignore_unused;
-static int __init clk_ignore_unused_setup(char *__unused)
+static unsigned long clk_ignore_unused_count = 1;
+
+void clk_ignore_unused(void)
 {
-	clk_ignore_unused = true;
-	return 1;
+	clk_prepare_lock();
+
+	if (clk_ignore_unused_count == 0)
+		pr_warn("clk: unused clocks already disabled\n");
+	else
+		clk_ignore_unused_count++;
+
+	clk_prepare_unlock();
 }
-__setup("clk_ignore_unused", clk_ignore_unused_setup);
 
-static int clk_disable_unused(void)
+void clk_unignore_unused(void)
 {
 	struct clk *clk;
 
-	if (clk_ignore_unused) {
-		pr_warn("clk: Not disabling unused clocks\n");
-		return 0;
-	}
-
 	clk_prepare_lock();
 
-	hlist_for_each_entry(clk, &clk_root_list, child_node)
-		clk_disable_unused_subtree(clk);
+	if (--clk_ignore_unused_count == 0) {
+		hlist_for_each_entry(clk, &clk_root_list, child_node)
+			clk_disable_unused_subtree(clk);
 
-	hlist_for_each_entry(clk, &clk_orphan_list, child_node)
-		clk_disable_unused_subtree(clk);
+		hlist_for_each_entry(clk, &clk_orphan_list, child_node)
+			clk_disable_unused_subtree(clk);
 
-	hlist_for_each_entry(clk, &clk_root_list, child_node)
-		clk_unprepare_unused_subtree(clk);
+		hlist_for_each_entry(clk, &clk_root_list, child_node)
+			clk_unprepare_unused_subtree(clk);
 
-	hlist_for_each_entry(clk, &clk_orphan_list, child_node)
-		clk_unprepare_unused_subtree(clk);
+		hlist_for_each_entry(clk, &clk_orphan_list, child_node)
+			clk_unprepare_unused_subtree(clk);
+	}
 
 	clk_prepare_unlock();
+}
+
+static int __init clk_ignore_unused_setup(char *__unused)
+{
+	clk_ignore_unused();
+	return 1;
+}
+__setup("clk_ignore_unused", clk_ignore_unused_setup);
+
+static int clk_disable_unused(void)
+{
+	clk_unignore_unused();
+
+	if (clk_ignore_unused_count > 0) {
+		pr_warn("clk: Not disabling unused clocks\n");
+		return 0;
+	}
 
 	return 0;
 }
diff --git a/include/linux/clk.h b/include/linux/clk.h
index afb44bfaf8d1..b587f2b2f2f5 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -106,6 +106,24 @@ int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb);
  */
 long clk_get_accuracy(struct clk *clk);
 
+/**
+ * clk_ignore_unused - request that unused clocks be kept running
+ *
+ * This function can be used by drivers to request that unused clocks are kept
+ * running. It is useful for drivers that take over hardware previously set up
+ * by firmware and which may not explicitly claim all clocks.
+ */
+void clk_ignore_unused(void);
+
+/**
+ * clk_unignore_unused - release unused clocks
+ *
+ * Use this function to undo the effects of clk_ignore_unused(). It is meant
+ * to be called by drivers for firmware devices after they've handed off the
+ * device to a proper hardware-specific driver.
+ */
+void clk_unignore_unused(void);
+
 #else
 
 static inline long clk_get_accuracy(struct clk *clk)
@@ -113,6 +131,14 @@ static inline long clk_get_accuracy(struct clk *clk)
 	return -ENOTSUPP;
 }
 
+static inline void clk_ignore_unused(void)
+{
+}
+
+static inline void clk_unignore_unused(void)
+{
+}
+
 #endif
 
 /**
-- 
2.1.0


[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-09-02 02:25:08)
> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > I would think the memory should still be reserved anyway to make sure
> > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > because the driver needs to know where to put framebuffer content. So
> > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > the clocks.
> > > > 
> > > > You agreed on the fact that the only thing we need to do with the
> > > > clocks is claim them. Really, I don't find what's complicated there
> > > > (or not generic).
> > > 
> > > That's not what I agreed on. What I said is that the only thing we need
> > > to do with the clocks is nothing. They are already in the state that
> > > they need to be.
> > 
> > Claim was probably a poor choice of words, but still. We have to keep
> > the clock running, and both the solution you've been giving and this
> > patch do so in a generic way.
> > 
> > > > > It doesn't know what frequency they should be running at
> > > > 
> > > > We don't care about that. Just like we don't care about which
> > > > frequency is the memory bus running at. It will just run at whatever
> > > > frequency is appropriate.
> > > 
> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > already configured the clocks to run at the correct frequencies, and it
> > > has made sure that they are enabled.
> > > 
> > > > > or what they're used for
> > > > 
> > > > And we don't care about that either. You're not interested in what
> > > > output the framebuffer is setup to use, which is pretty much the same
> > > > here, this is the same thing here.
> > > 
> > > That's precisely what I've been saying. The only thing that simplefb
> > > cares about is the memory it should be using and the format of the
> > > pixels (and how many of them) it writes into that memory. Everything
> > > else is assumed to have been set up.
> > > 
> > > Including clocks.
> > 
> > We're really discussing in circles here.
> > 
> > Mike?
> > 
> 
> -EHIGHLATENCYRESPONSE
> 
> I forgot about this thread. Sorry.
> 
> In an attempt to provide the least helpful answer possible, I will stay
> clear of all of the stuff relating to "how simple should simplefb be"
> and the related reserved memory discussion.
> 
> A few times in this thread it is stated that we can't prevent unused
> clocks from being disabled. That is only partially true.
> 
> The clock framework DOES provide a flag to prevent UNUSED clocks from
> being disabled at late_initcall-time by a clock "garbage collector"
> mechanism. Maxime and others familiar with the clock framework are aware
> of this.
> 
> What the framework doesn't do is to allow for a magic flag in DT, in
> platform_data or elsewhere that says, "don't let me get turned off until
> the right driver claims me". That would be an external or alternative
> method for preventing a clock from being disabled. We have a method for
> preventing clocks from being disabled. It is as follows:
> 
> struct clk *my_clk = clk_get(...);
> clk_prepare_enable(my_clk);
> 
> That is how it should be done. Period.
> 
> With that said I think that Luc's approach is very sensible. I'm not
> sure what purpose in the universe DT is supposed to serve if not for
> _this_exact_case_. We have a nice abstracted driver, usable by many
> people. The hardware details of how it is hooked up at the board level
> can all be hidden behind stable DT bindings that everyone already uses.

simplefb doesn't deal at all with hardware details. It simply uses what
firmware has set up, which is the only reason why it will work for many
people. What is passed in via its device tree node is the minimum amount
of information needed to draw something into the framebuffer. Also note
that the simplefb device tree node is not statically added to a DTS file
but needs to be dynamically generated by firmware at runtime.

If we start extending the binding with board-level details we end up
duplicating the device tree node for the proper video device. Also note
that it won't stop at clocks. Other setups will require regulators to be
listed in this device tree node as well so that they don't get disabled
at late_initcall. And the regulator bindings don't provide a method to
list an arbitrary number of clocks in a single property in the way that
the clocks property works.

There may be also resets involved. Fortunately the reset framework is
minimalistic enough not to care about asserting all unused resets at
late_initcall. And other things like power domains may also need to be
kept on.

Passing in clock information via the device tree already requires a non-
trivial amount of code in the firmware. A similar amount of code would
be necessary for each type of resource that needs to be kept enabled. In
addition to the above some devices may also require resources that have
no generic bindings. That just doesn't scale.

The only reasonable thing for simplefb to do is not deal with any kind
of resource at all (except perhaps area that contains the framebuffer
memory).

So how about instead of requiring resources to be explicitly claimed we
introduce something like the below patch? The intention being to give
"firmware device" drivers a way of signalling to the clock framework
that they need rely on clocks set up by firmware and when they no longer
need them. This implements essentially what Mark (CC'ing again on this
subthread) suggested earlier in this thread. Basically, it will allow
drivers to determine the time when unused clocks are really unused. It
will of course only work when used correctly by drivers. For the case of
simplefb I'd expect its .probe() implementation to call the new
clk_ignore_unused() function and once it has handed over control of the
display hardware to the real driver it can call clk_unignore_unused() to
signal that all unused clocks that it cares about have now been claimed.
This is "reference counted" and can therefore be used by more than a
single driver if necessary. Similar functionality could be added for
other resource subsystems as needed.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-clk-Allow-drivers-to-reference-unused-clocks.patch
Type: text/x-diff
Size: 5230 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/c3794a2c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/c3794a2c/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

(CC linux-pm, as PM is the real reason behind disabling unused clocks)
(CC gregkh and lkml, for driver core)

On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > the clocks.
>> > > >
>> > > > You agreed on the fact that the only thing we need to do with the
>> > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > (or not generic).
>> > >
>> > > That's not what I agreed on. What I said is that the only thing we need
>> > > to do with the clocks is nothing. They are already in the state that
>> > > they need to be.
>> >
>> > Claim was probably a poor choice of words, but still. We have to keep
>> > the clock running, and both the solution you've been giving and this
>> > patch do so in a generic way.
>> >
>> > > > > It doesn't know what frequency they should be running at
>> > > >
>> > > > We don't care about that. Just like we don't care about which
>> > > > frequency is the memory bus running at. It will just run at whatever
>> > > > frequency is appropriate.
>> > >
>> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > already configured the clocks to run at the correct frequencies, and it
>> > > has made sure that they are enabled.
>> > >
>> > > > > or what they're used for
>> > > >
>> > > > And we don't care about that either. You're not interested in what
>> > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > here, this is the same thing here.
>> > >
>> > > That's precisely what I've been saying. The only thing that simplefb
>> > > cares about is the memory it should be using and the format of the
>> > > pixels (and how many of them) it writes into that memory. Everything
>> > > else is assumed to have been set up.
>> > >
>> > > Including clocks.
>> >
>> > We're really discussing in circles here.
>> >
>> > Mike?
>> >
>>
>> -EHIGHLATENCYRESPONSE
>>
>> I forgot about this thread. Sorry.
>>
>> In an attempt to provide the least helpful answer possible, I will stay
>> clear of all of the stuff relating to "how simple should simplefb be"
>> and the related reserved memory discussion.
>>
>> A few times in this thread it is stated that we can't prevent unused
>> clocks from being disabled. That is only partially true.
>>
>> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> being disabled at late_initcall-time by a clock "garbage collector"
>> mechanism. Maxime and others familiar with the clock framework are aware
>> of this.
>>
>> What the framework doesn't do is to allow for a magic flag in DT, in
>> platform_data or elsewhere that says, "don't let me get turned off until
>> the right driver claims me". That would be an external or alternative
>> method for preventing a clock from being disabled. We have a method for
>> preventing clocks from being disabled. It is as follows:
>>
>> struct clk *my_clk = clk_get(...);
>> clk_prepare_enable(my_clk);
>>
>> That is how it should be done. Period.
>>
>> With that said I think that Luc's approach is very sensible. I'm not
>> sure what purpose in the universe DT is supposed to serve if not for
>> _this_exact_case_. We have a nice abstracted driver, usable by many
>> people. The hardware details of how it is hooked up at the board level
>> can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many

It doesn't deal with "hardware details for hardware components for which
no driver is available (yet)". That's why the hardware is still in a usable
state, after the firmware has set it up.

Clocks, regulators, PM domains typically have system-wide implications,
and thus need system-wide drivers (in the absence of such drivers,
things would work as-is).

Note that the driver still requests resources (ioremap the frame buffer),
so it needs to know about that tiny piece of hardware detail.

> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

The latter indeed complicates things. But see below... [*]

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Then (optional) regulator support needs to be added.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

Fortunately, unlike clocks, PM domains are first class citizens in the
device framework, as they're handled by the driver core.
So just adding a power-domains property to DTS will work, without any
driver change.

> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.

[*] The firmware does need to make sure the clocks, regulators, PM domains,
... are up and running for the initial video mode, too. So it already needs
to have this knowledge (unless enabled by SoC reset-state).

> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

This still won't work for modules, right? Or am I missing something?
With modules you will never know in advance what will be used and what
won't be used, so you need to keep all clocks, regulators, PM domains, ...
up and running?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

(CC linux-pm, as PM is the real reason behind disabling unused clocks)
(CC gregkh and lkml, for driver core)

On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > the clocks.
>> > > >
>> > > > You agreed on the fact that the only thing we need to do with the
>> > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > (or not generic).
>> > >
>> > > That's not what I agreed on. What I said is that the only thing we need
>> > > to do with the clocks is nothing. They are already in the state that
>> > > they need to be.
>> >
>> > Claim was probably a poor choice of words, but still. We have to keep
>> > the clock running, and both the solution you've been giving and this
>> > patch do so in a generic way.
>> >
>> > > > > It doesn't know what frequency they should be running at
>> > > >
>> > > > We don't care about that. Just like we don't care about which
>> > > > frequency is the memory bus running at. It will just run at whatever
>> > > > frequency is appropriate.
>> > >
>> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > already configured the clocks to run at the correct frequencies, and it
>> > > has made sure that they are enabled.
>> > >
>> > > > > or what they're used for
>> > > >
>> > > > And we don't care about that either. You're not interested in what
>> > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > here, this is the same thing here.
>> > >
>> > > That's precisely what I've been saying. The only thing that simplefb
>> > > cares about is the memory it should be using and the format of the
>> > > pixels (and how many of them) it writes into that memory. Everything
>> > > else is assumed to have been set up.
>> > >
>> > > Including clocks.
>> >
>> > We're really discussing in circles here.
>> >
>> > Mike?
>> >
>>
>> -EHIGHLATENCYRESPONSE
>>
>> I forgot about this thread. Sorry.
>>
>> In an attempt to provide the least helpful answer possible, I will stay
>> clear of all of the stuff relating to "how simple should simplefb be"
>> and the related reserved memory discussion.
>>
>> A few times in this thread it is stated that we can't prevent unused
>> clocks from being disabled. That is only partially true.
>>
>> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> being disabled at late_initcall-time by a clock "garbage collector"
>> mechanism. Maxime and others familiar with the clock framework are aware
>> of this.
>>
>> What the framework doesn't do is to allow for a magic flag in DT, in
>> platform_data or elsewhere that says, "don't let me get turned off until
>> the right driver claims me". That would be an external or alternative
>> method for preventing a clock from being disabled. We have a method for
>> preventing clocks from being disabled. It is as follows:
>>
>> struct clk *my_clk = clk_get(...);
>> clk_prepare_enable(my_clk);
>>
>> That is how it should be done. Period.
>>
>> With that said I think that Luc's approach is very sensible. I'm not
>> sure what purpose in the universe DT is supposed to serve if not for
>> _this_exact_case_. We have a nice abstracted driver, usable by many
>> people. The hardware details of how it is hooked up at the board level
>> can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many

It doesn't deal with "hardware details for hardware components for which
no driver is available (yet)". That's why the hardware is still in a usable
state, after the firmware has set it up.

Clocks, regulators, PM domains typically have system-wide implications,
and thus need system-wide drivers (in the absence of such drivers,
things would work as-is).

Note that the driver still requests resources (ioremap the frame buffer),
so it needs to know about that tiny piece of hardware detail.

> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

The latter indeed complicates things. But see below... [*]

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Then (optional) regulator support needs to be added.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

Fortunately, unlike clocks, PM domains are first class citizens in the
device framework, as they're handled by the driver core.
So just adding a power-domains property to DTS will work, without any
driver change.

> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.

[*] The firmware does need to make sure the clocks, regulators, PM domains,
... are up and running for the initial video mode, too. So it already needs
to have this knowledge (unless enabled by SoC reset-state).

> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

This still won't work for modules, right? Or am I missing something?
With modules you will never know in advance what will be used and what
won't be used, so you need to keep all clocks, regulators, PM domains, ...
up and running?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

(CC linux-pm, as PM is the real reason behind disabling unused clocks)
(CC gregkh and lkml, for driver core)

On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > the clocks.
>> > > >
>> > > > You agreed on the fact that the only thing we need to do with the
>> > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > (or not generic).
>> > >
>> > > That's not what I agreed on. What I said is that the only thing we need
>> > > to do with the clocks is nothing. They are already in the state that
>> > > they need to be.
>> >
>> > Claim was probably a poor choice of words, but still. We have to keep
>> > the clock running, and both the solution you've been giving and this
>> > patch do so in a generic way.
>> >
>> > > > > It doesn't know what frequency they should be running at
>> > > >
>> > > > We don't care about that. Just like we don't care about which
>> > > > frequency is the memory bus running at. It will just run at whatever
>> > > > frequency is appropriate.
>> > >
>> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > already configured the clocks to run at the correct frequencies, and it
>> > > has made sure that they are enabled.
>> > >
>> > > > > or what they're used for
>> > > >
>> > > > And we don't care about that either. You're not interested in what
>> > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > here, this is the same thing here.
>> > >
>> > > That's precisely what I've been saying. The only thing that simplefb
>> > > cares about is the memory it should be using and the format of the
>> > > pixels (and how many of them) it writes into that memory. Everything
>> > > else is assumed to have been set up.
>> > >
>> > > Including clocks.
>> >
>> > We're really discussing in circles here.
>> >
>> > Mike?
>> >
>>
>> -EHIGHLATENCYRESPONSE
>>
>> I forgot about this thread. Sorry.
>>
>> In an attempt to provide the least helpful answer possible, I will stay
>> clear of all of the stuff relating to "how simple should simplefb be"
>> and the related reserved memory discussion.
>>
>> A few times in this thread it is stated that we can't prevent unused
>> clocks from being disabled. That is only partially true.
>>
>> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> being disabled at late_initcall-time by a clock "garbage collector"
>> mechanism. Maxime and others familiar with the clock framework are aware
>> of this.
>>
>> What the framework doesn't do is to allow for a magic flag in DT, in
>> platform_data or elsewhere that says, "don't let me get turned off until
>> the right driver claims me". That would be an external or alternative
>> method for preventing a clock from being disabled. We have a method for
>> preventing clocks from being disabled. It is as follows:
>>
>> struct clk *my_clk = clk_get(...);
>> clk_prepare_enable(my_clk);
>>
>> That is how it should be done. Period.
>>
>> With that said I think that Luc's approach is very sensible. I'm not
>> sure what purpose in the universe DT is supposed to serve if not for
>> _this_exact_case_. We have a nice abstracted driver, usable by many
>> people. The hardware details of how it is hooked up at the board level
>> can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many

It doesn't deal with "hardware details for hardware components for which
no driver is available (yet)". That's why the hardware is still in a usable
state, after the firmware has set it up.

Clocks, regulators, PM domains typically have system-wide implications,
and thus need system-wide drivers (in the absence of such drivers,
things would work as-is).

Note that the driver still requests resources (ioremap the frame buffer),
so it needs to know about that tiny piece of hardware detail.

> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

The latter indeed complicates things. But see below... [*]

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Then (optional) regulator support needs to be added.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

Fortunately, unlike clocks, PM domains are first class citizens in the
device framework, as they're handled by the driver core.
So just adding a power-domains property to DTS will work, without any
driver change.

> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.

[*] The firmware does need to make sure the clocks, regulators, PM domains,
... are up and running for the initial video mode, too. So it already needs
to have this knowledge (unless enabled by SoC reset-state).

> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

This still won't work for modules, right? Or am I missing something?
With modules you will never know in advance what will be used and what
won't be used, so you need to keep all clocks, regulators, PM domains, ...
up and running?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

(CC linux-pm, as PM is the real reason behind disabling unused clocks)
(CC gregkh and lkml, for driver core)

On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > the clocks.
>> > > >
>> > > > You agreed on the fact that the only thing we need to do with the
>> > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > (or not generic).
>> > >
>> > > That's not what I agreed on. What I said is that the only thing we need
>> > > to do with the clocks is nothing. They are already in the state that
>> > > they need to be.
>> >
>> > Claim was probably a poor choice of words, but still. We have to keep
>> > the clock running, and both the solution you've been giving and this
>> > patch do so in a generic way.
>> >
>> > > > > It doesn't know what frequency they should be running at
>> > > >
>> > > > We don't care about that. Just like we don't care about which
>> > > > frequency is the memory bus running at. It will just run at whatever
>> > > > frequency is appropriate.
>> > >
>> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > already configured the clocks to run at the correct frequencies, and it
>> > > has made sure that they are enabled.
>> > >
>> > > > > or what they're used for
>> > > >
>> > > > And we don't care about that either. You're not interested in what
>> > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > here, this is the same thing here.
>> > >
>> > > That's precisely what I've been saying. The only thing that simplefb
>> > > cares about is the memory it should be using and the format of the
>> > > pixels (and how many of them) it writes into that memory. Everything
>> > > else is assumed to have been set up.
>> > >
>> > > Including clocks.
>> >
>> > We're really discussing in circles here.
>> >
>> > Mike?
>> >
>>
>> -EHIGHLATENCYRESPONSE
>>
>> I forgot about this thread. Sorry.
>>
>> In an attempt to provide the least helpful answer possible, I will stay
>> clear of all of the stuff relating to "how simple should simplefb be"
>> and the related reserved memory discussion.
>>
>> A few times in this thread it is stated that we can't prevent unused
>> clocks from being disabled. That is only partially true.
>>
>> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> being disabled at late_initcall-time by a clock "garbage collector"
>> mechanism. Maxime and others familiar with the clock framework are aware
>> of this.
>>
>> What the framework doesn't do is to allow for a magic flag in DT, in
>> platform_data or elsewhere that says, "don't let me get turned off until
>> the right driver claims me". That would be an external or alternative
>> method for preventing a clock from being disabled. We have a method for
>> preventing clocks from being disabled. It is as follows:
>>
>> struct clk *my_clk = clk_get(...);
>> clk_prepare_enable(my_clk);
>>
>> That is how it should be done. Period.
>>
>> With that said I think that Luc's approach is very sensible. I'm not
>> sure what purpose in the universe DT is supposed to serve if not for
>> _this_exact_case_. We have a nice abstracted driver, usable by many
>> people. The hardware details of how it is hooked up at the board level
>> can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many

It doesn't deal with "hardware details for hardware components for which
no driver is available (yet)". That's why the hardware is still in a usable
state, after the firmware has set it up.

Clocks, regulators, PM domains typically have system-wide implications,
and thus need system-wide drivers (in the absence of such drivers,
things would work as-is).

Note that the driver still requests resources (ioremap the frame buffer),
so it needs to know about that tiny piece of hardware detail.

> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

The latter indeed complicates things. But see below... [*]

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Then (optional) regulator support needs to be added.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

Fortunately, unlike clocks, PM domains are first class citizens in the
device framework, as they're handled by the driver core.
So just adding a power-domains property to DTS will work, without any
driver change.

> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.

[*] The firmware does need to make sure the clocks, regulators, PM domains,
... are up and running for the initial video mode, too. So it already needs
to have this knowledge (unless enabled by SoC reset-state).

> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

This still won't work for modules, right? Or am I missing something?
With modules you will never know in advance what will be used and what
won't be used, so you need to keep all clocks, regulators, PM domains, ...
up and running?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 11470 bytes --]

On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> (CC gregkh and lkml, for driver core)
> 
> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> > > > > the clocks.
> >> > > >
> >> > > > You agreed on the fact that the only thing we need to do with the
> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> > > > (or not generic).
> >> > >
> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> > > to do with the clocks is nothing. They are already in the state that
> >> > > they need to be.
> >> >
> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> > the clock running, and both the solution you've been giving and this
> >> > patch do so in a generic way.
> >> >
> >> > > > > It doesn't know what frequency they should be running at
> >> > > >
> >> > > > We don't care about that. Just like we don't care about which
> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> > > > frequency is appropriate.
> >> > >
> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> > > already configured the clocks to run at the correct frequencies, and it
> >> > > has made sure that they are enabled.
> >> > >
> >> > > > > or what they're used for
> >> > > >
> >> > > > And we don't care about that either. You're not interested in what
> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> > > > here, this is the same thing here.
> >> > >
> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> > > cares about is the memory it should be using and the format of the
> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> > > else is assumed to have been set up.
> >> > >
> >> > > Including clocks.
> >> >
> >> > We're really discussing in circles here.
> >> >
> >> > Mike?
> >> >
> >>
> >> -EHIGHLATENCYRESPONSE
> >>
> >> I forgot about this thread. Sorry.
> >>
> >> In an attempt to provide the least helpful answer possible, I will stay
> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> and the related reserved memory discussion.
> >>
> >> A few times in this thread it is stated that we can't prevent unused
> >> clocks from being disabled. That is only partially true.
> >>
> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> of this.
> >>
> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> the right driver claims me". That would be an external or alternative
> >> method for preventing a clock from being disabled. We have a method for
> >> preventing clocks from being disabled. It is as follows:
> >>
> >> struct clk *my_clk = clk_get(...);
> >> clk_prepare_enable(my_clk);
> >>
> >> That is how it should be done. Period.
> >>
> >> With that said I think that Luc's approach is very sensible. I'm not
> >> sure what purpose in the universe DT is supposed to serve if not for
> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> people. The hardware details of how it is hooked up at the board level
> >> can all be hidden behind stable DT bindings that everyone already uses.
> >
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> 
> It doesn't deal with "hardware details for hardware components for which
> no driver is available (yet)". That's why the hardware is still in a usable
> state, after the firmware has set it up.
> 
> Clocks, regulators, PM domains typically have system-wide implications,
> and thus need system-wide drivers (in the absence of such drivers,
> things would work as-is).
> 
> Note that the driver still requests resources (ioremap the frame buffer),
> so it needs to know about that tiny piece of hardware detail.

That's not a hardware detail. Or at least it isn't hardware specific. It
is needed and the same irrespective of display hardware. Clocks, power
domains, regulators and all those are not always the same.

> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> The latter indeed complicates things. But see below... [*]
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Then (optional) regulator support needs to be added.

Can you elaborate?

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> Fortunately, unlike clocks, PM domains are first class citizens in the
> device framework, as they're handled by the driver core.
> So just adding a power-domains property to DTS will work, without any
> driver change.

Well, the device driver would also need to call into the PM runtime
framework to enable all the first class citizen magic. But even if it
were to do that, you'd still need to add all the domains to the DTB.

Note that I'm saying DT*B* here, because the firmware needs to fill in
those properties after the DTS has been compiled. And since most of
these resources are linked via phandle you actually need to resolve
these first before you can fill in the new properties of this
dynamically created node.

So firmware needs to know exactly what device tree node to look for,
find a corresponding phandle and then put the phandle value in the
simplefb device tree node. And it needs to know intimate details about
the clock provider binding because it needs to add an appropriate
specifier, too.

And then all of a sudden something that was supposed to be simple and
generic needs to know the specifics of some hardware device.

> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> 
> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> ... are up and running for the initial video mode, too. So it already needs
> to have this knowledge (unless enabled by SoC reset-state).

Certainly. But not all firmware will use a DTB (or in fact the same DTB
as the kernel) to derive this information from, so it still needs to
inspect the DTB that will be passed to the kernel and painfully extract
information from various nodes and put it into a new node.

But that's not even the issue. You say yourself that the firmware set
everything up itself already. My point is: why should the kernel have to
do everything again, only to come to the conclusion that it doesn't have
to touch hardware at all because it's already in the state that it
should be?

In fact, Linux will at some point set things up from scratch anyway with
a fully-fledged driver. But doing it in simplefb too would be doubly
wasteful.

> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> >
> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> This still won't work for modules, right? Or am I missing something?
> With modules you will never know in advance what will be used and what
> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> up and running?

No. The way this works is that your firmware shim driver, simplefb in
this case, will call clk_ignore_unused() to tell the clock framework
that it uses clocks set up by the firmware, and therefore requests that
no clocks should be considered unused (for now). Later on when the
proper driver has successfully taken over from the shim driver, the shim
driver can unregister itself and call clk_unignore_unused(), which will
drop its "reference" on the unused clocks. When all references have been
dropped the clock framework will then disable all remaining unused
clocks.

In practice this will mean that all unused clocks will remain in their
current state until the shim driver relinquishes control to the proper
OS driver. And if that never happens then we're at least still left with
a working framebuffer.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> (CC gregkh and lkml, for driver core)
> 
> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> > > > > the clocks.
> >> > > >
> >> > > > You agreed on the fact that the only thing we need to do with the
> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> > > > (or not generic).
> >> > >
> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> > > to do with the clocks is nothing. They are already in the state that
> >> > > they need to be.
> >> >
> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> > the clock running, and both the solution you've been giving and this
> >> > patch do so in a generic way.
> >> >
> >> > > > > It doesn't know what frequency they should be running at
> >> > > >
> >> > > > We don't care about that. Just like we don't care about which
> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> > > > frequency is appropriate.
> >> > >
> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> > > already configured the clocks to run at the correct frequencies, and it
> >> > > has made sure that they are enabled.
> >> > >
> >> > > > > or what they're used for
> >> > > >
> >> > > > And we don't care about that either. You're not interested in what
> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> > > > here, this is the same thing here.
> >> > >
> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> > > cares about is the memory it should be using and the format of the
> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> > > else is assumed to have been set up.
> >> > >
> >> > > Including clocks.
> >> >
> >> > We're really discussing in circles here.
> >> >
> >> > Mike?
> >> >
> >>
> >> -EHIGHLATENCYRESPONSE
> >>
> >> I forgot about this thread. Sorry.
> >>
> >> In an attempt to provide the least helpful answer possible, I will stay
> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> and the related reserved memory discussion.
> >>
> >> A few times in this thread it is stated that we can't prevent unused
> >> clocks from being disabled. That is only partially true.
> >>
> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> of this.
> >>
> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> the right driver claims me". That would be an external or alternative
> >> method for preventing a clock from being disabled. We have a method for
> >> preventing clocks from being disabled. It is as follows:
> >>
> >> struct clk *my_clk = clk_get(...);
> >> clk_prepare_enable(my_clk);
> >>
> >> That is how it should be done. Period.
> >>
> >> With that said I think that Luc's approach is very sensible. I'm not
> >> sure what purpose in the universe DT is supposed to serve if not for
> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> people. The hardware details of how it is hooked up at the board level
> >> can all be hidden behind stable DT bindings that everyone already uses.
> >
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> 
> It doesn't deal with "hardware details for hardware components for which
> no driver is available (yet)". That's why the hardware is still in a usable
> state, after the firmware has set it up.
> 
> Clocks, regulators, PM domains typically have system-wide implications,
> and thus need system-wide drivers (in the absence of such drivers,
> things would work as-is).
> 
> Note that the driver still requests resources (ioremap the frame buffer),
> so it needs to know about that tiny piece of hardware detail.

That's not a hardware detail. Or at least it isn't hardware specific. It
is needed and the same irrespective of display hardware. Clocks, power
domains, regulators and all those are not always the same.

> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> The latter indeed complicates things. But see below... [*]
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Then (optional) regulator support needs to be added.

Can you elaborate?

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> Fortunately, unlike clocks, PM domains are first class citizens in the
> device framework, as they're handled by the driver core.
> So just adding a power-domains property to DTS will work, without any
> driver change.

Well, the device driver would also need to call into the PM runtime
framework to enable all the first class citizen magic. But even if it
were to do that, you'd still need to add all the domains to the DTB.

Note that I'm saying DT*B* here, because the firmware needs to fill in
those properties after the DTS has been compiled. And since most of
these resources are linked via phandle you actually need to resolve
these first before you can fill in the new properties of this
dynamically created node.

So firmware needs to know exactly what device tree node to look for,
find a corresponding phandle and then put the phandle value in the
simplefb device tree node. And it needs to know intimate details about
the clock provider binding because it needs to add an appropriate
specifier, too.

And then all of a sudden something that was supposed to be simple and
generic needs to know the specifics of some hardware device.

> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> 
> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> ... are up and running for the initial video mode, too. So it already needs
> to have this knowledge (unless enabled by SoC reset-state).

Certainly. But not all firmware will use a DTB (or in fact the same DTB
as the kernel) to derive this information from, so it still needs to
inspect the DTB that will be passed to the kernel and painfully extract
information from various nodes and put it into a new node.

But that's not even the issue. You say yourself that the firmware set
everything up itself already. My point is: why should the kernel have to
do everything again, only to come to the conclusion that it doesn't have
to touch hardware at all because it's already in the state that it
should be?

In fact, Linux will at some point set things up from scratch anyway with
a fully-fledged driver. But doing it in simplefb too would be doubly
wasteful.

> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> >
> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> This still won't work for modules, right? Or am I missing something?
> With modules you will never know in advance what will be used and what
> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> up and running?

No. The way this works is that your firmware shim driver, simplefb in
this case, will call clk_ignore_unused() to tell the clock framework
that it uses clocks set up by the firmware, and therefore requests that
no clocks should be considered unused (for now). Later on when the
proper driver has successfully taken over from the shim driver, the shim
driver can unregister itself and call clk_unignore_unused(), which will
drop its "reference" on the unused clocks. When all references have been
dropped the clock framework will then disable all remaining unused
clocks.

In practice this will mean that all unused clocks will remain in their
current state until the shim driver relinquishes control to the proper
OS driver. And if that never happens then we're at least still left with
a working framebuffer.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/92b8d2ff/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 11470 bytes --]

On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> (CC gregkh and lkml, for driver core)
> 
> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> > > > > the clocks.
> >> > > >
> >> > > > You agreed on the fact that the only thing we need to do with the
> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> > > > (or not generic).
> >> > >
> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> > > to do with the clocks is nothing. They are already in the state that
> >> > > they need to be.
> >> >
> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> > the clock running, and both the solution you've been giving and this
> >> > patch do so in a generic way.
> >> >
> >> > > > > It doesn't know what frequency they should be running at
> >> > > >
> >> > > > We don't care about that. Just like we don't care about which
> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> > > > frequency is appropriate.
> >> > >
> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> > > already configured the clocks to run at the correct frequencies, and it
> >> > > has made sure that they are enabled.
> >> > >
> >> > > > > or what they're used for
> >> > > >
> >> > > > And we don't care about that either. You're not interested in what
> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> > > > here, this is the same thing here.
> >> > >
> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> > > cares about is the memory it should be using and the format of the
> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> > > else is assumed to have been set up.
> >> > >
> >> > > Including clocks.
> >> >
> >> > We're really discussing in circles here.
> >> >
> >> > Mike?
> >> >
> >>
> >> -EHIGHLATENCYRESPONSE
> >>
> >> I forgot about this thread. Sorry.
> >>
> >> In an attempt to provide the least helpful answer possible, I will stay
> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> and the related reserved memory discussion.
> >>
> >> A few times in this thread it is stated that we can't prevent unused
> >> clocks from being disabled. That is only partially true.
> >>
> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> of this.
> >>
> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> the right driver claims me". That would be an external or alternative
> >> method for preventing a clock from being disabled. We have a method for
> >> preventing clocks from being disabled. It is as follows:
> >>
> >> struct clk *my_clk = clk_get(...);
> >> clk_prepare_enable(my_clk);
> >>
> >> That is how it should be done. Period.
> >>
> >> With that said I think that Luc's approach is very sensible. I'm not
> >> sure what purpose in the universe DT is supposed to serve if not for
> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> people. The hardware details of how it is hooked up at the board level
> >> can all be hidden behind stable DT bindings that everyone already uses.
> >
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> 
> It doesn't deal with "hardware details for hardware components for which
> no driver is available (yet)". That's why the hardware is still in a usable
> state, after the firmware has set it up.
> 
> Clocks, regulators, PM domains typically have system-wide implications,
> and thus need system-wide drivers (in the absence of such drivers,
> things would work as-is).
> 
> Note that the driver still requests resources (ioremap the frame buffer),
> so it needs to know about that tiny piece of hardware detail.

That's not a hardware detail. Or at least it isn't hardware specific. It
is needed and the same irrespective of display hardware. Clocks, power
domains, regulators and all those are not always the same.

> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> The latter indeed complicates things. But see below... [*]
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Then (optional) regulator support needs to be added.

Can you elaborate?

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> Fortunately, unlike clocks, PM domains are first class citizens in the
> device framework, as they're handled by the driver core.
> So just adding a power-domains property to DTS will work, without any
> driver change.

Well, the device driver would also need to call into the PM runtime
framework to enable all the first class citizen magic. But even if it
were to do that, you'd still need to add all the domains to the DTB.

Note that I'm saying DT*B* here, because the firmware needs to fill in
those properties after the DTS has been compiled. And since most of
these resources are linked via phandle you actually need to resolve
these first before you can fill in the new properties of this
dynamically created node.

So firmware needs to know exactly what device tree node to look for,
find a corresponding phandle and then put the phandle value in the
simplefb device tree node. And it needs to know intimate details about
the clock provider binding because it needs to add an appropriate
specifier, too.

And then all of a sudden something that was supposed to be simple and
generic needs to know the specifics of some hardware device.

> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> 
> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> ... are up and running for the initial video mode, too. So it already needs
> to have this knowledge (unless enabled by SoC reset-state).

Certainly. But not all firmware will use a DTB (or in fact the same DTB
as the kernel) to derive this information from, so it still needs to
inspect the DTB that will be passed to the kernel and painfully extract
information from various nodes and put it into a new node.

But that's not even the issue. You say yourself that the firmware set
everything up itself already. My point is: why should the kernel have to
do everything again, only to come to the conclusion that it doesn't have
to touch hardware at all because it's already in the state that it
should be?

In fact, Linux will at some point set things up from scratch anyway with
a fully-fledged driver. But doing it in simplefb too would be doubly
wasteful.

> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> >
> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> This still won't work for modules, right? Or am I missing something?
> With modules you will never know in advance what will be used and what
> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> up and running?

No. The way this works is that your firmware shim driver, simplefb in
this case, will call clk_ignore_unused() to tell the clock framework
that it uses clocks set up by the firmware, and therefore requests that
no clocks should be considered unused (for now). Later on when the
proper driver has successfully taken over from the shim driver, the shim
driver can unregister itself and call clk_unignore_unused(), which will
drop its "reference" on the unused clocks. When all references have been
dropped the clock framework will then disable all remaining unused
clocks.

In practice this will mean that all unused clocks will remain in their
current state until the shim driver relinquishes control to the proper
OS driver. And if that never happens then we're at least still left with
a working framebuffer.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 11500 bytes --]

On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> (CC gregkh and lkml, for driver core)
> 
> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> > > > > the clocks.
> >> > > >
> >> > > > You agreed on the fact that the only thing we need to do with the
> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> > > > (or not generic).
> >> > >
> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> > > to do with the clocks is nothing. They are already in the state that
> >> > > they need to be.
> >> >
> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> > the clock running, and both the solution you've been giving and this
> >> > patch do so in a generic way.
> >> >
> >> > > > > It doesn't know what frequency they should be running at
> >> > > >
> >> > > > We don't care about that. Just like we don't care about which
> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> > > > frequency is appropriate.
> >> > >
> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> > > already configured the clocks to run at the correct frequencies, and it
> >> > > has made sure that they are enabled.
> >> > >
> >> > > > > or what they're used for
> >> > > >
> >> > > > And we don't care about that either. You're not interested in what
> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> > > > here, this is the same thing here.
> >> > >
> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> > > cares about is the memory it should be using and the format of the
> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> > > else is assumed to have been set up.
> >> > >
> >> > > Including clocks.
> >> >
> >> > We're really discussing in circles here.
> >> >
> >> > Mike?
> >> >
> >>
> >> -EHIGHLATENCYRESPONSE
> >>
> >> I forgot about this thread. Sorry.
> >>
> >> In an attempt to provide the least helpful answer possible, I will stay
> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> and the related reserved memory discussion.
> >>
> >> A few times in this thread it is stated that we can't prevent unused
> >> clocks from being disabled. That is only partially true.
> >>
> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> of this.
> >>
> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> the right driver claims me". That would be an external or alternative
> >> method for preventing a clock from being disabled. We have a method for
> >> preventing clocks from being disabled. It is as follows:
> >>
> >> struct clk *my_clk = clk_get(...);
> >> clk_prepare_enable(my_clk);
> >>
> >> That is how it should be done. Period.
> >>
> >> With that said I think that Luc's approach is very sensible. I'm not
> >> sure what purpose in the universe DT is supposed to serve if not for
> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> people. The hardware details of how it is hooked up at the board level
> >> can all be hidden behind stable DT bindings that everyone already uses.
> >
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> 
> It doesn't deal with "hardware details for hardware components for which
> no driver is available (yet)". That's why the hardware is still in a usable
> state, after the firmware has set it up.
> 
> Clocks, regulators, PM domains typically have system-wide implications,
> and thus need system-wide drivers (in the absence of such drivers,
> things would work as-is).
> 
> Note that the driver still requests resources (ioremap the frame buffer),
> so it needs to know about that tiny piece of hardware detail.

That's not a hardware detail. Or at least it isn't hardware specific. It
is needed and the same irrespective of display hardware. Clocks, power
domains, regulators and all those are not always the same.

> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> The latter indeed complicates things. But see below... [*]
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Then (optional) regulator support needs to be added.

Can you elaborate?

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> Fortunately, unlike clocks, PM domains are first class citizens in the
> device framework, as they're handled by the driver core.
> So just adding a power-domains property to DTS will work, without any
> driver change.

Well, the device driver would also need to call into the PM runtime
framework to enable all the first class citizen magic. But even if it
were to do that, you'd still need to add all the domains to the DTB.

Note that I'm saying DT*B* here, because the firmware needs to fill in
those properties after the DTS has been compiled. And since most of
these resources are linked via phandle you actually need to resolve
these first before you can fill in the new properties of this
dynamically created node.

So firmware needs to know exactly what device tree node to look for,
find a corresponding phandle and then put the phandle value in the
simplefb device tree node. And it needs to know intimate details about
the clock provider binding because it needs to add an appropriate
specifier, too.

And then all of a sudden something that was supposed to be simple and
generic needs to know the specifics of some hardware device.

> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> 
> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> ... are up and running for the initial video mode, too. So it already needs
> to have this knowledge (unless enabled by SoC reset-state).

Certainly. But not all firmware will use a DTB (or in fact the same DTB
as the kernel) to derive this information from, so it still needs to
inspect the DTB that will be passed to the kernel and painfully extract
information from various nodes and put it into a new node.

But that's not even the issue. You say yourself that the firmware set
everything up itself already. My point is: why should the kernel have to
do everything again, only to come to the conclusion that it doesn't have
to touch hardware at all because it's already in the state that it
should be?

In fact, Linux will at some point set things up from scratch anyway with
a fully-fledged driver. But doing it in simplefb too would be doubly
wasteful.

> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> >
> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> This still won't work for modules, right? Or am I missing something?
> With modules you will never know in advance what will be used and what
> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> up and running?

No. The way this works is that your firmware shim driver, simplefb in
this case, will call clk_ignore_unused() to tell the clock framework
that it uses clocks set up by the firmware, and therefore requests that
no clocks should be considered unused (for now). Later on when the
proper driver has successfully taken over from the shim driver, the shim
driver can unregister itself and call clk_unignore_unused(), which will
drop its "reference" on the unused clocks. When all references have been
dropped the clock framework will then disable all remaining unused
clocks.

In practice this will mean that all unused clocks will remain in their
current state until the shim driver relinquishes control to the proper
OS driver. And if that never happens then we're at least still left with
a working framebuffer.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>>
>> Then (optional) regulator support needs to be added.
>
> Can you elaborate?

I'm not so familiar with regulators, but I guess it's similar to clocks?

>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.

Powering up domains can be done solely by the device-specific PM
domain code, without PM runtime. If simplefb is tied to the PM domain
and doesn't do any PM runtime, the domain will stay powered on
(only unused PM domains are powered down via late_initcall).

> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.

Indeed. Complicated.

> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

And suddenly we wish we could write a real driver and put the stuff in
the DTS, not DTB...

>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?
>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

So the shim must be built-in, not modular.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>>
>> Then (optional) regulator support needs to be added.
>
> Can you elaborate?

I'm not so familiar with regulators, but I guess it's similar to clocks?

>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.

Powering up domains can be done solely by the device-specific PM
domain code, without PM runtime. If simplefb is tied to the PM domain
and doesn't do any PM runtime, the domain will stay powered on
(only unused PM domains are powered down via late_initcall).

> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.

Indeed. Complicated.

> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

And suddenly we wish we could write a real driver and put the stuff in
the DTS, not DTB...

>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?
>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

So the shim must be built-in, not modular.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>>
>> Then (optional) regulator support needs to be added.
>
> Can you elaborate?

I'm not so familiar with regulators, but I guess it's similar to clocks?

>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.

Powering up domains can be done solely by the device-specific PM
domain code, without PM runtime. If simplefb is tied to the PM domain
and doesn't do any PM runtime, the domain will stay powered on
(only unused PM domains are powered down via late_initcall).

> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.

Indeed. Complicated.

> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

And suddenly we wish we could write a real driver and put the stuff in
the DTS, not DTB...

>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?
>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

So the shim must be built-in, not modular.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>>
>> Then (optional) regulator support needs to be added.
>
> Can you elaborate?

I'm not so familiar with regulators, but I guess it's similar to clocks?

>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.

Powering up domains can be done solely by the device-specific PM
domain code, without PM runtime. If simplefb is tied to the PM domain
and doesn't do any PM runtime, the domain will stay powered on
(only unused PM domains are powered down via late_initcall).

> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.

Indeed. Complicated.

> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

And suddenly we wish we could write a real driver and put the stuff in
the DTS, not DTB...

>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?
>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

So the shim must be built-in, not modular.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]

On Mon, Sep 29, 2014 at 11:10:53AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > If we start extending the binding with board-level details we end up
> >> > duplicating the device tree node for the proper video device. Also note
> >> > that it won't stop at clocks. Other setups will require regulators to be
> >> > listed in this device tree node as well so that they don't get disabled
> >> > at late_initcall. And the regulator bindings don't provide a method to
> >> > list an arbitrary number of clocks in a single property in the way that
> >> > the clocks property works.
> >>
> >> Then (optional) regulator support needs to be added.
> >
> > Can you elaborate?
> 
> I'm not so familiar with regulators, but I guess it's similar to clocks?

The bindings are different. Essentially what you use is a *-supply
property per regulator. There is no way to specify more than one
regulator in a single property.

So if you want to keep that generic you have to do crazy things like:

	simplefb {
		enable-0-supply = <&reg1>;
		enable-1-supply = <&reg2>;
		...
	};

I suppose a more generic supplies property could be created to support
this use-case, but I think this kind of proves my point. The only way
that the original proposal is going to work for other resources is if
they follow the same kind of binding. I don't think it makes sense to
introduce such a prerequisite merely because it would make life easy
for some exotic driver with a very specific application.

> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> And suddenly we wish we could write a real driver and put the stuff in
> the DTS, not DTB...

Oh, there's no doubt a real driver would be preferrable. Note that
simplefb is only meant to be a shim to pass a framebuffer from firmware
to kernel. In some cases it can be used with longer lifetime, like for
example if you really want to have graphical output but the real driver
isn't there yet.

Being a shim driver is precisely the reason why I think the binding
shouldn't be extended to cover all possible types of resources. That
should all go into the binding for the real device.

> >> > The only reasonable thing for simplefb to do is not deal with any kind
> >> > of resource at all (except perhaps area that contains the framebuffer
> >> > memory).
> >> >
> >> > So how about instead of requiring resources to be explicitly claimed we
> >> > introduce something like the below patch? The intention being to give
> >> > "firmware device" drivers a way of signalling to the clock framework
> >> > that they need rely on clocks set up by firmware and when they no longer
> >> > need them. This implements essentially what Mark (CC'ing again on this
> >> > subthread) suggested earlier in this thread. Basically, it will allow
> >> > drivers to determine the time when unused clocks are really unused. It
> >> > will of course only work when used correctly by drivers. For the case of
> >> > simplefb I'd expect its .probe() implementation to call the new
> >> > clk_ignore_unused() function and once it has handed over control of the
> >> > display hardware to the real driver it can call clk_unignore_unused() to
> >> > signal that all unused clocks that it cares about have now been claimed.
> >> > This is "reference counted" and can therefore be used by more than a
> >> > single driver if necessary. Similar functionality could be added for
> >> > other resource subsystems as needed.
> >>
> >> This still won't work for modules, right? Or am I missing something?
> >> With modules you will never know in advance what will be used and what
> >> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> >> up and running?
> >
> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> So the shim must be built-in, not modular.

Correct. Making it a module isn't very useful in my opinion. You'd loose
all the advantages.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:10:53AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > If we start extending the binding with board-level details we end up
> >> > duplicating the device tree node for the proper video device. Also note
> >> > that it won't stop at clocks. Other setups will require regulators to be
> >> > listed in this device tree node as well so that they don't get disabled
> >> > at late_initcall. And the regulator bindings don't provide a method to
> >> > list an arbitrary number of clocks in a single property in the way that
> >> > the clocks property works.
> >>
> >> Then (optional) regulator support needs to be added.
> >
> > Can you elaborate?
> 
> I'm not so familiar with regulators, but I guess it's similar to clocks?

The bindings are different. Essentially what you use is a *-supply
property per regulator. There is no way to specify more than one
regulator in a single property.

So if you want to keep that generic you have to do crazy things like:

	simplefb {
		enable-0-supply = <&reg1>;
		enable-1-supply = <&reg2>;
		...
	};

I suppose a more generic supplies property could be created to support
this use-case, but I think this kind of proves my point. The only way
that the original proposal is going to work for other resources is if
they follow the same kind of binding. I don't think it makes sense to
introduce such a prerequisite merely because it would make life easy
for some exotic driver with a very specific application.

> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> And suddenly we wish we could write a real driver and put the stuff in
> the DTS, not DTB...

Oh, there's no doubt a real driver would be preferrable. Note that
simplefb is only meant to be a shim to pass a framebuffer from firmware
to kernel. In some cases it can be used with longer lifetime, like for
example if you really want to have graphical output but the real driver
isn't there yet.

Being a shim driver is precisely the reason why I think the binding
shouldn't be extended to cover all possible types of resources. That
should all go into the binding for the real device.

> >> > The only reasonable thing for simplefb to do is not deal with any kind
> >> > of resource at all (except perhaps area that contains the framebuffer
> >> > memory).
> >> >
> >> > So how about instead of requiring resources to be explicitly claimed we
> >> > introduce something like the below patch? The intention being to give
> >> > "firmware device" drivers a way of signalling to the clock framework
> >> > that they need rely on clocks set up by firmware and when they no longer
> >> > need them. This implements essentially what Mark (CC'ing again on this
> >> > subthread) suggested earlier in this thread. Basically, it will allow
> >> > drivers to determine the time when unused clocks are really unused. It
> >> > will of course only work when used correctly by drivers. For the case of
> >> > simplefb I'd expect its .probe() implementation to call the new
> >> > clk_ignore_unused() function and once it has handed over control of the
> >> > display hardware to the real driver it can call clk_unignore_unused() to
> >> > signal that all unused clocks that it cares about have now been claimed.
> >> > This is "reference counted" and can therefore be used by more than a
> >> > single driver if necessary. Similar functionality could be added for
> >> > other resource subsystems as needed.
> >>
> >> This still won't work for modules, right? Or am I missing something?
> >> With modules you will never know in advance what will be used and what
> >> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> >> up and running?
> >
> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> So the shim must be built-in, not modular.

Correct. Making it a module isn't very useful in my opinion. You'd loose
all the advantages.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/08c17aac/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]

On Mon, Sep 29, 2014 at 11:10:53AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > If we start extending the binding with board-level details we end up
> >> > duplicating the device tree node for the proper video device. Also note
> >> > that it won't stop at clocks. Other setups will require regulators to be
> >> > listed in this device tree node as well so that they don't get disabled
> >> > at late_initcall. And the regulator bindings don't provide a method to
> >> > list an arbitrary number of clocks in a single property in the way that
> >> > the clocks property works.
> >>
> >> Then (optional) regulator support needs to be added.
> >
> > Can you elaborate?
> 
> I'm not so familiar with regulators, but I guess it's similar to clocks?

The bindings are different. Essentially what you use is a *-supply
property per regulator. There is no way to specify more than one
regulator in a single property.

So if you want to keep that generic you have to do crazy things like:

	simplefb {
		enable-0-supply = <&reg1>;
		enable-1-supply = <&reg2>;
		...
	};

I suppose a more generic supplies property could be created to support
this use-case, but I think this kind of proves my point. The only way
that the original proposal is going to work for other resources is if
they follow the same kind of binding. I don't think it makes sense to
introduce such a prerequisite merely because it would make life easy
for some exotic driver with a very specific application.

> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> And suddenly we wish we could write a real driver and put the stuff in
> the DTS, not DTB...

Oh, there's no doubt a real driver would be preferrable. Note that
simplefb is only meant to be a shim to pass a framebuffer from firmware
to kernel. In some cases it can be used with longer lifetime, like for
example if you really want to have graphical output but the real driver
isn't there yet.

Being a shim driver is precisely the reason why I think the binding
shouldn't be extended to cover all possible types of resources. That
should all go into the binding for the real device.

> >> > The only reasonable thing for simplefb to do is not deal with any kind
> >> > of resource at all (except perhaps area that contains the framebuffer
> >> > memory).
> >> >
> >> > So how about instead of requiring resources to be explicitly claimed we
> >> > introduce something like the below patch? The intention being to give
> >> > "firmware device" drivers a way of signalling to the clock framework
> >> > that they need rely on clocks set up by firmware and when they no longer
> >> > need them. This implements essentially what Mark (CC'ing again on this
> >> > subthread) suggested earlier in this thread. Basically, it will allow
> >> > drivers to determine the time when unused clocks are really unused. It
> >> > will of course only work when used correctly by drivers. For the case of
> >> > simplefb I'd expect its .probe() implementation to call the new
> >> > clk_ignore_unused() function and once it has handed over control of the
> >> > display hardware to the real driver it can call clk_unignore_unused() to
> >> > signal that all unused clocks that it cares about have now been claimed.
> >> > This is "reference counted" and can therefore be used by more than a
> >> > single driver if necessary. Similar functionality could be added for
> >> > other resource subsystems as needed.
> >>
> >> This still won't work for modules, right? Or am I missing something?
> >> With modules you will never know in advance what will be used and what
> >> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> >> up and running?
> >
> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> So the shim must be built-in, not modular.

Correct. Making it a module isn't very useful in my opinion. You'd loose
all the advantages.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5076 bytes --]

On Mon, Sep 29, 2014 at 11:10:53AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > If we start extending the binding with board-level details we end up
> >> > duplicating the device tree node for the proper video device. Also note
> >> > that it won't stop at clocks. Other setups will require regulators to be
> >> > listed in this device tree node as well so that they don't get disabled
> >> > at late_initcall. And the regulator bindings don't provide a method to
> >> > list an arbitrary number of clocks in a single property in the way that
> >> > the clocks property works.
> >>
> >> Then (optional) regulator support needs to be added.
> >
> > Can you elaborate?
> 
> I'm not so familiar with regulators, but I guess it's similar to clocks?

The bindings are different. Essentially what you use is a *-supply
property per regulator. There is no way to specify more than one
regulator in a single property.

So if you want to keep that generic you have to do crazy things like:

	simplefb {
		enable-0-supply = <&reg1>;
		enable-1-supply = <&reg2>;
		...
	};

I suppose a more generic supplies property could be created to support
this use-case, but I think this kind of proves my point. The only way
that the original proposal is going to work for other resources is if
they follow the same kind of binding. I don't think it makes sense to
introduce such a prerequisite merely because it would make life easy
for some exotic driver with a very specific application.

> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> And suddenly we wish we could write a real driver and put the stuff in
> the DTS, not DTB...

Oh, there's no doubt a real driver would be preferrable. Note that
simplefb is only meant to be a shim to pass a framebuffer from firmware
to kernel. In some cases it can be used with longer lifetime, like for
example if you really want to have graphical output but the real driver
isn't there yet.

Being a shim driver is precisely the reason why I think the binding
shouldn't be extended to cover all possible types of resources. That
should all go into the binding for the real device.

> >> > The only reasonable thing for simplefb to do is not deal with any kind
> >> > of resource at all (except perhaps area that contains the framebuffer
> >> > memory).
> >> >
> >> > So how about instead of requiring resources to be explicitly claimed we
> >> > introduce something like the below patch? The intention being to give
> >> > "firmware device" drivers a way of signalling to the clock framework
> >> > that they need rely on clocks set up by firmware and when they no longer
> >> > need them. This implements essentially what Mark (CC'ing again on this
> >> > subthread) suggested earlier in this thread. Basically, it will allow
> >> > drivers to determine the time when unused clocks are really unused. It
> >> > will of course only work when used correctly by drivers. For the case of
> >> > simplefb I'd expect its .probe() implementation to call the new
> >> > clk_ignore_unused() function and once it has handed over control of the
> >> > display hardware to the real driver it can call clk_unignore_unused() to
> >> > signal that all unused clocks that it cares about have now been claimed.
> >> > This is "reference counted" and can therefore be used by more than a
> >> > single driver if necessary. Similar functionality could be added for
> >> > other resource subsystems as needed.
> >>
> >> This still won't work for modules, right? Or am I missing something?
> >> With modules you will never know in advance what will be used and what
> >> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> >> up and running?
> >
> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> So the shim must be built-in, not modular.

Correct. Making it a module isn't very useful in my opinion. You'd loose
all the advantages.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> Hi Thierry,
>>
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> >> > > > > I would think the memory should still be reserved anyway to make sure
>> >> > > > > nothing else is writing over it. And it's in the device tree anyway
>> >> > > > > because the driver needs to know where to put framebuffer content. So
>> >> > > > > the point I was trying to make is that we can't treat the memory in the
>> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> >> > > > > clocks don't. The driver is simply too generic to know what to do with
>> >> > > > > the clocks.
>> >> > > >
>> >> > > > You agreed on the fact that the only thing we need to do with the
>> >> > > > clocks is claim them. Really, I don't find what's complicated there
>> >> > > > (or not generic).
>> >> > >
>> >> > > That's not what I agreed on. What I said is that the only thing we need
>> >> > > to do with the clocks is nothing. They are already in the state that
>> >> > > they need to be.
>> >> >
>> >> > Claim was probably a poor choice of words, but still. We have to keep
>> >> > the clock running, and both the solution you've been giving and this
>> >> > patch do so in a generic way.
>> >> >
>> >> > > > > It doesn't know what frequency they should be running at
>> >> > > >
>> >> > > > We don't care about that. Just like we don't care about which
>> >> > > > frequency is the memory bus running at. It will just run at whatever
>> >> > > > frequency is appropriate.
>> >> > >
>> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> >> > > already configured the clocks to run at the correct frequencies, and it
>> >> > > has made sure that they are enabled.
>> >> > >
>> >> > > > > or what they're used for
>> >> > > >
>> >> > > > And we don't care about that either. You're not interested in what
>> >> > > > output the framebuffer is setup to use, which is pretty much the same
>> >> > > > here, this is the same thing here.
>> >> > >
>> >> > > That's precisely what I've been saying. The only thing that simplefb
>> >> > > cares about is the memory it should be using and the format of the
>> >> > > pixels (and how many of them) it writes into that memory. Everything
>> >> > > else is assumed to have been set up.
>> >> > >
>> >> > > Including clocks.
>> >> >
>> >> > We're really discussing in circles here.
>> >> >
>> >> > Mike?
>> >> >
>> >>
>> >> -EHIGHLATENCYRESPONSE
>> >>
>> >> I forgot about this thread. Sorry.
>> >>
>> >> In an attempt to provide the least helpful answer possible, I will stay
>> >> clear of all of the stuff relating to "how simple should simplefb be"
>> >> and the related reserved memory discussion.
>> >>
>> >> A few times in this thread it is stated that we can't prevent unused
>> >> clocks from being disabled. That is only partially true.
>> >>
>> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> >> being disabled at late_initcall-time by a clock "garbage collector"
>> >> mechanism. Maxime and others familiar with the clock framework are aware
>> >> of this.
>> >>
>> >> What the framework doesn't do is to allow for a magic flag in DT, in
>> >> platform_data or elsewhere that says, "don't let me get turned off until
>> >> the right driver claims me". That would be an external or alternative
>> >> method for preventing a clock from being disabled. We have a method for
>> >> preventing clocks from being disabled. It is as follows:
>> >>
>> >> struct clk *my_clk = clk_get(...);
>> >> clk_prepare_enable(my_clk);
>> >>
>> >> That is how it should be done. Period.
>> >>
>> >> With that said I think that Luc's approach is very sensible. I'm not
>> >> sure what purpose in the universe DT is supposed to serve if not for
>> >> _this_exact_case_. We have a nice abstracted driver, usable by many
>> >> people. The hardware details of how it is hooked up at the board level
>> >> can all be hidden behind stable DT bindings that everyone already uses.
>> >
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>>
>> It doesn't deal with "hardware details for hardware components for which
>> no driver is available (yet)". That's why the hardware is still in a usable
>> state, after the firmware has set it up.
>>
>> Clocks, regulators, PM domains typically have system-wide implications,
>> and thus need system-wide drivers (in the absence of such drivers,
>> things would work as-is).
>>
>> Note that the driver still requests resources (ioremap the frame buffer),
>> so it needs to know about that tiny piece of hardware detail.
>
> That's not a hardware detail. Or at least it isn't hardware specific. It
> is needed and the same irrespective of display hardware. Clocks, power
> domains, regulators and all those are not always the same.

The framebuffer address, format, etc. is as hardware specific as the
clocks needed to run the crtc, regulators to power the backlight, etc.

You see this from the point of view of a platform that has not clock
driver. Then the platform has no clock information whatsoever, for any
driver. That's platform specific too.

Why do we have to go back to this *again*?

>
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.
>
> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.
>
> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

Note however that all the specific is in the firmware driver. The
linux simplefb driver only needs to read DT entries which is generic
hardware-neutral thing. It needs to handle clocks on platform that do
have a clock driver, yes. There is no way around that. See below.

>
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>>
>> [*] The firmware does need to make sure the clocks, regulators, PM domains,
>> ... are up and running for the initial video mode, too. So it already needs
>> to have this knowledge (unless enabled by SoC reset-state).
>
> Certainly. But not all firmware will use a DTB (or in fact the same DTB
> as the kernel) to derive this information from, so it still needs to
> inspect the DTB that will be passed to the kernel and painfully extract
> information from various nodes and put it into a new node.
>
> But that's not even the issue. You say yourself that the firmware set
> everything up itself already. My point is: why should the kernel have to
> do everything again, only to come to the conclusion that it doesn't have
> to touch hardware at all because it's already in the state that it
> should be?

It will do nothing. It will just read from DTB what firmware has set
up and inform all the relevant generic frameworks that these resources
are in use. The device-specific driver (if any) will then keep the
resource in question enabled. So all that is this patch doing is to
correct the kernel's resource bookkeeping.

>
> In fact, Linux will at some point set things up from scratch anyway with
> a fully-fledged driver. But doing it in simplefb too would be doubly
> wasteful.

It may or may not. And by having the bookkeeping straight we give that
choice to the user.

>
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?

Simplefb cannot work as module on any platform. Once kernel reclaims
the resources used by simplefb it cannot be started because kernel has
no way to reenable the resources (memory, clocks, etc). Reclaiming the
simplefb memory is currently not supported but once it is added
loading simplefb as module is no-go on any platform.

>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

> In practice this will mean that all unused clocks will remain in their
> current state until the shim driver relinquishes control to the proper
> OS driver. And if that never happens then we're at least still left with
> a working framebuffer.

This does not work. Firstly if you do not have a full driver (because
there is none or because kernel did not find the module, ...) then you
could run with the shim driver and have all clocks managed properly.
This is not possible with clk_ignore_unused.

Secondly clk_ignore_unused does not really mark clock as used. It only
skips disabling them at certain point at kernel startup so that kernel
survives that point and clock problems can be debugged. It is not
meant as an option to be used for running the kernel indefinitely. It
is indeed flawed: if at later point enabling or disabling a clock
results in a parent clock becoming unused it is still disabled. This
can affect many clocks if enabling a clock results in clock
reparenting.

Sure, clk_ignore_unused could be fixed to actually mark all clocks
enabled at boot time as used so that they are never disabled but
that's orthogonal to fixing simplefb so that when it is in use the
clock framework can work normally and can be tested, debugged, and
used for saving power by disabling unused clocks.

So please stop repeating that managing system resources is
system-specific and not fit for simplefb driver. It's been said enough
times, and enough times pointed out that simplefb driver must as any
other driver manage its resources (or more specifically tell the
kernel to manage them) to work properly. And that reading a list of
resources from DT and telling kernel to manage them is not system
specific, only specific to resource frameworks enabled on the platform
in question. That is you may need support for as many resource
frameworks as the platform has if they are ever used for framebuffer.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> Hi Thierry,
>>
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> >> > > > > I would think the memory should still be reserved anyway to make sure
>> >> > > > > nothing else is writing over it. And it's in the device tree anyway
>> >> > > > > because the driver needs to know where to put framebuffer content. So
>> >> > > > > the point I was trying to make is that we can't treat the memory in the
>> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> >> > > > > clocks don't. The driver is simply too generic to know what to do with
>> >> > > > > the clocks.
>> >> > > >
>> >> > > > You agreed on the fact that the only thing we need to do with the
>> >> > > > clocks is claim them. Really, I don't find what's complicated there
>> >> > > > (or not generic).
>> >> > >
>> >> > > That's not what I agreed on. What I said is that the only thing we need
>> >> > > to do with the clocks is nothing. They are already in the state that
>> >> > > they need to be.
>> >> >
>> >> > Claim was probably a poor choice of words, but still. We have to keep
>> >> > the clock running, and both the solution you've been giving and this
>> >> > patch do so in a generic way.
>> >> >
>> >> > > > > It doesn't know what frequency they should be running at
>> >> > > >
>> >> > > > We don't care about that. Just like we don't care about which
>> >> > > > frequency is the memory bus running at. It will just run at whatever
>> >> > > > frequency is appropriate.
>> >> > >
>> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> >> > > already configured the clocks to run at the correct frequencies, and it
>> >> > > has made sure that they are enabled.
>> >> > >
>> >> > > > > or what they're used for
>> >> > > >
>> >> > > > And we don't care about that either. You're not interested in what
>> >> > > > output the framebuffer is setup to use, which is pretty much the same
>> >> > > > here, this is the same thing here.
>> >> > >
>> >> > > That's precisely what I've been saying. The only thing that simplefb
>> >> > > cares about is the memory it should be using and the format of the
>> >> > > pixels (and how many of them) it writes into that memory. Everything
>> >> > > else is assumed to have been set up.
>> >> > >
>> >> > > Including clocks.
>> >> >
>> >> > We're really discussing in circles here.
>> >> >
>> >> > Mike?
>> >> >
>> >>
>> >> -EHIGHLATENCYRESPONSE
>> >>
>> >> I forgot about this thread. Sorry.
>> >>
>> >> In an attempt to provide the least helpful answer possible, I will stay
>> >> clear of all of the stuff relating to "how simple should simplefb be"
>> >> and the related reserved memory discussion.
>> >>
>> >> A few times in this thread it is stated that we can't prevent unused
>> >> clocks from being disabled. That is only partially true.
>> >>
>> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> >> being disabled at late_initcall-time by a clock "garbage collector"
>> >> mechanism. Maxime and others familiar with the clock framework are aware
>> >> of this.
>> >>
>> >> What the framework doesn't do is to allow for a magic flag in DT, in
>> >> platform_data or elsewhere that says, "don't let me get turned off until
>> >> the right driver claims me". That would be an external or alternative
>> >> method for preventing a clock from being disabled. We have a method for
>> >> preventing clocks from being disabled. It is as follows:
>> >>
>> >> struct clk *my_clk = clk_get(...);
>> >> clk_prepare_enable(my_clk);
>> >>
>> >> That is how it should be done. Period.
>> >>
>> >> With that said I think that Luc's approach is very sensible. I'm not
>> >> sure what purpose in the universe DT is supposed to serve if not for
>> >> _this_exact_case_. We have a nice abstracted driver, usable by many
>> >> people. The hardware details of how it is hooked up at the board level
>> >> can all be hidden behind stable DT bindings that everyone already uses.
>> >
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>>
>> It doesn't deal with "hardware details for hardware components for which
>> no driver is available (yet)". That's why the hardware is still in a usable
>> state, after the firmware has set it up.
>>
>> Clocks, regulators, PM domains typically have system-wide implications,
>> and thus need system-wide drivers (in the absence of such drivers,
>> things would work as-is).
>>
>> Note that the driver still requests resources (ioremap the frame buffer),
>> so it needs to know about that tiny piece of hardware detail.
>
> That's not a hardware detail. Or at least it isn't hardware specific. It
> is needed and the same irrespective of display hardware. Clocks, power
> domains, regulators and all those are not always the same.

The framebuffer address, format, etc. is as hardware specific as the
clocks needed to run the crtc, regulators to power the backlight, etc.

You see this from the point of view of a platform that has not clock
driver. Then the platform has no clock information whatsoever, for any
driver. That's platform specific too.

Why do we have to go back to this *again*?

>
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.
>
> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.
>
> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

Note however that all the specific is in the firmware driver. The
linux simplefb driver only needs to read DT entries which is generic
hardware-neutral thing. It needs to handle clocks on platform that do
have a clock driver, yes. There is no way around that. See below.

>
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>>
>> [*] The firmware does need to make sure the clocks, regulators, PM domains,
>> ... are up and running for the initial video mode, too. So it already needs
>> to have this knowledge (unless enabled by SoC reset-state).
>
> Certainly. But not all firmware will use a DTB (or in fact the same DTB
> as the kernel) to derive this information from, so it still needs to
> inspect the DTB that will be passed to the kernel and painfully extract
> information from various nodes and put it into a new node.
>
> But that's not even the issue. You say yourself that the firmware set
> everything up itself already. My point is: why should the kernel have to
> do everything again, only to come to the conclusion that it doesn't have
> to touch hardware at all because it's already in the state that it
> should be?

It will do nothing. It will just read from DTB what firmware has set
up and inform all the relevant generic frameworks that these resources
are in use. The device-specific driver (if any) will then keep the
resource in question enabled. So all that is this patch doing is to
correct the kernel's resource bookkeeping.

>
> In fact, Linux will at some point set things up from scratch anyway with
> a fully-fledged driver. But doing it in simplefb too would be doubly
> wasteful.

It may or may not. And by having the bookkeeping straight we give that
choice to the user.

>
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?

Simplefb cannot work as module on any platform. Once kernel reclaims
the resources used by simplefb it cannot be started because kernel has
no way to reenable the resources (memory, clocks, etc). Reclaiming the
simplefb memory is currently not supported but once it is added
loading simplefb as module is no-go on any platform.

>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

> In practice this will mean that all unused clocks will remain in their
> current state until the shim driver relinquishes control to the proper
> OS driver. And if that never happens then we're at least still left with
> a working framebuffer.

This does not work. Firstly if you do not have a full driver (because
there is none or because kernel did not find the module, ...) then you
could run with the shim driver and have all clocks managed properly.
This is not possible with clk_ignore_unused.

Secondly clk_ignore_unused does not really mark clock as used. It only
skips disabling them at certain point at kernel startup so that kernel
survives that point and clock problems can be debugged. It is not
meant as an option to be used for running the kernel indefinitely. It
is indeed flawed: if at later point enabling or disabling a clock
results in a parent clock becoming unused it is still disabled. This
can affect many clocks if enabling a clock results in clock
reparenting.

Sure, clk_ignore_unused could be fixed to actually mark all clocks
enabled at boot time as used so that they are never disabled but
that's orthogonal to fixing simplefb so that when it is in use the
clock framework can work normally and can be tested, debugged, and
used for saving power by disabling unused clocks.

So please stop repeating that managing system resources is
system-specific and not fit for simplefb driver. It's been said enough
times, and enough times pointed out that simplefb driver must as any
other driver manage its resources (or more specifically tell the
kernel to manage them) to work properly. And that reading a list of
resources from DT and telling kernel to manage them is not system
specific, only specific to resource frameworks enabled on the platform
in question. That is you may need support for as many resource
frameworks as the platform has if they are ever used for framebuffer.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> Hi Thierry,
>>
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> >> > > > > I would think the memory should still be reserved anyway to make sure
>> >> > > > > nothing else is writing over it. And it's in the device tree anyway
>> >> > > > > because the driver needs to know where to put framebuffer content. So
>> >> > > > > the point I was trying to make is that we can't treat the memory in the
>> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> >> > > > > clocks don't. The driver is simply too generic to know what to do with
>> >> > > > > the clocks.
>> >> > > >
>> >> > > > You agreed on the fact that the only thing we need to do with the
>> >> > > > clocks is claim them. Really, I don't find what's complicated there
>> >> > > > (or not generic).
>> >> > >
>> >> > > That's not what I agreed on. What I said is that the only thing we need
>> >> > > to do with the clocks is nothing. They are already in the state that
>> >> > > they need to be.
>> >> >
>> >> > Claim was probably a poor choice of words, but still. We have to keep
>> >> > the clock running, and both the solution you've been giving and this
>> >> > patch do so in a generic way.
>> >> >
>> >> > > > > It doesn't know what frequency they should be running at
>> >> > > >
>> >> > > > We don't care about that. Just like we don't care about which
>> >> > > > frequency is the memory bus running at. It will just run at whatever
>> >> > > > frequency is appropriate.
>> >> > >
>> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> >> > > already configured the clocks to run at the correct frequencies, and it
>> >> > > has made sure that they are enabled.
>> >> > >
>> >> > > > > or what they're used for
>> >> > > >
>> >> > > > And we don't care about that either. You're not interested in what
>> >> > > > output the framebuffer is setup to use, which is pretty much the same
>> >> > > > here, this is the same thing here.
>> >> > >
>> >> > > That's precisely what I've been saying. The only thing that simplefb
>> >> > > cares about is the memory it should be using and the format of the
>> >> > > pixels (and how many of them) it writes into that memory. Everything
>> >> > > else is assumed to have been set up.
>> >> > >
>> >> > > Including clocks.
>> >> >
>> >> > We're really discussing in circles here.
>> >> >
>> >> > Mike?
>> >> >
>> >>
>> >> -EHIGHLATENCYRESPONSE
>> >>
>> >> I forgot about this thread. Sorry.
>> >>
>> >> In an attempt to provide the least helpful answer possible, I will stay
>> >> clear of all of the stuff relating to "how simple should simplefb be"
>> >> and the related reserved memory discussion.
>> >>
>> >> A few times in this thread it is stated that we can't prevent unused
>> >> clocks from being disabled. That is only partially true.
>> >>
>> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> >> being disabled at late_initcall-time by a clock "garbage collector"
>> >> mechanism. Maxime and others familiar with the clock framework are aware
>> >> of this.
>> >>
>> >> What the framework doesn't do is to allow for a magic flag in DT, in
>> >> platform_data or elsewhere that says, "don't let me get turned off until
>> >> the right driver claims me". That would be an external or alternative
>> >> method for preventing a clock from being disabled. We have a method for
>> >> preventing clocks from being disabled. It is as follows:
>> >>
>> >> struct clk *my_clk = clk_get(...);
>> >> clk_prepare_enable(my_clk);
>> >>
>> >> That is how it should be done. Period.
>> >>
>> >> With that said I think that Luc's approach is very sensible. I'm not
>> >> sure what purpose in the universe DT is supposed to serve if not for
>> >> _this_exact_case_. We have a nice abstracted driver, usable by many
>> >> people. The hardware details of how it is hooked up at the board level
>> >> can all be hidden behind stable DT bindings that everyone already uses.
>> >
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>>
>> It doesn't deal with "hardware details for hardware components for which
>> no driver is available (yet)". That's why the hardware is still in a usable
>> state, after the firmware has set it up.
>>
>> Clocks, regulators, PM domains typically have system-wide implications,
>> and thus need system-wide drivers (in the absence of such drivers,
>> things would work as-is).
>>
>> Note that the driver still requests resources (ioremap the frame buffer),
>> so it needs to know about that tiny piece of hardware detail.
>
> That's not a hardware detail. Or at least it isn't hardware specific. It
> is needed and the same irrespective of display hardware. Clocks, power
> domains, regulators and all those are not always the same.

The framebuffer address, format, etc. is as hardware specific as the
clocks needed to run the crtc, regulators to power the backlight, etc.

You see this from the point of view of a platform that has not clock
driver. Then the platform has no clock information whatsoever, for any
driver. That's platform specific too.

Why do we have to go back to this *again*?

>
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.
>
> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.
>
> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

Note however that all the specific is in the firmware driver. The
linux simplefb driver only needs to read DT entries which is generic
hardware-neutral thing. It needs to handle clocks on platform that do
have a clock driver, yes. There is no way around that. See below.

>
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>>
>> [*] The firmware does need to make sure the clocks, regulators, PM domains,
>> ... are up and running for the initial video mode, too. So it already needs
>> to have this knowledge (unless enabled by SoC reset-state).
>
> Certainly. But not all firmware will use a DTB (or in fact the same DTB
> as the kernel) to derive this information from, so it still needs to
> inspect the DTB that will be passed to the kernel and painfully extract
> information from various nodes and put it into a new node.
>
> But that's not even the issue. You say yourself that the firmware set
> everything up itself already. My point is: why should the kernel have to
> do everything again, only to come to the conclusion that it doesn't have
> to touch hardware at all because it's already in the state that it
> should be?

It will do nothing. It will just read from DTB what firmware has set
up and inform all the relevant generic frameworks that these resources
are in use. The device-specific driver (if any) will then keep the
resource in question enabled. So all that is this patch doing is to
correct the kernel's resource bookkeeping.

>
> In fact, Linux will at some point set things up from scratch anyway with
> a fully-fledged driver. But doing it in simplefb too would be doubly
> wasteful.

It may or may not. And by having the bookkeeping straight we give that
choice to the user.

>
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?

Simplefb cannot work as module on any platform. Once kernel reclaims
the resources used by simplefb it cannot be started because kernel has
no way to reenable the resources (memory, clocks, etc). Reclaiming the
simplefb memory is currently not supported but once it is added
loading simplefb as module is no-go on any platform.

>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

> In practice this will mean that all unused clocks will remain in their
> current state until the shim driver relinquishes control to the proper
> OS driver. And if that never happens then we're at least still left with
> a working framebuffer.

This does not work. Firstly if you do not have a full driver (because
there is none or because kernel did not find the module, ...) then you
could run with the shim driver and have all clocks managed properly.
This is not possible with clk_ignore_unused.

Secondly clk_ignore_unused does not really mark clock as used. It only
skips disabling them at certain point at kernel startup so that kernel
survives that point and clock problems can be debugged. It is not
meant as an option to be used for running the kernel indefinitely. It
is indeed flawed: if at later point enabling or disabling a clock
results in a parent clock becoming unused it is still disabled. This
can affect many clocks if enabling a clock results in clock
reparenting.

Sure, clk_ignore_unused could be fixed to actually mark all clocks
enabled at boot time as used so that they are never disabled but
that's orthogonal to fixing simplefb so that when it is in use the
clock framework can work normally and can be tested, debugged, and
used for saving power by disabling unused clocks.

So please stop repeating that managing system resources is
system-specific and not fit for simplefb driver. It's been said enough
times, and enough times pointed out that simplefb driver must as any
other driver manage its resources (or more specifically tell the
kernel to manage them) to work properly. And that reading a list of
resources from DT and telling kernel to manage them is not system
specific, only specific to resource frameworks enabled on the platform
in question. That is you may need support for as many resource
frameworks as the platform has if they are ever used for framebuffer.

Thanks

Michal

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 10:54, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> Hi Thierry,
>>
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> >> > > > > I would think the memory should still be reserved anyway to make sure
>> >> > > > > nothing else is writing over it. And it's in the device tree anyway
>> >> > > > > because the driver needs to know where to put framebuffer content. So
>> >> > > > > the point I was trying to make is that we can't treat the memory in the
>> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> >> > > > > clocks don't. The driver is simply too generic to know what to do with
>> >> > > > > the clocks.
>> >> > > >
>> >> > > > You agreed on the fact that the only thing we need to do with the
>> >> > > > clocks is claim them. Really, I don't find what's complicated there
>> >> > > > (or not generic).
>> >> > >
>> >> > > That's not what I agreed on. What I said is that the only thing we need
>> >> > > to do with the clocks is nothing. They are already in the state that
>> >> > > they need to be.
>> >> >
>> >> > Claim was probably a poor choice of words, but still. We have to keep
>> >> > the clock running, and both the solution you've been giving and this
>> >> > patch do so in a generic way.
>> >> >
>> >> > > > > It doesn't know what frequency they should be running at
>> >> > > >
>> >> > > > We don't care about that. Just like we don't care about which
>> >> > > > frequency is the memory bus running at. It will just run at whatever
>> >> > > > frequency is appropriate.
>> >> > >
>> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> >> > > already configured the clocks to run at the correct frequencies, and it
>> >> > > has made sure that they are enabled.
>> >> > >
>> >> > > > > or what they're used for
>> >> > > >
>> >> > > > And we don't care about that either. You're not interested in what
>> >> > > > output the framebuffer is setup to use, which is pretty much the same
>> >> > > > here, this is the same thing here.
>> >> > >
>> >> > > That's precisely what I've been saying. The only thing that simplefb
>> >> > > cares about is the memory it should be using and the format of the
>> >> > > pixels (and how many of them) it writes into that memory. Everything
>> >> > > else is assumed to have been set up.
>> >> > >
>> >> > > Including clocks.
>> >> >
>> >> > We're really discussing in circles here.
>> >> >
>> >> > Mike?
>> >> >
>> >>
>> >> -EHIGHLATENCYRESPONSE
>> >>
>> >> I forgot about this thread. Sorry.
>> >>
>> >> In an attempt to provide the least helpful answer possible, I will stay
>> >> clear of all of the stuff relating to "how simple should simplefb be"
>> >> and the related reserved memory discussion.
>> >>
>> >> A few times in this thread it is stated that we can't prevent unused
>> >> clocks from being disabled. That is only partially true.
>> >>
>> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> >> being disabled at late_initcall-time by a clock "garbage collector"
>> >> mechanism. Maxime and others familiar with the clock framework are aware
>> >> of this.
>> >>
>> >> What the framework doesn't do is to allow for a magic flag in DT, in
>> >> platform_data or elsewhere that says, "don't let me get turned off until
>> >> the right driver claims me". That would be an external or alternative
>> >> method for preventing a clock from being disabled. We have a method for
>> >> preventing clocks from being disabled. It is as follows:
>> >>
>> >> struct clk *my_clk = clk_get(...);
>> >> clk_prepare_enable(my_clk);
>> >>
>> >> That is how it should be done. Period.
>> >>
>> >> With that said I think that Luc's approach is very sensible. I'm not
>> >> sure what purpose in the universe DT is supposed to serve if not for
>> >> _this_exact_case_. We have a nice abstracted driver, usable by many
>> >> people. The hardware details of how it is hooked up at the board level
>> >> can all be hidden behind stable DT bindings that everyone already uses.
>> >
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>>
>> It doesn't deal with "hardware details for hardware components for which
>> no driver is available (yet)". That's why the hardware is still in a usable
>> state, after the firmware has set it up.
>>
>> Clocks, regulators, PM domains typically have system-wide implications,
>> and thus need system-wide drivers (in the absence of such drivers,
>> things would work as-is).
>>
>> Note that the driver still requests resources (ioremap the frame buffer),
>> so it needs to know about that tiny piece of hardware detail.
>
> That's not a hardware detail. Or at least it isn't hardware specific. It
> is needed and the same irrespective of display hardware. Clocks, power
> domains, regulators and all those are not always the same.

The framebuffer address, format, etc. is as hardware specific as the
clocks needed to run the crtc, regulators to power the backlight, etc.

You see this from the point of view of a platform that has not clock
driver. Then the platform has no clock information whatsoever, for any
driver. That's platform specific too.

Why do we have to go back to this *again*?

>
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.
>
> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.
>
> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

Note however that all the specific is in the firmware driver. The
linux simplefb driver only needs to read DT entries which is generic
hardware-neutral thing. It needs to handle clocks on platform that do
have a clock driver, yes. There is no way around that. See below.

>
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>>
>> [*] The firmware does need to make sure the clocks, regulators, PM domains,
>> ... are up and running for the initial video mode, too. So it already needs
>> to have this knowledge (unless enabled by SoC reset-state).
>
> Certainly. But not all firmware will use a DTB (or in fact the same DTB
> as the kernel) to derive this information from, so it still needs to
> inspect the DTB that will be passed to the kernel and painfully extract
> information from various nodes and put it into a new node.
>
> But that's not even the issue. You say yourself that the firmware set
> everything up itself already. My point is: why should the kernel have to
> do everything again, only to come to the conclusion that it doesn't have
> to touch hardware at all because it's already in the state that it
> should be?

It will do nothing. It will just read from DTB what firmware has set
up and inform all the relevant generic frameworks that these resources
are in use. The device-specific driver (if any) will then keep the
resource in question enabled. So all that is this patch doing is to
correct the kernel's resource bookkeeping.

>
> In fact, Linux will at some point set things up from scratch anyway with
> a fully-fledged driver. But doing it in simplefb too would be doubly
> wasteful.

It may or may not. And by having the bookkeeping straight we give that
choice to the user.

>
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?

Simplefb cannot work as module on any platform. Once kernel reclaims
the resources used by simplefb it cannot be started because kernel has
no way to reenable the resources (memory, clocks, etc). Reclaiming the
simplefb memory is currently not supported but once it is added
loading simplefb as module is no-go on any platform.

>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

> In practice this will mean that all unused clocks will remain in their
> current state until the shim driver relinquishes control to the proper
> OS driver. And if that never happens then we're at least still left with
> a working framebuffer.

This does not work. Firstly if you do not have a full driver (because
there is none or because kernel did not find the module, ...) then you
could run with the shim driver and have all clocks managed properly.
This is not possible with clk_ignore_unused.

Secondly clk_ignore_unused does not really mark clock as used. It only
skips disabling them at certain point at kernel startup so that kernel
survives that point and clock problems can be debugged. It is not
meant as an option to be used for running the kernel indefinitely. It
is indeed flawed: if at later point enabling or disabling a clock
results in a parent clock becoming unused it is still disabled. This
can affect many clocks if enabling a clock results in clock
reparenting.

Sure, clk_ignore_unused could be fixed to actually mark all clocks
enabled at boot time as used so that they are never disabled but
that's orthogonal to fixing simplefb so that when it is in use the
clock framework can work normally and can be tested, debugged, and
used for saving power by disabling unused clocks.

So please stop repeating that managing system resources is
system-specific and not fit for simplefb driver. It's been said enough
times, and enough times pointed out that simplefb driver must as any
other driver manage its resources (or more specifically tell the
kernel to manage them) to work properly. And that reading a list of
resources from DT and telling kernel to manage them is not system
specific, only specific to resource frameworks enabled on the platform
in question. That is you may need support for as many resource
frameworks as the platform has if they are ever used for framebuffer.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 13787 bytes --]

On Mon, Sep 29, 2014 at 11:44:19AM +0200, Michal Suchanek wrote:
> On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> Hi Thierry,
> >>
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> >> > > > > the clocks.
> >> >> > > >
> >> >> > > > You agreed on the fact that the only thing we need to do with the
> >> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> >> > > > (or not generic).
> >> >> > >
> >> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> >> > > to do with the clocks is nothing. They are already in the state that
> >> >> > > they need to be.
> >> >> >
> >> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> >> > the clock running, and both the solution you've been giving and this
> >> >> > patch do so in a generic way.
> >> >> >
> >> >> > > > > It doesn't know what frequency they should be running at
> >> >> > > >
> >> >> > > > We don't care about that. Just like we don't care about which
> >> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> >> > > > frequency is appropriate.
> >> >> > >
> >> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> >> > > already configured the clocks to run at the correct frequencies, and it
> >> >> > > has made sure that they are enabled.
> >> >> > >
> >> >> > > > > or what they're used for
> >> >> > > >
> >> >> > > > And we don't care about that either. You're not interested in what
> >> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> >> > > > here, this is the same thing here.
> >> >> > >
> >> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> >> > > cares about is the memory it should be using and the format of the
> >> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> >> > > else is assumed to have been set up.
> >> >> > >
> >> >> > > Including clocks.
> >> >> >
> >> >> > We're really discussing in circles here.
> >> >> >
> >> >> > Mike?
> >> >> >
> >> >>
> >> >> -EHIGHLATENCYRESPONSE
> >> >>
> >> >> I forgot about this thread. Sorry.
> >> >>
> >> >> In an attempt to provide the least helpful answer possible, I will stay
> >> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> >> and the related reserved memory discussion.
> >> >>
> >> >> A few times in this thread it is stated that we can't prevent unused
> >> >> clocks from being disabled. That is only partially true.
> >> >>
> >> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> >> of this.
> >> >>
> >> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> >> the right driver claims me". That would be an external or alternative
> >> >> method for preventing a clock from being disabled. We have a method for
> >> >> preventing clocks from being disabled. It is as follows:
> >> >>
> >> >> struct clk *my_clk = clk_get(...);
> >> >> clk_prepare_enable(my_clk);
> >> >>
> >> >> That is how it should be done. Period.
> >> >>
> >> >> With that said I think that Luc's approach is very sensible. I'm not
> >> >> sure what purpose in the universe DT is supposed to serve if not for
> >> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> >> people. The hardware details of how it is hooked up at the board level
> >> >> can all be hidden behind stable DT bindings that everyone already uses.
> >> >
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >>
> >> It doesn't deal with "hardware details for hardware components for which
> >> no driver is available (yet)". That's why the hardware is still in a usable
> >> state, after the firmware has set it up.
> >>
> >> Clocks, regulators, PM domains typically have system-wide implications,
> >> and thus need system-wide drivers (in the absence of such drivers,
> >> things would work as-is).
> >>
> >> Note that the driver still requests resources (ioremap the frame buffer),
> >> so it needs to know about that tiny piece of hardware detail.
> >
> > That's not a hardware detail. Or at least it isn't hardware specific. It
> > is needed and the same irrespective of display hardware. Clocks, power
> > domains, regulators and all those are not always the same.
> 
> The framebuffer address, format, etc. is as hardware specific as the
> clocks needed to run the crtc, regulators to power the backlight, etc.

Framebuffer address and format are not hardware specific. Every display
driver requires them.

> You see this from the point of view of a platform that has not clock
> driver.

Wrong. What platform's point of view do you think I look at this from?

> Then the platform has no clock information whatsoever, for any
> driver. That's platform specific too.
> 
> Why do we have to go back to this *again*?

What exactly are we going back to again?

> >> > There may be also resets involved. Fortunately the reset framework is
> >> > minimalistic enough not to care about asserting all unused resets at
> >> > late_initcall. And other things like power domains may also need to be
> >> > kept on.
> >>
> >> Fortunately, unlike clocks, PM domains are first class citizens in the
> >> device framework, as they're handled by the driver core.
> >> So just adding a power-domains property to DTS will work, without any
> >> driver change.
> >
> > Well, the device driver would also need to call into the PM runtime
> > framework to enable all the first class citizen magic. But even if it
> > were to do that, you'd still need to add all the domains to the DTB.
> >
> > Note that I'm saying DT*B* here, because the firmware needs to fill in
> > those properties after the DTS has been compiled. And since most of
> > these resources are linked via phandle you actually need to resolve
> > these first before you can fill in the new properties of this
> > dynamically created node.
> >
> > So firmware needs to know exactly what device tree node to look for,
> > find a corresponding phandle and then put the phandle value in the
> > simplefb device tree node. And it needs to know intimate details about
> > the clock provider binding because it needs to add an appropriate
> > specifier, too.
> >
> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> Note however that all the specific is in the firmware driver. The
> linux simplefb driver only needs to read DT entries which is generic
> hardware-neutral thing.

No. The DT entries are very hardware-specific. That's precisely the
reason why I think it's wrong to put this into the simplefb node,
because simplefb is an abstraction of the real hardware underneath.

> >> > Passing in clock information via the device tree already requires a non-
> >> > trivial amount of code in the firmware. A similar amount of code would
> >> > be necessary for each type of resource that needs to be kept enabled. In
> >> > addition to the above some devices may also require resources that have
> >> > no generic bindings. That just doesn't scale.
> >>
> >> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> >> ... are up and running for the initial video mode, too. So it already needs
> >> to have this knowledge (unless enabled by SoC reset-state).
> >
> > Certainly. But not all firmware will use a DTB (or in fact the same DTB
> > as the kernel) to derive this information from, so it still needs to
> > inspect the DTB that will be passed to the kernel and painfully extract
> > information from various nodes and put it into a new node.
> >
> > But that's not even the issue. You say yourself that the firmware set
> > everything up itself already. My point is: why should the kernel have to
> > do everything again, only to come to the conclusion that it doesn't have
> > to touch hardware at all because it's already in the state that it
> > should be?
> 
> It will do nothing. It will just read from DTB what firmware has set
> up and inform all the relevant generic frameworks that these resources
> are in use. The device-specific driver (if any) will then keep the
> resource in question enabled. So all that is this patch doing is to
> correct the kernel's resource bookkeeping.

It's the device-specific driver that should be doing the book-keeping.
simplefb is only a stop-gap until a proper driver has been loaded. It
should never be considered a fully-functional driver, because it does
not know anything about the display hardware.

> > In fact, Linux will at some point set things up from scratch anyway with
> > a fully-fledged driver. But doing it in simplefb too would be doubly
> > wasteful.
> 
> It may or may not. And by having the bookkeeping straight we give that
> choice to the user.

What I'm proposing isn't really all that different. All it does is
prevent resources from being considered unused by default if a driver
that we know relies on an unspecified set of resources is active.

> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> > In practice this will mean that all unused clocks will remain in their
> > current state until the shim driver relinquishes control to the proper
> > OS driver. And if that never happens then we're at least still left with
> > a working framebuffer.
> 
> This does not work. Firstly if you do not have a full driver (because
> there is none or because kernel did not find the module, ...) then you
> could run with the shim driver and have all clocks managed properly.
> This is not possible with clk_ignore_unused.

Huh? Why not?

> Secondly clk_ignore_unused does not really mark clock as used.

Right. If that were the case it'd be called clk_use_unused() or similar.

>                                                                It only
> skips disabling them at certain point at kernel startup so that kernel
> survives that point and clock problems can be debugged. It is not
> meant as an option to be used for running the kernel indefinitely. It
> is indeed flawed: if at later point enabling or disabling a clock
> results in a parent clock becoming unused it is still disabled. This
> can affect many clocks if enabling a clock results in clock
> reparenting.
> 
> Sure, clk_ignore_unused could be fixed to actually mark all clocks
> enabled at boot time as used so that they are never disabled but
> that's orthogonal to fixing simplefb so that when it is in use the
> clock framework can work normally and can be tested, debugged, and
> used for saving power by disabling unused clocks.

Look, nobody's claiming that using the clk_ignore_unused command-line
argument is a good long-term solution. And it doesn't have to. Once you
have a proper display driver for your platform the problem goes away
entirely.

That is unless you also want to use simplefb for early boot and seamless
transition between firmware and kernel, in which case we'll return to
this discussion.

> So please stop repeating that managing system resources is
> system-specific and not fit for simplefb driver. It's been said enough
> times, and enough times pointed out that simplefb driver must as any
> other driver manage its resources (or more specifically tell the
> kernel to manage them) to work properly.

simplefb isn't anything like any other driver. If you want a proper
driver, go write a DRM/KMS driver and we can all stop having this
discussion. That's the right thing to do.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:44:19AM +0200, Michal Suchanek wrote:
> On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> Hi Thierry,
> >>
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> >> > > > > the clocks.
> >> >> > > >
> >> >> > > > You agreed on the fact that the only thing we need to do with the
> >> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> >> > > > (or not generic).
> >> >> > >
> >> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> >> > > to do with the clocks is nothing. They are already in the state that
> >> >> > > they need to be.
> >> >> >
> >> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> >> > the clock running, and both the solution you've been giving and this
> >> >> > patch do so in a generic way.
> >> >> >
> >> >> > > > > It doesn't know what frequency they should be running at
> >> >> > > >
> >> >> > > > We don't care about that. Just like we don't care about which
> >> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> >> > > > frequency is appropriate.
> >> >> > >
> >> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> >> > > already configured the clocks to run at the correct frequencies, and it
> >> >> > > has made sure that they are enabled.
> >> >> > >
> >> >> > > > > or what they're used for
> >> >> > > >
> >> >> > > > And we don't care about that either. You're not interested in what
> >> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> >> > > > here, this is the same thing here.
> >> >> > >
> >> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> >> > > cares about is the memory it should be using and the format of the
> >> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> >> > > else is assumed to have been set up.
> >> >> > >
> >> >> > > Including clocks.
> >> >> >
> >> >> > We're really discussing in circles here.
> >> >> >
> >> >> > Mike?
> >> >> >
> >> >>
> >> >> -EHIGHLATENCYRESPONSE
> >> >>
> >> >> I forgot about this thread. Sorry.
> >> >>
> >> >> In an attempt to provide the least helpful answer possible, I will stay
> >> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> >> and the related reserved memory discussion.
> >> >>
> >> >> A few times in this thread it is stated that we can't prevent unused
> >> >> clocks from being disabled. That is only partially true.
> >> >>
> >> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> >> of this.
> >> >>
> >> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> >> the right driver claims me". That would be an external or alternative
> >> >> method for preventing a clock from being disabled. We have a method for
> >> >> preventing clocks from being disabled. It is as follows:
> >> >>
> >> >> struct clk *my_clk = clk_get(...);
> >> >> clk_prepare_enable(my_clk);
> >> >>
> >> >> That is how it should be done. Period.
> >> >>
> >> >> With that said I think that Luc's approach is very sensible. I'm not
> >> >> sure what purpose in the universe DT is supposed to serve if not for
> >> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> >> people. The hardware details of how it is hooked up at the board level
> >> >> can all be hidden behind stable DT bindings that everyone already uses.
> >> >
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >>
> >> It doesn't deal with "hardware details for hardware components for which
> >> no driver is available (yet)". That's why the hardware is still in a usable
> >> state, after the firmware has set it up.
> >>
> >> Clocks, regulators, PM domains typically have system-wide implications,
> >> and thus need system-wide drivers (in the absence of such drivers,
> >> things would work as-is).
> >>
> >> Note that the driver still requests resources (ioremap the frame buffer),
> >> so it needs to know about that tiny piece of hardware detail.
> >
> > That's not a hardware detail. Or at least it isn't hardware specific. It
> > is needed and the same irrespective of display hardware. Clocks, power
> > domains, regulators and all those are not always the same.
> 
> The framebuffer address, format, etc. is as hardware specific as the
> clocks needed to run the crtc, regulators to power the backlight, etc.

Framebuffer address and format are not hardware specific. Every display
driver requires them.

> You see this from the point of view of a platform that has not clock
> driver.

Wrong. What platform's point of view do you think I look at this from?

> Then the platform has no clock information whatsoever, for any
> driver. That's platform specific too.
> 
> Why do we have to go back to this *again*?

What exactly are we going back to again?

> >> > There may be also resets involved. Fortunately the reset framework is
> >> > minimalistic enough not to care about asserting all unused resets at
> >> > late_initcall. And other things like power domains may also need to be
> >> > kept on.
> >>
> >> Fortunately, unlike clocks, PM domains are first class citizens in the
> >> device framework, as they're handled by the driver core.
> >> So just adding a power-domains property to DTS will work, without any
> >> driver change.
> >
> > Well, the device driver would also need to call into the PM runtime
> > framework to enable all the first class citizen magic. But even if it
> > were to do that, you'd still need to add all the domains to the DTB.
> >
> > Note that I'm saying DT*B* here, because the firmware needs to fill in
> > those properties after the DTS has been compiled. And since most of
> > these resources are linked via phandle you actually need to resolve
> > these first before you can fill in the new properties of this
> > dynamically created node.
> >
> > So firmware needs to know exactly what device tree node to look for,
> > find a corresponding phandle and then put the phandle value in the
> > simplefb device tree node. And it needs to know intimate details about
> > the clock provider binding because it needs to add an appropriate
> > specifier, too.
> >
> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> Note however that all the specific is in the firmware driver. The
> linux simplefb driver only needs to read DT entries which is generic
> hardware-neutral thing.

No. The DT entries are very hardware-specific. That's precisely the
reason why I think it's wrong to put this into the simplefb node,
because simplefb is an abstraction of the real hardware underneath.

> >> > Passing in clock information via the device tree already requires a non-
> >> > trivial amount of code in the firmware. A similar amount of code would
> >> > be necessary for each type of resource that needs to be kept enabled. In
> >> > addition to the above some devices may also require resources that have
> >> > no generic bindings. That just doesn't scale.
> >>
> >> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> >> ... are up and running for the initial video mode, too. So it already needs
> >> to have this knowledge (unless enabled by SoC reset-state).
> >
> > Certainly. But not all firmware will use a DTB (or in fact the same DTB
> > as the kernel) to derive this information from, so it still needs to
> > inspect the DTB that will be passed to the kernel and painfully extract
> > information from various nodes and put it into a new node.
> >
> > But that's not even the issue. You say yourself that the firmware set
> > everything up itself already. My point is: why should the kernel have to
> > do everything again, only to come to the conclusion that it doesn't have
> > to touch hardware at all because it's already in the state that it
> > should be?
> 
> It will do nothing. It will just read from DTB what firmware has set
> up and inform all the relevant generic frameworks that these resources
> are in use. The device-specific driver (if any) will then keep the
> resource in question enabled. So all that is this patch doing is to
> correct the kernel's resource bookkeeping.

It's the device-specific driver that should be doing the book-keeping.
simplefb is only a stop-gap until a proper driver has been loaded. It
should never be considered a fully-functional driver, because it does
not know anything about the display hardware.

> > In fact, Linux will at some point set things up from scratch anyway with
> > a fully-fledged driver. But doing it in simplefb too would be doubly
> > wasteful.
> 
> It may or may not. And by having the bookkeeping straight we give that
> choice to the user.

What I'm proposing isn't really all that different. All it does is
prevent resources from being considered unused by default if a driver
that we know relies on an unspecified set of resources is active.

> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> > In practice this will mean that all unused clocks will remain in their
> > current state until the shim driver relinquishes control to the proper
> > OS driver. And if that never happens then we're at least still left with
> > a working framebuffer.
> 
> This does not work. Firstly if you do not have a full driver (because
> there is none or because kernel did not find the module, ...) then you
> could run with the shim driver and have all clocks managed properly.
> This is not possible with clk_ignore_unused.

Huh? Why not?

> Secondly clk_ignore_unused does not really mark clock as used.

Right. If that were the case it'd be called clk_use_unused() or similar.

>                                                                It only
> skips disabling them at certain point at kernel startup so that kernel
> survives that point and clock problems can be debugged. It is not
> meant as an option to be used for running the kernel indefinitely. It
> is indeed flawed: if at later point enabling or disabling a clock
> results in a parent clock becoming unused it is still disabled. This
> can affect many clocks if enabling a clock results in clock
> reparenting.
> 
> Sure, clk_ignore_unused could be fixed to actually mark all clocks
> enabled at boot time as used so that they are never disabled but
> that's orthogonal to fixing simplefb so that when it is in use the
> clock framework can work normally and can be tested, debugged, and
> used for saving power by disabling unused clocks.

Look, nobody's claiming that using the clk_ignore_unused command-line
argument is a good long-term solution. And it doesn't have to. Once you
have a proper display driver for your platform the problem goes away
entirely.

That is unless you also want to use simplefb for early boot and seamless
transition between firmware and kernel, in which case we'll return to
this discussion.

> So please stop repeating that managing system resources is
> system-specific and not fit for simplefb driver. It's been said enough
> times, and enough times pointed out that simplefb driver must as any
> other driver manage its resources (or more specifically tell the
> kernel to manage them) to work properly.

simplefb isn't anything like any other driver. If you want a proper
driver, go write a DRM/KMS driver and we can all stop having this
discussion. That's the right thing to do.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/b9e52029/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 13787 bytes --]

On Mon, Sep 29, 2014 at 11:44:19AM +0200, Michal Suchanek wrote:
> On 29 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> Hi Thierry,
> >>
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> >> > > > > the clocks.
> >> >> > > >
> >> >> > > > You agreed on the fact that the only thing we need to do with the
> >> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> >> > > > (or not generic).
> >> >> > >
> >> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> >> > > to do with the clocks is nothing. They are already in the state that
> >> >> > > they need to be.
> >> >> >
> >> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> >> > the clock running, and both the solution you've been giving and this
> >> >> > patch do so in a generic way.
> >> >> >
> >> >> > > > > It doesn't know what frequency they should be running at
> >> >> > > >
> >> >> > > > We don't care about that. Just like we don't care about which
> >> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> >> > > > frequency is appropriate.
> >> >> > >
> >> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> >> > > already configured the clocks to run at the correct frequencies, and it
> >> >> > > has made sure that they are enabled.
> >> >> > >
> >> >> > > > > or what they're used for
> >> >> > > >
> >> >> > > > And we don't care about that either. You're not interested in what
> >> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> >> > > > here, this is the same thing here.
> >> >> > >
> >> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> >> > > cares about is the memory it should be using and the format of the
> >> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> >> > > else is assumed to have been set up.
> >> >> > >
> >> >> > > Including clocks.
> >> >> >
> >> >> > We're really discussing in circles here.
> >> >> >
> >> >> > Mike?
> >> >> >
> >> >>
> >> >> -EHIGHLATENCYRESPONSE
> >> >>
> >> >> I forgot about this thread. Sorry.
> >> >>
> >> >> In an attempt to provide the least helpful answer possible, I will stay
> >> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> >> and the related reserved memory discussion.
> >> >>
> >> >> A few times in this thread it is stated that we can't prevent unused
> >> >> clocks from being disabled. That is only partially true.
> >> >>
> >> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> >> of this.
> >> >>
> >> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> >> the right driver claims me". That would be an external or alternative
> >> >> method for preventing a clock from being disabled. We have a method for
> >> >> preventing clocks from being disabled. It is as follows:
> >> >>
> >> >> struct clk *my_clk = clk_get(...);
> >> >> clk_prepare_enable(my_clk);
> >> >>
> >> >> That is how it should be done. Period.
> >> >>
> >> >> With that said I think that Luc's approach is very sensible. I'm not
> >> >> sure what purpose in the universe DT is supposed to serve if not for
> >> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> >> people. The hardware details of how it is hooked up at the board level
> >> >> can all be hidden behind stable DT bindings that everyone already uses.
> >> >
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >>
> >> It doesn't deal with "hardware details for hardware components for which
> >> no driver is available (yet)". That's why the hardware is still in a usable
> >> state, after the firmware has set it up.
> >>
> >> Clocks, regulators, PM domains typically have system-wide implications,
> >> and thus need system-wide drivers (in the absence of such drivers,
> >> things would work as-is).
> >>
> >> Note that the driver still requests resources (ioremap the frame buffer),
> >> so it needs to know about that tiny piece of hardware detail.
> >
> > That's not a hardware detail. Or at least it isn't hardware specific. It
> > is needed and the same irrespective of display hardware. Clocks, power
> > domains, regulators and all those are not always the same.
> 
> The framebuffer address, format, etc. is as hardware specific as the
> clocks needed to run the crtc, regulators to power the backlight, etc.

Framebuffer address and format are not hardware specific. Every display
driver requires them.

> You see this from the point of view of a platform that has not clock
> driver.

Wrong. What platform's point of view do you think I look at this from?

> Then the platform has no clock information whatsoever, for any
> driver. That's platform specific too.
> 
> Why do we have to go back to this *again*?

What exactly are we going back to again?

> >> > There may be also resets involved. Fortunately the reset framework is
> >> > minimalistic enough not to care about asserting all unused resets at
> >> > late_initcall. And other things like power domains may also need to be
> >> > kept on.
> >>
> >> Fortunately, unlike clocks, PM domains are first class citizens in the
> >> device framework, as they're handled by the driver core.
> >> So just adding a power-domains property to DTS will work, without any
> >> driver change.
> >
> > Well, the device driver would also need to call into the PM runtime
> > framework to enable all the first class citizen magic. But even if it
> > were to do that, you'd still need to add all the domains to the DTB.
> >
> > Note that I'm saying DT*B* here, because the firmware needs to fill in
> > those properties after the DTS has been compiled. And since most of
> > these resources are linked via phandle you actually need to resolve
> > these first before you can fill in the new properties of this
> > dynamically created node.
> >
> > So firmware needs to know exactly what device tree node to look for,
> > find a corresponding phandle and then put the phandle value in the
> > simplefb device tree node. And it needs to know intimate details about
> > the clock provider binding because it needs to add an appropriate
> > specifier, too.
> >
> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> Note however that all the specific is in the firmware driver. The
> linux simplefb driver only needs to read DT entries which is generic
> hardware-neutral thing.

No. The DT entries are very hardware-specific. That's precisely the
reason why I think it's wrong to put this into the simplefb node,
because simplefb is an abstraction of the real hardware underneath.

> >> > Passing in clock information via the device tree already requires a non-
> >> > trivial amount of code in the firmware. A similar amount of code would
> >> > be necessary for each type of resource that needs to be kept enabled. In
> >> > addition to the above some devices may also require resources that have
> >> > no generic bindings. That just doesn't scale.
> >>
> >> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> >> ... are up and running for the initial video mode, too. So it already needs
> >> to have this knowledge (unless enabled by SoC reset-state).
> >
> > Certainly. But not all firmware will use a DTB (or in fact the same DTB
> > as the kernel) to derive this information from, so it still needs to
> > inspect the DTB that will be passed to the kernel and painfully extract
> > information from various nodes and put it into a new node.
> >
> > But that's not even the issue. You say yourself that the firmware set
> > everything up itself already. My point is: why should the kernel have to
> > do everything again, only to come to the conclusion that it doesn't have
> > to touch hardware at all because it's already in the state that it
> > should be?
> 
> It will do nothing. It will just read from DTB what firmware has set
> up and inform all the relevant generic frameworks that these resources
> are in use. The device-specific driver (if any) will then keep the
> resource in question enabled. So all that is this patch doing is to
> correct the kernel's resource bookkeeping.

It's the device-specific driver that should be doing the book-keeping.
simplefb is only a stop-gap until a proper driver has been loaded. It
should never be considered a fully-functional driver, because it does
not know anything about the display hardware.

> > In fact, Linux will at some point set things up from scratch anyway with
> > a fully-fledged driver. But doing it in simplefb too would be doubly
> > wasteful.
> 
> It may or may not. And by having the bookkeeping straight we give that
> choice to the user.

What I'm proposing isn't really all that different. All it does is
prevent resources from being considered unused by default if a driver
that we know relies on an unspecified set of resources is active.

> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> > In practice this will mean that all unused clocks will remain in their
> > current state until the shim driver relinquishes control to the proper
> > OS driver. And if that never happens then we're at least still left with
> > a working framebuffer.
> 
> This does not work. Firstly if you do not have a full driver (because
> there is none or because kernel did not find the module, ...) then you
> could run with the shim driver and have all clocks managed properly.
> This is not possible with clk_ignore_unused.

Huh? Why not?

> Secondly clk_ignore_unused does not really mark clock as used.

Right. If that were the case it'd be called clk_use_unused() or similar.

>                                                                It only
> skips disabling them at certain point at kernel startup so that kernel
> survives that point and clock problems can be debugged. It is not
> meant as an option to be used for running the kernel indefinitely. It
> is indeed flawed: if at later point enabling or disabling a clock
> results in a parent clock becoming unused it is still disabled. This
> can affect many clocks if enabling a clock results in clock
> reparenting.
> 
> Sure, clk_ignore_unused could be fixed to actually mark all clocks
> enabled at boot time as used so that they are never disabled but
> that's orthogonal to fixing simplefb so that when it is in use the
> clock framework can work normally and can be tested, debugged, and
> used for saving power by disabling unused clocks.

Look, nobody's claiming that using the clk_ignore_unused command-line
argument is a good long-term solution. And it doesn't have to. Once you
have a proper display driver for your platform the problem goes away
entirely.

That is unless you also want to use simplefb for early boot and seamless
transition between firmware and kernel, in which case we'll return to
this discussion.

> So please stop repeating that managing system resources is
> system-specific and not fit for simplefb driver. It's been said enough
> times, and enough times pointed out that simplefb driver must as any
> other driver manage its resources (or more specifically tell the
> kernel to manage them) to work properly.

simplefb isn't anything like any other driver. If you want a proper
driver, go write a DRM/KMS driver and we can all stop having this
discussion. That's the right thing to do.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 13847 bytes --]

On Mon, Sep 29, 2014 at 11:44:19AM +0200, Michal Suchanek wrote:
> On 29 September 2014 10:54, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> Hi Thierry,
> >>
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >> <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> >> > > > > I would think the memory should still be reserved anyway to make sure
> >> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> >> > > > > because the driver needs to know where to put framebuffer content. So
> >> >> > > > > the point I was trying to make is that we can't treat the memory in the
> >> >> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> >> >> > > > > clocks don't. The driver is simply too generic to know what to do with
> >> >> > > > > the clocks.
> >> >> > > >
> >> >> > > > You agreed on the fact that the only thing we need to do with the
> >> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> >> > > > (or not generic).
> >> >> > >
> >> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> >> > > to do with the clocks is nothing. They are already in the state that
> >> >> > > they need to be.
> >> >> >
> >> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> >> > the clock running, and both the solution you've been giving and this
> >> >> > patch do so in a generic way.
> >> >> >
> >> >> > > > > It doesn't know what frequency they should be running at
> >> >> > > >
> >> >> > > > We don't care about that. Just like we don't care about which
> >> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> >> > > > frequency is appropriate.
> >> >> > >
> >> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> >> > > already configured the clocks to run at the correct frequencies, and it
> >> >> > > has made sure that they are enabled.
> >> >> > >
> >> >> > > > > or what they're used for
> >> >> > > >
> >> >> > > > And we don't care about that either. You're not interested in what
> >> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> >> > > > here, this is the same thing here.
> >> >> > >
> >> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> >> > > cares about is the memory it should be using and the format of the
> >> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> >> > > else is assumed to have been set up.
> >> >> > >
> >> >> > > Including clocks.
> >> >> >
> >> >> > We're really discussing in circles here.
> >> >> >
> >> >> > Mike?
> >> >> >
> >> >>
> >> >> -EHIGHLATENCYRESPONSE
> >> >>
> >> >> I forgot about this thread. Sorry.
> >> >>
> >> >> In an attempt to provide the least helpful answer possible, I will stay
> >> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> >> and the related reserved memory discussion.
> >> >>
> >> >> A few times in this thread it is stated that we can't prevent unused
> >> >> clocks from being disabled. That is only partially true.
> >> >>
> >> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> >> of this.
> >> >>
> >> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> >> the right driver claims me". That would be an external or alternative
> >> >> method for preventing a clock from being disabled. We have a method for
> >> >> preventing clocks from being disabled. It is as follows:
> >> >>
> >> >> struct clk *my_clk = clk_get(...);
> >> >> clk_prepare_enable(my_clk);
> >> >>
> >> >> That is how it should be done. Period.
> >> >>
> >> >> With that said I think that Luc's approach is very sensible. I'm not
> >> >> sure what purpose in the universe DT is supposed to serve if not for
> >> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> >> people. The hardware details of how it is hooked up at the board level
> >> >> can all be hidden behind stable DT bindings that everyone already uses.
> >> >
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >>
> >> It doesn't deal with "hardware details for hardware components for which
> >> no driver is available (yet)". That's why the hardware is still in a usable
> >> state, after the firmware has set it up.
> >>
> >> Clocks, regulators, PM domains typically have system-wide implications,
> >> and thus need system-wide drivers (in the absence of such drivers,
> >> things would work as-is).
> >>
> >> Note that the driver still requests resources (ioremap the frame buffer),
> >> so it needs to know about that tiny piece of hardware detail.
> >
> > That's not a hardware detail. Or at least it isn't hardware specific. It
> > is needed and the same irrespective of display hardware. Clocks, power
> > domains, regulators and all those are not always the same.
> 
> The framebuffer address, format, etc. is as hardware specific as the
> clocks needed to run the crtc, regulators to power the backlight, etc.

Framebuffer address and format are not hardware specific. Every display
driver requires them.

> You see this from the point of view of a platform that has not clock
> driver.

Wrong. What platform's point of view do you think I look at this from?

> Then the platform has no clock information whatsoever, for any
> driver. That's platform specific too.
> 
> Why do we have to go back to this *again*?

What exactly are we going back to again?

> >> > There may be also resets involved. Fortunately the reset framework is
> >> > minimalistic enough not to care about asserting all unused resets at
> >> > late_initcall. And other things like power domains may also need to be
> >> > kept on.
> >>
> >> Fortunately, unlike clocks, PM domains are first class citizens in the
> >> device framework, as they're handled by the driver core.
> >> So just adding a power-domains property to DTS will work, without any
> >> driver change.
> >
> > Well, the device driver would also need to call into the PM runtime
> > framework to enable all the first class citizen magic. But even if it
> > were to do that, you'd still need to add all the domains to the DTB.
> >
> > Note that I'm saying DT*B* here, because the firmware needs to fill in
> > those properties after the DTS has been compiled. And since most of
> > these resources are linked via phandle you actually need to resolve
> > these first before you can fill in the new properties of this
> > dynamically created node.
> >
> > So firmware needs to know exactly what device tree node to look for,
> > find a corresponding phandle and then put the phandle value in the
> > simplefb device tree node. And it needs to know intimate details about
> > the clock provider binding because it needs to add an appropriate
> > specifier, too.
> >
> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> Note however that all the specific is in the firmware driver. The
> linux simplefb driver only needs to read DT entries which is generic
> hardware-neutral thing.

No. The DT entries are very hardware-specific. That's precisely the
reason why I think it's wrong to put this into the simplefb node,
because simplefb is an abstraction of the real hardware underneath.

> >> > Passing in clock information via the device tree already requires a non-
> >> > trivial amount of code in the firmware. A similar amount of code would
> >> > be necessary for each type of resource that needs to be kept enabled. In
> >> > addition to the above some devices may also require resources that have
> >> > no generic bindings. That just doesn't scale.
> >>
> >> [*] The firmware does need to make sure the clocks, regulators, PM domains,
> >> ... are up and running for the initial video mode, too. So it already needs
> >> to have this knowledge (unless enabled by SoC reset-state).
> >
> > Certainly. But not all firmware will use a DTB (or in fact the same DTB
> > as the kernel) to derive this information from, so it still needs to
> > inspect the DTB that will be passed to the kernel and painfully extract
> > information from various nodes and put it into a new node.
> >
> > But that's not even the issue. You say yourself that the firmware set
> > everything up itself already. My point is: why should the kernel have to
> > do everything again, only to come to the conclusion that it doesn't have
> > to touch hardware at all because it's already in the state that it
> > should be?
> 
> It will do nothing. It will just read from DTB what firmware has set
> up and inform all the relevant generic frameworks that these resources
> are in use. The device-specific driver (if any) will then keep the
> resource in question enabled. So all that is this patch doing is to
> correct the kernel's resource bookkeeping.

It's the device-specific driver that should be doing the book-keeping.
simplefb is only a stop-gap until a proper driver has been loaded. It
should never be considered a fully-functional driver, because it does
not know anything about the display hardware.

> > In fact, Linux will at some point set things up from scratch anyway with
> > a fully-fledged driver. But doing it in simplefb too would be doubly
> > wasteful.
> 
> It may or may not. And by having the bookkeeping straight we give that
> choice to the user.

What I'm proposing isn't really all that different. All it does is
prevent resources from being considered unused by default if a driver
that we know relies on an unspecified set of resources is active.

> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> > In practice this will mean that all unused clocks will remain in their
> > current state until the shim driver relinquishes control to the proper
> > OS driver. And if that never happens then we're at least still left with
> > a working framebuffer.
> 
> This does not work. Firstly if you do not have a full driver (because
> there is none or because kernel did not find the module, ...) then you
> could run with the shim driver and have all clocks managed properly.
> This is not possible with clk_ignore_unused.

Huh? Why not?

> Secondly clk_ignore_unused does not really mark clock as used.

Right. If that were the case it'd be called clk_use_unused() or similar.

>                                                                It only
> skips disabling them at certain point at kernel startup so that kernel
> survives that point and clock problems can be debugged. It is not
> meant as an option to be used for running the kernel indefinitely. It
> is indeed flawed: if at later point enabling or disabling a clock
> results in a parent clock becoming unused it is still disabled. This
> can affect many clocks if enabling a clock results in clock
> reparenting.
> 
> Sure, clk_ignore_unused could be fixed to actually mark all clocks
> enabled at boot time as used so that they are never disabled but
> that's orthogonal to fixing simplefb so that when it is in use the
> clock framework can work normally and can be tested, debugged, and
> used for saving power by disabling unused clocks.

Look, nobody's claiming that using the clk_ignore_unused command-line
argument is a good long-term solution. And it doesn't have to. Once you
have a proper display driver for your platform the problem goes away
entirely.

That is unless you also want to use simplefb for early boot and seamless
transition between firmware and kernel, in which case we'll return to
this discussion.

> So please stop repeating that managing system resources is
> system-specific and not fit for simplefb driver. It's been said enough
> times, and enough times pointed out that simplefb driver must as any
> other driver manage its resources (or more specifically tell the
> kernel to manage them) to work properly.

simplefb isn't anything like any other driver. If you want a proper
driver, go write a DRM/KMS driver and we can all stop having this
discussion. That's the right thing to do.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 8240 bytes --]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. So
> > > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > > the clocks.
> > > > > 
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > > 
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > > 
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > > 
> > > > > > It doesn't know what frequency they should be running at
> > > > > 
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > > 
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > > 
> > > > > > or what they're used for
> > > > > 
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > > 
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > > 
> > > > Including clocks.
> > > 
> > > We're really discussing in circles here.
> > > 
> > > Mike?
> > > 
> > 
> > -EHIGHLATENCYRESPONSE
> > 
> > I forgot about this thread. Sorry.
> > 
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> > 
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> > 
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> > 
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> > 
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> > 
> > That is how it should be done. Period.
> > 
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
> 
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

Which makes the whole even simpler, since the firmware already knows
all about which clocks it had to enable.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.
> 
> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.
> 
> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.
> 
> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).

You should really read that thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html

It's quite interesting, because you'll see that:
A) Your approach, even on the platform you're working on, doesn't
   work. Or at least, isn't reliable.
B) Other maintainers, precisely like Mark, came to the same conclusion
   than Mike.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

So, just to be clear, instead of doing a generic clk_get and
clk_prepare_enable, you're willing to do a just as much generic
clk_ignore_unused call?

How is that less generic? You know that you are going to call that for
regulator, reset, power domains, just as you would have needed to with
the proper API, unless that with this kind of solution, you would have
to modify *every* framework that might interact with any resource
involved in getting simplefb running?

Plus, speaking more specifically about the clocks, that won't prevent
your clock to be shut down as a side effect of a later clk_disable
call from another driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. So
> > > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > > the clocks.
> > > > > 
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > > 
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > > 
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > > 
> > > > > > It doesn't know what frequency they should be running at
> > > > > 
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > > 
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > > 
> > > > > > or what they're used for
> > > > > 
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > > 
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > > 
> > > > Including clocks.
> > > 
> > > We're really discussing in circles here.
> > > 
> > > Mike?
> > > 
> > 
> > -EHIGHLATENCYRESPONSE
> > 
> > I forgot about this thread. Sorry.
> > 
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> > 
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> > 
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> > 
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> > 
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> > 
> > That is how it should be done. Period.
> > 
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
> 
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

Which makes the whole even simpler, since the firmware already knows
all about which clocks it had to enable.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.
> 
> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.
> 
> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.
> 
> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).

You should really read that thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html

It's quite interesting, because you'll see that:
A) Your approach, even on the platform you're working on, doesn't
   work. Or at least, isn't reliable.
B) Other maintainers, precisely like Mark, came to the same conclusion
   than Mike.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

So, just to be clear, instead of doing a generic clk_get and
clk_prepare_enable, you're willing to do a just as much generic
clk_ignore_unused call?

How is that less generic? You know that you are going to call that for
regulator, reset, power domains, just as you would have needed to with
the proper API, unless that with this kind of solution, you would have
to modify *every* framework that might interact with any resource
involved in getting simplefb running?

Plus, speaking more specifically about the clocks, that won't prevent
your clock to be shut down as a side effect of a later clk_disable
call from another driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/86543453/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6141 bytes --]

On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
[...]
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> Which makes the whole even simpler, since the firmware already knows
> all about which clocks it had to enable.

It makes things very complicated in the firmware because it now needs to
be able to generate DTB content that we would otherwise be able to do
much easier with a text editor.

> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> > 
> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> > 
> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> > 
> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> 
> You should really read that thread:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> 
> It's quite interesting, because you'll see that:
> A) Your approach, even on the platform you're working on, doesn't
>    work. Or at least, isn't reliable.

What platform exactly do you think I'm working on? Why do you think what
I proposed isn't going to work or be reliable? I don't see any arguments
in the thread that would imply that.

> B) Other maintainers, precisely like Mark, came to the same conclusion
>    than Mike.

Well, and others didn't.

Also I think if you read that thread and look at my proposal it matches
exactly what was discussed as one of the solutions at one point in the
thread.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> So, just to be clear, instead of doing a generic clk_get and
> clk_prepare_enable, you're willing to do a just as much generic
> clk_ignore_unused call?

Yes.

> How is that less generic?

It's more generic. That's the whole point.

The difference is that with the solution I proposed we don't have to
keep track of all the resources. We know that firmware has set them up
and we know that a real driver will properly take them over at some
point, so duplicating what the real driver does within the simplefb
driver is just that, duplication. We don't allow duplication anywhere
else in the kernel, why should simplefb be an exception?

> You know that you are going to call that for regulator, reset, power
> domains, just as you would have needed to with the proper API, unless
> that with this kind of solution, you would have to modify *every*
> framework that might interact with any resource involved in getting
> simplefb running?

We have to add handling for every kind of resource either way. Also if
this evolves into a common pattern we can easily wrap it up in a single
function call.

> Plus, speaking more specifically about the clocks, that won't prevent
> your clock to be shut down as a side effect of a later clk_disable
> call from another driver.

If we need to prevent that, then that's something that could be fixed,
too. But both this and the other thread at least agree on the fact that
simplefb is a shim driver that's going to be replaced by something real
at some point, so hopefully concurrent users aren't the problem because
that would cause the real driver to break too.

Also note that if some other driver could call clk_disable() it could
just as easily call clk_set_rate() and break simplefb.

Furthermore isn't it a bug for a driver to call clk_disable() before a
preceding clk_enable()? There are patches being worked on that will
enable per-user clocks and as I understand it they will specifically
disallow drivers to disable the hardware clock if other drivers are
still keeping them on via their own referenc.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
[...]
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> Which makes the whole even simpler, since the firmware already knows
> all about which clocks it had to enable.

It makes things very complicated in the firmware because it now needs to
be able to generate DTB content that we would otherwise be able to do
much easier with a text editor.

> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> > 
> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> > 
> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> > 
> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> 
> You should really read that thread:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> 
> It's quite interesting, because you'll see that:
> A) Your approach, even on the platform you're working on, doesn't
>    work. Or at least, isn't reliable.

What platform exactly do you think I'm working on? Why do you think what
I proposed isn't going to work or be reliable? I don't see any arguments
in the thread that would imply that.

> B) Other maintainers, precisely like Mark, came to the same conclusion
>    than Mike.

Well, and others didn't.

Also I think if you read that thread and look at my proposal it matches
exactly what was discussed as one of the solutions at one point in the
thread.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> So, just to be clear, instead of doing a generic clk_get and
> clk_prepare_enable, you're willing to do a just as much generic
> clk_ignore_unused call?

Yes.

> How is that less generic?

It's more generic. That's the whole point.

The difference is that with the solution I proposed we don't have to
keep track of all the resources. We know that firmware has set them up
and we know that a real driver will properly take them over at some
point, so duplicating what the real driver does within the simplefb
driver is just that, duplication. We don't allow duplication anywhere
else in the kernel, why should simplefb be an exception?

> You know that you are going to call that for regulator, reset, power
> domains, just as you would have needed to with the proper API, unless
> that with this kind of solution, you would have to modify *every*
> framework that might interact with any resource involved in getting
> simplefb running?

We have to add handling for every kind of resource either way. Also if
this evolves into a common pattern we can easily wrap it up in a single
function call.

> Plus, speaking more specifically about the clocks, that won't prevent
> your clock to be shut down as a side effect of a later clk_disable
> call from another driver.

If we need to prevent that, then that's something that could be fixed,
too. But both this and the other thread at least agree on the fact that
simplefb is a shim driver that's going to be replaced by something real
at some point, so hopefully concurrent users aren't the problem because
that would cause the real driver to break too.

Also note that if some other driver could call clk_disable() it could
just as easily call clk_set_rate() and break simplefb.

Furthermore isn't it a bug for a driver to call clk_disable() before a
preceding clk_enable()? There are patches being worked on that will
enable per-user clocks and as I understand it they will specifically
disallow drivers to disable the hardware clock if other drivers are
still keeping them on via their own referenc.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/3e3ca957/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>> How is that less generic?
>
> It's more generic. That's the whole point.
>
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point, so duplicating what the real driver does within the simplefb
> driver is just that, duplication. We don't allow duplication anywhere
> else in the kernel, why should simplefb be an exception?
>
>> You know that you are going to call that for regulator, reset, power
>> domains, just as you would have needed to with the proper API, unless
>> that with this kind of solution, you would have to modify *every*
>> framework that might interact with any resource involved in getting
>> simplefb running?
>
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.

disable_all_power_management(), as this is not limited to clocks.

>> Plus, speaking more specifically about the clocks, that won't prevent
>> your clock to be shut down as a side effect of a later clk_disable
>> call from another driver.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.

Calling clk_disable() preceding clk_enable() is a bug.

Calling clk_disable() after clk_enable() will disable the clock (and
its parents)
if the clock subsystem thinks there are no other users, which is what will
happen here.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>> How is that less generic?
>
> It's more generic. That's the whole point.
>
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point, so duplicating what the real driver does within the simplefb
> driver is just that, duplication. We don't allow duplication anywhere
> else in the kernel, why should simplefb be an exception?
>
>> You know that you are going to call that for regulator, reset, power
>> domains, just as you would have needed to with the proper API, unless
>> that with this kind of solution, you would have to modify *every*
>> framework that might interact with any resource involved in getting
>> simplefb running?
>
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.

disable_all_power_management(), as this is not limited to clocks.

>> Plus, speaking more specifically about the clocks, that won't prevent
>> your clock to be shut down as a side effect of a later clk_disable
>> call from another driver.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.

Calling clk_disable() preceding clk_enable() is a bug.

Calling clk_disable() after clk_enable() will disable the clock (and
its parents)
if the clock subsystem thinks there are no other users, which is what will
happen here.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

On Mon, Sep 29, 2014 at 12:35:17PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> >> How is that less generic?
> >
> > It's more generic. That's the whole point.
> >
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point, so duplicating what the real driver does within the simplefb
> > driver is just that, duplication. We don't allow duplication anywhere
> > else in the kernel, why should simplefb be an exception?
> >
> >> You know that you are going to call that for regulator, reset, power
> >> domains, just as you would have needed to with the proper API, unless
> >> that with this kind of solution, you would have to modify *every*
> >> framework that might interact with any resource involved in getting
> >> simplefb running?
> >
> > We have to add handling for every kind of resource either way. Also if
> > this evolves into a common pattern we can easily wrap it up in a single
> > function call.
> 
> disable_all_power_management(), as this is not limited to clocks.

Right. But it isn't all power management either. It just shouldn't turn
everything unused off. Clocks, regulators, power domains and so on which
are used can very well be power managed.

> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> your clock to be shut down as a side effect of a later clk_disable
> >> call from another driver.
> 
> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > preceding clk_enable()? There are patches being worked on that will
> > enable per-user clocks and as I understand it they will specifically
> > disallow drivers to disable the hardware clock if other drivers are
> > still keeping them on via their own referenc.
> 
> Calling clk_disable() preceding clk_enable() is a bug.
> 
> Calling clk_disable() after clk_enable() will disable the clock (and
> its parents)
> if the clock subsystem thinks there are no other users, which is what will
> happen here.

Right. I'm not sure this is really applicable to this situation, though.
Either way, if there are other users of a clock then they will just as
likely want to modify the rate at which point simplefb will break just
as badly.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 12:35:17PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> >> How is that less generic?
> >
> > It's more generic. That's the whole point.
> >
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point, so duplicating what the real driver does within the simplefb
> > driver is just that, duplication. We don't allow duplication anywhere
> > else in the kernel, why should simplefb be an exception?
> >
> >> You know that you are going to call that for regulator, reset, power
> >> domains, just as you would have needed to with the proper API, unless
> >> that with this kind of solution, you would have to modify *every*
> >> framework that might interact with any resource involved in getting
> >> simplefb running?
> >
> > We have to add handling for every kind of resource either way. Also if
> > this evolves into a common pattern we can easily wrap it up in a single
> > function call.
> 
> disable_all_power_management(), as this is not limited to clocks.

Right. But it isn't all power management either. It just shouldn't turn
everything unused off. Clocks, regulators, power domains and so on which
are used can very well be power managed.

> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> your clock to be shut down as a side effect of a later clk_disable
> >> call from another driver.
> 
> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > preceding clk_enable()? There are patches being worked on that will
> > enable per-user clocks and as I understand it they will specifically
> > disallow drivers to disable the hardware clock if other drivers are
> > still keeping them on via their own referenc.
> 
> Calling clk_disable() preceding clk_enable() is a bug.
> 
> Calling clk_disable() after clk_enable() will disable the clock (and
> its parents)
> if the clock subsystem thinks there are no other users, which is what will
> happen here.

Right. I'm not sure this is really applicable to this situation, though.
Either way, if there are other users of a clock then they will just as
likely want to modify the rate at which point simplefb will break just
as badly.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/6eb50a02/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>> >> You know that you are going to call that for regulator, reset, power
>> >> domains, just as you would have needed to with the proper API, unless
>> >> that with this kind of solution, you would have to modify *every*
>> >> framework that might interact with any resource involved in getting
>> >> simplefb running?
>> >
>> > We have to add handling for every kind of resource either way. Also if
>> > this evolves into a common pattern we can easily wrap it up in a single
>> > function call.
>>
>> disable_all_power_management(), as this is not limited to clocks.
>
> Right. But it isn't all power management either. It just shouldn't turn
> everything unused off. Clocks, regulators, power domains and so on which
> are used can very well be power managed.

No they can't, as the clock/regulator/PM domain core cannot know if any
of the used ones are also used by a shim driver like simplefb.
Clocks and regulators may be shared. PM domains can contain multiple
hardware blocks. Without more knowledge, the only safe thing is not
disabling anything.

>> >> Plus, speaking more specifically about the clocks, that won't prevent
>> >> your clock to be shut down as a side effect of a later clk_disable
>> >> call from another driver.
>>
>> > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > preceding clk_enable()? There are patches being worked on that will
>> > enable per-user clocks and as I understand it they will specifically
>> > disallow drivers to disable the hardware clock if other drivers are
>> > still keeping them on via their own referenc.
>>
>> Calling clk_disable() preceding clk_enable() is a bug.
>>
>> Calling clk_disable() after clk_enable() will disable the clock (and
>> its parents)
>> if the clock subsystem thinks there are no other users, which is what will
>> happen here.
>
> Right. I'm not sure this is really applicable to this situation, though.

Yes it is: if all users of a clock/regulator/PM domain are gone, it will
be disabled. Bad luck for simplefb still needing them.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

BTW, this can also happen for clocks that are properly used.
I guess the clock core code does some arbitration to handle such cases.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>> >> You know that you are going to call that for regulator, reset, power
>> >> domains, just as you would have needed to with the proper API, unless
>> >> that with this kind of solution, you would have to modify *every*
>> >> framework that might interact with any resource involved in getting
>> >> simplefb running?
>> >
>> > We have to add handling for every kind of resource either way. Also if
>> > this evolves into a common pattern we can easily wrap it up in a single
>> > function call.
>>
>> disable_all_power_management(), as this is not limited to clocks.
>
> Right. But it isn't all power management either. It just shouldn't turn
> everything unused off. Clocks, regulators, power domains and so on which
> are used can very well be power managed.

No they can't, as the clock/regulator/PM domain core cannot know if any
of the used ones are also used by a shim driver like simplefb.
Clocks and regulators may be shared. PM domains can contain multiple
hardware blocks. Without more knowledge, the only safe thing is not
disabling anything.

>> >> Plus, speaking more specifically about the clocks, that won't prevent
>> >> your clock to be shut down as a side effect of a later clk_disable
>> >> call from another driver.
>>
>> > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > preceding clk_enable()? There are patches being worked on that will
>> > enable per-user clocks and as I understand it they will specifically
>> > disallow drivers to disable the hardware clock if other drivers are
>> > still keeping them on via their own referenc.
>>
>> Calling clk_disable() preceding clk_enable() is a bug.
>>
>> Calling clk_disable() after clk_enable() will disable the clock (and
>> its parents)
>> if the clock subsystem thinks there are no other users, which is what will
>> happen here.
>
> Right. I'm not sure this is really applicable to this situation, though.

Yes it is: if all users of a clock/regulator/PM domain are gone, it will
be disabled. Bad luck for simplefb still needing them.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

BTW, this can also happen for clocks that are properly used.
I guess the clock core code does some arbitration to handle such cases.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

On Mon, Sep 29, 2014 at 01:32:44PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> >> >> You know that you are going to call that for regulator, reset, power
> >> >> domains, just as you would have needed to with the proper API, unless
> >> >> that with this kind of solution, you would have to modify *every*
> >> >> framework that might interact with any resource involved in getting
> >> >> simplefb running?
> >> >
> >> > We have to add handling for every kind of resource either way. Also if
> >> > this evolves into a common pattern we can easily wrap it up in a single
> >> > function call.
> >>
> >> disable_all_power_management(), as this is not limited to clocks.
> >
> > Right. But it isn't all power management either. It just shouldn't turn
> > everything unused off. Clocks, regulators, power domains and so on which
> > are used can very well be power managed.
> 
> No they can't, as the clock/regulator/PM domain core cannot know if any
> of the used ones are also used by a shim driver like simplefb.
> Clocks and regulators may be shared. PM domains can contain multiple
> hardware blocks. Without more knowledge, the only safe thing is not
> disabling anything.

Indeed. That's a shame. In the most common case that probably won't
matter all that much, given that the real driver can be expected to load
within a reasonable amount of time.

> >> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> >> your clock to be shut down as a side effect of a later clk_disable
> >> >> call from another driver.
> >>
> >> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > preceding clk_enable()? There are patches being worked on that will
> >> > enable per-user clocks and as I understand it they will specifically
> >> > disallow drivers to disable the hardware clock if other drivers are
> >> > still keeping them on via their own referenc.
> >>
> >> Calling clk_disable() preceding clk_enable() is a bug.
> >>
> >> Calling clk_disable() after clk_enable() will disable the clock (and
> >> its parents)
> >> if the clock subsystem thinks there are no other users, which is what will
> >> happen here.
> >
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> Yes it is: if all users of a clock/regulator/PM domain are gone, it will
> be disabled. Bad luck for simplefb still needing them.

Hmm... if all users are gone, then aren't the resources unused again and
should therefore be ignored?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:32:44PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> >> >> You know that you are going to call that for regulator, reset, power
> >> >> domains, just as you would have needed to with the proper API, unless
> >> >> that with this kind of solution, you would have to modify *every*
> >> >> framework that might interact with any resource involved in getting
> >> >> simplefb running?
> >> >
> >> > We have to add handling for every kind of resource either way. Also if
> >> > this evolves into a common pattern we can easily wrap it up in a single
> >> > function call.
> >>
> >> disable_all_power_management(), as this is not limited to clocks.
> >
> > Right. But it isn't all power management either. It just shouldn't turn
> > everything unused off. Clocks, regulators, power domains and so on which
> > are used can very well be power managed.
> 
> No they can't, as the clock/regulator/PM domain core cannot know if any
> of the used ones are also used by a shim driver like simplefb.
> Clocks and regulators may be shared. PM domains can contain multiple
> hardware blocks. Without more knowledge, the only safe thing is not
> disabling anything.

Indeed. That's a shame. In the most common case that probably won't
matter all that much, given that the real driver can be expected to load
within a reasonable amount of time.

> >> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> >> your clock to be shut down as a side effect of a later clk_disable
> >> >> call from another driver.
> >>
> >> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > preceding clk_enable()? There are patches being worked on that will
> >> > enable per-user clocks and as I understand it they will specifically
> >> > disallow drivers to disable the hardware clock if other drivers are
> >> > still keeping them on via their own referenc.
> >>
> >> Calling clk_disable() preceding clk_enable() is a bug.
> >>
> >> Calling clk_disable() after clk_enable() will disable the clock (and
> >> its parents)
> >> if the clock subsystem thinks there are no other users, which is what will
> >> happen here.
> >
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> Yes it is: if all users of a clock/regulator/PM domain are gone, it will
> be disabled. Bad luck for simplefb still needing them.

Hmm... if all users are gone, then aren't the resources unused again and
should therefore be ignored?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/acf79846/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > >> Plus, speaking more specifically about the clocks, that won't prevent
> > >> your clock to be shut down as a side effect of a later clk_disable
> > >> call from another driver.
> > 
> > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > preceding clk_enable()? There are patches being worked on that will
> > > enable per-user clocks and as I understand it they will specifically
> > > disallow drivers to disable the hardware clock if other drivers are
> > > still keeping them on via their own referenc.
> > 
> > Calling clk_disable() preceding clk_enable() is a bug.
> > 
> > Calling clk_disable() after clk_enable() will disable the clock (and
> > its parents)
> > if the clock subsystem thinks there are no other users, which is what will
> > happen here.
> 
> Right. I'm not sure this is really applicable to this situation, though.

It's actually very easy to do. Have a driver that probes, enables its
clock, fails to probe for any reason, call clk_disable in its exit
path. If there's no other user at that time of this particular clock
tree, it will be shut down. Bam. You just lost your framebuffer.

Really, it's just that simple, and relying on the fact that some other
user of the same clock tree will always be their is beyond fragile.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

And this can be handled just as well. Register a clock notifier,
refuse any rate change, done. But of course, that would require having
a clock handle.

Now, how would *you* prevent such a change?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > >> Plus, speaking more specifically about the clocks, that won't prevent
> > >> your clock to be shut down as a side effect of a later clk_disable
> > >> call from another driver.
> > 
> > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > preceding clk_enable()? There are patches being worked on that will
> > > enable per-user clocks and as I understand it they will specifically
> > > disallow drivers to disable the hardware clock if other drivers are
> > > still keeping them on via their own referenc.
> > 
> > Calling clk_disable() preceding clk_enable() is a bug.
> > 
> > Calling clk_disable() after clk_enable() will disable the clock (and
> > its parents)
> > if the clock subsystem thinks there are no other users, which is what will
> > happen here.
> 
> Right. I'm not sure this is really applicable to this situation, though.

It's actually very easy to do. Have a driver that probes, enables its
clock, fails to probe for any reason, call clk_disable in its exit
path. If there's no other user at that time of this particular clock
tree, it will be shut down. Bam. You just lost your framebuffer.

Really, it's just that simple, and relying on the fact that some other
user of the same clock tree will always be their is beyond fragile.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

And this can be handled just as well. Register a clock notifier,
refuse any rate change, done. But of course, that would require having
a clock handle.

Now, how would *you* prevent such a change?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/a36af406/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > >> your clock to be shut down as a side effect of a later clk_disable
> > > >> call from another driver.
> > > 
> > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > preceding clk_enable()? There are patches being worked on that will
> > > > enable per-user clocks and as I understand it they will specifically
> > > > disallow drivers to disable the hardware clock if other drivers are
> > > > still keeping them on via their own referenc.
> > > 
> > > Calling clk_disable() preceding clk_enable() is a bug.
> > > 
> > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > its parents)
> > > if the clock subsystem thinks there are no other users, which is what will
> > > happen here.
> > 
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> It's actually very easy to do. Have a driver that probes, enables its
> clock, fails to probe for any reason, call clk_disable in its exit
> path. If there's no other user at that time of this particular clock
> tree, it will be shut down. Bam. You just lost your framebuffer.
> 
> Really, it's just that simple, and relying on the fact that some other
> user of the same clock tree will always be their is beyond fragile.

Perhaps the meaning clk_ignore_unused should be revised, then. What you
describe isn't at all what I'd expect from such an option. And it does
not match the description in Documentation/kernel-parameters.txt either.

> > Either way, if there are other users of a clock then they will just as
> > likely want to modify the rate at which point simplefb will break just
> > as badly.
> 
> And this can be handled just as well. Register a clock notifier,
> refuse any rate change, done. But of course, that would require having
> a clock handle.
> 
> Now, how would *you* prevent such a change?

Like I said in the other thread. If you have two drivers that use the
same clock but need different frequencies you've lost anyway.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > >> your clock to be shut down as a side effect of a later clk_disable
> > > >> call from another driver.
> > > 
> > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > preceding clk_enable()? There are patches being worked on that will
> > > > enable per-user clocks and as I understand it they will specifically
> > > > disallow drivers to disable the hardware clock if other drivers are
> > > > still keeping them on via their own referenc.
> > > 
> > > Calling clk_disable() preceding clk_enable() is a bug.
> > > 
> > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > its parents)
> > > if the clock subsystem thinks there are no other users, which is what will
> > > happen here.
> > 
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> It's actually very easy to do. Have a driver that probes, enables its
> clock, fails to probe for any reason, call clk_disable in its exit
> path. If there's no other user at that time of this particular clock
> tree, it will be shut down. Bam. You just lost your framebuffer.
> 
> Really, it's just that simple, and relying on the fact that some other
> user of the same clock tree will always be their is beyond fragile.

Perhaps the meaning clk_ignore_unused should be revised, then. What you
describe isn't at all what I'd expect from such an option. And it does
not match the description in Documentation/kernel-parameters.txt either.

> > Either way, if there are other users of a clock then they will just as
> > likely want to modify the rate at which point simplefb will break just
> > as badly.
> 
> And this can be handled just as well. Register a clock notifier,
> refuse any rate change, done. But of course, that would require having
> a clock handle.
> 
> Now, how would *you* prevent such a change?

Like I said in the other thread. If you have two drivers that use the
same clock but need different frequencies you've lost anyway.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/1a341b5c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > >> call from another driver.
> > > > 
> > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > enable per-user clocks and as I understand it they will specifically
> > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > still keeping them on via their own referenc.
> > > > 
> > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > 
> > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > its parents)
> > > > if the clock subsystem thinks there are no other users, which is what will
> > > > happen here.
> > > 
> > > Right. I'm not sure this is really applicable to this situation, though.
> > 
> > It's actually very easy to do. Have a driver that probes, enables its
> > clock, fails to probe for any reason, call clk_disable in its exit
> > path. If there's no other user at that time of this particular clock
> > tree, it will be shut down. Bam. You just lost your framebuffer.
> > 
> > Really, it's just that simple, and relying on the fact that some other
> > user of the same clock tree will always be their is beyond fragile.
> 
> Perhaps the meaning clk_ignore_unused should be revised, then. What you
> describe isn't at all what I'd expect from such an option. And it does
> not match the description in Documentation/kernel-parameters.txt either.

Well, it never says that it also prevent them from being disabled
later on. But it's true it's not very explicit.

> > > Either way, if there are other users of a clock then they will just as
> > > likely want to modify the rate at which point simplefb will break just
> > > as badly.
> > 
> > And this can be handled just as well. Register a clock notifier,
> > refuse any rate change, done. But of course, that would require having
> > a clock handle.
> > 
> > Now, how would *you* prevent such a change?
> 
> Like I said in the other thread. If you have two drivers that use the
> same clock but need different frequencies you've lost anyway.

Except that the driver that has the most logic (ie not simplefb) will
have a way to recover and deal with that. You prevented the clock rate
*and* your system can react, I guess you actually won.

But sure, you can still try to point new issues, get an obvious and
robust solution, and then discard the issue when the solution doesn't
go your way...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > >> call from another driver.
> > > > 
> > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > enable per-user clocks and as I understand it they will specifically
> > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > still keeping them on via their own referenc.
> > > > 
> > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > 
> > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > its parents)
> > > > if the clock subsystem thinks there are no other users, which is what will
> > > > happen here.
> > > 
> > > Right. I'm not sure this is really applicable to this situation, though.
> > 
> > It's actually very easy to do. Have a driver that probes, enables its
> > clock, fails to probe for any reason, call clk_disable in its exit
> > path. If there's no other user at that time of this particular clock
> > tree, it will be shut down. Bam. You just lost your framebuffer.
> > 
> > Really, it's just that simple, and relying on the fact that some other
> > user of the same clock tree will always be their is beyond fragile.
> 
> Perhaps the meaning clk_ignore_unused should be revised, then. What you
> describe isn't at all what I'd expect from such an option. And it does
> not match the description in Documentation/kernel-parameters.txt either.

Well, it never says that it also prevent them from being disabled
later on. But it's true it's not very explicit.

> > > Either way, if there are other users of a clock then they will just as
> > > likely want to modify the rate at which point simplefb will break just
> > > as badly.
> > 
> > And this can be handled just as well. Register a clock notifier,
> > refuse any rate change, done. But of course, that would require having
> > a clock handle.
> > 
> > Now, how would *you* prevent such a change?
> 
> Like I said in the other thread. If you have two drivers that use the
> same clock but need different frequencies you've lost anyway.

Except that the driver that has the most logic (ie not simplefb) will
have a way to recover and deal with that. You prevented the clock rate
*and* your system can react, I guess you actually won.

But sure, you can still try to point new issues, get an obvious and
robust solution, and then discard the issue when the solution doesn't
go your way...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/4245fc55/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > >> call from another driver.
> > > > > 
> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > still keeping them on via their own referenc.
> > > > > 
> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > 
> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > its parents)
> > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > happen here.
> > > > 
> > > > Right. I'm not sure this is really applicable to this situation, though.
> > > 
> > > It's actually very easy to do. Have a driver that probes, enables its
> > > clock, fails to probe for any reason, call clk_disable in its exit
> > > path. If there's no other user at that time of this particular clock
> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > 
> > > Really, it's just that simple, and relying on the fact that some other
> > > user of the same clock tree will always be their is beyond fragile.
> > 
> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > describe isn't at all what I'd expect from such an option. And it does
> > not match the description in Documentation/kernel-parameters.txt either.
> 
> Well, it never says that it also prevent them from being disabled
> later on. But it's true it's not very explicit.

It says:

	Keep all clocks already enabled by bootloader on,
	even if no driver has claimed them. ...

There's no "until" or anything there, so I interpret that as
indefinitely.

> > > > Either way, if there are other users of a clock then they will just as
> > > > likely want to modify the rate at which point simplefb will break just
> > > > as badly.
> > > 
> > > And this can be handled just as well. Register a clock notifier,
> > > refuse any rate change, done. But of course, that would require having
> > > a clock handle.
> > > 
> > > Now, how would *you* prevent such a change?
> > 
> > Like I said in the other thread. If you have two drivers that use the
> > same clock but need different frequencies you've lost anyway.
> 
> Except that the driver that has the most logic (ie not simplefb) will
> have a way to recover and deal with that.

You're making an assumption here. Why would the driver have such logic
if nothing ever prevented it from setting the rate properly before.

> But sure, you can still try to point new issues, get an obvious and
> robust solution, and then discard the issue when the solution doesn't
> go your way...

And you've already proven that you're completely unwilling to even
consider any other solution than what was originally proposed, so I
really don't see how discussing this further with you is going to be
productive.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > >> call from another driver.
> > > > > 
> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > still keeping them on via their own referenc.
> > > > > 
> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > 
> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > its parents)
> > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > happen here.
> > > > 
> > > > Right. I'm not sure this is really applicable to this situation, though.
> > > 
> > > It's actually very easy to do. Have a driver that probes, enables its
> > > clock, fails to probe for any reason, call clk_disable in its exit
> > > path. If there's no other user at that time of this particular clock
> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > 
> > > Really, it's just that simple, and relying on the fact that some other
> > > user of the same clock tree will always be their is beyond fragile.
> > 
> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > describe isn't at all what I'd expect from such an option. And it does
> > not match the description in Documentation/kernel-parameters.txt either.
> 
> Well, it never says that it also prevent them from being disabled
> later on. But it's true it's not very explicit.

It says:

	Keep all clocks already enabled by bootloader on,
	even if no driver has claimed them. ...

There's no "until" or anything there, so I interpret that as
indefinitely.

> > > > Either way, if there are other users of a clock then they will just as
> > > > likely want to modify the rate at which point simplefb will break just
> > > > as badly.
> > > 
> > > And this can be handled just as well. Register a clock notifier,
> > > refuse any rate change, done. But of course, that would require having
> > > a clock handle.
> > > 
> > > Now, how would *you* prevent such a change?
> > 
> > Like I said in the other thread. If you have two drivers that use the
> > same clock but need different frequencies you've lost anyway.
> 
> Except that the driver that has the most logic (ie not simplefb) will
> have a way to recover and deal with that.

You're making an assumption here. Why would the driver have such logic
if nothing ever prevented it from setting the rate properly before.

> But sure, you can still try to point new issues, get an obvious and
> robust solution, and then discard the issue when the solution doesn't
> go your way...

And you've already proven that you're completely unwilling to even
consider any other solution than what was originally proposed, so I
really don't see how discussing this further with you is going to be
productive.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/34cb9718/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4647 bytes --]

On Tue, Sep 30, 2014 at 06:59:59AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > > >> call from another driver.
> > > > > > 
> > > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > > still keeping them on via their own referenc.
> > > > > > 
> > > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > > 
> > > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > > its parents)
> > > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > > happen here.
> > > > > 
> > > > > Right. I'm not sure this is really applicable to this situation, though.
> > > > 
> > > > It's actually very easy to do. Have a driver that probes, enables its
> > > > clock, fails to probe for any reason, call clk_disable in its exit
> > > > path. If there's no other user at that time of this particular clock
> > > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > > 
> > > > Really, it's just that simple, and relying on the fact that some other
> > > > user of the same clock tree will always be their is beyond fragile.
> > > 
> > > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > > describe isn't at all what I'd expect from such an option. And it does
> > > not match the description in Documentation/kernel-parameters.txt either.
> > 
> > Well, it never says that it also prevent them from being disabled
> > later on. But it's true it's not very explicit.
> 
> It says:
> 
> 	Keep all clocks already enabled by bootloader on,
> 	even if no driver has claimed them. ...
> 
> There's no "until" or anything there, so I interpret that as
> indefinitely.

Well, then, sorry, but that's not how it works.

> > > > > Either way, if there are other users of a clock then they will just as
> > > > > likely want to modify the rate at which point simplefb will break just
> > > > > as badly.
> > > > 
> > > > And this can be handled just as well. Register a clock notifier,
> > > > refuse any rate change, done. But of course, that would require having
> > > > a clock handle.
> > > > 
> > > > Now, how would *you* prevent such a change?
> > > 
> > > Like I said in the other thread. If you have two drivers that use the
> > > same clock but need different frequencies you've lost anyway.
> > 
> > Except that the driver that has the most logic (ie not simplefb) will
> > have a way to recover and deal with that.
> 
> You're making an assumption here. Why would the driver have such logic
> if nothing ever prevented it from setting the rate properly before.

I'm not saying it has, but it something that can be done. You usually
have several strategies, which depending on the device, might or might
not be possible, such as reparenting, trying to use an additional
divider.

Worst case scenario, you're indeed doomed. But you do have a best case
scenario, which isn't the case with your approach. And you didn't
screw the framebuffer silently.

> > But sure, you can still try to point new issues, get an obvious and
> > robust solution, and then discard the issue when the solution doesn't
> > go your way...
> 
> And you've already proven that you're completely unwilling to even
> consider any other solution than what was originally proposed, so I
> really don't see how discussing this further with you is going to be
> productive.

You haven't express *what* you wanted to achieve for quite some time,
but only *how*. And your how has some deficiencies that have already
been pointed out numerous times.

However, I do come to the same conclusion. I really don't see how we
can be productive. Just like I really don't see how we will ever be
able to get any DRM/KMS driver in when the time comes.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Sep 30, 2014 at 06:59:59AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > > >> call from another driver.
> > > > > > 
> > > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > > still keeping them on via their own referenc.
> > > > > > 
> > > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > > 
> > > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > > its parents)
> > > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > > happen here.
> > > > > 
> > > > > Right. I'm not sure this is really applicable to this situation, though.
> > > > 
> > > > It's actually very easy to do. Have a driver that probes, enables its
> > > > clock, fails to probe for any reason, call clk_disable in its exit
> > > > path. If there's no other user at that time of this particular clock
> > > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > > 
> > > > Really, it's just that simple, and relying on the fact that some other
> > > > user of the same clock tree will always be their is beyond fragile.
> > > 
> > > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > > describe isn't at all what I'd expect from such an option. And it does
> > > not match the description in Documentation/kernel-parameters.txt either.
> > 
> > Well, it never says that it also prevent them from being disabled
> > later on. But it's true it's not very explicit.
> 
> It says:
> 
> 	Keep all clocks already enabled by bootloader on,
> 	even if no driver has claimed them. ...
> 
> There's no "until" or anything there, so I interpret that as
> indefinitely.

Well, then, sorry, but that's not how it works.

> > > > > Either way, if there are other users of a clock then they will just as
> > > > > likely want to modify the rate at which point simplefb will break just
> > > > > as badly.
> > > > 
> > > > And this can be handled just as well. Register a clock notifier,
> > > > refuse any rate change, done. But of course, that would require having
> > > > a clock handle.
> > > > 
> > > > Now, how would *you* prevent such a change?
> > > 
> > > Like I said in the other thread. If you have two drivers that use the
> > > same clock but need different frequencies you've lost anyway.
> > 
> > Except that the driver that has the most logic (ie not simplefb) will
> > have a way to recover and deal with that.
> 
> You're making an assumption here. Why would the driver have such logic
> if nothing ever prevented it from setting the rate properly before.

I'm not saying it has, but it something that can be done. You usually
have several strategies, which depending on the device, might or might
not be possible, such as reparenting, trying to use an additional
divider.

Worst case scenario, you're indeed doomed. But you do have a best case
scenario, which isn't the case with your approach. And you didn't
screw the framebuffer silently.

> > But sure, you can still try to point new issues, get an obvious and
> > robust solution, and then discard the issue when the solution doesn't
> > go your way...
> 
> And you've already proven that you're completely unwilling to even
> consider any other solution than what was originally proposed, so I
> really don't see how discussing this further with you is going to be
> productive.

You haven't express *what* you wanted to achieve for quite some time,
but only *how*. And your how has some deficiencies that have already
been pointed out numerous times.

However, I do come to the same conclusion. I really don't see how we
can be productive. Just like I really don't see how we will ever be
able to get any DRM/KMS driver in when the time comes.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/fc2f9893/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 09/30/2014 06:59 AM, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:

<snip>

>> But sure, you can still try to point new issues, get an obvious and
>> robust solution, and then discard the issue when the solution doesn't
>> go your way...
> 
> And you've already proven that you're completely unwilling to even
> consider any other solution than what was originally proposed, so I
> really don't see how discussing this further with you is going to be
> productive.

That is not true, we have seriously considered various other alternatives,
as you know since you've participated in the discussion about them.

And we've found them all lacking, mostly because they are 10 times as
complicated.

You've made your point that you don't like this solution quite loudly
already, and we've all heard you. However you seem to be mostly alone in
this. Even the clk maintainer has said that what we want to do is
exactly how clocks are supposed to be used in dt.

If you don't like this no-one is forcing you to use the clocks property
in your own code. If it is not there, simplefb will behave exactly as
before.

Now since you're the only one very vocally against this, and a lot
of people are in favor of this and have a need for this, can we
please just get this merged and get this over with ?

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 09/30/2014 06:59 AM, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:

<snip>

>> But sure, you can still try to point new issues, get an obvious and
>> robust solution, and then discard the issue when the solution doesn't
>> go your way...
> 
> And you've already proven that you're completely unwilling to even
> consider any other solution than what was originally proposed, so I
> really don't see how discussing this further with you is going to be
> productive.

That is not true, we have seriously considered various other alternatives,
as you know since you've participated in the discussion about them.

And we've found them all lacking, mostly because they are 10 times as
complicated.

You've made your point that you don't like this solution quite loudly
already, and we've all heard you. However you seem to be mostly alone in
this. Even the clk maintainer has said that what we want to do is
exactly how clocks are supposed to be used in dt.

If you don't like this no-one is forcing you to use the clocks property
in your own code. If it is not there, simplefb will behave exactly as
before.

Now since you're the only one very vocally against this, and a lot
of people are in favor of this and have a need for this, can we
please just get this merged and get this over with ?

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

On Tue, Sep 30, 2014 at 01:43:45PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/30/2014 06:59 AM, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> 
> <snip>
> 
> >> But sure, you can still try to point new issues, get an obvious and
> >> robust solution, and then discard the issue when the solution doesn't
> >> go your way...
> > 
> > And you've already proven that you're completely unwilling to even
> > consider any other solution than what was originally proposed, so I
> > really don't see how discussing this further with you is going to be
> > productive.
> 
> That is not true, we have seriously considered various other alternatives,
> as you know since you've participated in the discussion about them.
> 
> And we've found them all lacking, mostly because they are 10 times as
> complicated.
> 
> You've made your point that you don't like this solution quite loudly
> already, and we've all heard you. However you seem to be mostly alone in
> this. Even the clk maintainer has said that what we want to do is
> exactly how clocks are supposed to be used in dt.
> 
> If you don't like this no-one is forcing you to use the clocks property
> in your own code. If it is not there, simplefb will behave exactly as
> before.
> 
> Now since you're the only one very vocally against this, and a lot
> of people are in favor of this and have a need for this, can we
> please just get this merged and get this over with ?

Whatever. I no longer care.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 01:43:45PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/30/2014 06:59 AM, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> 
> <snip>
> 
> >> But sure, you can still try to point new issues, get an obvious and
> >> robust solution, and then discard the issue when the solution doesn't
> >> go your way...
> > 
> > And you've already proven that you're completely unwilling to even
> > consider any other solution than what was originally proposed, so I
> > really don't see how discussing this further with you is going to be
> > productive.
> 
> That is not true, we have seriously considered various other alternatives,
> as you know since you've participated in the discussion about them.
> 
> And we've found them all lacking, mostly because they are 10 times as
> complicated.
> 
> You've made your point that you don't like this solution quite loudly
> already, and we've all heard you. However you seem to be mostly alone in
> this. Even the clk maintainer has said that what we want to do is
> exactly how clocks are supposed to be used in dt.
> 
> If you don't like this no-one is forcing you to use the clocks property
> in your own code. If it is not there, simplefb will behave exactly as
> before.
> 
> Now since you're the only one very vocally against this, and a lot
> of people are in favor of this and have a need for this, can we
> please just get this merged and get this over with ?

Whatever. I no longer care.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/201cf473/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

Quoting Thierry Reding (2014-09-29 06:54:00)
> On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > >> call from another driver.
> > > > 
> > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > enable per-user clocks and as I understand it they will specifically
> > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > still keeping them on via their own referenc.
> > > > 
> > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > 
> > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > its parents)
> > > > if the clock subsystem thinks there are no other users, which is what will
> > > > happen here.
> > > 
> > > Right. I'm not sure this is really applicable to this situation, though.
> > 
> > It's actually very easy to do. Have a driver that probes, enables its
> > clock, fails to probe for any reason, call clk_disable in its exit
> > path. If there's no other user at that time of this particular clock
> > tree, it will be shut down. Bam. You just lost your framebuffer.
> > 
> > Really, it's just that simple, and relying on the fact that some other
> > user of the same clock tree will always be their is beyond fragile.
> 
> Perhaps the meaning clk_ignore_unused should be revised, then. What you
> describe isn't at all what I'd expect from such an option. And it does
> not match the description in Documentation/kernel-parameters.txt either.

From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
From: Mike Turquette <mturquette@linaro.org>
Date: Tue, 30 Sep 2014 14:24:38 -0700
Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused

Refine the definition around clk_ignore_unused, which caused some
confusion recently on the linux-fbdev and linux-arm-kernel mailing
lists[0].

[0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>

Signed-off-by: Mike Turquette <mturquette@linaro.org>
---
Thierry,

Please let me know if this wording makes the feature more clear.

 Documentation/kernel-parameters.txt | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 10d51c2..0ce01fb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -605,11 +605,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			See Documentation/s390/CommonIO for details.
 	clk_ignore_unused
 			[CLK]
-			Keep all clocks already enabled by bootloader on,
-			even if no driver has claimed them. This is useful
-			for debug and development, but should not be
-			needed on a platform with proper driver support.
-			For more information, see Documentation/clk.txt.
+			Prevents the clock framework from automatically gating
+			clocks that have not been explicitly enabled by a Linux
+			device driver but are enabled in hardware at reset or
+			by the bootloader/firmware. Note that this does not
+			force such clocks to be always-on nor does it reserve
+			those clocks in any way. This parameter is useful for
+			debug and development, but should not be needed on a
+			platform with proper driver support.  For more
+			information, see Documentation/clk.txt.
 
 	clock=		[BUGS=X86-32, HW] gettimeofday clocksource override.
 			[Deprecated]
-- 
1.8.3.2

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

Quoting Thierry Reding (2014-09-29 06:54:00)
> On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > >> call from another driver.
> > > > 
> > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > enable per-user clocks and as I understand it they will specifically
> > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > still keeping them on via their own referenc.
> > > > 
> > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > 
> > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > its parents)
> > > > if the clock subsystem thinks there are no other users, which is what will
> > > > happen here.
> > > 
> > > Right. I'm not sure this is really applicable to this situation, though.
> > 
> > It's actually very easy to do. Have a driver that probes, enables its
> > clock, fails to probe for any reason, call clk_disable in its exit
> > path. If there's no other user at that time of this particular clock
> > tree, it will be shut down. Bam. You just lost your framebuffer.
> > 
> > Really, it's just that simple, and relying on the fact that some other
> > user of the same clock tree will always be their is beyond fragile.
> 
> Perhaps the meaning clk_ignore_unused should be revised, then. What you
> describe isn't at all what I'd expect from such an option. And it does
> not match the description in Documentation/kernel-parameters.txt either.

>From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
From: Mike Turquette <mturquette@linaro.org>
Date: Tue, 30 Sep 2014 14:24:38 -0700
Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused

Refine the definition around clk_ignore_unused, which caused some
confusion recently on the linux-fbdev and linux-arm-kernel mailing
lists[0].

[0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>

Signed-off-by: Mike Turquette <mturquette@linaro.org>
---
Thierry,

Please let me know if this wording makes the feature more clear.

 Documentation/kernel-parameters.txt | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 10d51c2..0ce01fb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -605,11 +605,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			See Documentation/s390/CommonIO for details.
 	clk_ignore_unused
 			[CLK]
-			Keep all clocks already enabled by bootloader on,
-			even if no driver has claimed them. This is useful
-			for debug and development, but should not be
-			needed on a platform with proper driver support.
-			For more information, see Documentation/clk.txt.
+			Prevents the clock framework from automatically gating
+			clocks that have not been explicitly enabled by a Linux
+			device driver but are enabled in hardware at reset or
+			by the bootloader/firmware. Note that this does not
+			force such clocks to be always-on nor does it reserve
+			those clocks in any way. This parameter is useful for
+			debug and development, but should not be needed on a
+			platform with proper driver support.  For more
+			information, see Documentation/clk.txt.
 
 	clock=		[BUGS=X86-32, HW] gettimeofday clocksource override.
 			[Deprecated]
-- 
1.8.3.2

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> Quoting Thierry Reding (2014-09-29 06:54:00)
> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > >> call from another driver.
> > > > > 
> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > still keeping them on via their own referenc.
> > > > > 
> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > 
> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > its parents)
> > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > happen here.
> > > > 
> > > > Right. I'm not sure this is really applicable to this situation, though.
> > > 
> > > It's actually very easy to do. Have a driver that probes, enables its
> > > clock, fails to probe for any reason, call clk_disable in its exit
> > > path. If there's no other user at that time of this particular clock
> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > 
> > > Really, it's just that simple, and relying on the fact that some other
> > > user of the same clock tree will always be their is beyond fragile.
> > 
> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > describe isn't at all what I'd expect from such an option. And it does
> > not match the description in Documentation/kernel-parameters.txt either.
> 
> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> From: Mike Turquette <mturquette@linaro.org>
> Date: Tue, 30 Sep 2014 14:24:38 -0700
> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> 
> Refine the definition around clk_ignore_unused, which caused some
> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> lists[0].
> 
> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> 
> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> ---
> Thierry,
> 
> Please let me know if this wording makes the feature more clear.

I think that's better than before, but I don't think it's accurate yet.
As pointed out by Maxime unused clock may still be disabled if it's part
of a tree and that tree is being disabled because there are no users
left.

What I had argued is that it's unexpected behaviour, because the clock
is still unused (or becomes unused again), therefore shouldn't be
disabled at that point either.

So if you want to keep the current behaviour where an unused clock can
still be disabled depending on what other users do, then I think it'd be
good to mention that as a potential caveat.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> Quoting Thierry Reding (2014-09-29 06:54:00)
> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > >> call from another driver.
> > > > > 
> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > still keeping them on via their own referenc.
> > > > > 
> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > 
> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > its parents)
> > > > > if the clock subsystem thinks there are no other users, which is what will
> > > > > happen here.
> > > > 
> > > > Right. I'm not sure this is really applicable to this situation, though.
> > > 
> > > It's actually very easy to do. Have a driver that probes, enables its
> > > clock, fails to probe for any reason, call clk_disable in its exit
> > > path. If there's no other user at that time of this particular clock
> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > 
> > > Really, it's just that simple, and relying on the fact that some other
> > > user of the same clock tree will always be their is beyond fragile.
> > 
> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > describe isn't at all what I'd expect from such an option. And it does
> > not match the description in Documentation/kernel-parameters.txt either.
> 
> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> From: Mike Turquette <mturquette@linaro.org>
> Date: Tue, 30 Sep 2014 14:24:38 -0700
> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> 
> Refine the definition around clk_ignore_unused, which caused some
> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> lists[0].
> 
> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> 
> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> ---
> Thierry,
> 
> Please let me know if this wording makes the feature more clear.

I think that's better than before, but I don't think it's accurate yet.
As pointed out by Maxime unused clock may still be disabled if it's part
of a tree and that tree is being disabled because there are no users
left.

What I had argued is that it's unexpected behaviour, because the clock
is still unused (or becomes unused again), therefore shouldn't be
disabled at that point either.

So if you want to keep the current behaviour where an unused clock can
still be disabled depending on what other users do, then I think it'd be
good to mention that as a potential caveat.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/0e90b079/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
>> Quoting Thierry Reding (2014-09-29 06:54:00)
>> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
>> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
>> > > > > >> your clock to be shut down as a side effect of a later clk_disable
>> > > > > >> call from another driver.
>> > > > >
>> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > > > > > preceding clk_enable()? There are patches being worked on that will
>> > > > > > enable per-user clocks and as I understand it they will specifically
>> > > > > > disallow drivers to disable the hardware clock if other drivers are
>> > > > > > still keeping them on via their own referenc.
>> > > > >
>> > > > > Calling clk_disable() preceding clk_enable() is a bug.
>> > > > >
>> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
>> > > > > its parents)
>> > > > > if the clock subsystem thinks there are no other users, which is what will
>> > > > > happen here.
>> > > >
>> > > > Right. I'm not sure this is really applicable to this situation, though.
>> > >
>> > > It's actually very easy to do. Have a driver that probes, enables its
>> > > clock, fails to probe for any reason, call clk_disable in its exit
>> > > path. If there's no other user at that time of this particular clock
>> > > tree, it will be shut down. Bam. You just lost your framebuffer.
>> > >
>> > > Really, it's just that simple, and relying on the fact that some other
>> > > user of the same clock tree will always be their is beyond fragile.
>> >
>> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
>> > describe isn't at all what I'd expect from such an option. And it does
>> > not match the description in Documentation/kernel-parameters.txt either.
>>
>> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
>> From: Mike Turquette <mturquette@linaro.org>
>> Date: Tue, 30 Sep 2014 14:24:38 -0700
>> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
>>
>> Refine the definition around clk_ignore_unused, which caused some
>> confusion recently on the linux-fbdev and linux-arm-kernel mailing
>> lists[0].
>>
>> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
>>
>> Signed-off-by: Mike Turquette <mturquette@linaro.org>
>> ---
>> Thierry,
>>
>> Please let me know if this wording makes the feature more clear.
>
> I think that's better than before, but I don't think it's accurate yet.
> As pointed out by Maxime unused clock may still be disabled if it's part
> of a tree and that tree is being disabled because there are no users
> left.

It is entirely accurate. This feature does in fact "prevent the clock
framework from *automatically* gating clock ...".

And it was merged by Olof so that he could use simplefb with the Chromebook!

>
> What I had argued is that it's unexpected behavior, because the clock
> is still unused (or becomes unused again), therefore shouldn't be
> disabled at that point either.

Leaving clocks enabled because nobody claimed them is not an option.

>
> So if you want to keep the current behaviour where an unused clock can
> still be disabled depending on what other users do, then I think it'd be
> good to mention that as a potential caveat.

Do you have a suggestion on the wording?

Thanks,
Mike

>
> Thierry

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mike Turquette]

On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
>> Quoting Thierry Reding (2014-09-29 06:54:00)
>> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
>> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
>> > > > > >> your clock to be shut down as a side effect of a later clk_disable
>> > > > > >> call from another driver.
>> > > > >
>> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > > > > > preceding clk_enable()? There are patches being worked on that will
>> > > > > > enable per-user clocks and as I understand it they will specifically
>> > > > > > disallow drivers to disable the hardware clock if other drivers are
>> > > > > > still keeping them on via their own referenc.
>> > > > >
>> > > > > Calling clk_disable() preceding clk_enable() is a bug.
>> > > > >
>> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
>> > > > > its parents)
>> > > > > if the clock subsystem thinks there are no other users, which is what will
>> > > > > happen here.
>> > > >
>> > > > Right. I'm not sure this is really applicable to this situation, though.
>> > >
>> > > It's actually very easy to do. Have a driver that probes, enables its
>> > > clock, fails to probe for any reason, call clk_disable in its exit
>> > > path. If there's no other user at that time of this particular clock
>> > > tree, it will be shut down. Bam. You just lost your framebuffer.
>> > >
>> > > Really, it's just that simple, and relying on the fact that some other
>> > > user of the same clock tree will always be their is beyond fragile.
>> >
>> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
>> > describe isn't at all what I'd expect from such an option. And it does
>> > not match the description in Documentation/kernel-parameters.txt either.
>>
>> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
>> From: Mike Turquette <mturquette@linaro.org>
>> Date: Tue, 30 Sep 2014 14:24:38 -0700
>> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
>>
>> Refine the definition around clk_ignore_unused, which caused some
>> confusion recently on the linux-fbdev and linux-arm-kernel mailing
>> lists[0].
>>
>> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
>>
>> Signed-off-by: Mike Turquette <mturquette@linaro.org>
>> ---
>> Thierry,
>>
>> Please let me know if this wording makes the feature more clear.
>
> I think that's better than before, but I don't think it's accurate yet.
> As pointed out by Maxime unused clock may still be disabled if it's part
> of a tree and that tree is being disabled because there are no users
> left.

It is entirely accurate. This feature does in fact "prevent the clock
framework from *automatically* gating clock ...".

And it was merged by Olof so that he could use simplefb with the Chromebook!

>
> What I had argued is that it's unexpected behavior, because the clock
> is still unused (or becomes unused again), therefore shouldn't be
> disabled at that point either.

Leaving clocks enabled because nobody claimed them is not an option.

>
> So if you want to keep the current behaviour where an unused clock can
> still be disabled depending on what other users do, then I think it'd be
> good to mention that as a potential caveat.

Do you have a suggestion on the wording?

Thanks,
Mike

>
> Thierry

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]

On Wed, Oct 01, 2014 at 11:17:23AM -0700, Mike Turquette wrote:
> On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-09-29 06:54:00)
> >> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> >> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> >> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> >> > > > > >> call from another driver.
> >> > > > >
> >> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > > > > > preceding clk_enable()? There are patches being worked on that will
> >> > > > > > enable per-user clocks and as I understand it they will specifically
> >> > > > > > disallow drivers to disable the hardware clock if other drivers are
> >> > > > > > still keeping them on via their own referenc.
> >> > > > >
> >> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> >> > > > >
> >> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> >> > > > > its parents)
> >> > > > > if the clock subsystem thinks there are no other users, which is what will
> >> > > > > happen here.
> >> > > >
> >> > > > Right. I'm not sure this is really applicable to this situation, though.
> >> > >
> >> > > It's actually very easy to do. Have a driver that probes, enables its
> >> > > clock, fails to probe for any reason, call clk_disable in its exit
> >> > > path. If there's no other user at that time of this particular clock
> >> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> >> > >
> >> > > Really, it's just that simple, and relying on the fact that some other
> >> > > user of the same clock tree will always be their is beyond fragile.
> >> >
> >> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> >> > describe isn't at all what I'd expect from such an option. And it does
> >> > not match the description in Documentation/kernel-parameters.txt either.
> >>
> >> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> >> From: Mike Turquette <mturquette@linaro.org>
> >> Date: Tue, 30 Sep 2014 14:24:38 -0700
> >> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> >>
> >> Refine the definition around clk_ignore_unused, which caused some
> >> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> >> lists[0].
> >>
> >> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> >>
> >> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> >> ---
> >> Thierry,
> >>
> >> Please let me know if this wording makes the feature more clear.
> >
> > I think that's better than before, but I don't think it's accurate yet.
> > As pointed out by Maxime unused clock may still be disabled if it's part
> > of a tree and that tree is being disabled because there are no users
> > left.
> 
> It is entirely accurate. This feature does in fact "prevent the clock
> framework from *automatically* gating clock ...".

According to what Maxime said if an unused clock is a sibling (has the
same parent) of a clock that is used and then gets disabled, then if the
parent has no other clocks that are enabled, the unused clock will still
be disabled.

That's still counts as "automatically" to me. Not automatically would
mean that the clock needs to be disabled explicitly for it to become
disabled. Disabling it as a side-effect of its parent getting disabled
is still automatic.

> And it was merged by Olof so that he could use simplefb with the
> Chromebook!

And presumably it does work for that specific Chromebook. It seems,
though that for hardware with a somewhat whackier clock tree it doesn't
work so well. As far as I can tell that's the reason for this patch and
the ensuing discussion in the first place.

Although, perhaps nobody ever really tested whether or not the above
scenario was actually a problem for sunxi and maybe clk_ignore_unused
would work for them. But as I understand they don't want to use it, so
this whole debate about this kernel parameter is a bit moot.

> > What I had argued is that it's unexpected behavior, because the clock
> > is still unused (or becomes unused again), therefore shouldn't be
> > disabled at that point either.
> 
> Leaving clocks enabled because nobody claimed them is not an option.

But that's exactly what clk_ignore_unused is, isn't it? I'm now totally
confused.

> > So if you want to keep the current behaviour where an unused clock can
> > still be disabled depending on what other users do, then I think it'd be
> > good to mention that as a potential caveat.
> 
> Do you have a suggestion on the wording?

Perhaps something like this:

	Note that if an unused clock shares a parent with clocks that
	are used, the unused clock may still become disabled as a side-
	effect of the parent clock being disabled when none of the
	children that are used remain enabled.

?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Oct 01, 2014 at 11:17:23AM -0700, Mike Turquette wrote:
> On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-09-29 06:54:00)
> >> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> >> > > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> >> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> >> > > > > >> call from another driver.
> >> > > > >
> >> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > > > > > preceding clk_enable()? There are patches being worked on that will
> >> > > > > > enable per-user clocks and as I understand it they will specifically
> >> > > > > > disallow drivers to disable the hardware clock if other drivers are
> >> > > > > > still keeping them on via their own referenc.
> >> > > > >
> >> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> >> > > > >
> >> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> >> > > > > its parents)
> >> > > > > if the clock subsystem thinks there are no other users, which is what will
> >> > > > > happen here.
> >> > > >
> >> > > > Right. I'm not sure this is really applicable to this situation, though.
> >> > >
> >> > > It's actually very easy to do. Have a driver that probes, enables its
> >> > > clock, fails to probe for any reason, call clk_disable in its exit
> >> > > path. If there's no other user at that time of this particular clock
> >> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> >> > >
> >> > > Really, it's just that simple, and relying on the fact that some other
> >> > > user of the same clock tree will always be their is beyond fragile.
> >> >
> >> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> >> > describe isn't at all what I'd expect from such an option. And it does
> >> > not match the description in Documentation/kernel-parameters.txt either.
> >>
> >> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> >> From: Mike Turquette <mturquette@linaro.org>
> >> Date: Tue, 30 Sep 2014 14:24:38 -0700
> >> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> >>
> >> Refine the definition around clk_ignore_unused, which caused some
> >> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> >> lists[0].
> >>
> >> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> >>
> >> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> >> ---
> >> Thierry,
> >>
> >> Please let me know if this wording makes the feature more clear.
> >
> > I think that's better than before, but I don't think it's accurate yet.
> > As pointed out by Maxime unused clock may still be disabled if it's part
> > of a tree and that tree is being disabled because there are no users
> > left.
> 
> It is entirely accurate. This feature does in fact "prevent the clock
> framework from *automatically* gating clock ...".

According to what Maxime said if an unused clock is a sibling (has the
same parent) of a clock that is used and then gets disabled, then if the
parent has no other clocks that are enabled, the unused clock will still
be disabled.

That's still counts as "automatically" to me. Not automatically would
mean that the clock needs to be disabled explicitly for it to become
disabled. Disabling it as a side-effect of its parent getting disabled
is still automatic.

> And it was merged by Olof so that he could use simplefb with the
> Chromebook!

And presumably it does work for that specific Chromebook. It seems,
though that for hardware with a somewhat whackier clock tree it doesn't
work so well. As far as I can tell that's the reason for this patch and
the ensuing discussion in the first place.

Although, perhaps nobody ever really tested whether or not the above
scenario was actually a problem for sunxi and maybe clk_ignore_unused
would work for them. But as I understand they don't want to use it, so
this whole debate about this kernel parameter is a bit moot.

> > What I had argued is that it's unexpected behavior, because the clock
> > is still unused (or becomes unused again), therefore shouldn't be
> > disabled at that point either.
> 
> Leaving clocks enabled because nobody claimed them is not an option.

But that's exactly what clk_ignore_unused is, isn't it? I'm now totally
confused.

> > So if you want to keep the current behaviour where an unused clock can
> > still be disabled depending on what other users do, then I think it'd be
> > good to mention that as a potential caveat.
> 
> Do you have a suggestion on the wording?

Perhaps something like this:

	Note that if an unused clock shares a parent with clocks that
	are used, the unused clock may still become disabled as a side-
	effect of the parent clock being disabled when none of the
	children that are used remain enabled.

?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141002/d26295c7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>> > people. What is passed in via its device tree node is the minimum amount
>> > of information needed to draw something into the framebuffer. Also note
>> > that the simplefb device tree node is not statically added to a DTS file
>> > but needs to be dynamically generated by firmware at runtime.
>>
>> Which makes the whole even simpler, since the firmware already knows
>> all about which clocks it had to enable.
>
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

As far as the kernel is concerned, this is a solved problem.

Firmware is going to be doing some dark magic to set up the hardware
to be a dumb frame buffer and some other stuff to add the simplefb
device node - so by this point, adding the clocks (or whatever)
required by the hardware should be fairly uncomplicated - the firmware
already knows the hardware intimately. As for the actual device tree
manipulations, U-boot (or whatever) will probably just grow some
helper functions to make this simple.

Alternatively, it could simply add the relevant data to an existing
device node and munge it's compatible property so simplefb picks it
up.

>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>> >
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>> >
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>> >
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>>
>> You should really read that thread:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
>>
>> It's quite interesting, because you'll see that:
>> A) Your approach, even on the platform you're working on, doesn't
>>    work. Or at least, isn't reliable.
>
> What platform exactly do you think I'm working on? Why do you think what
> I proposed isn't going to work or be reliable? I don't see any arguments
> in the thread that would imply that.
>
>> B) Other maintainers, precisely like Mark, came to the same conclusion
>>    than Mike.
>
> Well, and others didn't.
>
> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.
>
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> So, just to be clear, instead of doing a generic clk_get and
>> clk_prepare_enable, you're willing to do a just as much generic
>> clk_ignore_unused call?
>
> Yes.
>
>> How is that less generic?
>
> It's more generic. That's the whole point.
>
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point, so duplicating what the real driver does within the simplefb
> driver is just that, duplication. We don't allow duplication anywhere
> else in the kernel, why should simplefb be an exception?

The various subsystems could just grow some accessor functions (where
required) which, with devm, should be as simple as ~10 lines per
subsystem. With ~5 subsystems this is ~50 lines of code; Or we can
disable the automatic disabling of resources and put the system in a
potentially unstable state; Or each subarch could use some shim driver
or some arch code to grab the clocks for simplefb, and we end up with
each subarch having it's own, slightly different version of what is
essentially the same code; Or we have to have every single KMS driver
built in and bloat the kernel.

With ~50 lines of generic code added to simplefb, distros get their
slim multi-subarch kernels, your driver is still generic, power
management works and users get pretty graphics from bootloader to
desktop.

>> You know that you are going to call that for regulator, reset, power
>> domains, just as you would have needed to with the proper API, unless
>> that with this kind of solution, you would have to modify *every*
>> framework that might interact with any resource involved in getting
>> simplefb running?
>
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.
>
>> Plus, speaking more specifically about the clocks, that won't prevent
>> your clock to be shut down as a side effect of a later clk_disable
>> call from another driver.
>
> If we need to prevent that, then that's something that could be fixed,
> too. But both this and the other thread at least agree on the fact that
> simplefb is a shim driver that's going to be replaced by something real
> at some point, so hopefully concurrent users aren't the problem because
> that would cause the real driver to break too.
>
> Also note that if some other driver could call clk_disable() it could
> just as easily call clk_set_rate() and break simplefb.

If simplefb has called clk_get() then nobody can disable the clocks
it's depending on.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.
>
> Thierry

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>> > people. What is passed in via its device tree node is the minimum amount
>> > of information needed to draw something into the framebuffer. Also note
>> > that the simplefb device tree node is not statically added to a DTS file
>> > but needs to be dynamically generated by firmware at runtime.
>>
>> Which makes the whole even simpler, since the firmware already knows
>> all about which clocks it had to enable.
>
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

As far as the kernel is concerned, this is a solved problem.

Firmware is going to be doing some dark magic to set up the hardware
to be a dumb frame buffer and some other stuff to add the simplefb
device node - so by this point, adding the clocks (or whatever)
required by the hardware should be fairly uncomplicated - the firmware
already knows the hardware intimately. As for the actual device tree
manipulations, U-boot (or whatever) will probably just grow some
helper functions to make this simple.

Alternatively, it could simply add the relevant data to an existing
device node and munge it's compatible property so simplefb picks it
up.

>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>> >
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>> >
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>> >
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>>
>> You should really read that thread:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
>>
>> It's quite interesting, because you'll see that:
>> A) Your approach, even on the platform you're working on, doesn't
>>    work. Or at least, isn't reliable.
>
> What platform exactly do you think I'm working on? Why do you think what
> I proposed isn't going to work or be reliable? I don't see any arguments
> in the thread that would imply that.
>
>> B) Other maintainers, precisely like Mark, came to the same conclusion
>>    than Mike.
>
> Well, and others didn't.
>
> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.
>
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> So, just to be clear, instead of doing a generic clk_get and
>> clk_prepare_enable, you're willing to do a just as much generic
>> clk_ignore_unused call?
>
> Yes.
>
>> How is that less generic?
>
> It's more generic. That's the whole point.
>
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point, so duplicating what the real driver does within the simplefb
> driver is just that, duplication. We don't allow duplication anywhere
> else in the kernel, why should simplefb be an exception?

The various subsystems could just grow some accessor functions (where
required) which, with devm, should be as simple as ~10 lines per
subsystem. With ~5 subsystems this is ~50 lines of code; Or we can
disable the automatic disabling of resources and put the system in a
potentially unstable state; Or each subarch could use some shim driver
or some arch code to grab the clocks for simplefb, and we end up with
each subarch having it's own, slightly different version of what is
essentially the same code; Or we have to have every single KMS driver
built in and bloat the kernel.

With ~50 lines of generic code added to simplefb, distros get their
slim multi-subarch kernels, your driver is still generic, power
management works and users get pretty graphics from bootloader to
desktop.

>> You know that you are going to call that for regulator, reset, power
>> domains, just as you would have needed to with the proper API, unless
>> that with this kind of solution, you would have to modify *every*
>> framework that might interact with any resource involved in getting
>> simplefb running?
>
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.
>
>> Plus, speaking more specifically about the clocks, that won't prevent
>> your clock to be shut down as a side effect of a later clk_disable
>> call from another driver.
>
> If we need to prevent that, then that's something that could be fixed,
> too. But both this and the other thread at least agree on the fact that
> simplefb is a shim driver that's going to be replaced by something real
> at some point, so hopefully concurrent users aren't the problem because
> that would cause the real driver to break too.
>
> Also note that if some other driver could call clk_disable() it could
> just as easily call clk_set_rate() and break simplefb.

If simplefb has called clk_get() then nobody can disable the clocks
it's depending on.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.
>
> Thierry

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]

On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> Hi Thierry,

If you address people directly please make sure they are in the To:
line. Or at least Cc.

> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >> > people. What is passed in via its device tree node is the minimum amount
> >> > of information needed to draw something into the framebuffer. Also note
> >> > that the simplefb device tree node is not statically added to a DTS file
> >> > but needs to be dynamically generated by firmware at runtime.
> >>
> >> Which makes the whole even simpler, since the firmware already knows
> >> all about which clocks it had to enable.
> >
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> As far as the kernel is concerned, this is a solved problem.

It's not completely solved. There's still the issue of no generic way to
specify regulators like you can do for clocks, resets or power domains.

But the kernel isn't the real issue here. The issue is the firmware that
now has to go out of its way not only to initialize display hardware but
also create device tree content just to make Linux not turn everything
off.

> Firmware is going to be doing some dark magic to set up the hardware
> to be a dumb frame buffer and some other stuff to add the simplefb
> device node - so by this point, adding the clocks (or whatever)
> required by the hardware should be fairly uncomplicated - the firmware
> already knows the hardware intimately. As for the actual device tree
> manipulations, U-boot (or whatever) will probably just grow some
> helper functions to make this simple.

Have you looked at the code needed to do this? It's not at all trivial.
And the point is really that all this information is there already, so
we're completely duplicating this into a dynamically created device tree
node and for what reason? Only to have one driver request all these
resources and have them forcefully released a few seconds later.

> Alternatively, it could simply add the relevant data to an existing
> device node and munge it's compatible property so simplefb picks it
> up.

Yes, I think that'd be a much better solution. Of course it's going to
be very difficult to make that work with a generic driver because now
that generic driver needs to parse the DT binding for any number of
"compatible" devices.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> Hi Thierry,

If you address people directly please make sure they are in the To:
line. Or at least Cc.

> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >> > people. What is passed in via its device tree node is the minimum amount
> >> > of information needed to draw something into the framebuffer. Also note
> >> > that the simplefb device tree node is not statically added to a DTS file
> >> > but needs to be dynamically generated by firmware at runtime.
> >>
> >> Which makes the whole even simpler, since the firmware already knows
> >> all about which clocks it had to enable.
> >
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> As far as the kernel is concerned, this is a solved problem.

It's not completely solved. There's still the issue of no generic way to
specify regulators like you can do for clocks, resets or power domains.

But the kernel isn't the real issue here. The issue is the firmware that
now has to go out of its way not only to initialize display hardware but
also create device tree content just to make Linux not turn everything
off.

> Firmware is going to be doing some dark magic to set up the hardware
> to be a dumb frame buffer and some other stuff to add the simplefb
> device node - so by this point, adding the clocks (or whatever)
> required by the hardware should be fairly uncomplicated - the firmware
> already knows the hardware intimately. As for the actual device tree
> manipulations, U-boot (or whatever) will probably just grow some
> helper functions to make this simple.

Have you looked at the code needed to do this? It's not at all trivial.
And the point is really that all this information is there already, so
we're completely duplicating this into a dynamically created device tree
node and for what reason? Only to have one driver request all these
resources and have them forcefully released a few seconds later.

> Alternatively, it could simply add the relevant data to an existing
> device node and munge it's compatible property so simplefb picks it
> up.

Yes, I think that'd be a much better solution. Of course it's going to
be very difficult to make that work with a generic driver because now
that generic driver needs to parse the DT binding for any number of
"compatible" devices.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/a6e9e08a/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> Hi Thierry,
>
> If you address people directly please make sure they are in the To:
> line. Or at least Cc.

Sorry about that, the mailing list I received this through (Google
Groups based) generally strips to: and CC: lines, so my mail client
(Gmail) doesn't do it automatically. I'm still getting used to it.

>> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > firmware has set up, which is the only reason why it will work for many
>> >> > people. What is passed in via its device tree node is the minimum amount
>> >> > of information needed to draw something into the framebuffer. Also note
>> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> > but needs to be dynamically generated by firmware at runtime.
>> >>
>> >> Which makes the whole even simpler, since the firmware already knows
>> >> all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> As far as the kernel is concerned, this is a solved problem.
>
> It's not completely solved. There's still the issue of no generic way to
> specify regulators like you can do for clocks, resets or power domains.
> But the kernel isn't the real issue here. The issue is the firmware that
> now has to go out of its way not only to initialize display hardware but
> also create device tree content just to make Linux not turn everything
> off.

My point is that the firmware is going to be doing complicated stuff
already, adding and using some helpers to configure a device tree node
is relatively simple in comparison to dealing with the actual
hardware. It wouldn't surprise me if u-boot, for example, ended up
with a set of functions to handle this exact case as more graphics
hardware gets brought up.

>> Firmware is going to be doing some dark magic to set up the hardware
>> to be a dumb frame buffer and some other stuff to add the simplefb
>> device node - so by this point, adding the clocks (or whatever)
>> required by the hardware should be fairly uncomplicated - the firmware
>> already knows the hardware intimately. As for the actual device tree
>> manipulations, U-boot (or whatever) will probably just grow some
>> helper functions to make this simple.
>
> Have you looked at the code needed to do this? It's not at all trivial.
> And the point is really that all this information is there already, so
> we're completely duplicating this into a dynamically created device tree
> node and for what reason? Only to have one driver request all these
> resources and have them forcefully released a few seconds later.
>
>> Alternatively, it could simply add the relevant data to an existing
>> device node and munge it's compatible property so simplefb picks it
>> up.
>
> Yes, I think that'd be a much better solution. Of course it's going to
> be very difficult to make that work with a generic driver because now
> that generic driver needs to parse the DT binding for any number of
> "compatible" devices.

Not necessarily.

The patch that started this discussion can work with any number of
clocks specified in a "clocks" property. Therefore all that needs to
happen is that the final hardware binding specifies it's clocks that
way. This is how, for example, the ahci_platform driver's clock code
works.

I'm sure that as hardware diversifies, the other subsystems will grow
in similar directions and eventually be dealt with using similarly
generic code.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> Hi Thierry,
>
> If you address people directly please make sure they are in the To:
> line. Or at least Cc.

Sorry about that, the mailing list I received this through (Google
Groups based) generally strips to: and CC: lines, so my mail client
(Gmail) doesn't do it automatically. I'm still getting used to it.

>> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > firmware has set up, which is the only reason why it will work for many
>> >> > people. What is passed in via its device tree node is the minimum amount
>> >> > of information needed to draw something into the framebuffer. Also note
>> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> > but needs to be dynamically generated by firmware at runtime.
>> >>
>> >> Which makes the whole even simpler, since the firmware already knows
>> >> all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> As far as the kernel is concerned, this is a solved problem.
>
> It's not completely solved. There's still the issue of no generic way to
> specify regulators like you can do for clocks, resets or power domains.
> But the kernel isn't the real issue here. The issue is the firmware that
> now has to go out of its way not only to initialize display hardware but
> also create device tree content just to make Linux not turn everything
> off.

My point is that the firmware is going to be doing complicated stuff
already, adding and using some helpers to configure a device tree node
is relatively simple in comparison to dealing with the actual
hardware. It wouldn't surprise me if u-boot, for example, ended up
with a set of functions to handle this exact case as more graphics
hardware gets brought up.

>> Firmware is going to be doing some dark magic to set up the hardware
>> to be a dumb frame buffer and some other stuff to add the simplefb
>> device node - so by this point, adding the clocks (or whatever)
>> required by the hardware should be fairly uncomplicated - the firmware
>> already knows the hardware intimately. As for the actual device tree
>> manipulations, U-boot (or whatever) will probably just grow some
>> helper functions to make this simple.
>
> Have you looked at the code needed to do this? It's not at all trivial.
> And the point is really that all this information is there already, so
> we're completely duplicating this into a dynamically created device tree
> node and for what reason? Only to have one driver request all these
> resources and have them forcefully released a few seconds later.
>
>> Alternatively, it could simply add the relevant data to an existing
>> device node and munge it's compatible property so simplefb picks it
>> up.
>
> Yes, I think that'd be a much better solution. Of course it's going to
> be very difficult to make that work with a generic driver because now
> that generic driver needs to parse the DT binding for any number of
> "compatible" devices.

Not necessarily.

The patch that started this discussion can work with any number of
clocks specified in a "clocks" property. Therefore all that needs to
happen is that the final hardware binding specifies it's clocks that
way. This is how, for example, the ahci_platform driver's clock code
works.

I'm sure that as hardware diversifies, the other subsystems will grow
in similar directions and eventually be dealt with using similarly
generic code.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5840 bytes --]

On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> >> Hi Thierry,
> >
> > If you address people directly please make sure they are in the To:
> > line. Or at least Cc.
> 
> Sorry about that, the mailing list I received this through (Google
> Groups based) generally strips to: and CC: lines, so my mail client
> (Gmail) doesn't do it automatically. I'm still getting used to it.

Yeah, I wish mailing lists would stop doing that.

> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> >> > firmware has set up, which is the only reason why it will work for many
> >> >> > people. What is passed in via its device tree node is the minimum amount
> >> >> > of information needed to draw something into the framebuffer. Also note
> >> >> > that the simplefb device tree node is not statically added to a DTS file
> >> >> > but needs to be dynamically generated by firmware at runtime.
> >> >>
> >> >> Which makes the whole even simpler, since the firmware already knows
> >> >> all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> As far as the kernel is concerned, this is a solved problem.
> >
> > It's not completely solved. There's still the issue of no generic way to
> > specify regulators like you can do for clocks, resets or power domains.
> > But the kernel isn't the real issue here. The issue is the firmware that
> > now has to go out of its way not only to initialize display hardware but
> > also create device tree content just to make Linux not turn everything
> > off.
> 
> My point is that the firmware is going to be doing complicated stuff
> already, adding and using some helpers to configure a device tree node
> is relatively simple in comparison to dealing with the actual
> hardware. It wouldn't surprise me if u-boot, for example, ended up
> with a set of functions to handle this exact case as more graphics
> hardware gets brought up.

Not all firmware is based on U-Boot. Essentially whatever binding
changes we make will need to be implemented in all firmware. And the
complexity isn't so much about writing the actual DT data, but more
about figuring out which data to write. Every firmware image needs to
know exactly which clocks and other resources to transcribe for a given
board. It'll essentially need to contain some sort of "driver" for each
device that parses a DTB, correlates the data to what it knows of the
device internals and write a subset of that data back into the DTB in a
slightly different format. That's just whacky.

DT was meant to simplify things.

> >> Firmware is going to be doing some dark magic to set up the hardware
> >> to be a dumb frame buffer and some other stuff to add the simplefb
> >> device node - so by this point, adding the clocks (or whatever)
> >> required by the hardware should be fairly uncomplicated - the firmware
> >> already knows the hardware intimately. As for the actual device tree
> >> manipulations, U-boot (or whatever) will probably just grow some
> >> helper functions to make this simple.
> >
> > Have you looked at the code needed to do this? It's not at all trivial.
> > And the point is really that all this information is there already, so
> > we're completely duplicating this into a dynamically created device tree
> > node and for what reason? Only to have one driver request all these
> > resources and have them forcefully released a few seconds later.
> >
> >> Alternatively, it could simply add the relevant data to an existing
> >> device node and munge it's compatible property so simplefb picks it
> >> up.
> >
> > Yes, I think that'd be a much better solution. Of course it's going to
> > be very difficult to make that work with a generic driver because now
> > that generic driver needs to parse the DT binding for any number of
> > "compatible" devices.
> 
> Not necessarily.
> 
> The patch that started this discussion can work with any number of
> clocks specified in a "clocks" property. Therefore all that needs to
> happen is that the final hardware binding specifies it's clocks that
> way.

Are you suggesting that we should be modeling the hardware specific
binding to match what the simplefb binding does?

> I'm sure that as hardware diversifies, the other subsystems will grow
> in similar directions and eventually be dealt with using similarly
> generic code.

For regulators this already works very differently. As opposed to the
clocks/clock-names type of binding it uses one where the consumer name
of the regulator comes from the prefix of a -supply property. That is
you'd get something like this:

	foo-supply = <&reg1>;
	bar-supply = <&reg2>;

And since you don't have enough information in the kernel simplefb
driver to attach any meaning to these, the best you can do would be
iterating over a range and have:

	0-supply = <&reg0>;
	1-supply = <&reg1>;
	...
	n-supply = <&reg2>;

This is made more difficult by the fact that these regulators may be
required by components not immediately related to the display engine.
They could be for an attached panel, a video bridge or the +5V pin on
the HDMI connector.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> >> Hi Thierry,
> >
> > If you address people directly please make sure they are in the To:
> > line. Or at least Cc.
> 
> Sorry about that, the mailing list I received this through (Google
> Groups based) generally strips to: and CC: lines, so my mail client
> (Gmail) doesn't do it automatically. I'm still getting used to it.

Yeah, I wish mailing lists would stop doing that.

> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
> >> <thierry.reding@gmail.com> wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> >> > firmware has set up, which is the only reason why it will work for many
> >> >> > people. What is passed in via its device tree node is the minimum amount
> >> >> > of information needed to draw something into the framebuffer. Also note
> >> >> > that the simplefb device tree node is not statically added to a DTS file
> >> >> > but needs to be dynamically generated by firmware at runtime.
> >> >>
> >> >> Which makes the whole even simpler, since the firmware already knows
> >> >> all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> As far as the kernel is concerned, this is a solved problem.
> >
> > It's not completely solved. There's still the issue of no generic way to
> > specify regulators like you can do for clocks, resets or power domains.
> > But the kernel isn't the real issue here. The issue is the firmware that
> > now has to go out of its way not only to initialize display hardware but
> > also create device tree content just to make Linux not turn everything
> > off.
> 
> My point is that the firmware is going to be doing complicated stuff
> already, adding and using some helpers to configure a device tree node
> is relatively simple in comparison to dealing with the actual
> hardware. It wouldn't surprise me if u-boot, for example, ended up
> with a set of functions to handle this exact case as more graphics
> hardware gets brought up.

Not all firmware is based on U-Boot. Essentially whatever binding
changes we make will need to be implemented in all firmware. And the
complexity isn't so much about writing the actual DT data, but more
about figuring out which data to write. Every firmware image needs to
know exactly which clocks and other resources to transcribe for a given
board. It'll essentially need to contain some sort of "driver" for each
device that parses a DTB, correlates the data to what it knows of the
device internals and write a subset of that data back into the DTB in a
slightly different format. That's just whacky.

DT was meant to simplify things.

> >> Firmware is going to be doing some dark magic to set up the hardware
> >> to be a dumb frame buffer and some other stuff to add the simplefb
> >> device node - so by this point, adding the clocks (or whatever)
> >> required by the hardware should be fairly uncomplicated - the firmware
> >> already knows the hardware intimately. As for the actual device tree
> >> manipulations, U-boot (or whatever) will probably just grow some
> >> helper functions to make this simple.
> >
> > Have you looked at the code needed to do this? It's not at all trivial.
> > And the point is really that all this information is there already, so
> > we're completely duplicating this into a dynamically created device tree
> > node and for what reason? Only to have one driver request all these
> > resources and have them forcefully released a few seconds later.
> >
> >> Alternatively, it could simply add the relevant data to an existing
> >> device node and munge it's compatible property so simplefb picks it
> >> up.
> >
> > Yes, I think that'd be a much better solution. Of course it's going to
> > be very difficult to make that work with a generic driver because now
> > that generic driver needs to parse the DT binding for any number of
> > "compatible" devices.
> 
> Not necessarily.
> 
> The patch that started this discussion can work with any number of
> clocks specified in a "clocks" property. Therefore all that needs to
> happen is that the final hardware binding specifies it's clocks that
> way.

Are you suggesting that we should be modeling the hardware specific
binding to match what the simplefb binding does?

> I'm sure that as hardware diversifies, the other subsystems will grow
> in similar directions and eventually be dealt with using similarly
> generic code.

For regulators this already works very differently. As opposed to the
clocks/clock-names type of binding it uses one where the consumer name
of the regulator comes from the prefix of a -supply property. That is
you'd get something like this:

	foo-supply = <&reg1>;
	bar-supply = <&reg2>;

And since you don't have enough information in the kernel simplefb
driver to attach any meaning to these, the best you can do would be
iterating over a range and have:

	0-supply = <&reg0>;
	1-supply = <&reg1>;
	...
	n-supply = <&reg2>;

This is made more difficult by the fact that these regulators may be
required by components not immediately related to the display engine.
They could be for an attached panel, a video bridge or the +5V pin on
the HDMI connector.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/5aa6ab99/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 17:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >> <thierry.reding@gmail.com> wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> >> > firmware has set up, which is the only reason why it will work for many
>> >> >> > people. What is passed in via its device tree node is the minimum amount
>> >> >> > of information needed to draw something into the framebuffer. Also note
>> >> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

The firmware only needs to implement DT parsing and writing if it
wants to communicate the configuration it set up to the kernel. If you
do not have control over the firmware or do not want to write support
for the firmware to generate the DT you can produce a fixed
configuration DT and have the firmware load that with the kernel. It
is fully backwards compatible with dumb firmware that does not support
DT modification during boot. You will just need a different DT for
slightly different devices (eg. tablets with different display) or
different configurations of same device (eg. different displays
connected to the HDMI port of your devboard).

>> I'm sure that as hardware diversifies, the other subsystems will grow
>> in similar directions and eventually be dealt with using similarly
>> generic code.
>
> For regulators this already works very differently. As opposed to the
> clocks/clock-names type of binding it uses one where the consumer name
> of the regulator comes from the prefix of a -supply property. That is
> you'd get something like this:
>
>         foo-supply = <&reg1>;
>         bar-supply = <&reg2>;
>
> And since you don't have enough information in the kernel simplefb
> driver to attach any meaning to these, the best you can do would be
> iterating over a range and have:
>
>         0-supply = <&reg0>;
>         1-supply = <&reg1>;
>         ...
>         n-supply = <&reg2>;
>
> This is made more difficult by the fact that these regulators may be
> required by components not immediately related to the display engine.
> They could be for an attached panel, a video bridge or the +5V pin on
> the HDMI connector.

So you are saying that listing the properties of the simplefb node and
filtering foo-supply and bar-supply out of that is too difficult?

I hope kernel development did not get this dumb.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 17:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >> <thierry.reding@gmail.com> wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> >> > firmware has set up, which is the only reason why it will work for many
>> >> >> > people. What is passed in via its device tree node is the minimum amount
>> >> >> > of information needed to draw something into the framebuffer. Also note
>> >> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

The firmware only needs to implement DT parsing and writing if it
wants to communicate the configuration it set up to the kernel. If you
do not have control over the firmware or do not want to write support
for the firmware to generate the DT you can produce a fixed
configuration DT and have the firmware load that with the kernel. It
is fully backwards compatible with dumb firmware that does not support
DT modification during boot. You will just need a different DT for
slightly different devices (eg. tablets with different display) or
different configurations of same device (eg. different displays
connected to the HDMI port of your devboard).

>> I'm sure that as hardware diversifies, the other subsystems will grow
>> in similar directions and eventually be dealt with using similarly
>> generic code.
>
> For regulators this already works very differently. As opposed to the
> clocks/clock-names type of binding it uses one where the consumer name
> of the regulator comes from the prefix of a -supply property. That is
> you'd get something like this:
>
>         foo-supply = <&reg1>;
>         bar-supply = <&reg2>;
>
> And since you don't have enough information in the kernel simplefb
> driver to attach any meaning to these, the best you can do would be
> iterating over a range and have:
>
>         0-supply = <&reg0>;
>         1-supply = <&reg1>;
>         ...
>         n-supply = <&reg2>;
>
> This is made more difficult by the fact that these regulators may be
> required by components not immediately related to the display engine.
> They could be for an attached panel, a video bridge or the +5V pin on
> the HDMI connector.

So you are saying that listing the properties of the simplefb node and
filtering foo-supply and bar-supply out of that is too difficult?

I hope kernel development did not get this dumb.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Tue, Sep 30, 2014 at 1:19 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> Hi Thierry,
>>
>> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> >> Hi Thierry,
>> >
>> > If you address people directly please make sure they are in the To:
>> > line. Or at least Cc.
>>
>> Sorry about that, the mailing list I received this through (Google
>> Groups based) generally strips to: and CC: lines, so my mail client
>> (Gmail) doesn't do it automatically. I'm still getting used to it.
>
> Yeah, I wish mailing lists would stop doing that.
>
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >> <thierry.reding@gmail.com> wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> >> > firmware has set up, which is the only reason why it will work for many
>> >> >> > people. What is passed in via its device tree node is the minimum amount
>> >> >> > of information needed to draw something into the framebuffer. Also note
>> >> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

Ok, fair enough, while it's a tempting solution - it makes the kernel
end of things nice and simple, it's probably not completely scalable.
U-boot definitely does have "drivers" for the hardware it supports,
but we can't expect every bootloader to do that.

>> >> Firmware is going to be doing some dark magic to set up the hardware
>> >> to be a dumb frame buffer and some other stuff to add the simplefb
>> >> device node - so by this point, adding the clocks (or whatever)
>> >> required by the hardware should be fairly uncomplicated - the firmware
>> >> already knows the hardware intimately. As for the actual device tree
>> >> manipulations, U-boot (or whatever) will probably just grow some
>> >> helper functions to make this simple.
>> >
>> > Have you looked at the code needed to do this? It's not at all trivial.
>> > And the point is really that all this information is there already, so
>> > we're completely duplicating this into a dynamically created device tree
>> > node and for what reason? Only to have one driver request all these
>> > resources and have them forcefully released a few seconds later.
>> >
>> >> Alternatively, it could simply add the relevant data to an existing
>> >> device node and munge it's compatible property so simplefb picks it
>> >> up.
>> >
>> > Yes, I think that'd be a much better solution. Of course it's going to
>> > be very difficult to make that work with a generic driver because now
>> > that generic driver needs to parse the DT binding for any number of
>> > "compatible" devices.
>>
>> Not necessarily.
>>
>> The patch that started this discussion can work with any number of
>> clocks specified in a "clocks" property. Therefore all that needs to
>> happen is that the final hardware binding specifies it's clocks that
>> way.
>
> Are you suggesting that we should be modeling the hardware specific
> binding to match what the simplefb binding does?

I'll admit that this sounded pretty dumb when I thought over it in the
morning. Let's call it a strawman and let's call me a hilariously
unskilled debater.

I don't have a kernel tree in front of me, so I don't know that all
the helpers used below exist or are named like I've shown, but code
like this could grab all the resources specified in a tree of nodes:

void simplefb_grab_all_resources(node *root)
{
    node *next = root;
    node *cur;

    while( next ) {
        cur = next;

        get_all_resources(cur);

        if( next = of_get_first_child(cur) )
            continue;

        if( next = of_get_next_sibling(cur) )
            continue;

        while( !next && cur != root ) {
            cur = of_get_parent_node(cur);
            next = of_get_next_sibling(cur);
        }

        if( cur = root )
            break;
    }
}

If we added in a few tests in get_all_resources() to keep it from
doing things which are obviously stupid (e.g. grabbing resources for
nodes which have drivers we already have registered) that should work
for any binding and could easily be extended to any resource type.
We're already using linked lists to hold references to those
resources, so there's no problems I can see here, other than adding
some code.

>> I'm sure that as hardware diversifies, the other subsystems will grow
>> in similar directions and eventually be dealt with using similarly
>> generic code.
>
> For regulators this already works very differently. As opposed to the
> clocks/clock-names type of binding it uses one where the consumer name
> of the regulator comes from the prefix of a -supply property. That is
> you'd get something like this:
>
>         foo-supply = <&reg1>;
>         bar-supply = <&reg2>;
>
> And since you don't have enough information in the kernel simplefb
> driver to attach any meaning to these, the best you can do would be
> iterating over a range and have:
>
>         0-supply = <&reg0>;
>         1-supply = <&reg1>;
>         ...
>         n-supply = <&reg2>;
>
> This is made more difficult by the fact that these regulators may be
> required by components not immediately related to the display engine.
> They could be for an attached panel, a video bridge or the +5V pin on
> the HDMI connector.

Surely an iterator could be constructed to go through each node and
process every one named something like "*-supply"?

As for there being regulators for each separate part of the device,
could we read what their current state is then maintain that state?

I'll admit that this is getting rather hairy at this point.

Finally, the clock subsystem has evolved away from "*-clock" bindings
towards the current "clocks" and "clock-names" bindings. I'm sure
other subsystems will follow.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Tue, Sep 30, 2014 at 1:19 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> Hi Thierry,
>>
>> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
>> <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> >> Hi Thierry,
>> >
>> > If you address people directly please make sure they are in the To:
>> > line. Or at least Cc.
>>
>> Sorry about that, the mailing list I received this through (Google
>> Groups based) generally strips to: and CC: lines, so my mail client
>> (Gmail) doesn't do it automatically. I'm still getting used to it.
>
> Yeah, I wish mailing lists would stop doing that.
>
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >> <thierry.reding@gmail.com> wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> >> > firmware has set up, which is the only reason why it will work for many
>> >> >> > people. What is passed in via its device tree node is the minimum amount
>> >> >> > of information needed to draw something into the framebuffer. Also note
>> >> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

Ok, fair enough, while it's a tempting solution - it makes the kernel
end of things nice and simple, it's probably not completely scalable.
U-boot definitely does have "drivers" for the hardware it supports,
but we can't expect every bootloader to do that.

>> >> Firmware is going to be doing some dark magic to set up the hardware
>> >> to be a dumb frame buffer and some other stuff to add the simplefb
>> >> device node - so by this point, adding the clocks (or whatever)
>> >> required by the hardware should be fairly uncomplicated - the firmware
>> >> already knows the hardware intimately. As for the actual device tree
>> >> manipulations, U-boot (or whatever) will probably just grow some
>> >> helper functions to make this simple.
>> >
>> > Have you looked at the code needed to do this? It's not at all trivial.
>> > And the point is really that all this information is there already, so
>> > we're completely duplicating this into a dynamically created device tree
>> > node and for what reason? Only to have one driver request all these
>> > resources and have them forcefully released a few seconds later.
>> >
>> >> Alternatively, it could simply add the relevant data to an existing
>> >> device node and munge it's compatible property so simplefb picks it
>> >> up.
>> >
>> > Yes, I think that'd be a much better solution. Of course it's going to
>> > be very difficult to make that work with a generic driver because now
>> > that generic driver needs to parse the DT binding for any number of
>> > "compatible" devices.
>>
>> Not necessarily.
>>
>> The patch that started this discussion can work with any number of
>> clocks specified in a "clocks" property. Therefore all that needs to
>> happen is that the final hardware binding specifies it's clocks that
>> way.
>
> Are you suggesting that we should be modeling the hardware specific
> binding to match what the simplefb binding does?

I'll admit that this sounded pretty dumb when I thought over it in the
morning. Let's call it a strawman and let's call me a hilariously
unskilled debater.

I don't have a kernel tree in front of me, so I don't know that all
the helpers used below exist or are named like I've shown, but code
like this could grab all the resources specified in a tree of nodes:

void simplefb_grab_all_resources(node *root)
{
    node *next = root;
    node *cur;

    while( next ) {
        cur = next;

        get_all_resources(cur);

        if( next = of_get_first_child(cur) )
            continue;

        if( next = of_get_next_sibling(cur) )
            continue;

        while( !next && cur != root ) {
            cur = of_get_parent_node(cur);
            next = of_get_next_sibling(cur);
        }

        if( cur == root )
            break;
    }
}

If we added in a few tests in get_all_resources() to keep it from
doing things which are obviously stupid (e.g. grabbing resources for
nodes which have drivers we already have registered) that should work
for any binding and could easily be extended to any resource type.
We're already using linked lists to hold references to those
resources, so there's no problems I can see here, other than adding
some code.

>> I'm sure that as hardware diversifies, the other subsystems will grow
>> in similar directions and eventually be dealt with using similarly
>> generic code.
>
> For regulators this already works very differently. As opposed to the
> clocks/clock-names type of binding it uses one where the consumer name
> of the regulator comes from the prefix of a -supply property. That is
> you'd get something like this:
>
>         foo-supply = <&reg1>;
>         bar-supply = <&reg2>;
>
> And since you don't have enough information in the kernel simplefb
> driver to attach any meaning to these, the best you can do would be
> iterating over a range and have:
>
>         0-supply = <&reg0>;
>         1-supply = <&reg1>;
>         ...
>         n-supply = <&reg2>;
>
> This is made more difficult by the fact that these regulators may be
> required by components not immediately related to the display engine.
> They could be for an attached panel, a video bridge or the +5V pin on
> the HDMI connector.

Surely an iterator could be constructed to go through each node and
process every one named something like "*-supply"?

As for there being regulators for each separate part of the device,
could we read what their current state is then maintain that state?

I'll admit that this is getting rather hairy at this point.

Finally, the clock subsystem has evolved away from "*-clock" bindings
towards the current "clocks" and "clock-names" bindings. I'm sure
other subsystems will follow.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 7829 bytes --]

On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
> > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > firmware has set up, which is the only reason why it will work for many
> > > people. What is passed in via its device tree node is the minimum amount
> > > of information needed to draw something into the framebuffer. Also note
> > > that the simplefb device tree node is not statically added to a DTS file
> > > but needs to be dynamically generated by firmware at runtime.
> > 
> > Which makes the whole even simpler, since the firmware already knows
> > all about which clocks it had to enable.
> 
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

Didn't you just say that it was dynamically generated at runtime? So
we can just ignore the "text editor" case.

> > > If we start extending the binding with board-level details we end up
> > > duplicating the device tree node for the proper video device. Also note
> > > that it won't stop at clocks. Other setups will require regulators to be
> > > listed in this device tree node as well so that they don't get disabled
> > > at late_initcall. And the regulator bindings don't provide a method to
> > > list an arbitrary number of clocks in a single property in the way that
> > > the clocks property works.
> > > 
> > > There may be also resets involved. Fortunately the reset framework is
> > > minimalistic enough not to care about asserting all unused resets at
> > > late_initcall. And other things like power domains may also need to be
> > > kept on.
> > > 
> > > Passing in clock information via the device tree already requires a non-
> > > trivial amount of code in the firmware. A similar amount of code would
> > > be necessary for each type of resource that needs to be kept enabled. In
> > > addition to the above some devices may also require resources that have
> > > no generic bindings. That just doesn't scale.
> > > 
> > > The only reasonable thing for simplefb to do is not deal with any kind
> > > of resource at all (except perhaps area that contains the framebuffer
> > > memory).
> > 
> > You should really read that thread:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> > 
> > It's quite interesting, because you'll see that:
> > A) Your approach, even on the platform you're working on, doesn't
> >    work. Or at least, isn't reliable.
> 
> What platform exactly do you think I'm working on?

My bad, I thought it was a tegra SoC in there. I should have read more
carefully obviously.

> Why do you think what I proposed isn't going to work or be reliable?
> I don't see any arguments in the thread that would imply that.

The fact that it broke in the first place?

> > B) Other maintainers, precisely like Mark, came to the same conclusion
> >    than Mike.
> 
> Well, and others didn't.

We've been talking about both clocks and regulators up to now. I can
see Mike and Mark both suggesting to use the usual clocks and
regulators APIs, either in that thread or the one I pointed out.

> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.

I've seen it, and replied to that already.

> > > So how about instead of requiring resources to be explicitly claimed we
> > > introduce something like the below patch? The intention being to give
> > > "firmware device" drivers a way of signalling to the clock framework
> > > that they need rely on clocks set up by firmware and when they no longer
> > > need them. This implements essentially what Mark (CC'ing again on this
> > > subthread) suggested earlier in this thread. Basically, it will allow
> > > drivers to determine the time when unused clocks are really unused. It
> > > will of course only work when used correctly by drivers. For the case of
> > > simplefb I'd expect its .probe() implementation to call the new
> > > clk_ignore_unused() function and once it has handed over control of the
> > > display hardware to the real driver it can call clk_unignore_unused() to
> > > signal that all unused clocks that it cares about have now been claimed.
> > > This is "reference counted" and can therefore be used by more than a
> > > single driver if necessary. Similar functionality could be added for
> > > other resource subsystems as needed.
> > 
> > So, just to be clear, instead of doing a generic clk_get and
> > clk_prepare_enable, you're willing to do a just as much generic
> > clk_ignore_unused call?
> 
> Yes.
> 
> > How is that less generic?
> 
> It's more generic. That's the whole point.
> 
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point

You keep saying that... and you know that you can't make this
assumption.

> so duplicating what the real driver does within the simplefb driver
> is just that, duplication. We don't allow duplication anywhere else
> in the kernel, why should simplefb be an exception?

Oh come on. Since when a clk_prepare_enable call is duplication?

If so, then we really have a duplication issue, and it's not just for
the clock API.

> > You know that you are going to call that for regulator, reset, power
> > domains, just as you would have needed to with the proper API, unless
> > that with this kind of solution, you would have to modify *every*
> > framework that might interact with any resource involved in getting
> > simplefb running?
> 
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.

Unless that in one case, we already have everything needed to handle
everything properly, and in another, you keep hacking more and more
into the involved frameworks.

> > Plus, speaking more specifically about the clocks, that won't prevent
> > your clock to be shut down as a side effect of a later clk_disable
> > call from another driver.
> 
> If we need to prevent that, then that's something that could be fixed,
> too.

See, you keep hacking it more...

> But both this and the other thread at least agree on the fact that
> simplefb is a shim driver that's going to be replaced by something real
> at some point

I think our definition of "at some point" diverges. Yours seem to be
"at some point during the boot process", which might not even happen
in some platforms (or at least in the foreseeable kernel releases).

> so hopefully concurrent users aren't the problem because that would
> cause the real driver to break too.
> 
> Also note that if some other driver could call clk_disable() it could
> just as easily call clk_set_rate() and break simplefb.

This is not true, see my other reply.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.

It is, but I was talking about a clk_disable after a clk_enable.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
> > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > firmware has set up, which is the only reason why it will work for many
> > > people. What is passed in via its device tree node is the minimum amount
> > > of information needed to draw something into the framebuffer. Also note
> > > that the simplefb device tree node is not statically added to a DTS file
> > > but needs to be dynamically generated by firmware at runtime.
> > 
> > Which makes the whole even simpler, since the firmware already knows
> > all about which clocks it had to enable.
> 
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

Didn't you just say that it was dynamically generated at runtime? So
we can just ignore the "text editor" case.

> > > If we start extending the binding with board-level details we end up
> > > duplicating the device tree node for the proper video device. Also note
> > > that it won't stop at clocks. Other setups will require regulators to be
> > > listed in this device tree node as well so that they don't get disabled
> > > at late_initcall. And the regulator bindings don't provide a method to
> > > list an arbitrary number of clocks in a single property in the way that
> > > the clocks property works.
> > > 
> > > There may be also resets involved. Fortunately the reset framework is
> > > minimalistic enough not to care about asserting all unused resets at
> > > late_initcall. And other things like power domains may also need to be
> > > kept on.
> > > 
> > > Passing in clock information via the device tree already requires a non-
> > > trivial amount of code in the firmware. A similar amount of code would
> > > be necessary for each type of resource that needs to be kept enabled. In
> > > addition to the above some devices may also require resources that have
> > > no generic bindings. That just doesn't scale.
> > > 
> > > The only reasonable thing for simplefb to do is not deal with any kind
> > > of resource at all (except perhaps area that contains the framebuffer
> > > memory).
> > 
> > You should really read that thread:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> > 
> > It's quite interesting, because you'll see that:
> > A) Your approach, even on the platform you're working on, doesn't
> >    work. Or at least, isn't reliable.
> 
> What platform exactly do you think I'm working on?

My bad, I thought it was a tegra SoC in there. I should have read more
carefully obviously.

> Why do you think what I proposed isn't going to work or be reliable?
> I don't see any arguments in the thread that would imply that.

The fact that it broke in the first place?

> > B) Other maintainers, precisely like Mark, came to the same conclusion
> >    than Mike.
> 
> Well, and others didn't.

We've been talking about both clocks and regulators up to now. I can
see Mike and Mark both suggesting to use the usual clocks and
regulators APIs, either in that thread or the one I pointed out.

> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.

I've seen it, and replied to that already.

> > > So how about instead of requiring resources to be explicitly claimed we
> > > introduce something like the below patch? The intention being to give
> > > "firmware device" drivers a way of signalling to the clock framework
> > > that they need rely on clocks set up by firmware and when they no longer
> > > need them. This implements essentially what Mark (CC'ing again on this
> > > subthread) suggested earlier in this thread. Basically, it will allow
> > > drivers to determine the time when unused clocks are really unused. It
> > > will of course only work when used correctly by drivers. For the case of
> > > simplefb I'd expect its .probe() implementation to call the new
> > > clk_ignore_unused() function and once it has handed over control of the
> > > display hardware to the real driver it can call clk_unignore_unused() to
> > > signal that all unused clocks that it cares about have now been claimed.
> > > This is "reference counted" and can therefore be used by more than a
> > > single driver if necessary. Similar functionality could be added for
> > > other resource subsystems as needed.
> > 
> > So, just to be clear, instead of doing a generic clk_get and
> > clk_prepare_enable, you're willing to do a just as much generic
> > clk_ignore_unused call?
> 
> Yes.
> 
> > How is that less generic?
> 
> It's more generic. That's the whole point.
> 
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point

You keep saying that... and you know that you can't make this
assumption.

> so duplicating what the real driver does within the simplefb driver
> is just that, duplication. We don't allow duplication anywhere else
> in the kernel, why should simplefb be an exception?

Oh come on. Since when a clk_prepare_enable call is duplication?

If so, then we really have a duplication issue, and it's not just for
the clock API.

> > You know that you are going to call that for regulator, reset, power
> > domains, just as you would have needed to with the proper API, unless
> > that with this kind of solution, you would have to modify *every*
> > framework that might interact with any resource involved in getting
> > simplefb running?
> 
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.

Unless that in one case, we already have everything needed to handle
everything properly, and in another, you keep hacking more and more
into the involved frameworks.

> > Plus, speaking more specifically about the clocks, that won't prevent
> > your clock to be shut down as a side effect of a later clk_disable
> > call from another driver.
> 
> If we need to prevent that, then that's something that could be fixed,
> too.

See, you keep hacking it more...

> But both this and the other thread at least agree on the fact that
> simplefb is a shim driver that's going to be replaced by something real
> at some point

I think our definition of "at some point" diverges. Yours seem to be
"at some point during the boot process", which might not even happen
in some platforms (or at least in the foreseeable kernel releases).

> so hopefully concurrent users aren't the problem because that would
> cause the real driver to break too.
> 
> Also note that if some other driver could call clk_disable() it could
> just as easily call clk_set_rate() and break simplefb.

This is not true, see my other reply.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.

It is, but I was talking about a clk_disable after a clk_enable.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/1cebdefc/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 7485 bytes --]

On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > firmware has set up, which is the only reason why it will work for many
> > > > people. What is passed in via its device tree node is the minimum amount
> > > > of information needed to draw something into the framebuffer. Also note
> > > > that the simplefb device tree node is not statically added to a DTS file
> > > > but needs to be dynamically generated by firmware at runtime.
> > > 
> > > Which makes the whole even simpler, since the firmware already knows
> > > all about which clocks it had to enable.
> > 
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> Didn't you just say that it was dynamically generated at runtime? So
> we can just ignore the "text editor" case.

Perhaps read the sentence again. I said "that we would *otherwise* be
able to do much easier with a text editor.".

My point remains that there shouldn't be a need to generate DTB content
of this complexity at all.

> > Why do you think what I proposed isn't going to work or be reliable?
> > I don't see any arguments in the thread that would imply that.
> 
> The fact that it broke in the first place?

That's exactly the point. And it's going to break again and again as
simplefb is extended with new things. Generally DT bindings should be
backwards compatible. When extended they should provide a way to fall
back to a reasonable default. There's simply no way you can do that
with simplefb.

What happened in the Snow example is that regulators that were
previously on would all of a sudden be automatically disabled on boot
because there was now a driver that registered them with a generic
framework.

The same thing is going to happen with simplefb for your device. If you
later realize that you need a regulator to keep the panel going, you'll
have to add code to your firmware to populate the corresponding
properties, otherwise the regulator will end up unused and will be
automatically disabled. At the same time you're going to break upstream
for all users of your old firmware because it doesn't add that property
yet.

And the same will continue to happen for every new type of resource
you're going to add.

> > > > So how about instead of requiring resources to be explicitly claimed we
> > > > introduce something like the below patch? The intention being to give
> > > > "firmware device" drivers a way of signalling to the clock framework
> > > > that they need rely on clocks set up by firmware and when they no longer
> > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > drivers to determine the time when unused clocks are really unused. It
> > > > will of course only work when used correctly by drivers. For the case of
> > > > simplefb I'd expect its .probe() implementation to call the new
> > > > clk_ignore_unused() function and once it has handed over control of the
> > > > display hardware to the real driver it can call clk_unignore_unused() to
> > > > signal that all unused clocks that it cares about have now been claimed.
> > > > This is "reference counted" and can therefore be used by more than a
> > > > single driver if necessary. Similar functionality could be added for
> > > > other resource subsystems as needed.
> > > 
> > > So, just to be clear, instead of doing a generic clk_get and
> > > clk_prepare_enable, you're willing to do a just as much generic
> > > clk_ignore_unused call?
> > 
> > Yes.
> > 
> > > How is that less generic?
> > 
> > It's more generic. That's the whole point.
> > 
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point
> 
> You keep saying that... and you know that you can't make this
> assumption.

Why not? Are you really expecting to keep running with simplefb forever?
Nobody is going to seriously use an upstream kernel in any product with
only simplefb as a framebuffer. I've said before that this is a hack to
get you working display. And that's all it is. If you want to do it
properly go and write a DRM/KMS driver.

> > > You know that you are going to call that for regulator, reset, power
> > > domains, just as you would have needed to with the proper API, unless
> > > that with this kind of solution, you would have to modify *every*
> > > framework that might interact with any resource involved in getting
> > > simplefb running?
> > 
> > We have to add handling for every kind of resource either way. Also if
> > this evolves into a common pattern we can easily wrap it up in a single
> > function call.
> 
> Unless that in one case, we already have everything needed to handle
> everything properly, and in another, you keep hacking more and more
> into the involved frameworks.

This is a fundamental issue that we are facing and I'm trying to come up
with a solution that is future-proof and will work for drivers other
than simplefb.

Just because we currently lack this functionality doesn't make it a hack
trying to add it.

> > > Plus, speaking more specifically about the clocks, that won't prevent
> > > your clock to be shut down as a side effect of a later clk_disable
> > > call from another driver.
> > 
> > If we need to prevent that, then that's something that could be fixed,
> > too.
> 
> See, you keep hacking it more...

If you don't see this as a problem that exists beyond simplefb then I
would of course not expect you to think that anything needs fixing.

> > But both this and the other thread at least agree on the fact that
> > simplefb is a shim driver that's going to be replaced by something real
> > at some point
> 
> I think our definition of "at some point" diverges. Yours seem to be
> "at some point during the boot process", which might not even happen
> in some platforms (or at least in the foreseeable kernel releases).

Then instead of hacking existing drivers to work on your particular
platform you should start looking into hacking your platform drivers to
cope with the lack of a proper display driver. Or alternatively spend
the time getting a proper display driver merged.

Whether simplefb is used as primary framebuffer or just during only boot
until hand-off to a real driver, it still remains a stop-gap solution.

> > so hopefully concurrent users aren't the problem because that would
> > cause the real driver to break too.
> > 
> > Also note that if some other driver could call clk_disable() it could
> > just as easily call clk_set_rate() and break simplefb.
> 
> This is not true, see my other reply.

If you mean that you could register a clock notifier to prevent clock
changes, then that's going to lead to other drivers failing since they
can now no longer set the rate that they need.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > firmware has set up, which is the only reason why it will work for many
> > > > people. What is passed in via its device tree node is the minimum amount
> > > > of information needed to draw something into the framebuffer. Also note
> > > > that the simplefb device tree node is not statically added to a DTS file
> > > > but needs to be dynamically generated by firmware at runtime.
> > > 
> > > Which makes the whole even simpler, since the firmware already knows
> > > all about which clocks it had to enable.
> > 
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> Didn't you just say that it was dynamically generated at runtime? So
> we can just ignore the "text editor" case.

Perhaps read the sentence again. I said "that we would *otherwise* be
able to do much easier with a text editor.".

My point remains that there shouldn't be a need to generate DTB content
of this complexity at all.

> > Why do you think what I proposed isn't going to work or be reliable?
> > I don't see any arguments in the thread that would imply that.
> 
> The fact that it broke in the first place?

That's exactly the point. And it's going to break again and again as
simplefb is extended with new things. Generally DT bindings should be
backwards compatible. When extended they should provide a way to fall
back to a reasonable default. There's simply no way you can do that
with simplefb.

What happened in the Snow example is that regulators that were
previously on would all of a sudden be automatically disabled on boot
because there was now a driver that registered them with a generic
framework.

The same thing is going to happen with simplefb for your device. If you
later realize that you need a regulator to keep the panel going, you'll
have to add code to your firmware to populate the corresponding
properties, otherwise the regulator will end up unused and will be
automatically disabled. At the same time you're going to break upstream
for all users of your old firmware because it doesn't add that property
yet.

And the same will continue to happen for every new type of resource
you're going to add.

> > > > So how about instead of requiring resources to be explicitly claimed we
> > > > introduce something like the below patch? The intention being to give
> > > > "firmware device" drivers a way of signalling to the clock framework
> > > > that they need rely on clocks set up by firmware and when they no longer
> > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > drivers to determine the time when unused clocks are really unused. It
> > > > will of course only work when used correctly by drivers. For the case of
> > > > simplefb I'd expect its .probe() implementation to call the new
> > > > clk_ignore_unused() function and once it has handed over control of the
> > > > display hardware to the real driver it can call clk_unignore_unused() to
> > > > signal that all unused clocks that it cares about have now been claimed.
> > > > This is "reference counted" and can therefore be used by more than a
> > > > single driver if necessary. Similar functionality could be added for
> > > > other resource subsystems as needed.
> > > 
> > > So, just to be clear, instead of doing a generic clk_get and
> > > clk_prepare_enable, you're willing to do a just as much generic
> > > clk_ignore_unused call?
> > 
> > Yes.
> > 
> > > How is that less generic?
> > 
> > It's more generic. That's the whole point.
> > 
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point
> 
> You keep saying that... and you know that you can't make this
> assumption.

Why not? Are you really expecting to keep running with simplefb forever?
Nobody is going to seriously use an upstream kernel in any product with
only simplefb as a framebuffer. I've said before that this is a hack to
get you working display. And that's all it is. If you want to do it
properly go and write a DRM/KMS driver.

> > > You know that you are going to call that for regulator, reset, power
> > > domains, just as you would have needed to with the proper API, unless
> > > that with this kind of solution, you would have to modify *every*
> > > framework that might interact with any resource involved in getting
> > > simplefb running?
> > 
> > We have to add handling for every kind of resource either way. Also if
> > this evolves into a common pattern we can easily wrap it up in a single
> > function call.
> 
> Unless that in one case, we already have everything needed to handle
> everything properly, and in another, you keep hacking more and more
> into the involved frameworks.

This is a fundamental issue that we are facing and I'm trying to come up
with a solution that is future-proof and will work for drivers other
than simplefb.

Just because we currently lack this functionality doesn't make it a hack
trying to add it.

> > > Plus, speaking more specifically about the clocks, that won't prevent
> > > your clock to be shut down as a side effect of a later clk_disable
> > > call from another driver.
> > 
> > If we need to prevent that, then that's something that could be fixed,
> > too.
> 
> See, you keep hacking it more...

If you don't see this as a problem that exists beyond simplefb then I
would of course not expect you to think that anything needs fixing.

> > But both this and the other thread at least agree on the fact that
> > simplefb is a shim driver that's going to be replaced by something real
> > at some point
> 
> I think our definition of "at some point" diverges. Yours seem to be
> "at some point during the boot process", which might not even happen
> in some platforms (or at least in the foreseeable kernel releases).

Then instead of hacking existing drivers to work on your particular
platform you should start looking into hacking your platform drivers to
cope with the lack of a proper display driver. Or alternatively spend
the time getting a proper display driver merged.

Whether simplefb is used as primary framebuffer or just during only boot
until hand-off to a real driver, it still remains a stop-gap solution.

> > so hopefully concurrent users aren't the problem because that would
> > cause the real driver to break too.
> > 
> > Also note that if some other driver could call clk_disable() it could
> > just as easily call clk_set_rate() and break simplefb.
> 
> This is not true, see my other reply.

If you mean that you could register a clock notifier to prevent clock
changes, then that's going to lead to other drivers failing since they
can now no longer set the rate that they need.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/be42a7b5/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> > > > simplefb doesn't deal at all with hardware details. It simply uses what
>> > > > firmware has set up, which is the only reason why it will work for many
>> > > > people. What is passed in via its device tree node is the minimum amount
>> > > > of information needed to draw something into the framebuffer. Also note
>> > > > that the simplefb device tree node is not statically added to a DTS file
>> > > > but needs to be dynamically generated by firmware at runtime.
>> > >
>> > > Which makes the whole even simpler, since the firmware already knows
>> > > all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> Didn't you just say that it was dynamically generated at runtime? So
>> we can just ignore the "text editor" case.
>
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
>
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
>
>> > Why do you think what I proposed isn't going to work or be reliable?
>> > I don't see any arguments in the thread that would imply that.
>>
>> The fact that it broke in the first place?
>
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.
>
> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

So what? You get a driver for regulators and suddenly find that
nothing registered regulators because they were on all the time anyway
and everything breaks? What a surprise!

>
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

Sure. And what can you do about that? It's not like the original Snow
firmware writes anything of use to the DT at all. So to run a
development kernel you need a development firmware. If you add new
features to the kernel that involve intefacing to the firmware you
need to update the firmware as well. Once support for Snow platform is
stable you can expect that users can use a stable release of firmware
indefinitely.

>
> And the same will continue to happen for every new type of resource
> you're going to add.

The like 5 resource types, yes. Some of which may not even apply to simplefb.

>
>> > > > So how about instead of requiring resources to be explicitly claimed we
>> > > > introduce something like the below patch? The intention being to give
>> > > > "firmware device" drivers a way of signalling to the clock framework
>> > > > that they need rely on clocks set up by firmware and when they no longer
>> > > > need them. This implements essentially what Mark (CC'ing again on this
>> > > > subthread) suggested earlier in this thread. Basically, it will allow
>> > > > drivers to determine the time when unused clocks are really unused. It
>> > > > will of course only work when used correctly by drivers. For the case of
>> > > > simplefb I'd expect its .probe() implementation to call the new
>> > > > clk_ignore_unused() function and once it has handed over control of the
>> > > > display hardware to the real driver it can call clk_unignore_unused() to
>> > > > signal that all unused clocks that it cares about have now been claimed.
>> > > > This is "reference counted" and can therefore be used by more than a
>> > > > single driver if necessary. Similar functionality could be added for
>> > > > other resource subsystems as needed.
>> > >
>> > > So, just to be clear, instead of doing a generic clk_get and
>> > > clk_prepare_enable, you're willing to do a just as much generic
>> > > clk_ignore_unused call?
>> >
>> > Yes.
>> >
>> > > How is that less generic?
>> >
>> > It's more generic. That's the whole point.
>> >
>> > The difference is that with the solution I proposed we don't have to
>> > keep track of all the resources. We know that firmware has set them up
>> > and we know that a real driver will properly take them over at some
>> > point
>>
>> You keep saying that... and you know that you can't make this
>> assumption.
>
> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to

Why not? You can use shadowfb (software acceleration) with simplefb
all right. Shadowfb is hands down the fastest video acceleration we
have on anything but hardware that has _very_ slow CPU or that can run
Intel UXA drivers. With manufacturers adding more and more superfluous
cores to the CPUs shadowfb is actually not too stressing on the
system, either.

On hardware like Allwinner A13 (single core) the use of shadowfb over
actual video acceleration hardware has its benefits and drawbacks and
is neither clearly better nor worse. The same hardware tends to have
only one fixed video output - a tablet LCD panel. On such hardware
modesetting is needless luxury if u-boot provides the simplfb
bindings, at least for some use cases.

And there is still the use of simplefb during development and for
generic distribution kernels. I prefer that during development of the
KMS driver and during bootup before the KMS module becomes available
the system behaves normally, not in special hacked way that is useless
for anything but this special system mode. Worse, such special mode
will not be regularly tested on well supported hardware and will
likely bitrot and lead to mysterious issues at boot time when KMS is
not available and this special system mode is in effect.

> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.
>
>> > > You know that you are going to call that for regulator, reset, power
>> > > domains, just as you would have needed to with the proper API, unless
>> > > that with this kind of solution, you would have to modify *every*
>> > > framework that might interact with any resource involved in getting
>> > > simplefb running?
>> >
>> > We have to add handling for every kind of resource either way. Also if
>> > this evolves into a common pattern we can easily wrap it up in a single
>> > function call.
>>
>> Unless that in one case, we already have everything needed to handle
>> everything properly, and in another, you keep hacking more and more
>> into the involved frameworks.
>
> This is a fundamental issue that we are facing and I'm trying to come up
> with a solution that is future-proof and will work for drivers other
> than simplefb.

How is proper resource management not going to work for drivers other
than simplefb?

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> > > > simplefb doesn't deal at all with hardware details. It simply uses what
>> > > > firmware has set up, which is the only reason why it will work for many
>> > > > people. What is passed in via its device tree node is the minimum amount
>> > > > of information needed to draw something into the framebuffer. Also note
>> > > > that the simplefb device tree node is not statically added to a DTS file
>> > > > but needs to be dynamically generated by firmware at runtime.
>> > >
>> > > Which makes the whole even simpler, since the firmware already knows
>> > > all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> Didn't you just say that it was dynamically generated at runtime? So
>> we can just ignore the "text editor" case.
>
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
>
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
>
>> > Why do you think what I proposed isn't going to work or be reliable?
>> > I don't see any arguments in the thread that would imply that.
>>
>> The fact that it broke in the first place?
>
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.
>
> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

So what? You get a driver for regulators and suddenly find that
nothing registered regulators because they were on all the time anyway
and everything breaks? What a surprise!

>
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

Sure. And what can you do about that? It's not like the original Snow
firmware writes anything of use to the DT at all. So to run a
development kernel you need a development firmware. If you add new
features to the kernel that involve intefacing to the firmware you
need to update the firmware as well. Once support for Snow platform is
stable you can expect that users can use a stable release of firmware
indefinitely.

>
> And the same will continue to happen for every new type of resource
> you're going to add.

The like 5 resource types, yes. Some of which may not even apply to simplefb.

>
>> > > > So how about instead of requiring resources to be explicitly claimed we
>> > > > introduce something like the below patch? The intention being to give
>> > > > "firmware device" drivers a way of signalling to the clock framework
>> > > > that they need rely on clocks set up by firmware and when they no longer
>> > > > need them. This implements essentially what Mark (CC'ing again on this
>> > > > subthread) suggested earlier in this thread. Basically, it will allow
>> > > > drivers to determine the time when unused clocks are really unused. It
>> > > > will of course only work when used correctly by drivers. For the case of
>> > > > simplefb I'd expect its .probe() implementation to call the new
>> > > > clk_ignore_unused() function and once it has handed over control of the
>> > > > display hardware to the real driver it can call clk_unignore_unused() to
>> > > > signal that all unused clocks that it cares about have now been claimed.
>> > > > This is "reference counted" and can therefore be used by more than a
>> > > > single driver if necessary. Similar functionality could be added for
>> > > > other resource subsystems as needed.
>> > >
>> > > So, just to be clear, instead of doing a generic clk_get and
>> > > clk_prepare_enable, you're willing to do a just as much generic
>> > > clk_ignore_unused call?
>> >
>> > Yes.
>> >
>> > > How is that less generic?
>> >
>> > It's more generic. That's the whole point.
>> >
>> > The difference is that with the solution I proposed we don't have to
>> > keep track of all the resources. We know that firmware has set them up
>> > and we know that a real driver will properly take them over at some
>> > point
>>
>> You keep saying that... and you know that you can't make this
>> assumption.
>
> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to

Why not? You can use shadowfb (software acceleration) with simplefb
all right. Shadowfb is hands down the fastest video acceleration we
have on anything but hardware that has _very_ slow CPU or that can run
Intel UXA drivers. With manufacturers adding more and more superfluous
cores to the CPUs shadowfb is actually not too stressing on the
system, either.

On hardware like Allwinner A13 (single core) the use of shadowfb over
actual video acceleration hardware has its benefits and drawbacks and
is neither clearly better nor worse. The same hardware tends to have
only one fixed video output - a tablet LCD panel. On such hardware
modesetting is needless luxury if u-boot provides the simplfb
bindings, at least for some use cases.

And there is still the use of simplefb during development and for
generic distribution kernels. I prefer that during development of the
KMS driver and during bootup before the KMS module becomes available
the system behaves normally, not in special hacked way that is useless
for anything but this special system mode. Worse, such special mode
will not be regularly tested on well supported hardware and will
likely bitrot and lead to mysterious issues at boot time when KMS is
not available and this special system mode is in effect.

> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.
>
>> > > You know that you are going to call that for regulator, reset, power
>> > > domains, just as you would have needed to with the proper API, unless
>> > > that with this kind of solution, you would have to modify *every*
>> > > framework that might interact with any resource involved in getting
>> > > simplefb running?
>> >
>> > We have to add handling for every kind of resource either way. Also if
>> > this evolves into a common pattern we can easily wrap it up in a single
>> > function call.
>>
>> Unless that in one case, we already have everything needed to handle
>> everything properly, and in another, you keep hacking more and more
>> into the involved frameworks.
>
> This is a fundamental issue that we are facing and I'm trying to come up
> with a solution that is future-proof and will work for drivers other
> than simplefb.

How is proper resource management not going to work for drivers other
than simplefb?

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 9804 bytes --]

On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
> On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> > > > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > > > firmware has set up, which is the only reason why it will work for many
> >> > > > people. What is passed in via its device tree node is the minimum amount
> >> > > > of information needed to draw something into the framebuffer. Also note
> >> > > > that the simplefb device tree node is not statically added to a DTS file
> >> > > > but needs to be dynamically generated by firmware at runtime.
> >> > >
> >> > > Which makes the whole even simpler, since the firmware already knows
> >> > > all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> Didn't you just say that it was dynamically generated at runtime? So
> >> we can just ignore the "text editor" case.
> >
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> >
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> >
> >> > Why do you think what I proposed isn't going to work or be reliable?
> >> > I don't see any arguments in the thread that would imply that.
> >>
> >> The fact that it broke in the first place?
> >
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> >
> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> 
> So what? You get a driver for regulators and suddenly find that
> nothing registered regulators because they were on all the time anyway
> and everything breaks? What a surprise!

I agree, this is not a surprise at all. But like I pointed out this is
bound to happen again and again. So how about we learn from it and add
the functionality needed to prevent it from happening?

> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> Sure. And what can you do about that? It's not like the original Snow
> firmware writes anything of use to the DT at all. So to run a
> development kernel you need a development firmware. If you add new
> features to the kernel that involve intefacing to the firmware you
> need to update the firmware as well. Once support for Snow platform is
> stable you can expect that users can use a stable release of firmware
> indefinitely.

Feel free to take that up with the DT ABI stability committee.

> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> The like 5 resource types, yes. Some of which may not even apply to simplefb.

Today it's 5, tomorrow 6, next year, who knows.

> >> > > > So how about instead of requiring resources to be explicitly claimed we
> >> > > > introduce something like the below patch? The intention being to give
> >> > > > "firmware device" drivers a way of signalling to the clock framework
> >> > > > that they need rely on clocks set up by firmware and when they no longer
> >> > > > need them. This implements essentially what Mark (CC'ing again on this
> >> > > > subthread) suggested earlier in this thread. Basically, it will allow
> >> > > > drivers to determine the time when unused clocks are really unused. It
> >> > > > will of course only work when used correctly by drivers. For the case of
> >> > > > simplefb I'd expect its .probe() implementation to call the new
> >> > > > clk_ignore_unused() function and once it has handed over control of the
> >> > > > display hardware to the real driver it can call clk_unignore_unused() to
> >> > > > signal that all unused clocks that it cares about have now been claimed.
> >> > > > This is "reference counted" and can therefore be used by more than a
> >> > > > single driver if necessary. Similar functionality could be added for
> >> > > > other resource subsystems as needed.
> >> > >
> >> > > So, just to be clear, instead of doing a generic clk_get and
> >> > > clk_prepare_enable, you're willing to do a just as much generic
> >> > > clk_ignore_unused call?
> >> >
> >> > Yes.
> >> >
> >> > > How is that less generic?
> >> >
> >> > It's more generic. That's the whole point.
> >> >
> >> > The difference is that with the solution I proposed we don't have to
> >> > keep track of all the resources. We know that firmware has set them up
> >> > and we know that a real driver will properly take them over at some
> >> > point
> >>
> >> You keep saying that... and you know that you can't make this
> >> assumption.
> >
> > Why not? Are you really expecting to keep running with simplefb forever?
> > Nobody is going to seriously use an upstream kernel in any product with
> > only simplefb as a framebuffer. I've said before that this is a hack to
> 
> Why not? You can use shadowfb (software acceleration) with simplefb
> all right. Shadowfb is hands down the fastest video acceleration we
> have on anything but hardware that has _very_ slow CPU or that can run
> Intel UXA drivers. With manufacturers adding more and more superfluous
> cores to the CPUs shadowfb is actually not too stressing on the
> system, either.
> 
> On hardware like Allwinner A13 (single core) the use of shadowfb over
> actual video acceleration hardware has its benefits and drawbacks and
> is neither clearly better nor worse. The same hardware tends to have
> only one fixed video output - a tablet LCD panel. On such hardware
> modesetting is needless luxury if u-boot provides the simplfb
> bindings, at least for some use cases.

I presume some of those tablets will have HDMI connectors. And surely
somebody will eventually put an Allwinner SoC into something that's not
a tablet.

Note also that with only simplefb you won't be able to use any kind of
hardware acceleration, not even 3D. Perhaps you could even pull it off
but certainly not with any kind of double-buffering, so while it might
be an easy way to get something to display, please stop pretending that
DRM/KMS don't matter.

Also this is all hypothetical since Luc said himself that he's already
working on a DRM/KMS driver.

> And there is still the use of simplefb during development and for
> generic distribution kernels.

Generic distribution kernels can use DRM/KMS just fine. And they also
want to use it because it gives them a lot of advanced features using a
standard API.

> I prefer that during development of the
> KMS driver and during bootup before the KMS module becomes available
> the system behaves normally, not in special hacked way that is useless
> for anything but this special system mode. Worse, such special mode
> will not be regularly tested on well supported hardware and will
> likely bitrot and lead to mysterious issues at boot time when KMS is
> not available and this special system mode is in effect.

It's not at all special or hacked. It merely uses a couple of
assumptions that differ from what you might expect from a regular
driver. And that's really the essence of simplefb.

> > get you working display. And that's all it is. If you want to do it
> > properly go and write a DRM/KMS driver.
> >
> >> > > You know that you are going to call that for regulator, reset, power
> >> > > domains, just as you would have needed to with the proper API, unless
> >> > > that with this kind of solution, you would have to modify *every*
> >> > > framework that might interact with any resource involved in getting
> >> > > simplefb running?
> >> >
> >> > We have to add handling for every kind of resource either way. Also if
> >> > this evolves into a common pattern we can easily wrap it up in a single
> >> > function call.
> >>
> >> Unless that in one case, we already have everything needed to handle
> >> everything properly, and in another, you keep hacking more and more
> >> into the involved frameworks.
> >
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> 
> How is proper resource management not going to work for drivers other
> than simplefb?

I have no doubt that it's going to work. It already does. But unless we
solve this at the core we'll be reiterating this for every new type of
resource that we need to support and for every other driver of the same
nature (i.e. uses a "virtual" device set up by firmware).

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
> On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> > > > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > > > firmware has set up, which is the only reason why it will work for many
> >> > > > people. What is passed in via its device tree node is the minimum amount
> >> > > > of information needed to draw something into the framebuffer. Also note
> >> > > > that the simplefb device tree node is not statically added to a DTS file
> >> > > > but needs to be dynamically generated by firmware at runtime.
> >> > >
> >> > > Which makes the whole even simpler, since the firmware already knows
> >> > > all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> Didn't you just say that it was dynamically generated at runtime? So
> >> we can just ignore the "text editor" case.
> >
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> >
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> >
> >> > Why do you think what I proposed isn't going to work or be reliable?
> >> > I don't see any arguments in the thread that would imply that.
> >>
> >> The fact that it broke in the first place?
> >
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> >
> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> 
> So what? You get a driver for regulators and suddenly find that
> nothing registered regulators because they were on all the time anyway
> and everything breaks? What a surprise!

I agree, this is not a surprise at all. But like I pointed out this is
bound to happen again and again. So how about we learn from it and add
the functionality needed to prevent it from happening?

> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> Sure. And what can you do about that? It's not like the original Snow
> firmware writes anything of use to the DT at all. So to run a
> development kernel you need a development firmware. If you add new
> features to the kernel that involve intefacing to the firmware you
> need to update the firmware as well. Once support for Snow platform is
> stable you can expect that users can use a stable release of firmware
> indefinitely.

Feel free to take that up with the DT ABI stability committee.

> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> The like 5 resource types, yes. Some of which may not even apply to simplefb.

Today it's 5, tomorrow 6, next year, who knows.

> >> > > > So how about instead of requiring resources to be explicitly claimed we
> >> > > > introduce something like the below patch? The intention being to give
> >> > > > "firmware device" drivers a way of signalling to the clock framework
> >> > > > that they need rely on clocks set up by firmware and when they no longer
> >> > > > need them. This implements essentially what Mark (CC'ing again on this
> >> > > > subthread) suggested earlier in this thread. Basically, it will allow
> >> > > > drivers to determine the time when unused clocks are really unused. It
> >> > > > will of course only work when used correctly by drivers. For the case of
> >> > > > simplefb I'd expect its .probe() implementation to call the new
> >> > > > clk_ignore_unused() function and once it has handed over control of the
> >> > > > display hardware to the real driver it can call clk_unignore_unused() to
> >> > > > signal that all unused clocks that it cares about have now been claimed.
> >> > > > This is "reference counted" and can therefore be used by more than a
> >> > > > single driver if necessary. Similar functionality could be added for
> >> > > > other resource subsystems as needed.
> >> > >
> >> > > So, just to be clear, instead of doing a generic clk_get and
> >> > > clk_prepare_enable, you're willing to do a just as much generic
> >> > > clk_ignore_unused call?
> >> >
> >> > Yes.
> >> >
> >> > > How is that less generic?
> >> >
> >> > It's more generic. That's the whole point.
> >> >
> >> > The difference is that with the solution I proposed we don't have to
> >> > keep track of all the resources. We know that firmware has set them up
> >> > and we know that a real driver will properly take them over at some
> >> > point
> >>
> >> You keep saying that... and you know that you can't make this
> >> assumption.
> >
> > Why not? Are you really expecting to keep running with simplefb forever?
> > Nobody is going to seriously use an upstream kernel in any product with
> > only simplefb as a framebuffer. I've said before that this is a hack to
> 
> Why not? You can use shadowfb (software acceleration) with simplefb
> all right. Shadowfb is hands down the fastest video acceleration we
> have on anything but hardware that has _very_ slow CPU or that can run
> Intel UXA drivers. With manufacturers adding more and more superfluous
> cores to the CPUs shadowfb is actually not too stressing on the
> system, either.
> 
> On hardware like Allwinner A13 (single core) the use of shadowfb over
> actual video acceleration hardware has its benefits and drawbacks and
> is neither clearly better nor worse. The same hardware tends to have
> only one fixed video output - a tablet LCD panel. On such hardware
> modesetting is needless luxury if u-boot provides the simplfb
> bindings, at least for some use cases.

I presume some of those tablets will have HDMI connectors. And surely
somebody will eventually put an Allwinner SoC into something that's not
a tablet.

Note also that with only simplefb you won't be able to use any kind of
hardware acceleration, not even 3D. Perhaps you could even pull it off
but certainly not with any kind of double-buffering, so while it might
be an easy way to get something to display, please stop pretending that
DRM/KMS don't matter.

Also this is all hypothetical since Luc said himself that he's already
working on a DRM/KMS driver.

> And there is still the use of simplefb during development and for
> generic distribution kernels.

Generic distribution kernels can use DRM/KMS just fine. And they also
want to use it because it gives them a lot of advanced features using a
standard API.

> I prefer that during development of the
> KMS driver and during bootup before the KMS module becomes available
> the system behaves normally, not in special hacked way that is useless
> for anything but this special system mode. Worse, such special mode
> will not be regularly tested on well supported hardware and will
> likely bitrot and lead to mysterious issues at boot time when KMS is
> not available and this special system mode is in effect.

It's not at all special or hacked. It merely uses a couple of
assumptions that differ from what you might expect from a regular
driver. And that's really the essence of simplefb.

> > get you working display. And that's all it is. If you want to do it
> > properly go and write a DRM/KMS driver.
> >
> >> > > You know that you are going to call that for regulator, reset, power
> >> > > domains, just as you would have needed to with the proper API, unless
> >> > > that with this kind of solution, you would have to modify *every*
> >> > > framework that might interact with any resource involved in getting
> >> > > simplefb running?
> >> >
> >> > We have to add handling for every kind of resource either way. Also if
> >> > this evolves into a common pattern we can easily wrap it up in a single
> >> > function call.
> >>
> >> Unless that in one case, we already have everything needed to handle
> >> everything properly, and in another, you keep hacking more and more
> >> into the involved frameworks.
> >
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> 
> How is proper resource management not going to work for drivers other
> than simplefb?

I have no doubt that it's going to work. It already does. But unless we
solve this at the core we'll be reiterating this for every new type of
resource that we need to support and for every other driver of the same
nature (i.e. uses a "virtual" device set up by firmware).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/d541b228/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 17:49, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
>> On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> > > > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > > > firmware has set up, which is the only reason why it will work for many
>> >> > > > people. What is passed in via its device tree node is the minimum amount
>> >> > > > of information needed to draw something into the framebuffer. Also note
>> >> > > > that the simplefb device tree node is not statically added to a DTS file
>> >> > > > but needs to be dynamically generated by firmware at runtime.
>> >> > >
>> >> > > Which makes the whole even simpler, since the firmware already knows
>> >> > > all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> Didn't you just say that it was dynamically generated at runtime? So
>> >> we can just ignore the "text editor" case.
>> >
>> > Perhaps read the sentence again. I said "that we would *otherwise* be
>> > able to do much easier with a text editor.".
>> >
>> > My point remains that there shouldn't be a need to generate DTB content
>> > of this complexity at all.
>> >
>> >> > Why do you think what I proposed isn't going to work or be reliable?
>> >> > I don't see any arguments in the thread that would imply that.
>> >>
>> >> The fact that it broke in the first place?
>> >
>> > That's exactly the point. And it's going to break again and again as
>> > simplefb is extended with new things. Generally DT bindings should be
>> > backwards compatible. When extended they should provide a way to fall
>> > back to a reasonable default. There's simply no way you can do that
>> > with simplefb.
>> >
>> > What happened in the Snow example is that regulators that were
>> > previously on would all of a sudden be automatically disabled on boot
>> > because there was now a driver that registered them with a generic
>> > framework.
>>
>> So what? You get a driver for regulators and suddenly find that
>> nothing registered regulators because they were on all the time anyway
>> and everything breaks? What a surprise!
>
> I agree, this is not a surprise at all. But like I pointed out this is
> bound to happen again and again. So how about we learn from it and add
> the functionality needed to prevent it from happening?
>
>> > The same thing is going to happen with simplefb for your device. If you
>> > later realize that you need a regulator to keep the panel going, you'll
>> > have to add code to your firmware to populate the corresponding
>> > properties, otherwise the regulator will end up unused and will be
>> > automatically disabled. At the same time you're going to break upstream
>> > for all users of your old firmware because it doesn't add that property
>> > yet.
>>
>> Sure. And what can you do about that? It's not like the original Snow
>> firmware writes anything of use to the DT at all. So to run a
>> development kernel you need a development firmware. If you add new
>> features to the kernel that involve intefacing to the firmware you
>> need to update the firmware as well. Once support for Snow platform is
>> stable you can expect that users can use a stable release of firmware
>> indefinitely.
>
> Feel free to take that up with the DT ABI stability committee.

As pointed out you can also generate by hand a DT that exactly
describes what the preinstalled firmware sets up - so long as the
preinstalled firmware sets upa any usable framebuffer at all and
always sets up the same thing. If the preinstalled firmware can set up
the framebuffer in different ways and is not willing to communicate to
the kernel in what way it set up the framebuffer then it is unusable
with simplefb. That sucks but there is no way around that.

>> > Why not? Are you really expecting to keep running with simplefb forever?
>> > Nobody is going to seriously use an upstream kernel in any product with
>> > only simplefb as a framebuffer. I've said before that this is a hack to
>>
>> Why not? You can use shadowfb (software acceleration) with simplefb
>> all right. Shadowfb is hands down the fastest video acceleration we
>> have on anything but hardware that has _very_ slow CPU or that can run
>> Intel UXA drivers. With manufacturers adding more and more superfluous
>> cores to the CPUs shadowfb is actually not too stressing on the
>> system, either.
>>
>> On hardware like Allwinner A13 (single core) the use of shadowfb over
>> actual video acceleration hardware has its benefits and drawbacks and
>> is neither clearly better nor worse. The same hardware tends to have
>> only one fixed video output - a tablet LCD panel. On such hardware
>> modesetting is needless luxury if u-boot provides the simplfb
>> bindings, at least for some use cases.
>
> I presume some of those tablets will have HDMI connectors. And surely

Nope. Only 1 output.

> somebody will eventually put an Allwinner SoC into something that's not
> a tablet.

Sure. And you might want to bother with modesetting then.

>
> Note also that with only simplefb you won't be able to use any kind of
> hardware acceleration, not even 3D. Perhaps you could even pull it off

Nope. I won't be able to use that staggering performance of 1 hardware shader.

But my UI will draw really fast unless I want those wobbly windows.
Now who cares about wobbliness when you want to run everything
fullscreen anyway to get the most of the 480p screen estate.

> but certainly not with any kind of double-buffering, so while it might
> be an easy way to get something to display, please stop pretending that
> DRM/KMS don't matter.

Yes, it will matter for 3d and might matter for video acceleration as well.

But will not matter for using a terminal emulator or reading a book.

>> >> > > You know that you are going to call that for regulator, reset, power
>> >> > > domains, just as you would have needed to with the proper API, unless
>> >> > > that with this kind of solution, you would have to modify *every*
>> >> > > framework that might interact with any resource involved in getting
>> >> > > simplefb running?
>> >> >
>> >> > We have to add handling for every kind of resource either way. Also if
>> >> > this evolves into a common pattern we can easily wrap it up in a single
>> >> > function call.
>> >>
>> >> Unless that in one case, we already have everything needed to handle
>> >> everything properly, and in another, you keep hacking more and more
>> >> into the involved frameworks.
>> >
>> > This is a fundamental issue that we are facing and I'm trying to come up
>> > with a solution that is future-proof and will work for drivers other
>> > than simplefb.
>>
>> How is proper resource management not going to work for drivers other
>> than simplefb?
>
> I have no doubt that it's going to work. It already does. But unless we
> solve this at the core we'll be reiterating this for every new type of
> resource that we need to support and for every other driver of the same
> nature (i.e. uses a "virtual" device set up by firmware).

Once it's solved for every resource every 'virtual' driver will work
the same way.

I do not see a problem here.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 17:49, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
>> On 29 September 2014 15:47, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> > > > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > > > firmware has set up, which is the only reason why it will work for many
>> >> > > > people. What is passed in via its device tree node is the minimum amount
>> >> > > > of information needed to draw something into the framebuffer. Also note
>> >> > > > that the simplefb device tree node is not statically added to a DTS file
>> >> > > > but needs to be dynamically generated by firmware at runtime.
>> >> > >
>> >> > > Which makes the whole even simpler, since the firmware already knows
>> >> > > all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> Didn't you just say that it was dynamically generated at runtime? So
>> >> we can just ignore the "text editor" case.
>> >
>> > Perhaps read the sentence again. I said "that we would *otherwise* be
>> > able to do much easier with a text editor.".
>> >
>> > My point remains that there shouldn't be a need to generate DTB content
>> > of this complexity at all.
>> >
>> >> > Why do you think what I proposed isn't going to work or be reliable?
>> >> > I don't see any arguments in the thread that would imply that.
>> >>
>> >> The fact that it broke in the first place?
>> >
>> > That's exactly the point. And it's going to break again and again as
>> > simplefb is extended with new things. Generally DT bindings should be
>> > backwards compatible. When extended they should provide a way to fall
>> > back to a reasonable default. There's simply no way you can do that
>> > with simplefb.
>> >
>> > What happened in the Snow example is that regulators that were
>> > previously on would all of a sudden be automatically disabled on boot
>> > because there was now a driver that registered them with a generic
>> > framework.
>>
>> So what? You get a driver for regulators and suddenly find that
>> nothing registered regulators because they were on all the time anyway
>> and everything breaks? What a surprise!
>
> I agree, this is not a surprise at all. But like I pointed out this is
> bound to happen again and again. So how about we learn from it and add
> the functionality needed to prevent it from happening?
>
>> > The same thing is going to happen with simplefb for your device. If you
>> > later realize that you need a regulator to keep the panel going, you'll
>> > have to add code to your firmware to populate the corresponding
>> > properties, otherwise the regulator will end up unused and will be
>> > automatically disabled. At the same time you're going to break upstream
>> > for all users of your old firmware because it doesn't add that property
>> > yet.
>>
>> Sure. And what can you do about that? It's not like the original Snow
>> firmware writes anything of use to the DT at all. So to run a
>> development kernel you need a development firmware. If you add new
>> features to the kernel that involve intefacing to the firmware you
>> need to update the firmware as well. Once support for Snow platform is
>> stable you can expect that users can use a stable release of firmware
>> indefinitely.
>
> Feel free to take that up with the DT ABI stability committee.

As pointed out you can also generate by hand a DT that exactly
describes what the preinstalled firmware sets up - so long as the
preinstalled firmware sets upa any usable framebuffer at all and
always sets up the same thing. If the preinstalled firmware can set up
the framebuffer in different ways and is not willing to communicate to
the kernel in what way it set up the framebuffer then it is unusable
with simplefb. That sucks but there is no way around that.

>> > Why not? Are you really expecting to keep running with simplefb forever?
>> > Nobody is going to seriously use an upstream kernel in any product with
>> > only simplefb as a framebuffer. I've said before that this is a hack to
>>
>> Why not? You can use shadowfb (software acceleration) with simplefb
>> all right. Shadowfb is hands down the fastest video acceleration we
>> have on anything but hardware that has _very_ slow CPU or that can run
>> Intel UXA drivers. With manufacturers adding more and more superfluous
>> cores to the CPUs shadowfb is actually not too stressing on the
>> system, either.
>>
>> On hardware like Allwinner A13 (single core) the use of shadowfb over
>> actual video acceleration hardware has its benefits and drawbacks and
>> is neither clearly better nor worse. The same hardware tends to have
>> only one fixed video output - a tablet LCD panel. On such hardware
>> modesetting is needless luxury if u-boot provides the simplfb
>> bindings, at least for some use cases.
>
> I presume some of those tablets will have HDMI connectors. And surely

Nope. Only 1 output.

> somebody will eventually put an Allwinner SoC into something that's not
> a tablet.

Sure. And you might want to bother with modesetting then.

>
> Note also that with only simplefb you won't be able to use any kind of
> hardware acceleration, not even 3D. Perhaps you could even pull it off

Nope. I won't be able to use that staggering performance of 1 hardware shader.

But my UI will draw really fast unless I want those wobbly windows.
Now who cares about wobbliness when you want to run everything
fullscreen anyway to get the most of the 480p screen estate.

> but certainly not with any kind of double-buffering, so while it might
> be an easy way to get something to display, please stop pretending that
> DRM/KMS don't matter.

Yes, it will matter for 3d and might matter for video acceleration as well.

But will not matter for using a terminal emulator or reading a book.

>> >> > > You know that you are going to call that for regulator, reset, power
>> >> > > domains, just as you would have needed to with the proper API, unless
>> >> > > that with this kind of solution, you would have to modify *every*
>> >> > > framework that might interact with any resource involved in getting
>> >> > > simplefb running?
>> >> >
>> >> > We have to add handling for every kind of resource either way. Also if
>> >> > this evolves into a common pattern we can easily wrap it up in a single
>> >> > function call.
>> >>
>> >> Unless that in one case, we already have everything needed to handle
>> >> everything properly, and in another, you keep hacking more and more
>> >> into the involved frameworks.
>> >
>> > This is a fundamental issue that we are facing and I'm trying to come up
>> > with a solution that is future-proof and will work for drivers other
>> > than simplefb.
>>
>> How is proper resource management not going to work for drivers other
>> than simplefb?
>
> I have no doubt that it's going to work. It already does. But unless we
> solve this at the core we'll be reiterating this for every new type of
> resource that we need to support and for every other driver of the same
> nature (i.e. uses a "virtual" device set up by firmware).

Once it's solved for every resource every 'virtual' driver will work
the same way.

I do not see a problem here.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

Not quite - there was also DT added for them.  With just the driver the
regulator API shouldn't have touched them, it'd just have exposed them
read only.

> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

> And the same will continue to happen for every new type of resource
> you're going to add.

So long as we're ensuring that when we don't start supporting resources
without DT additions or at least require DT additions to actively manage
them (which can then include simplefb hookup) we should be fine.

> > > The difference is that with the solution I proposed we don't have to
> > > keep track of all the resources. We know that firmware has set them up
> > > and we know that a real driver will properly take them over at some
> > > point

> > You keep saying that... and you know that you can't make this
> > assumption.

> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to
> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.

Well, for product probably not.  But in terms of the runtime of a kernel
I'd not be so sure - people do dogfood and we should be allowing that.
I've used unaccelerated displays with reasonable success for a large
part of my work in the past.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

Not quite - there was also DT added for them.  With just the driver the
regulator API shouldn't have touched them, it'd just have exposed them
read only.

> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

> And the same will continue to happen for every new type of resource
> you're going to add.

So long as we're ensuring that when we don't start supporting resources
without DT additions or at least require DT additions to actively manage
them (which can then include simplefb hookup) we should be fine.

> > > The difference is that with the solution I proposed we don't have to
> > > keep track of all the resources. We know that firmware has set them up
> > > and we know that a real driver will properly take them over at some
> > > point

> > You keep saying that... and you know that you can't make this
> > assumption.

> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to
> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.

Well, for product probably not.  But in terms of the runtime of a kernel
I'd not be so sure - people do dogfood and we should be allowing that.
I've used unaccelerated displays with reasonable success for a large
part of my work in the past.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/946d1de9/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
[...]
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> So long as we're ensuring that when we don't start supporting resources
> without DT additions or at least require DT additions to actively manage
> them (which can then include simplefb hookup) we should be fine.

I'm not sure I understand what you mean. If we add a driver for the PMIC
that exposes these regulators and then add a DT node for the PMIC, we'd
still need to fix the firmware to generate the appropriate DT properties
to allow simplefb to enable the regulators.

So unless firmware is updated at the same time, regulators will get
disabled because they are unused.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
[...]
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> So long as we're ensuring that when we don't start supporting resources
> without DT additions or at least require DT additions to actively manage
> them (which can then include simplefb hookup) we should be fine.

I'm not sure I understand what you mean. If we add a driver for the PMIC
that exposes these regulators and then add a DT node for the PMIC, we'd
still need to fix the firmware to generate the appropriate DT properties
to allow simplefb to enable the regulators.

So unless firmware is updated at the same time, regulators will get
disabled because they are unused.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/4f9e4be0/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:

> > So long as we're ensuring that when we don't start supporting resources
> > without DT additions or at least require DT additions to actively manage
> > them (which can then include simplefb hookup) we should be fine.

> I'm not sure I understand what you mean. If we add a driver for the PMIC
> that exposes these regulators and then add a DT node for the PMIC, we'd
> still need to fix the firmware to generate the appropriate DT properties
> to allow simplefb to enable the regulators.

No, you don't.  It's only if you start describing the regulators in the
PMIC in DT that you run into problems.  Unconfigured regulators won't be
touched.

> So unless firmware is updated at the same time, regulators will get
> disabled because they are unused.

That won't happen unless the regulators are explicitly described, if
they are described as unused then this will of course happen.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:

> > So long as we're ensuring that when we don't start supporting resources
> > without DT additions or at least require DT additions to actively manage
> > them (which can then include simplefb hookup) we should be fine.

> I'm not sure I understand what you mean. If we add a driver for the PMIC
> that exposes these regulators and then add a DT node for the PMIC, we'd
> still need to fix the firmware to generate the appropriate DT properties
> to allow simplefb to enable the regulators.

No, you don't.  It's only if you start describing the regulators in the
PMIC in DT that you run into problems.  Unconfigured regulators won't be
touched.

> So unless firmware is updated at the same time, regulators will get
> disabled because they are unused.

That won't happen unless the regulators are explicitly described, if
they are described as unused then this will of course happen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/a8cd1e73/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
> 
> > > So long as we're ensuring that when we don't start supporting resources
> > > without DT additions or at least require DT additions to actively manage
> > > them (which can then include simplefb hookup) we should be fine.
> 
> > I'm not sure I understand what you mean. If we add a driver for the PMIC
> > that exposes these regulators and then add a DT node for the PMIC, we'd
> > still need to fix the firmware to generate the appropriate DT properties
> > to allow simplefb to enable the regulators.
> 
> No, you don't.  It's only if you start describing the regulators in the
> PMIC in DT that you run into problems.  Unconfigured regulators won't be
> touched.

Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
omit the description of the regulators that it exposes. Unless the
regulators are truly unused, as in not connected to any peripherals.

> > So unless firmware is updated at the same time, regulators will get
> > disabled because they are unused.
> 
> That won't happen unless the regulators are explicitly described, if
> they are described as unused then this will of course happen.

With described as unused you mean they have a node in DT, so constraints
are applied and all that, but no driver actually uses them?

The fundamental issue is that if we start describing simplefb nodes with
an incomplete set of resources then we're bound to run into problems
where it'll break once these new resources are described in the DTS. If
the simplefb node was described in the DTS then this would be less of a
problem because the resources could be added to the simplefb node at the
same time.

However given that simplefb is supposed to be generated by firmware this
is no longer possible. It will inevitably break unless you upgrade the
DTB and the firmware at the same time. And it was already decided long
ago that upgrading the firmware should never be a requirement for
keeping things working.

I don't see any way to prevent that other than ignoring the resources in
simplefb completely.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
> 
> > > So long as we're ensuring that when we don't start supporting resources
> > > without DT additions or at least require DT additions to actively manage
> > > them (which can then include simplefb hookup) we should be fine.
> 
> > I'm not sure I understand what you mean. If we add a driver for the PMIC
> > that exposes these regulators and then add a DT node for the PMIC, we'd
> > still need to fix the firmware to generate the appropriate DT properties
> > to allow simplefb to enable the regulators.
> 
> No, you don't.  It's only if you start describing the regulators in the
> PMIC in DT that you run into problems.  Unconfigured regulators won't be
> touched.

Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
omit the description of the regulators that it exposes. Unless the
regulators are truly unused, as in not connected to any peripherals.

> > So unless firmware is updated at the same time, regulators will get
> > disabled because they are unused.
> 
> That won't happen unless the regulators are explicitly described, if
> they are described as unused then this will of course happen.

With described as unused you mean they have a node in DT, so constraints
are applied and all that, but no driver actually uses them?

The fundamental issue is that if we start describing simplefb nodes with
an incomplete set of resources then we're bound to run into problems
where it'll break once these new resources are described in the DTS. If
the simplefb node was described in the DTS then this would be less of a
problem because the resources could be added to the simplefb node at the
same time.

However given that simplefb is supposed to be generated by firmware this
is no longer possible. It will inevitably break unless you upgrade the
DTB and the firmware at the same time. And it was already decided long
ago that upgrading the firmware should never be a requirement for
keeping things working.

I don't see any way to prevent that other than ignoring the resources in
simplefb completely.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/fa5ec5f8/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Javier Martinez Canillas]

On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:
>> On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
>>
>> > > So long as we're ensuring that when we don't start supporting resources
>> > > without DT additions or at least require DT additions to actively manage
>> > > them (which can then include simplefb hookup) we should be fine.
>>
>> > I'm not sure I understand what you mean. If we add a driver for the PMIC
>> > that exposes these regulators and then add a DT node for the PMIC, we'd
>> > still need to fix the firmware to generate the appropriate DT properties
>> > to allow simplefb to enable the regulators.
>>
>> No, you don't.  It's only if you start describing the regulators in the
>> PMIC in DT that you run into problems.  Unconfigured regulators won't be
>> touched.
>
> Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> omit the description of the regulators that it exposes. Unless the
> regulators are truly unused, as in not connected to any peripherals.
>

Agreed, I added similar PMIC support to other Chromebooks (Peach Pit
and Pi) DTS and for me it made totally sense to add nodes for all the
regulators that are connected to peripherals according to the board
schematic. Specially since the framework is smart enough to disable
any regulator that is not used.

After all, a DT is meant to describe the hardware, so how can possibly
be an issue to add more details about the hw in a DTS?

If something is working relying on parts of the hw on not being
described, then is essentially relying on side-effects and
implementation details which are bound to be broken anyways.

>> > So unless firmware is updated at the same time, regulators will get
>> > disabled because they are unused.
>>
>> That won't happen unless the regulators are explicitly described, if
>> they are described as unused then this will of course happen.
>
> With described as unused you mean they have a node in DT, so constraints
> are applied and all that, but no driver actually uses them?
>

Adding your resources (clock, regulators, etc) incrementally and only
when the driver for the device that use these resources is available,
will only make adding support for a new platform slower IMHO since
there will be more patches to be posted, reviewed and merged.

> The fundamental issue is that if we start describing simplefb nodes with
> an incomplete set of resources then we're bound to run into problems
> where it'll break once these new resources are described in the DTS. If
> the simplefb node was described in the DTS then this would be less of a
> problem because the resources could be added to the simplefb node at the
> same time.
>

Agreed, the assumptions made by simplefb are quite fragile so we
should either document somewhere that simplefb ignores all the
resources and that is a best effort so users should not consider the
display breaking a regression or make it robust enough so users can
expect that it will always work.

Just adding the clocks is a partial solution which I think will make
the situation even worst since it will give a false illusion of
robustness but as you said it will break anyways due other resources.

> However given that simplefb is supposed to be generated by firmware this
> is no longer possible. It will inevitably break unless you upgrade the
> DTB and the firmware at the same time. And it was already decided long
> ago that upgrading the firmware should never be a requirement for
> keeping things working.
>

AFAICT in practice most platforms' firmware do not generate the
simplefb by default. In the case of Chromebooks for example, a custom
U-boot needs to be flashed in order to have simplefb support. In fact
most people working on mainline support for Chromebooks do not use
simplefb and that is why the issue was not spot when adding the
support for clocks and regulators.

Personally I didn't even know how simplefb worked before Will reported
that his display used to work on Snow before 3.16. So I assume that
his reasonable to expect that users using simplefb are able to update
their bootloader.

Which brings a more general question about DT and backward
compatibility. Should we have backward compatibility only with the
official firmware that is ship on a device when is bought or should we
maintain backward compatibility against any firmware out there that
someone re-built and added logic to mangle the FDT before is passed to
the kernel?

Going back to simplefb, I think the fact that the simplefb is not in
the DTS is the fundamental issue here. For me, the most reasonable
approach to solve this is the one suggested by Doug Anderson. That is
to have the simplefb node in the DTS so all the references to the
resources it uses can be added in the DTS but keep the simplefb node
as status = "disabled".

The bootloader can find the simplefb node and fill all the information
about the framebuffer memory region (location and size, width, height,
format, etc) and also enable the node by setting the status to "okay"
so the simplefb driver will be probed.

If a FDT does not have a simplefb node then the boot loader can create
one (like is made for the /choosen node in most bootloaders) and make
it a best effort in that case, assuming that all the resources enabled
by the bootloader will remain enabled once the kernel boots.

This of course will require users to update their boot-loaders but as
stated above I think that is reasonable since anyone using simplefb is
using a non-official firmware anyways.

> I don't see any way to prevent that other than ignoring the resources in
> simplefb completely.
>
> Thierry
>

Best regards,
Javier

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Javier Martinez Canillas]

On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:
>> On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
>>
>> > > So long as we're ensuring that when we don't start supporting resources
>> > > without DT additions or at least require DT additions to actively manage
>> > > them (which can then include simplefb hookup) we should be fine.
>>
>> > I'm not sure I understand what you mean. If we add a driver for the PMIC
>> > that exposes these regulators and then add a DT node for the PMIC, we'd
>> > still need to fix the firmware to generate the appropriate DT properties
>> > to allow simplefb to enable the regulators.
>>
>> No, you don't.  It's only if you start describing the regulators in the
>> PMIC in DT that you run into problems.  Unconfigured regulators won't be
>> touched.
>
> Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> omit the description of the regulators that it exposes. Unless the
> regulators are truly unused, as in not connected to any peripherals.
>

Agreed, I added similar PMIC support to other Chromebooks (Peach Pit
and Pi) DTS and for me it made totally sense to add nodes for all the
regulators that are connected to peripherals according to the board
schematic. Specially since the framework is smart enough to disable
any regulator that is not used.

After all, a DT is meant to describe the hardware, so how can possibly
be an issue to add more details about the hw in a DTS?

If something is working relying on parts of the hw on not being
described, then is essentially relying on side-effects and
implementation details which are bound to be broken anyways.

>> > So unless firmware is updated at the same time, regulators will get
>> > disabled because they are unused.
>>
>> That won't happen unless the regulators are explicitly described, if
>> they are described as unused then this will of course happen.
>
> With described as unused you mean they have a node in DT, so constraints
> are applied and all that, but no driver actually uses them?
>

Adding your resources (clock, regulators, etc) incrementally and only
when the driver for the device that use these resources is available,
will only make adding support for a new platform slower IMHO since
there will be more patches to be posted, reviewed and merged.

> The fundamental issue is that if we start describing simplefb nodes with
> an incomplete set of resources then we're bound to run into problems
> where it'll break once these new resources are described in the DTS. If
> the simplefb node was described in the DTS then this would be less of a
> problem because the resources could be added to the simplefb node at the
> same time.
>

Agreed, the assumptions made by simplefb are quite fragile so we
should either document somewhere that simplefb ignores all the
resources and that is a best effort so users should not consider the
display breaking a regression or make it robust enough so users can
expect that it will always work.

Just adding the clocks is a partial solution which I think will make
the situation even worst since it will give a false illusion of
robustness but as you said it will break anyways due other resources.

> However given that simplefb is supposed to be generated by firmware this
> is no longer possible. It will inevitably break unless you upgrade the
> DTB and the firmware at the same time. And it was already decided long
> ago that upgrading the firmware should never be a requirement for
> keeping things working.
>

AFAICT in practice most platforms' firmware do not generate the
simplefb by default. In the case of Chromebooks for example, a custom
U-boot needs to be flashed in order to have simplefb support. In fact
most people working on mainline support for Chromebooks do not use
simplefb and that is why the issue was not spot when adding the
support for clocks and regulators.

Personally I didn't even know how simplefb worked before Will reported
that his display used to work on Snow before 3.16. So I assume that
his reasonable to expect that users using simplefb are able to update
their bootloader.

Which brings a more general question about DT and backward
compatibility. Should we have backward compatibility only with the
official firmware that is ship on a device when is bought or should we
maintain backward compatibility against any firmware out there that
someone re-built and added logic to mangle the FDT before is passed to
the kernel?

Going back to simplefb, I think the fact that the simplefb is not in
the DTS is the fundamental issue here. For me, the most reasonable
approach to solve this is the one suggested by Doug Anderson. That is
to have the simplefb node in the DTS so all the references to the
resources it uses can be added in the DTS but keep the simplefb node
as status = "disabled".

The bootloader can find the simplefb node and fill all the information
about the framebuffer memory region (location and size, width, height,
format, etc) and also enable the node by setting the status to "okay"
so the simplefb driver will be probed.

If a FDT does not have a simplefb node then the boot loader can create
one (like is made for the /choosen node in most bootloaders) and make
it a best effort in that case, assuming that all the resources enabled
by the bootloader will remain enabled once the kernel boots.

This of course will require users to update their boot-loaders but as
stated above I think that is reasonable since anyone using simplefb is
using a non-official firmware anyways.

> I don't see any way to prevent that other than ignoring the resources in
> simplefb completely.
>
> Thierry
>

Best regards,
Javier

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote:
> On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding <thierry.reding@gmail.com> wrote:

> > Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> > omit the description of the regulators that it exposes. Unless the
> > regulators are truly unused, as in not connected to any peripherals.

> Agreed, I added similar PMIC support to other Chromebooks (Peach Pit
> and Pi) DTS and for me it made totally sense to add nodes for all the
> regulators that are connected to peripherals according to the board
> schematic. Specially since the framework is smart enough to disable
> any regulator that is not used.

> After all, a DT is meant to describe the hardware, so how can possibly
> be an issue to add more details about the hw in a DTS?

> If something is working relying on parts of the hw on not being
> described, then is essentially relying on side-effects and
> implementation details which are bound to be broken anyways.

It's not a problem to describe the hardware, it's a problem to describe
the hardware inaccurately.  If you add something and explicitly tell the
kernel that nothing needs it then it shouldn't be a surprise that it
gets turned off.

> > With described as unused you mean they have a node in DT, so constraints
> > are applied and all that, but no driver actually uses them?

> Adding your resources (clock, regulators, etc) incrementally and only
> when the driver for the device that use these resources is available,
> will only make adding support for a new platform slower IMHO since
> there will be more patches to be posted, reviewed and merged.

So don't do that if you're worried about it then, provide the bits of DT
that hook everything up from the start or otherwise describe things as
being in use.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote:
> On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding <thierry.reding@gmail.com> wrote:

> > Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> > omit the description of the regulators that it exposes. Unless the
> > regulators are truly unused, as in not connected to any peripherals.

> Agreed, I added similar PMIC support to other Chromebooks (Peach Pit
> and Pi) DTS and for me it made totally sense to add nodes for all the
> regulators that are connected to peripherals according to the board
> schematic. Specially since the framework is smart enough to disable
> any regulator that is not used.

> After all, a DT is meant to describe the hardware, so how can possibly
> be an issue to add more details about the hw in a DTS?

> If something is working relying on parts of the hw on not being
> described, then is essentially relying on side-effects and
> implementation details which are bound to be broken anyways.

It's not a problem to describe the hardware, it's a problem to describe
the hardware inaccurately.  If you add something and explicitly tell the
kernel that nothing needs it then it shouldn't be a surprise that it
gets turned off.

> > With described as unused you mean they have a node in DT, so constraints
> > are applied and all that, but no driver actually uses them?

> Adding your resources (clock, regulators, etc) incrementally and only
> when the driver for the device that use these resources is available,
> will only make adding support for a new platform slower IMHO since
> there will be more patches to be posted, reviewed and merged.

So don't do that if you're worried about it then, provide the bits of DT
that hook everything up from the start or otherwise describe things as
being in use.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/074750a5/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote:
[...]
> > Adding your resources (clock, regulators, etc) incrementally and only
> > when the driver for the device that use these resources is available,
> > will only make adding support for a new platform slower IMHO since
> > there will be more patches to be posted, reviewed and merged.
> 
> So don't do that if you're worried about it then, provide the bits of DT
> that hook everything up from the start or otherwise describe things as
> being in use.

"Otherwise describe things as being in use" doesn't work for clocks for
example. And Mike already said he wasn't willing to add something like
an always-on DT property for clocks.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote:
[...]
> > Adding your resources (clock, regulators, etc) incrementally and only
> > when the driver for the device that use these resources is available,
> > will only make adding support for a new platform slower IMHO since
> > there will be more patches to be posted, reviewed and merged.
> 
> So don't do that if you're worried about it then, provide the bits of DT
> that hook everything up from the start or otherwise describe things as
> being in use.

"Otherwise describe things as being in use" doesn't work for clocks for
example. And Mike already said he wasn't willing to add something like
an always-on DT property for clocks.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/d3972a47/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:

> > So don't do that if you're worried about it then, provide the bits of DT
> > that hook everything up from the start or otherwise describe things as
> > being in use.

> "Otherwise describe things as being in use" doesn't work for clocks for
> example. And Mike already said he wasn't willing to add something like
> an always-on DT property for clocks.

That's not the only way of doing things - another way would be to have a
stub driver that just holds the resources while working on getting a
full one in place for example.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:

> > So don't do that if you're worried about it then, provide the bits of DT
> > that hook everything up from the start or otherwise describe things as
> > being in use.

> "Otherwise describe things as being in use" doesn't work for clocks for
> example. And Mike already said he wasn't willing to add something like
> an always-on DT property for clocks.

That's not the only way of doing things - another way would be to have a
stub driver that just holds the resources while working on getting a
full one in place for example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/8bd9d8e1/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/01/2014 07:05 PM, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
> 
>>> So don't do that if you're worried about it then, provide the bits of DT
>>> that hook everything up from the start or otherwise describe things as
>>> being in use.
> 
>> "Otherwise describe things as being in use" doesn't work for clocks for
>> example. And Mike already said he wasn't willing to add something like
>> an always-on DT property for clocks.
> 
> That's not the only way of doing things - another way would be to have a
> stub driver that just holds the resources while working on getting a
> full one in place for example.

That won't work because the real driver which will eventually replace the
stub one will likely be a module, and then we will loose video output
between the kernel finalizing the initial boot, and the module actually
loading.

We've been over all this again and again and again.

AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

All solutions provided sofar are both tons more complicated, then the
simple solution of simply having the simplefb dt node declare which
clocks it needs. And to make things worse all of them sofar have
unresolved issues (due to their complexity mostly).

With the clocks in the simplefb node, then all a real driver has to do,
is claim those same clocks before unregistering the simplefb driver,
and everything will just work.

Yet we've been discussing this for months, all because of some
vague worries from Thierry, and *only* from Thierry that this will
make simplefb less generic / not abstract enough, while a simple
generic clocks property is about as generic as things come.

This madness has to end! Thierry can we please have a clear and
unambiguous NACK from you on having the clocks property in the simplefb
dt node, and if you do so I expect a proof of concept patch from you
with an alternative solution within a week, or can you please stop
blocking this from getting merged?

And again, if you believe this will cause some sort of dt compat
issues or whatever, no one is making you use this property for
your boards!

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/01/2014 07:05 PM, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
> 
>>> So don't do that if you're worried about it then, provide the bits of DT
>>> that hook everything up from the start or otherwise describe things as
>>> being in use.
> 
>> "Otherwise describe things as being in use" doesn't work for clocks for
>> example. And Mike already said he wasn't willing to add something like
>> an always-on DT property for clocks.
> 
> That's not the only way of doing things - another way would be to have a
> stub driver that just holds the resources while working on getting a
> full one in place for example.

That won't work because the real driver which will eventually replace the
stub one will likely be a module, and then we will loose video output
between the kernel finalizing the initial boot, and the module actually
loading.

We've been over all this again and again and again.

AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

All solutions provided sofar are both tons more complicated, then the
simple solution of simply having the simplefb dt node declare which
clocks it needs. And to make things worse all of them sofar have
unresolved issues (due to their complexity mostly).

With the clocks in the simplefb node, then all a real driver has to do,
is claim those same clocks before unregistering the simplefb driver,
and everything will just work.

Yet we've been discussing this for months, all because of some
vague worries from Thierry, and *only* from Thierry that this will
make simplefb less generic / not abstract enough, while a simple
generic clocks property is about as generic as things come.

This madness has to end! Thierry can we please have a clear and
unambiguous NACK from you on having the clocks property in the simplefb
dt node, and if you do so I expect a proof of concept patch from you
with an alternative solution within a week, or can you please stop
blocking this from getting merged?

And again, if you believe this will cause some sort of dt compat
issues or whatever, no one is making you use this property for
your boards!

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 07:05 PM, Mark Brown wrote:
>> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
>>
>>>> So don't do that if you're worried about it then, provide the bits of DT
>>>> that hook everything up from the start or otherwise describe things as
>>>> being in use.
>>
>>> "Otherwise describe things as being in use" doesn't work for clocks for
>>> example. And Mike already said he wasn't willing to add something like
>>> an always-on DT property for clocks.
>>
>> That's not the only way of doing things - another way would be to have a
>> stub driver that just holds the resources while working on getting a
>> full one in place for example.
>
> That won't work because the real driver which will eventually replace the
> stub one will likely be a module, and then we will loose video output
> between the kernel finalizing the initial boot, and the module actually
> loading.

Is this correct? Do the clocks really get shut off before a driver on
initrd can load?

I agree this is true if you wait until user space is fully up and
stick this driver out on a disk drive.


>
> We've been over all this again and again and again.
>
> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>
> All solutions provided sofar are both tons more complicated, then the
> simple solution of simply having the simplefb dt node declare which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has to do,
> is claim those same clocks before unregistering the simplefb driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>
> This madness has to end! Thierry can we please have a clear and
> unambiguous NACK from you on having the clocks property in the simplefb
> dt node, and if you do so I expect a proof of concept patch from you
> with an alternative solution within a week, or can you please stop
> blocking this from getting merged?
>
> And again, if you believe this will cause some sort of dt compat
> issues or whatever, no one is making you use this property for
> your boards!
>
> Regards,
>
> Hans
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 07:05 PM, Mark Brown wrote:
>> On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote:
>>> On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote:
>>
>>>> So don't do that if you're worried about it then, provide the bits of DT
>>>> that hook everything up from the start or otherwise describe things as
>>>> being in use.
>>
>>> "Otherwise describe things as being in use" doesn't work for clocks for
>>> example. And Mike already said he wasn't willing to add something like
>>> an always-on DT property for clocks.
>>
>> That's not the only way of doing things - another way would be to have a
>> stub driver that just holds the resources while working on getting a
>> full one in place for example.
>
> That won't work because the real driver which will eventually replace the
> stub one will likely be a module, and then we will loose video output
> between the kernel finalizing the initial boot, and the module actually
> loading.

Is this correct? Do the clocks really get shut off before a driver on
initrd can load?

I agree this is true if you wait until user space is fully up and
stick this driver out on a disk drive.


>
> We've been over all this again and again and again.
>
> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>
> All solutions provided sofar are both tons more complicated, then the
> simple solution of simply having the simplefb dt node declare which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has to do,
> is claim those same clocks before unregistering the simplefb driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>
> This madness has to end! Thierry can we please have a clear and
> unambiguous NACK from you on having the clocks property in the simplefb
> dt node, and if you do so I expect a proof of concept patch from you
> with an alternative solution within a week, or can you please stop
> blocking this from getting merged?
>
> And again, if you believe this will cause some sort of dt compat
> issues or whatever, no one is making you use this property for
> your boards!
>
> Regards,
>
> Hans
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
...
>> We've been over all this again and again and again.
>>
>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>
>> All solutions provided sofar are both tons more complicated, then the
>> simple solution of simply having the simplefb dt node declare which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has to do,
>> is claim those same clocks before unregistering the simplefb driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

Note: I haven't been following this thread, and really don't have the 
time to get involved, but I did want to point out one thing:

As I think I mentioned very early on in this thread, one of the big 
concerns when simplefb was merged was that it would slowly grow and 
become a monster. As such, a condition of merging it was that it would 
not grow features like resource management at all. That means no 
clock/regulator/... support. It's intended as a simple stop-gap between 
early platform bringup and whenever a real driver exists for the HW. If 
you need resource management, write a HW-specific driver. The list 
archives presumably have a record of the discussion, but I don't know 
the links off the top of my head. If nobody other than Thierry is 
objecting, presumably the people who originally objected simply haven't 
noticed this patch/thread. I suppose it's possible they changed their mind.

BTW, there's no reason that the simplefb code couldn't be refactored out 
into a support library that's used by both the simplefb we currently 
have and any new HW-specific driver. It's just that the simplefb binding 
and driver shouldn't grow.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
...
>> We've been over all this again and again and again.
>>
>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>
>> All solutions provided sofar are both tons more complicated, then the
>> simple solution of simply having the simplefb dt node declare which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has to do,
>> is claim those same clocks before unregistering the simplefb driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

Note: I haven't been following this thread, and really don't have the 
time to get involved, but I did want to point out one thing:

As I think I mentioned very early on in this thread, one of the big 
concerns when simplefb was merged was that it would slowly grow and 
become a monster. As such, a condition of merging it was that it would 
not grow features like resource management at all. That means no 
clock/regulator/... support. It's intended as a simple stop-gap between 
early platform bringup and whenever a real driver exists for the HW. If 
you need resource management, write a HW-specific driver. The list 
archives presumably have a record of the discussion, but I don't know 
the links off the top of my head. If nobody other than Thierry is 
objecting, presumably the people who originally objected simply haven't 
noticed this patch/thread. I suppose it's possible they changed their mind.

BTW, there's no reason that the simplefb code couldn't be refactored out 
into a support library that's used by both the simplefb we currently 
have and any new HW-specific driver. It's just that the simplefb binding 
and driver shouldn't grow.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Wed, Oct 01, 2014 at 12:12:20PM -0600, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the  
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big  
> concerns when simplefb was merged was that it would slowly grow and  
> become a monster. As such, a condition of merging it was that it would  
> not grow features like resource management at all. That means no  
> clock/regulator/... support. It's intended as a simple stop-gap between  
> early platform bringup and whenever a real driver exists for the HW. If  
> you need resource management, write a HW-specific driver. The list  
> archives presumably have a record of the discussion, but I don't know  
> the links off the top of my head. If nobody other than Thierry is  
> objecting, presumably the people who originally objected simply haven't  
> noticed this patch/thread. I suppose it's possible they changed their 
> mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored out  
> into a support library that's used by both the simplefb we currently  
> have and any new HW-specific driver. It's just that the simplefb binding  
> and driver shouldn't grow.

Define "resource management".

Simplefb should never alter resources. It should never alter anything 
that $bootloader set up. It should however claim resources to prevent 
them from being altered.

Perhaps the word "managing" should be split up in "claiming" and 
"altering" here.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Wed, Oct 01, 2014 at 12:12:20PM -0600, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the  
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big  
> concerns when simplefb was merged was that it would slowly grow and  
> become a monster. As such, a condition of merging it was that it would  
> not grow features like resource management at all. That means no  
> clock/regulator/... support. It's intended as a simple stop-gap between  
> early platform bringup and whenever a real driver exists for the HW. If  
> you need resource management, write a HW-specific driver. The list  
> archives presumably have a record of the discussion, but I don't know  
> the links off the top of my head. If nobody other than Thierry is  
> objecting, presumably the people who originally objected simply haven't  
> noticed this patch/thread. I suppose it's possible they changed their 
> mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored out  
> into a support library that's used by both the simplefb we currently  
> have and any new HW-specific driver. It's just that the simplefb binding  
> and driver shouldn't grow.

Define "resource management".

Simplefb should never alter resources. It should never alter anything 
that $bootloader set up. It should however claim resources to prevent 
them from being altered.

Perhaps the word "managing" should be split up in "claiming" and 
"altering" here.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
> 
> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
> 
> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
> 
> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.

The whole reason why we want to use simplefb is not just to get things
running until HW specific driver is in place, but also to have early console
output (to help debugging boot problems on devices without a serial console),
in a world where most video drivers are build as loadable modules, so we
won't have video output until quite late into the boot process.

This is also the reason why we're working on adding hdmi console support
to u-boot in the first place, to debug boot problems.

So the whole "write a HW specific driver" answer just does not cut it. Just
like we have vgacon / efifb on x86, we need something similar on ARM, and
since ARM does not have a generic hw interface like vga, we need a firmware
solution like efifb.

So as said the whole "write a HW specific driver" just will not work, so
that means using something like simplefb. Now I can take simplefb, copy
it to rename it to firmwarefb or ubootfb or something, and then add the clocks
support, but that is just silly.

You indicate that you don't have the time for this discussion, and I note that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
my responsibility (and in my own benefit) to stop this from growing into
a monster ?

To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
which will be just a copy with the clocks added.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
> 
> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
> 
> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
> 
> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.

The whole reason why we want to use simplefb is not just to get things
running until HW specific driver is in place, but also to have early console
output (to help debugging boot problems on devices without a serial console),
in a world where most video drivers are build as loadable modules, so we
won't have video output until quite late into the boot process.

This is also the reason why we're working on adding hdmi console support
to u-boot in the first place, to debug boot problems.

So the whole "write a HW specific driver" answer just does not cut it. Just
like we have vgacon / efifb on x86, we need something similar on ARM, and
since ARM does not have a generic hw interface like vga, we need a firmware
solution like efifb.

So as said the whole "write a HW specific driver" just will not work, so
that means using something like simplefb. Now I can take simplefb, copy
it to rename it to firmwarefb or ubootfb or something, and then add the clocks
support, but that is just silly.

You indicate that you don't have the time for this discussion, and I note that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
my responsibility (and in my own benefit) to stop this from growing into
a monster ?

To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
which will be just a copy with the clocks added.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> ...
>>>> We've been over all this again and again and again.
>>>>
>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>
>>>> All solutions provided sofar are both tons more complicated, then the
>>>> simple solution of simply having the simplefb dt node declare which
>>>> clocks it needs. And to make things worse all of them sofar have
>>>> unresolved issues (due to their complexity mostly).
>>>>
>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>> is claim those same clocks before unregistering the simplefb driver,
>>>> and everything will just work.
>>>>
>>>> Yet we've been discussing this for months, all because of some
>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>> make simplefb less generic / not abstract enough, while a simple
>>>> generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

You need both.

1) temporary early boot console -- this is nothing but an address in
RAM and the x/y layout. The character set from framebuffer is built
into the kernel.  The parallel to this is early-printk and how it uses
the UARTs without interrupts. This console vaporizes late in the boot
process -- the same thing happens with the early printk UART driver.
EARLYPRINTK on the command line enables this.

2) a device specific driver -- this sits on initrd and it loaded as
soon as possible. The same thing happens with the real UART driver for
the console. CONSOLE= on the command line causes the transition. There
is an API in the kernel to do this transition, I believe it is called
set_console() but it's been a while.

>
> This is also the reason why we're working on adding hdmi console support
> to u-boot in the first place, to debug boot problems.
>
> So the whole "write a HW specific driver" answer just does not cut it. Just
> like we have vgacon / efifb on x86, we need something similar on ARM, and
> since ARM does not have a generic hw interface like vga, we need a firmware
> solution like efifb.
>
> So as said the whole "write a HW specific driver" just will not work, so
> that means using something like simplefb. Now I can take simplefb, copy
> it to rename it to firmwarefb or ubootfb or something, and then add the clocks
> support, but that is just silly.
>
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
>
> To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
> which will be just a copy with the clocks added.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> ...
>>>> We've been over all this again and again and again.
>>>>
>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>
>>>> All solutions provided sofar are both tons more complicated, then the
>>>> simple solution of simply having the simplefb dt node declare which
>>>> clocks it needs. And to make things worse all of them sofar have
>>>> unresolved issues (due to their complexity mostly).
>>>>
>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>> is claim those same clocks before unregistering the simplefb driver,
>>>> and everything will just work.
>>>>
>>>> Yet we've been discussing this for months, all because of some
>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>> make simplefb less generic / not abstract enough, while a simple
>>>> generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

You need both.

1) temporary early boot console -- this is nothing but an address in
RAM and the x/y layout. The character set from framebuffer is built
into the kernel.  The parallel to this is early-printk and how it uses
the UARTs without interrupts. This console vaporizes late in the boot
process -- the same thing happens with the early printk UART driver.
EARLYPRINTK on the command line enables this.

2) a device specific driver -- this sits on initrd and it loaded as
soon as possible. The same thing happens with the real UART driver for
the console. CONSOLE= on the command line causes the transition. There
is an API in the kernel to do this transition, I believe it is called
set_console() but it's been a while.

>
> This is also the reason why we're working on adding hdmi console support
> to u-boot in the first place, to debug boot problems.
>
> So the whole "write a HW specific driver" answer just does not cut it. Just
> like we have vgacon / efifb on x86, we need something similar on ARM, and
> since ARM does not have a generic hw interface like vga, we need a firmware
> solution like efifb.
>
> So as said the whole "write a HW specific driver" just will not work, so
> that means using something like simplefb. Now I can take simplefb, copy
> it to rename it to firmwarefb or ubootfb or something, and then add the clocks
> support, but that is just silly.
>
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
>
> To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
> which will be just a copy with the clocks added.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> ...
>>>>> We've been over all this again and again and again.
>>>>>
>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>
>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>> simple solution of simply having the simplefb dt node declare which
>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>> unresolved issues (due to their complexity mostly).
>>>>>
>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>> and everything will just work.
>>>>>
>>>>> Yet we've been discussing this for months, all because of some
>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
> 
> You need both.
> 
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
> 
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

Eventually we need both, yes. But 1) should stay working until 2) loads,
not until some phase of the bootup is completed, but simply until 2) loads.

Which means we must reserve necessary resources so that they don't get
disabled until 2 loads.

One example why this is necessary is e.g. to debug things where the problem
is that the right module is not included in the initrd.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> ...
>>>>> We've been over all this again and again and again.
>>>>>
>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>
>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>> simple solution of simply having the simplefb dt node declare which
>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>> unresolved issues (due to their complexity mostly).
>>>>>
>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>> and everything will just work.
>>>>>
>>>>> Yet we've been discussing this for months, all because of some
>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
> 
> You need both.
> 
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
> 
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

Eventually we need both, yes. But 1) should stay working until 2) loads,
not until some phase of the bootup is completed, but simply until 2) loads.

Which means we must reserve necessary resources so that they don't get
disabled until 2 loads.

One example why this is necessary is e.g. to debug things where the problem
is that the right module is not included in the initrd.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> ...
>>>>>> We've been over all this again and again and again.
>>>>>>
>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>
>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>
>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>> and everything will just work.
>>>>>>
>>>>>> Yet we've been discussing this for months, all because of some
>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>> generic clocks property is about as generic as things come.
>>>>
>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>
>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>
>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get things
>>> running until HW specific driver is in place, but also to have early console
>>> output (to help debugging boot problems on devices without a serial console),
>>> in a world where most video drivers are build as loadable modules, so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver for
>> the console. CONSOLE= on the command line causes the transition. There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
> Eventually we need both, yes. But 1) should stay working until 2) loads,
> not until some phase of the bootup is completed, but simply until 2) loads.

No, that is where you get into trouble. The device specific driver has
to go onto initrd where it can be loaded as early in the boot process
as possible.

Trying to indefinitely extend the life of the earlyprintk or
earlyframeuffer is what causes problems.  Doing that forces you to
basically turn them into device specific drivers which do things like
claiming device specific resources and gaining device specific
dependency knowledge, things that shouldn't be in earlyframebuffer.



>
> Which means we must reserve necessary resources so that they don't get
> disabled until 2 loads.
>
> One example why this is necessary is e.g. to debug things where the problem
> is that the right module is not included in the initrd.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> ...
>>>>>> We've been over all this again and again and again.
>>>>>>
>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>
>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>
>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>> and everything will just work.
>>>>>>
>>>>>> Yet we've been discussing this for months, all because of some
>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>> generic clocks property is about as generic as things come.
>>>>
>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>
>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>
>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get things
>>> running until HW specific driver is in place, but also to have early console
>>> output (to help debugging boot problems on devices without a serial console),
>>> in a world where most video drivers are build as loadable modules, so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver for
>> the console. CONSOLE= on the command line causes the transition. There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
> Eventually we need both, yes. But 1) should stay working until 2) loads,
> not until some phase of the bootup is completed, but simply until 2) loads.

No, that is where you get into trouble. The device specific driver has
to go onto initrd where it can be loaded as early in the boot process
as possible.

Trying to indefinitely extend the life of the earlyprintk or
earlyframeuffer is what causes problems.  Doing that forces you to
basically turn them into device specific drivers which do things like
claiming device specific resources and gaining device specific
dependency knowledge, things that shouldn't be in earlyframebuffer.



>
> Which means we must reserve necessary resources so that they don't get
> disabled until 2 loads.
>
> One example why this is necessary is e.g. to debug things where the problem
> is that the right module is not included in the initrd.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> ...
>>>>>>> We've been over all this again and again and again.
>>>>>>>
>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>
>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>
>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>> and everything will just work.
>>>>>>>
>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>> generic clocks property is about as generic as things come.
>>>>>
>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>
>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>
>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>
>>>> The whole reason why we want to use simplefb is not just to get things
>>>> running until HW specific driver is in place, but also to have early console
>>>> output (to help debugging boot problems on devices without a serial console),
>>>> in a world where most video drivers are build as loadable modules, so we
>>>> won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
> 
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.

This is an argument in the "you cannot do that" / "your use case is not valid"
category, IOW this is not a technical argument. You say I cannot do that I
say I can, deadlock.

I've already explained that we not only can do that (we already have working
code proving that), but also that this is something which we absolutely need:

>> One example why this is necessary is e.g. to debug things where the problem
>> is that the right module is not included in the initrd.

If we ever want ARM support to stop being about cute embedded non-sense hacks,
we must be able to have users get some meaningful output in failure cases like
this without needing to first solder a serial console to some test pads.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> ...
>>>>>>> We've been over all this again and again and again.
>>>>>>>
>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>
>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>
>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>> and everything will just work.
>>>>>>>
>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>> generic clocks property is about as generic as things come.
>>>>>
>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>
>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>
>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>
>>>> The whole reason why we want to use simplefb is not just to get things
>>>> running until HW specific driver is in place, but also to have early console
>>>> output (to help debugging boot problems on devices without a serial console),
>>>> in a world where most video drivers are build as loadable modules, so we
>>>> won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
> 
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.

This is an argument in the "you cannot do that" / "your use case is not valid"
category, IOW this is not a technical argument. You say I cannot do that I
say I can, deadlock.

I've already explained that we not only can do that (we already have working
code proving that), but also that this is something which we absolutely need:

>> One example why this is necessary is e.g. to debug things where the problem
>> is that the right module is not included in the initrd.

If we ever want ARM support to stop being about cute embedded non-sense hacks,
we must be able to have users get some meaningful output in failure cases like
this without needing to first solder a serial console to some test pads.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> ...
>>>>>>>> We've been over all this again and again and again.
>>>>>>>>
>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>
>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>
>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>> and everything will just work.
>>>>>>>>
>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>
>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>
>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>
>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>
>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>> running until HW specific driver is in place, but also to have early console
>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>> won't have video output until quite late into the boot process.
>>>>
>>>> You need both.
>>>>
>>>> 1) temporary early boot console -- this is nothing but an address in
>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>> process -- the same thing happens with the early printk UART driver.
>>>> EARLYPRINTK on the command line enables this.
>>>>
>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>> soon as possible. The same thing happens with the real UART driver for
>>>> the console. CONSOLE= on the command line causes the transition. There
>>>> is an API in the kernel to do this transition, I believe it is called
>>>> set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>
> This is an argument in the "you cannot do that" / "your use case is not valid"
> category, IOW this is not a technical argument. You say I cannot do that I
> say I can, deadlock.

It is certainly possible to extend an earlyframebuffer to be able to
run as a user space console. It is just going to turn into a
Frankenmonster driver with piles of device specific, special case code
in it.

I think that device specific code belongs in a device specific driver
and earlyframebuffer should handoff to it as soon as possible.

>
> I've already explained that we not only can do that (we already have working
> code proving that), but also that this is something which we absolutely need:
>
>>> One example why this is necessary is e.g. to debug things where the problem
>>> is that the right module is not included in the initrd.

A generic earlyframebuffer would show this error.

Just use earlyprintk as a guideline, if earlyprintk shows the error
earlyframebuffer would also show it.


>
> If we ever want ARM support to stop being about cute embedded non-sense hacks,
> we must be able to have users get some meaningful output in failure cases like
> this without needing to first solder a serial console to some test pads.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> ...
>>>>>>>> We've been over all this again and again and again.
>>>>>>>>
>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>
>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>
>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>> and everything will just work.
>>>>>>>>
>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>
>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>
>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>
>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>
>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>> running until HW specific driver is in place, but also to have early console
>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>> won't have video output until quite late into the boot process.
>>>>
>>>> You need both.
>>>>
>>>> 1) temporary early boot console -- this is nothing but an address in
>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>> process -- the same thing happens with the early printk UART driver.
>>>> EARLYPRINTK on the command line enables this.
>>>>
>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>> soon as possible. The same thing happens with the real UART driver for
>>>> the console. CONSOLE= on the command line causes the transition. There
>>>> is an API in the kernel to do this transition, I believe it is called
>>>> set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>
> This is an argument in the "you cannot do that" / "your use case is not valid"
> category, IOW this is not a technical argument. You say I cannot do that I
> say I can, deadlock.

It is certainly possible to extend an earlyframebuffer to be able to
run as a user space console. It is just going to turn into a
Frankenmonster driver with piles of device specific, special case code
in it.

I think that device specific code belongs in a device specific driver
and earlyframebuffer should handoff to it as soon as possible.

>
> I've already explained that we not only can do that (we already have working
> code proving that), but also that this is something which we absolutely need:
>
>>> One example why this is necessary is e.g. to debug things where the problem
>>> is that the right module is not included in the initrd.

A generic earlyframebuffer would show this error.

Just use earlyprintk as a guideline, if earlyprintk shows the error
earlyframebuffer would also show it.


>
> If we ever want ARM support to stop being about cute embedded non-sense hacks,
> we must be able to have users get some meaningful output in failure cases like
> this without needing to first solder a serial console to some test pads.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> ...
>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>
>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>
>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>
>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>> and everything will just work.
>>>>>>>>>
>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>
>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>
>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>
>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>
>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>> won't have video output until quite late into the boot process.
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
> 
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

There is nothing hardware specific about a framebuffer needing some
clocks to not be disabled. Tons of SoC's will have this. Which clocks,
that is hardware specific, but the framebuffer driver does not need to
worry about that, it just sees a clocks property with some random clocks
in there, and that is as generic as it gets.

> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.
> 
>>
>> I've already explained that we not only can do that (we already have working
>> code proving that), but also that this is something which we absolutely need:
>>
>>>> One example why this is necessary is e.g. to debug things where the problem
>>>> is that the right module is not included in the initrd.
> 
> A generic earlyframebuffer would show this error.

If it reserves the clocks it needs, yes. If it does not then the clocks will
be disabled before the initrd starts, and the screen will be black from then
on.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> ...
>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>
>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>
>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>
>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>> and everything will just work.
>>>>>>>>>
>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>
>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>
>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>
>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>
>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>> won't have video output until quite late into the boot process.
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
> 
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

There is nothing hardware specific about a framebuffer needing some
clocks to not be disabled. Tons of SoC's will have this. Which clocks,
that is hardware specific, but the framebuffer driver does not need to
worry about that, it just sees a clocks property with some random clocks
in there, and that is as generic as it gets.

> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.
> 
>>
>> I've already explained that we not only can do that (we already have working
>> code proving that), but also that this is something which we absolutely need:
>>
>>>> One example why this is necessary is e.g. to debug things where the problem
>>>> is that the right module is not included in the initrd.
> 
> A generic earlyframebuffer would show this error.

If it reserves the clocks it needs, yes. If it does not then the clocks will
be disabled before the initrd starts, and the screen will be black from then
on.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> ...
>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>
>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>
>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>
>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>> and everything will just work.
>>>>>>>>>>
>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>
>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>
>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>
>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>
>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>> won't have video output until quite late into the boot process.
>>>>>>
>>>>>> You need both.
>>>>>>
>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>
>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>> set_console() but it's been a while.
>>>>>
>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>
>>>> No, that is where you get into trouble. The device specific driver has
>>>> to go onto initrd where it can be loaded as early in the boot process
>>>> as possible.
>>>
>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>> category, IOW this is not a technical argument. You say I cannot do that I
>>> say I can, deadlock.
>>
>> It is certainly possible to extend an earlyframebuffer to be able to
>> run as a user space console. It is just going to turn into a
>> Frankenmonster driver with piles of device specific, special case code
>> in it.
>
> There is nothing hardware specific about a framebuffer needing some
> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
> that is hardware specific, but the framebuffer driver does not need to
> worry about that, it just sees a clocks property with some random clocks
> in there, and that is as generic as it gets.
>
>> I think that device specific code belongs in a device specific driver
>> and earlyframebuffer should handoff to it as soon as possible.
>>
>>>
>>> I've already explained that we not only can do that (we already have working
>>> code proving that), but also that this is something which we absolutely need:
>>>
>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>> is that the right module is not included in the initrd.
>>
>> A generic earlyframebuffer would show this error.
>
> If it reserves the clocks it needs, yes. If it does not then the clocks will
> be disabled before the initrd starts, and the screen will be black from then

I thought the clock/regulator clean up happened after initrd loading,
but maybe that is not the case.

A cleaner solution would then be to modify the clock/regulator clean
up to happen after driver loading is finished from initrd. Deferring
until after that completes is a fixed limit, everything is sitting
there in RAM. I would not propose extending it until harddisk based
loading happens.

So there are two ways to do this...
1) modify things like earlyconsole to protect device specific resource
(I think this is a bad idea)
2) delay the clock/regulator cleanup until after there is a fixed
window for device specific drivers to load in. Loading from initrd is
a fixed window.

Two seems to me to be the better solution.



> on.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> ...
>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>
>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>
>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>
>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>> and everything will just work.
>>>>>>>>>>
>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>
>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>
>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>
>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>
>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>> won't have video output until quite late into the boot process.
>>>>>>
>>>>>> You need both.
>>>>>>
>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>
>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>> set_console() but it's been a while.
>>>>>
>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>
>>>> No, that is where you get into trouble. The device specific driver has
>>>> to go onto initrd where it can be loaded as early in the boot process
>>>> as possible.
>>>
>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>> category, IOW this is not a technical argument. You say I cannot do that I
>>> say I can, deadlock.
>>
>> It is certainly possible to extend an earlyframebuffer to be able to
>> run as a user space console. It is just going to turn into a
>> Frankenmonster driver with piles of device specific, special case code
>> in it.
>
> There is nothing hardware specific about a framebuffer needing some
> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
> that is hardware specific, but the framebuffer driver does not need to
> worry about that, it just sees a clocks property with some random clocks
> in there, and that is as generic as it gets.
>
>> I think that device specific code belongs in a device specific driver
>> and earlyframebuffer should handoff to it as soon as possible.
>>
>>>
>>> I've already explained that we not only can do that (we already have working
>>> code proving that), but also that this is something which we absolutely need:
>>>
>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>> is that the right module is not included in the initrd.
>>
>> A generic earlyframebuffer would show this error.
>
> If it reserves the clocks it needs, yes. If it does not then the clocks will
> be disabled before the initrd starts, and the screen will be black from then

I thought the clock/regulator clean up happened after initrd loading,
but maybe that is not the case.

A cleaner solution would then be to modify the clock/regulator clean
up to happen after driver loading is finished from initrd. Deferring
until after that completes is a fixed limit, everything is sitting
there in RAM. I would not propose extending it until harddisk based
loading happens.

So there are two ways to do this...
1) modify things like earlyconsole to protect device specific resource
(I think this is a bad idea)
2) delay the clock/regulator cleanup until after there is a fixed
window for device specific drivers to load in. Loading from initrd is
a fixed window.

Two seems to me to be the better solution.



> on.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> ...
>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>
>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>
>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>
>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>
>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>
>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>
>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>
>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>
>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>
>>>>>>> You need both.
>>>>>>>
>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>
>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>> set_console() but it's been a while.
>>>>>>
>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>
>>>>> No, that is where you get into trouble. The device specific driver has
>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>> as possible.
>>>>
>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>> say I can, deadlock.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> I've already explained that we not only can do that (we already have working
>>>> code proving that), but also that this is something which we absolutely need:
>>>>
>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>> is that the right module is not included in the initrd.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
> 
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
> 
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
> 
> So there are two ways to do this...
> 1) modify things like earlyconsole to protect device specific resource
> (I think this is a bad idea)

Why is this a bad idea? If the bootloader tells us exactly which resources
are needed, then earlyconsole can claim them, and release them on
handover to the real display driver.

> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.

As I already explained by example in another mail, this won't work:

"delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.

So the boot will continue normally with a black screen, and things are
still impossible to debug."

We've been down the whole delay till $random point in time thing in the
past with storage enumeration, where you need to wait for say all members
of a raid set to show up. The lesson learned from that is that you should
not wait $random time / event, but wait for the actual storage device to
show up.

And this is just like that, we need to wait for the actual display driver
to have loaded and taken over before "cleaning up" the clocks used by
the display engine.

I guess we could just delay all clock cleanup until then, not really
pretty, and I still prefer to just list the clocks in the simplefb
dtnode, but if this version would be acceptable to all involved, I can
live with it.

Mike, would a patch adding 2 calls like these to the clock core be
acceptable ?  :

clk_block_disable_unused()
clk_unblock_disable_unused()

Where an earlyconsole driver can then call clk_block_disable_unused(),
which will turn any calls to clk_disable_unused into a nop.

And when the earlyconsole gets unregistered because the real driver
takes over, it calls clk_unblock_disable_unused(), which then checks if
clk_disable_unused() has already been called (iow check if we're post
late_init), and if it has calls clk_disable_unused() at that time.

If this is acceptable I can whip up a patch for this.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:40 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> ...
>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>
>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>
>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>
>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>
>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>
>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>
>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>
>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>
>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>
>>>>>>> You need both.
>>>>>>>
>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>
>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>> set_console() but it's been a while.
>>>>>>
>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>
>>>>> No, that is where you get into trouble. The device specific driver has
>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>> as possible.
>>>>
>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>> say I can, deadlock.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> I've already explained that we not only can do that (we already have working
>>>> code proving that), but also that this is something which we absolutely need:
>>>>
>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>> is that the right module is not included in the initrd.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
> 
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
> 
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
> 
> So there are two ways to do this...
> 1) modify things like earlyconsole to protect device specific resource
> (I think this is a bad idea)

Why is this a bad idea? If the bootloader tells us exactly which resources
are needed, then earlyconsole can claim them, and release them on
handover to the real display driver.

> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.

As I already explained by example in another mail, this won't work:

"delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.

So the boot will continue normally with a black screen, and things are
still impossible to debug."

We've been down the whole delay till $random point in time thing in the
past with storage enumeration, where you need to wait for say all members
of a raid set to show up. The lesson learned from that is that you should
not wait $random time / event, but wait for the actual storage device to
show up.

And this is just like that, we need to wait for the actual display driver
to have loaded and taken over before "cleaning up" the clocks used by
the display engine.

I guess we could just delay all clock cleanup until then, not really
pretty, and I still prefer to just list the clocks in the simplefb
dtnode, but if this version would be acceptable to all involved, I can
live with it.

Mike, would a patch adding 2 calls like these to the clock core be
acceptable ?  :

clk_block_disable_unused()
clk_unblock_disable_unused()

Where an earlyconsole driver can then call clk_block_disable_unused(),
which will turn any calls to clk_disable_unused into a nop.

And when the earlyconsole gets unregistered because the real driver
takes over, it calls clk_unblock_disable_unused(), which then checks if
clk_disable_unused() has already been called (iow check if we're post
late_init), and if it has calls clk_disable_unused() at that time.

If this is acceptable I can whip up a patch for this.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>> ...
>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>
>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>
>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>
>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>
>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>
>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>
>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>
>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>
>>>>>>>> You need both.
>>>>>>>>
>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>
>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>> set_console() but it's been a while.
>>>>>>>
>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>
>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>> as possible.
>>>>>
>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>> say I can, deadlock.
>>>>
>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>> run as a user space console. It is just going to turn into a
>>>> Frankenmonster driver with piles of device specific, special case code
>>>> in it.
>>>
>>> There is nothing hardware specific about a framebuffer needing some
>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>> that is hardware specific, but the framebuffer driver does not need to
>>> worry about that, it just sees a clocks property with some random clocks
>>> in there, and that is as generic as it gets.
>>>
>>>> I think that device specific code belongs in a device specific driver
>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>
>>>>>
>>>>> I've already explained that we not only can do that (we already have working
>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>
>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>> is that the right module is not included in the initrd.
>>>>
>>>> A generic earlyframebuffer would show this error.
>>>
>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>> be disabled before the initrd starts, and the screen will be black from then
>>
>> I thought the clock/regulator clean up happened after initrd loading,
>> but maybe that is not the case.
>>
>> A cleaner solution would then be to modify the clock/regulator clean
>> up to happen after driver loading is finished from initrd. Deferring
>> until after that completes is a fixed limit, everything is sitting
>> there in RAM. I would not propose extending it until harddisk based
>> loading happens.
>>
>> So there are two ways to do this...
>> 1) modify things like earlyconsole to protect device specific resource
>> (I think this is a bad idea)
>
> Why is this a bad idea? If the bootloader tells us exactly which resources
> are needed, then earlyconsole can claim them, and release them on
> handover to the real display driver.
>
>> 2) delay the clock/regulator cleanup until after there is a fixed
>> window for device specific drivers to load in. Loading from initrd is
>> a fixed window.
>
> As I already explained by example in another mail, this won't work:
>
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."
>
> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
>
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
>
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
>
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ?  :
>
> clk_block_disable_unused()
> clk_unblock_disable_unused()
>
> Where an earlyconsole driver can then call clk_block_disable_unused(),
> which will turn any calls to clk_disable_unused into a nop.

Is there a way to use the existing eprobe_defer system to do this?

>
> And when the earlyconsole gets unregistered because the real driver
> takes over, it calls clk_unblock_disable_unused(), which then checks if
> clk_disable_unused() has already been called (iow check if we're post
> late_init), and if it has calls clk_disable_unused() at that time.
>
> If this is acceptable I can whip up a patch for this.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:40 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>> ...
>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>
>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>
>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>
>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>
>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>
>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>
>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>
>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>
>>>>>>>> You need both.
>>>>>>>>
>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>
>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>> set_console() but it's been a while.
>>>>>>>
>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>
>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>> as possible.
>>>>>
>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>> say I can, deadlock.
>>>>
>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>> run as a user space console. It is just going to turn into a
>>>> Frankenmonster driver with piles of device specific, special case code
>>>> in it.
>>>
>>> There is nothing hardware specific about a framebuffer needing some
>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>> that is hardware specific, but the framebuffer driver does not need to
>>> worry about that, it just sees a clocks property with some random clocks
>>> in there, and that is as generic as it gets.
>>>
>>>> I think that device specific code belongs in a device specific driver
>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>
>>>>>
>>>>> I've already explained that we not only can do that (we already have working
>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>
>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>> is that the right module is not included in the initrd.
>>>>
>>>> A generic earlyframebuffer would show this error.
>>>
>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>> be disabled before the initrd starts, and the screen will be black from then
>>
>> I thought the clock/regulator clean up happened after initrd loading,
>> but maybe that is not the case.
>>
>> A cleaner solution would then be to modify the clock/regulator clean
>> up to happen after driver loading is finished from initrd. Deferring
>> until after that completes is a fixed limit, everything is sitting
>> there in RAM. I would not propose extending it until harddisk based
>> loading happens.
>>
>> So there are two ways to do this...
>> 1) modify things like earlyconsole to protect device specific resource
>> (I think this is a bad idea)
>
> Why is this a bad idea? If the bootloader tells us exactly which resources
> are needed, then earlyconsole can claim them, and release them on
> handover to the real display driver.
>
>> 2) delay the clock/regulator cleanup until after there is a fixed
>> window for device specific drivers to load in. Loading from initrd is
>> a fixed window.
>
> As I already explained by example in another mail, this won't work:
>
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."
>
> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
>
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
>
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
>
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ?  :
>
> clk_block_disable_unused()
> clk_unblock_disable_unused()
>
> Where an earlyconsole driver can then call clk_block_disable_unused(),
> which will turn any calls to clk_disable_unused into a nop.

Is there a way to use the existing eprobe_defer system to do this?

>
> And when the earlyconsole gets unregistered because the real driver
> takes over, it calls clk_unblock_disable_unused(), which then checks if
> clk_disable_unused() has already been called (iow check if we're post
> late_init), and if it has calls clk_disable_unused() at that time.
>
> If this is acceptable I can whip up a patch for this.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>> ...
>>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>>
>>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>>
>>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>>
>>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>>
>>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>>
>>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>>
>>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>>
>>>>>>>>> You need both.
>>>>>>>>>
>>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>>
>>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>>> set_console() but it's been a while.
>>>>>>>>
>>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>>
>>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>>> as possible.
>>>>>>
>>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>>> say I can, deadlock.
>>>>>
>>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>>> run as a user space console. It is just going to turn into a
>>>>> Frankenmonster driver with piles of device specific, special case code
>>>>> in it.
>>>>
>>>> There is nothing hardware specific about a framebuffer needing some
>>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>>> that is hardware specific, but the framebuffer driver does not need to
>>>> worry about that, it just sees a clocks property with some random clocks
>>>> in there, and that is as generic as it gets.
>>>>
>>>>> I think that device specific code belongs in a device specific driver
>>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>>
>>>>>>
>>>>>> I've already explained that we not only can do that (we already have working
>>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>>
>>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>>> is that the right module is not included in the initrd.
>>>>>
>>>>> A generic earlyframebuffer would show this error.
>>>>
>>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>>> be disabled before the initrd starts, and the screen will be black from then
>>>
>>> I thought the clock/regulator clean up happened after initrd loading,
>>> but maybe that is not the case.
>>>
>>> A cleaner solution would then be to modify the clock/regulator clean
>>> up to happen after driver loading is finished from initrd. Deferring
>>> until after that completes is a fixed limit, everything is sitting
>>> there in RAM. I would not propose extending it until harddisk based
>>> loading happens.
>>>
>>> So there are two ways to do this...
>>> 1) modify things like earlyconsole to protect device specific resource
>>> (I think this is a bad idea)
>>
>> Why is this a bad idea? If the bootloader tells us exactly which resources
>> are needed, then earlyconsole can claim them, and release them on
>> handover to the real display driver.

Jon, can you please answer this ? I really really want to know why people
think this is such a bad idea. Understanding why people think this is a bad
idea is necessary to be able to come up with an alternative solution.

>>
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
>>
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ?  :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
>>
>> Where an earlyconsole driver can then call clk_block_disable_unused(),
>> which will turn any calls to clk_disable_unused into a nop.
> 
> Is there a way to use the existing eprobe_defer system to do this?

No, that is not what it is intended for (at all). If we go this way
2 subsystem specific calls for this is the best way to deal with this.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:40 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>> ...
>>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>>
>>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>>
>>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>>
>>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>>
>>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>>
>>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>>
>>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>>
>>>>>>>>> You need both.
>>>>>>>>>
>>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>>
>>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>>> set_console() but it's been a while.
>>>>>>>>
>>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>>
>>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>>> as possible.
>>>>>>
>>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>>> say I can, deadlock.
>>>>>
>>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>>> run as a user space console. It is just going to turn into a
>>>>> Frankenmonster driver with piles of device specific, special case code
>>>>> in it.
>>>>
>>>> There is nothing hardware specific about a framebuffer needing some
>>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>>> that is hardware specific, but the framebuffer driver does not need to
>>>> worry about that, it just sees a clocks property with some random clocks
>>>> in there, and that is as generic as it gets.
>>>>
>>>>> I think that device specific code belongs in a device specific driver
>>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>>
>>>>>>
>>>>>> I've already explained that we not only can do that (we already have working
>>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>>
>>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>>> is that the right module is not included in the initrd.
>>>>>
>>>>> A generic earlyframebuffer would show this error.
>>>>
>>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>>> be disabled before the initrd starts, and the screen will be black from then
>>>
>>> I thought the clock/regulator clean up happened after initrd loading,
>>> but maybe that is not the case.
>>>
>>> A cleaner solution would then be to modify the clock/regulator clean
>>> up to happen after driver loading is finished from initrd. Deferring
>>> until after that completes is a fixed limit, everything is sitting
>>> there in RAM. I would not propose extending it until harddisk based
>>> loading happens.
>>>
>>> So there are two ways to do this...
>>> 1) modify things like earlyconsole to protect device specific resource
>>> (I think this is a bad idea)
>>
>> Why is this a bad idea? If the bootloader tells us exactly which resources
>> are needed, then earlyconsole can claim them, and release them on
>> handover to the real display driver.

Jon, can you please answer this ? I really really want to know why people
think this is such a bad idea. Understanding why people think this is a bad
idea is necessary to be able to come up with an alternative solution.

>>
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
>>
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ?  :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
>>
>> Where an earlyconsole driver can then call clk_block_disable_unused(),
>> which will turn any calls to clk_disable_unused into a nop.
> 
> Is there a way to use the existing eprobe_defer system to do this?

No, that is not what it is intended for (at all). If we go this way
2 subsystem specific calls for this is the best way to deal with this.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:40 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>>> ...
>>>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>>>
>>>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>>>
>>>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>>>
>>>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>>>
>>>>>>>>>> You need both.
>>>>>>>>>>
>>>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>>>
>>>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>>>> set_console() but it's been a while.
>>>>>>>>>
>>>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>>>
>>>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>>>> as possible.
>>>>>>>
>>>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>>>> say I can, deadlock.
>>>>>>
>>>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>>>> run as a user space console. It is just going to turn into a
>>>>>> Frankenmonster driver with piles of device specific, special case code
>>>>>> in it.
>>>>>
>>>>> There is nothing hardware specific about a framebuffer needing some
>>>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>>>> that is hardware specific, but the framebuffer driver does not need to
>>>>> worry about that, it just sees a clocks property with some random clocks
>>>>> in there, and that is as generic as it gets.
>>>>>
>>>>>> I think that device specific code belongs in a device specific driver
>>>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>>>
>>>>>>>
>>>>>>> I've already explained that we not only can do that (we already have working
>>>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>>>
>>>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>>>> is that the right module is not included in the initrd.
>>>>>>
>>>>>> A generic earlyframebuffer would show this error.
>>>>>
>>>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>>>> be disabled before the initrd starts, and the screen will be black from then
>>>>
>>>> I thought the clock/regulator clean up happened after initrd loading,
>>>> but maybe that is not the case.
>>>>
>>>> A cleaner solution would then be to modify the clock/regulator clean
>>>> up to happen after driver loading is finished from initrd. Deferring
>>>> until after that completes is a fixed limit, everything is sitting
>>>> there in RAM. I would not propose extending it until harddisk based
>>>> loading happens.
>>>>
>>>> So there are two ways to do this...
>>>> 1) modify things like earlyconsole to protect device specific resource
>>>> (I think this is a bad idea)
>>>
>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>> are needed, then earlyconsole can claim them, and release them on
>>> handover to the real display driver.
>
> Jon, can you please answer this ? I really really want to know why people
> think this is such a bad idea. Understanding why people think this is a bad
> idea is necessary to be able to come up with an alternative solution.

The list of resources should not be duplicated in the device tree -
once in the simplefb node and again in the real device node. Device
tree is a hardware description and it is being twisted to solve a
software issue. This problem is not limited to clocks, same problem
exists with regulators. On SGI systems this would exist with entire
bus controllers (but they are x86 based, console is not on the root
bus). This is a very messy problem and will lead to a Frankenstein
sized driver over time.

But... I think this is a red herring which is masking the real
problem. The real problem seems to be that there is no window for
loading device specific drivers before the resource clean up phase
happens. That's a real problem -- multi architecture distros are going
to have lots of loadable device specific drivers.

This leads me into thinking that the resource cleanup is not being
done at the right time. Maybe it should be part of the housekeeping
that goes on in the system idle task or something like that. I don't
work enough with the user space transition to know the right place to
move it to.

If we can get this resource clean up sorted out, the problem with
simplefb needing a protected resource list disappears. It make sense
to me that we have to have some way of loading device specific drivers
before this clean up happens.

I'll add Linus to the list, maybe he'll give us some guidance on how
to handle this.

>
>>>
>>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>>> window for device specific drivers to load in. Loading from initrd is
>>>> a fixed window.
>>>
>>> As I already explained by example in another mail, this won't work:
>>>
>>> "delaying over the initrd is not helpful. Not having the real driver
>>> load for whatever reasons, is not necessarily a boot blocking event,
>>> and if it us just missing will not lead to any error messages.
>>>
>>> So the boot will continue normally with a black screen, and things are
>>> still impossible to debug."
>>>
>>> We've been down the whole delay till $random point in time thing in the
>>> past with storage enumeration, where you need to wait for say all members
>>> of a raid set to show up. The lesson learned from that is that you should
>>> not wait $random time / event, but wait for the actual storage device to
>>> show up.
>>>
>>> And this is just like that, we need to wait for the actual display driver
>>> to have loaded and taken over before "cleaning up" the clocks used by
>>> the display engine.
>>>
>>> I guess we could just delay all clock cleanup until then, not really
>>> pretty, and I still prefer to just list the clocks in the simplefb
>>> dtnode, but if this version would be acceptable to all involved, I can
>>> live with it.
>>>
>>> Mike, would a patch adding 2 calls like these to the clock core be
>>> acceptable ?  :
>>>
>>> clk_block_disable_unused()
>>> clk_unblock_disable_unused()
>>>
>>> Where an earlyconsole driver can then call clk_block_disable_unused(),
>>> which will turn any calls to clk_disable_unused into a nop.
>>
>> Is there a way to use the existing eprobe_defer system to do this?
>
> No, that is not what it is intended for (at all). If we go this way
> 2 subsystem specific calls for this is the best way to deal with this.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:40 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>>> ...
>>>>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>>>>
>>>>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>>>>
>>>>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>>>>
>>>>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>>>>
>>>>>>>>>> You need both.
>>>>>>>>>>
>>>>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>>>>
>>>>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>>>>> set_console() but it's been a while.
>>>>>>>>>
>>>>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>>>>
>>>>>>>> No, that is where you get into trouble. The device specific driver has
>>>>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>>>>> as possible.
>>>>>>>
>>>>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>>>>> say I can, deadlock.
>>>>>>
>>>>>> It is certainly possible to extend an earlyframebuffer to be able to
>>>>>> run as a user space console. It is just going to turn into a
>>>>>> Frankenmonster driver with piles of device specific, special case code
>>>>>> in it.
>>>>>
>>>>> There is nothing hardware specific about a framebuffer needing some
>>>>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>>>>> that is hardware specific, but the framebuffer driver does not need to
>>>>> worry about that, it just sees a clocks property with some random clocks
>>>>> in there, and that is as generic as it gets.
>>>>>
>>>>>> I think that device specific code belongs in a device specific driver
>>>>>> and earlyframebuffer should handoff to it as soon as possible.
>>>>>>
>>>>>>>
>>>>>>> I've already explained that we not only can do that (we already have working
>>>>>>> code proving that), but also that this is something which we absolutely need:
>>>>>>>
>>>>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>>>>> is that the right module is not included in the initrd.
>>>>>>
>>>>>> A generic earlyframebuffer would show this error.
>>>>>
>>>>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>>>>> be disabled before the initrd starts, and the screen will be black from then
>>>>
>>>> I thought the clock/regulator clean up happened after initrd loading,
>>>> but maybe that is not the case.
>>>>
>>>> A cleaner solution would then be to modify the clock/regulator clean
>>>> up to happen after driver loading is finished from initrd. Deferring
>>>> until after that completes is a fixed limit, everything is sitting
>>>> there in RAM. I would not propose extending it until harddisk based
>>>> loading happens.
>>>>
>>>> So there are two ways to do this...
>>>> 1) modify things like earlyconsole to protect device specific resource
>>>> (I think this is a bad idea)
>>>
>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>> are needed, then earlyconsole can claim them, and release them on
>>> handover to the real display driver.
>
> Jon, can you please answer this ? I really really want to know why people
> think this is such a bad idea. Understanding why people think this is a bad
> idea is necessary to be able to come up with an alternative solution.

The list of resources should not be duplicated in the device tree -
once in the simplefb node and again in the real device node. Device
tree is a hardware description and it is being twisted to solve a
software issue. This problem is not limited to clocks, same problem
exists with regulators. On SGI systems this would exist with entire
bus controllers (but they are x86 based, console is not on the root
bus). This is a very messy problem and will lead to a Frankenstein
sized driver over time.

But... I think this is a red herring which is masking the real
problem. The real problem seems to be that there is no window for
loading device specific drivers before the resource clean up phase
happens. That's a real problem -- multi architecture distros are going
to have lots of loadable device specific drivers.

This leads me into thinking that the resource cleanup is not being
done at the right time. Maybe it should be part of the housekeeping
that goes on in the system idle task or something like that. I don't
work enough with the user space transition to know the right place to
move it to.

If we can get this resource clean up sorted out, the problem with
simplefb needing a protected resource list disappears. It make sense
to me that we have to have some way of loading device specific drivers
before this clean up happens.

I'll add Linus to the list, maybe he'll give us some guidance on how
to handle this.

>
>>>
>>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>>> window for device specific drivers to load in. Loading from initrd is
>>>> a fixed window.
>>>
>>> As I already explained by example in another mail, this won't work:
>>>
>>> "delaying over the initrd is not helpful. Not having the real driver
>>> load for whatever reasons, is not necessarily a boot blocking event,
>>> and if it us just missing will not lead to any error messages.
>>>
>>> So the boot will continue normally with a black screen, and things are
>>> still impossible to debug."
>>>
>>> We've been down the whole delay till $random point in time thing in the
>>> past with storage enumeration, where you need to wait for say all members
>>> of a raid set to show up. The lesson learned from that is that you should
>>> not wait $random time / event, but wait for the actual storage device to
>>> show up.
>>>
>>> And this is just like that, we need to wait for the actual display driver
>>> to have loaded and taken over before "cleaning up" the clocks used by
>>> the display engine.
>>>
>>> I guess we could just delay all clock cleanup until then, not really
>>> pretty, and I still prefer to just list the clocks in the simplefb
>>> dtnode, but if this version would be acceptable to all involved, I can
>>> live with it.
>>>
>>> Mike, would a patch adding 2 calls like these to the clock core be
>>> acceptable ?  :
>>>
>>> clk_block_disable_unused()
>>> clk_unblock_disable_unused()
>>>
>>> Where an earlyconsole driver can then call clk_block_disable_unused(),
>>> which will turn any calls to clk_disable_unused into a nop.
>>
>> Is there a way to use the existing eprobe_defer system to do this?
>
> No, that is not what it is intended for (at all). If we go this way
> 2 subsystem specific calls for this is the best way to deal with this.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:

<snip>

>>>>> So there are two ways to do this...
>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>> (I think this is a bad idea)
>>>>
>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>> are needed, then earlyconsole can claim them, and release them on
>>>> handover to the real display driver.
>>
>> Jon, can you please answer this ? I really really want to know why people
>> think this is such a bad idea. Understanding why people think this is a bad
>> idea is necessary to be able to come up with an alternative solution.
> 
> The list of resources should not be duplicated in the device tree -
> once in the simplefb node and again in the real device node.

It is not duplicated, the simplefb node will list the clocks used for the
mode / output as setup by the firmware, which are often not all clocks
which the display engine supports. Where as the real device node will list
all clocks the display engine may use.

> Device
> tree is a hardware description and it is being twisted to solve a
> software issue.

This is not true, various core devicetree developers have already said
that storing other info in the devicetree is fine, and being able to do so
is part of the original design.

> This problem is not limited to clocks, same problem
> exists with regulators. On SGI systems this would exist with entire
> bus controllers (but they are x86 based, console is not on the root
> bus). This is a very messy problem and will lead to a Frankenstein
> sized driver over time.

This is a "what if ..." argument, we can discuss potential hypothetical
problems all day long, what happens if the sky falls down?

> But... I think this is a red herring which is masking the real
> problem. The real problem seems to be that there is no window for
> loading device specific drivers before the resource clean up phase
> happens. That's a real problem -- multi architecture distros are going
> to have lots of loadable device specific drivers.

As Maxime pointed out to my alternative solution to fixing the clocks
problem, this is not strictly a when to do cleanup problem. If another
driver uses the same clocks, and does a clk_disable call after probing
(because the device is put in low power mode until used by userspace),
then the clk will be disabled even without any cleanup running at all.

The real problem here is simply that to work the simplefb needs certain
resources, just like any other device. And while for any other device
simply listing the needed resources is an accepted practice, for simplefb
for some reason (which I still do not understand) people all of a sudden
see listing resources as a problem.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:

<snip>

>>>>> So there are two ways to do this...
>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>> (I think this is a bad idea)
>>>>
>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>> are needed, then earlyconsole can claim them, and release them on
>>>> handover to the real display driver.
>>
>> Jon, can you please answer this ? I really really want to know why people
>> think this is such a bad idea. Understanding why people think this is a bad
>> idea is necessary to be able to come up with an alternative solution.
> 
> The list of resources should not be duplicated in the device tree -
> once in the simplefb node and again in the real device node.

It is not duplicated, the simplefb node will list the clocks used for the
mode / output as setup by the firmware, which are often not all clocks
which the display engine supports. Where as the real device node will list
all clocks the display engine may use.

> Device
> tree is a hardware description and it is being twisted to solve a
> software issue.

This is not true, various core devicetree developers have already said
that storing other info in the devicetree is fine, and being able to do so
is part of the original design.

> This problem is not limited to clocks, same problem
> exists with regulators. On SGI systems this would exist with entire
> bus controllers (but they are x86 based, console is not on the root
> bus). This is a very messy problem and will lead to a Frankenstein
> sized driver over time.

This is a "what if ..." argument, we can discuss potential hypothetical
problems all day long, what happens if the sky falls down?

> But... I think this is a red herring which is masking the real
> problem. The real problem seems to be that there is no window for
> loading device specific drivers before the resource clean up phase
> happens. That's a real problem -- multi architecture distros are going
> to have lots of loadable device specific drivers.

As Maxime pointed out to my alternative solution to fixing the clocks
problem, this is not strictly a when to do cleanup problem. If another
driver uses the same clocks, and does a clk_disable call after probing
(because the device is put in low power mode until used by userspace),
then the clk will be disabled even without any cleanup running at all.

The real problem here is simply that to work the simplefb needs certain
resources, just like any other device. And while for any other device
simply listing the needed resources is an accepted practice, for simplefb
for some reason (which I still do not understand) people all of a sudden
see listing resources as a problem.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>
> <snip>
>
>>>>>> So there are two ways to do this...
>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>> (I think this is a bad idea)
>>>>>
>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>> handover to the real display driver.
>>>
>>> Jon, can you please answer this ? I really really want to know why people
>>> think this is such a bad idea. Understanding why people think this is a bad
>>> idea is necessary to be able to come up with an alternative solution.
>>
>> The list of resources should not be duplicated in the device tree -
>> once in the simplefb node and again in the real device node.
>
> It is not duplicated, the simplefb node will list the clocks used for the
> mode / output as setup by the firmware, which are often not all clocks
> which the display engine supports. Where as the real device node will list
> all clocks the display engine may use.
>
>> Device
>> tree is a hardware description and it is being twisted to solve a
>> software issue.
>
> This is not true, various core devicetree developers have already said
> that storing other info in the devicetree is fine, and being able to do so
> is part of the original design.
>
>> This problem is not limited to clocks, same problem
>> exists with regulators. On SGI systems this would exist with entire
>> bus controllers (but they are x86 based, console is not on the root
>> bus). This is a very messy problem and will lead to a Frankenstein
>> sized driver over time.
>
> This is a "what if ..." argument, we can discuss potential hypothetical
> problems all day long, what happens if the sky falls down?
>
>> But... I think this is a red herring which is masking the real
>> problem. The real problem seems to be that there is no window for
>> loading device specific drivers before the resource clean up phase
>> happens. That's a real problem -- multi architecture distros are going
>> to have lots of loadable device specific drivers.
>
> As Maxime pointed out to my alternative solution to fixing the clocks
> problem, this is not strictly a when to do cleanup problem. If another
> driver uses the same clocks, and does a clk_disable call after probing
> (because the device is put in low power mode until used by userspace),
> then the clk will be disabled even without any cleanup running at all.
>
> The real problem here is simply that to work the simplefb needs certain
> resources, just like any other device. And while for any other device
> simply listing the needed resources is an accepted practice, for simplefb
> for some reason (which I still do not understand) people all of a sudden
> see listing resources as a problem.

Because you are creating two different device tree nodes describing a
single piece of hardware and that's not suppose to happen in a device
tree.  The accurate description of the hardware is being perverted to
solve a software problem.

One node describes the hardware in a format to make simplefb happy.
Another node describes the same hardware in a format to make the
device specific driver happy.


>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>
> <snip>
>
>>>>>> So there are two ways to do this...
>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>> (I think this is a bad idea)
>>>>>
>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>> handover to the real display driver.
>>>
>>> Jon, can you please answer this ? I really really want to know why people
>>> think this is such a bad idea. Understanding why people think this is a bad
>>> idea is necessary to be able to come up with an alternative solution.
>>
>> The list of resources should not be duplicated in the device tree -
>> once in the simplefb node and again in the real device node.
>
> It is not duplicated, the simplefb node will list the clocks used for the
> mode / output as setup by the firmware, which are often not all clocks
> which the display engine supports. Where as the real device node will list
> all clocks the display engine may use.
>
>> Device
>> tree is a hardware description and it is being twisted to solve a
>> software issue.
>
> This is not true, various core devicetree developers have already said
> that storing other info in the devicetree is fine, and being able to do so
> is part of the original design.
>
>> This problem is not limited to clocks, same problem
>> exists with regulators. On SGI systems this would exist with entire
>> bus controllers (but they are x86 based, console is not on the root
>> bus). This is a very messy problem and will lead to a Frankenstein
>> sized driver over time.
>
> This is a "what if ..." argument, we can discuss potential hypothetical
> problems all day long, what happens if the sky falls down?
>
>> But... I think this is a red herring which is masking the real
>> problem. The real problem seems to be that there is no window for
>> loading device specific drivers before the resource clean up phase
>> happens. That's a real problem -- multi architecture distros are going
>> to have lots of loadable device specific drivers.
>
> As Maxime pointed out to my alternative solution to fixing the clocks
> problem, this is not strictly a when to do cleanup problem. If another
> driver uses the same clocks, and does a clk_disable call after probing
> (because the device is put in low power mode until used by userspace),
> then the clk will be disabled even without any cleanup running at all.
>
> The real problem here is simply that to work the simplefb needs certain
> resources, just like any other device. And while for any other device
> simply listing the needed resources is an accepted practice, for simplefb
> for some reason (which I still do not understand) people all of a sudden
> see listing resources as a problem.

Because you are creating two different device tree nodes describing a
single piece of hardware and that's not suppose to happen in a device
tree.  The accurate description of the hardware is being perverted to
solve a software problem.

One node describes the hardware in a format to make simplefb happy.
Another node describes the same hardware in a format to make the
device specific driver happy.


>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

But... I think all of this device tree stuff is a red herring and not
the core problem.

Core problem.....

Bios sets stuff up
Built-in drivers initialize
Bios settings get cleaned up (display goes blank)
Loadable drivers initialize (display comes back)

In multi-architecture kernels almost all of the drivers are loadable.
We need to figure out how to change the order....

Bios sets stuff up
Built-in drivers initialize
Loadable drivers initialize
Bios settings get cleaned up

Maybe the Bios cleanup turns into a small app you place at the end of
your init scripts. It's just a power saving cleanup and shouldn't be
causing this much trouble.

I don't think leaving the order as is and using the device tree to
construct a big list of exceptions to the clean up process is the
right approach.

>
>
>>
>> Regards,
>>
>> Hans
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

But... I think all of this device tree stuff is a red herring and not
the core problem.

Core problem.....

Bios sets stuff up
Built-in drivers initialize
Bios settings get cleaned up (display goes blank)
Loadable drivers initialize (display comes back)

In multi-architecture kernels almost all of the drivers are loadable.
We need to figure out how to change the order....

Bios sets stuff up
Built-in drivers initialize
Loadable drivers initialize
Bios settings get cleaned up

Maybe the Bios cleanup turns into a small app you place at the end of
your init scripts. It's just a power saving cleanup and shouldn't be
causing this much trouble.

I don't think leaving the order as is and using the device tree to
construct a big list of exceptions to the clean up process is the
right approach.

>
>
>>
>> Regards,
>>
>> Hans
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 05:30 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.

That again is a very narrow reading of what is a very generic descriptive
language. Also note that we are already in this situation with simplefb,
all we're advocating is extending the info which is in the simplefb node
so that it is actually usable in a much wider range of scenarios.

>> The accurate description of the hardware is being perverted to
>> solve a software problem.

Again, devicetree is not strictly a hardware description language.

>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
> 
> But... I think all of this device tree stuff is a red herring and not
> the core problem.

Actually the red herring is people focussing on the init ordering
solution, which as already explained will simply never work, quoting
myself (from above):

>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.

And to repeat myself yet again:

"The real problem here is simply that to work the simplefb needs certain
resources, just like any other device."

So the logical thing to do is to just put the clocks in the node. The only
counter argument I hear you make is "this is not a hardware description,
so it does not belong in devicetree". An argument which has already
been discussed earlier in this thread (about a month ago) and one of the
officialo devicetree maintainers responded to that saying that it is fine
to have non hardware info in the dt.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 05:30 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.

That again is a very narrow reading of what is a very generic descriptive
language. Also note that we are already in this situation with simplefb,
all we're advocating is extending the info which is in the simplefb node
so that it is actually usable in a much wider range of scenarios.

>> The accurate description of the hardware is being perverted to
>> solve a software problem.

Again, devicetree is not strictly a hardware description language.

>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
> 
> But... I think all of this device tree stuff is a red herring and not
> the core problem.

Actually the red herring is people focussing on the init ordering
solution, which as already explained will simply never work, quoting
myself (from above):

>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.

And to repeat myself yet again:

"The real problem here is simply that to work the simplefb needs certain
resources, just like any other device."

So the logical thing to do is to just put the clocks in the node. The only
counter argument I hear you make is "this is not a hardware description,
so it does not belong in devicetree". An argument which has already
been discussed earlier in this thread (about a month ago) and one of the
officialo devicetree maintainers responded to that saying that it is fine
to have non hardware info in the dt.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 17:30, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.  The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.

No.

one node describes the state in which the hardware was left by u-boot
and other node describes the display hardware in full.

Obviously, this will overlap but is not duplication.

Or as pointed out the simplefb node is not hardware description but
'other information' which is part of the DT design. If your system
does not use simplefb it can be ignored with no ill side effect (once
the part with claiming memory for simplefb cleanly is resolved).

Did we not discuss that several times already?

>
> But... I think all of this device tree stuff is a red herring and not
> the core problem.
>
> Core problem.....
>
> Bios sets stuff up
> Built-in drivers initialize
> Bios settings get cleaned up (display goes blank)
> Loadable drivers initialize (display comes back)
>
> In multi-architecture kernels almost all of the drivers are loadable.
> We need to figure out how to change the order....
>
> Bios sets stuff up
> Built-in drivers initialize
> Loadable drivers initialize
> Bios settings get cleaned up
>
> Maybe the Bios cleanup turns into a small app you place at the end of
> your init scripts. It's just a power saving cleanup and shouldn't be
> causing this much trouble.

No. You need to do cleanup during driver loading as well. So not doing
the cleanup early gives you more bizarre problems.

Did we not discuss that several times as well?

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 17:30, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.  The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.

No.

one node describes the state in which the hardware was left by u-boot
and other node describes the display hardware in full.

Obviously, this will overlap but is not duplication.

Or as pointed out the simplefb node is not hardware description but
'other information' which is part of the DT design. If your system
does not use simplefb it can be ignored with no ill side effect (once
the part with claiming memory for simplefb cleanly is resolved).

Did we not discuss that several times already?

>
> But... I think all of this device tree stuff is a red herring and not
> the core problem.
>
> Core problem.....
>
> Bios sets stuff up
> Built-in drivers initialize
> Bios settings get cleaned up (display goes blank)
> Loadable drivers initialize (display comes back)
>
> In multi-architecture kernels almost all of the drivers are loadable.
> We need to figure out how to change the order....
>
> Bios sets stuff up
> Built-in drivers initialize
> Loadable drivers initialize
> Bios settings get cleaned up
>
> Maybe the Bios cleanup turns into a small app you place at the end of
> your init scripts. It's just a power saving cleanup and shouldn't be
> causing this much trouble.

No. You need to do cleanup during driver loading as well. So not doing
the cleanup early gives you more bizarre problems.

Did we not discuss that several times as well?

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi,

On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

Stupid question: What about mangling an existing device node to be
simplefb compatible, and writing simplefb to be binding agnostic?

I listed some psuedo-code to do the latter earlier in the thread.

I.e. changing something like this:

vopb: vopb@ff930000 {
    compatible = "rockchip,rk3288-vop";
    reg = <0xff930000 0x19c>;
    interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
    clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
    resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
    reset-names = "axi", "ahb", "dclk";
    iommus = <&vopb_mmu>;
    vopb_out: port {
        #address-cells = <1>;
        #size-cells = <0>;
        vopb_out_edp: endpoint@0 {
            reg = <0>;
            remote-endpoint=<&edp_in_vopb>;
        };
        vopb_out_hdmi: endpoint@1 {
            reg = <1>;
            remote-endpoint=<&hdmi_in_vopb>;
        };
    };
};

into something like this:

vopb: vopb@ff930000 {
    compatible = "rockchip,rk3288-vop", "simple-framebuffer";
    framebuffer {
        reg = <0x1d385000 (1600 * 1200 * 2)>;
        width = <1600>;
        height = <1200>;
        stride = <(1600 * 2)>;
        format = "r5g6b5";
    };
    reg = <0xff930000 0x19c>;
    interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
    clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
    resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
    reset-names = "axi", "ahb", "dclk";
    iommus = <&vopb_mmu>;
    vopb_out: port {
        #address-cells = <1>;
        #size-cells = <0>;
        vopb_out_edp: endpoint@0 {
            reg = <0>;
            remote-endpoint=<&edp_in_vopb>;
        };
        vopb_out_hdmi: endpoint@1 {
            reg = <1>;
            remote-endpoint=<&hdmi_in_vopb>;
        };
    };
};

And if the clocks are output port specific, we could add some lines
like "simple-framebuffer,ignore-node" to it so simplefb doesn't enable
HDMI clocks when we're using a build-in LCD.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi,

On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> <snip>
>>
>>>>>>> So there are two ways to do this...
>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>> (I think this is a bad idea)
>>>>>>
>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>> handover to the real display driver.
>>>>
>>>> Jon, can you please answer this ? I really really want to know why people
>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>> idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

Stupid question: What about mangling an existing device node to be
simplefb compatible, and writing simplefb to be binding agnostic?

I listed some psuedo-code to do the latter earlier in the thread.

I.e. changing something like this:

vopb: vopb at ff930000 {
    compatible = "rockchip,rk3288-vop";
    reg = <0xff930000 0x19c>;
    interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
    clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
    resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
    reset-names = "axi", "ahb", "dclk";
    iommus = <&vopb_mmu>;
    vopb_out: port {
        #address-cells = <1>;
        #size-cells = <0>;
        vopb_out_edp: endpoint at 0 {
            reg = <0>;
            remote-endpoint=<&edp_in_vopb>;
        };
        vopb_out_hdmi: endpoint at 1 {
            reg = <1>;
            remote-endpoint=<&hdmi_in_vopb>;
        };
    };
};

into something like this:

vopb: vopb at ff930000 {
    compatible = "rockchip,rk3288-vop", "simple-framebuffer";
    framebuffer {
        reg = <0x1d385000 (1600 * 1200 * 2)>;
        width = <1600>;
        height = <1200>;
        stride = <(1600 * 2)>;
        format = "r5g6b5";
    };
    reg = <0xff930000 0x19c>;
    interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
    clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
    resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
    reset-names = "axi", "ahb", "dclk";
    iommus = <&vopb_mmu>;
    vopb_out: port {
        #address-cells = <1>;
        #size-cells = <0>;
        vopb_out_edp: endpoint at 0 {
            reg = <0>;
            remote-endpoint=<&edp_in_vopb>;
        };
        vopb_out_hdmi: endpoint at 1 {
            reg = <1>;
            remote-endpoint=<&hdmi_in_vopb>;
        };
    };
};

And if the clocks are output port specific, we could add some lines
like "simple-framebuffer,ignore-node" to it so simplefb doesn't enable
HDMI clocks when we're using a build-in LCD.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/03/2014 01:31 AM, Julian Calaby wrote:
> Hi,
> 
> On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.  The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
> 
> Stupid question: What about mangling an existing device node to be
> simplefb compatible, and writing simplefb to be binding agnostic?

That will not work, with simplefb a single node represents the currently
active video output. While in real hardware that may involve multiple
blocks, e.g on sunxi for hdmi out this involves the compositor (which
generates video data from 1 or more layers) which feeds into the
lcd-controller (which in this case is only used to generate hsync + vsync)
signals really, which feeds into the hdmi encoder, all 3 of which are
separate hardware blocks with their own clocks, etc.

And which hardware blocks exactly are involved will differ depending
on which video output of the device has been setup by the firmware.

The simplefb node is a virtual device, describing what the firmware
has setup, where as the hardware nodes are describing the real hardware.

I can see that people see this as duplicate info, but really it is not,
one is runtime information passed from the bootloader/firmware to the
kernel, the other is standard hardware description as people are used
to seeing in devicetree.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/03/2014 01:31 AM, Julian Calaby wrote:
> Hi,
> 
> On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 04:16 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> <snip>
>>>
>>>>>>>> So there are two ways to do this...
>>>>>>>> 1) modify things like earlyconsole to protect device specific resource
>>>>>>>> (I think this is a bad idea)
>>>>>>>
>>>>>>> Why is this a bad idea? If the bootloader tells us exactly which resources
>>>>>>> are needed, then earlyconsole can claim them, and release them on
>>>>>>> handover to the real display driver.
>>>>>
>>>>> Jon, can you please answer this ? I really really want to know why people
>>>>> think this is such a bad idea. Understanding why people think this is a bad
>>>>> idea is necessary to be able to come up with an alternative solution.
>>>>
>>>> The list of resources should not be duplicated in the device tree -
>>>> once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
>>>> Device
>>>> tree is a hardware description and it is being twisted to solve a
>>>> software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
>>>> This problem is not limited to clocks, same problem
>>>> exists with regulators. On SGI systems this would exist with entire
>>>> bus controllers (but they are x86 based, console is not on the root
>>>> bus). This is a very messy problem and will lead to a Frankenstein
>>>> sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
>>>> But... I think this is a red herring which is masking the real
>>>> problem. The real problem seems to be that there is no window for
>>>> loading device specific drivers before the resource clean up phase
>>>> happens. That's a real problem -- multi architecture distros are going
>>>> to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.  The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
> 
> Stupid question: What about mangling an existing device node to be
> simplefb compatible, and writing simplefb to be binding agnostic?

That will not work, with simplefb a single node represents the currently
active video output. While in real hardware that may involve multiple
blocks, e.g on sunxi for hdmi out this involves the compositor (which
generates video data from 1 or more layers) which feeds into the
lcd-controller (which in this case is only used to generate hsync + vsync)
signals really, which feeds into the hdmi encoder, all 3 of which are
separate hardware blocks with their own clocks, etc.

And which hardware blocks exactly are involved will differ depending
on which video output of the device has been setup by the firmware.

The simplefb node is a virtual device, describing what the firmware
has setup, where as the hardware nodes are describing the real hardware.

I can see that people see this as duplicate info, but really it is not,
one is runtime information passed from the bootloader/firmware to the
kernel, the other is standard hardware description as people are used
to seeing in devicetree.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Grant Likely]

On Fri, 03 Oct 2014 09:56:27 +0200
, Hans de Goede <hdegoede@redhat.com>
 wrote:
> On 10/03/2014 01:31 AM, Julian Calaby wrote:
> > On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> >> Because you are creating two different device tree nodes describing a
> >> single piece of hardware and that's not suppose to happen in a device
> >> tree.  The accurate description of the hardware is being perverted to
> >> solve a software problem.
> >>
> >> One node describes the hardware in a format to make simplefb happy.
> >> Another node describes the same hardware in a format to make the
> >> device specific driver happy.
> > 
> > Stupid question: What about mangling an existing device node to be
> > simplefb compatible, and writing simplefb to be binding agnostic?
> 
> That will not work, with simplefb a single node represents the currently
> active video output. While in real hardware that may involve multiple
> blocks, e.g on sunxi for hdmi out this involves the compositor (which
> generates video data from 1 or more layers) which feeds into the
> lcd-controller (which in this case is only used to generate hsync + vsync)
> signals really, which feeds into the hdmi encoder, all 3 of which are
> separate hardware blocks with their own clocks, etc.

The answer here should be, 'whoever does the DMA'.

Julian's suggestion is actually the sanest approach, and there is
precedence for doing exactly that in DT, both for serial devices
(of_serial.c) and framebuffers (offb.c).

g.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Grant Likely]

On Fri, 03 Oct 2014 09:56:27 +0200
, Hans de Goede <hdegoede@redhat.com>
 wrote:
> On 10/03/2014 01:31 AM, Julian Calaby wrote:
> > On Fri, Oct 3, 2014 at 1:14 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> >> Because you are creating two different device tree nodes describing a
> >> single piece of hardware and that's not suppose to happen in a device
> >> tree.  The accurate description of the hardware is being perverted to
> >> solve a software problem.
> >>
> >> One node describes the hardware in a format to make simplefb happy.
> >> Another node describes the same hardware in a format to make the
> >> device specific driver happy.
> > 
> > Stupid question: What about mangling an existing device node to be
> > simplefb compatible, and writing simplefb to be binding agnostic?
> 
> That will not work, with simplefb a single node represents the currently
> active video output. While in real hardware that may involve multiple
> blocks, e.g on sunxi for hdmi out this involves the compositor (which
> generates video data from 1 or more layers) which feeds into the
> lcd-controller (which in this case is only used to generate hsync + vsync)
> signals really, which feeds into the hdmi encoder, all 3 of which are
> separate hardware blocks with their own clocks, etc.

The answer here should be, 'whoever does the DMA'.

Julian's suggestion is actually the sanest approach, and there is
precedence for doing exactly that in DT, both for serial devices
(of_serial.c) and framebuffers (offb.c).

g.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
> > 2) delay the clock/regulator cleanup until after there is a fixed
> > window for device specific drivers to load in. Loading from initrd is
> > a fixed window.
> 
> As I already explained by example in another mail, this won't work:
> 
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
> 
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."

Plus:

1) you might not have an initrd, which doesn't change a thing: your
clock get disabled before you can load your driver

2) you might not have a rootfs, and no driver to load, which would
leave the clock enabled forever.

> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
> 
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
> 
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
> 
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ?  :
> 
> clk_block_disable_unused()
> clk_unblock_disable_unused()

Thierry actually already made such a patch somewhere in this
thread. The thing is that it should also block clk_disable (and all
the potential users of clk_disable: clk_set_rate, clk_set_parent,
etc.) from actually disabling them. Otherwise, you might still end up
with your clock disabled.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
> > 2) delay the clock/regulator cleanup until after there is a fixed
> > window for device specific drivers to load in. Loading from initrd is
> > a fixed window.
> 
> As I already explained by example in another mail, this won't work:
> 
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
> 
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."

Plus:

1) you might not have an initrd, which doesn't change a thing: your
clock get disabled before you can load your driver

2) you might not have a rootfs, and no driver to load, which would
leave the clock enabled forever.

> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
> 
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
> 
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
> 
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ?  :
> 
> clk_block_disable_unused()
> clk_unblock_disable_unused()

Thierry actually already made such a patch somewhere in this
thread. The thing is that it should also block clk_disable (and all
the potential users of clk_disable: clk_set_rate, clk_set_parent,
etc.) from actually disabling them. Otherwise, you might still end up
with your clock disabled.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141002/40038c20/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:18 PM, Maxime Ripard wrote:
> On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
> 
> Plus:
> 
> 1) you might not have an initrd, which doesn't change a thing: your
> clock get disabled before you can load your driver
> 
> 2) you might not have a rootfs, and no driver to load, which would
> leave the clock enabled forever.
> 
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ?  :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
> 
> Thierry actually already made such a patch somewhere in this
> thread. The thing is that it should also block clk_disable (and all
> the potential users of clk_disable: clk_set_rate, clk_set_parent,
> etc.) from actually disabling them. Otherwise, you might still end up
> with your clock disabled.

A valid point, which brings us back to simply adding the clocks to the
dt node really being both the simplest solution, as well as the only
solution without any pitfalls.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 04:18 PM, Maxime Ripard wrote:
> On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
> 
> Plus:
> 
> 1) you might not have an initrd, which doesn't change a thing: your
> clock get disabled before you can load your driver
> 
> 2) you might not have a rootfs, and no driver to load, which would
> leave the clock enabled forever.
> 
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ?  :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
> 
> Thierry actually already made such a patch somewhere in this
> thread. The thing is that it should also block clk_disable (and all
> the potential users of clk_disable: clk_set_rate, clk_set_parent,
> etc.) from actually disabling them. Otherwise, you might still end up
> with your clock disabled.

A valid point, which brings us back to simply adding the clocks to the
dt node really being both the simplest solution, as well as the only
solution without any pitfalls.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 15:40, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> ...
>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>
>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>
>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>
>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>
>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>
>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>
>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>
>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>
>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>
>>>>>>> You need both.
>>>>>>>
>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>
>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>> set_console() but it's been a while.
>>>>>>
>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>
>>>>> No, that is where you get into trouble. The device specific driver has
>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>> as possible.
>>>>
>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>> say I can, deadlock.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> I've already explained that we not only can do that (we already have working
>>>> code proving that), but also that this is something which we absolutely need:
>>>>
>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>> is that the right module is not included in the initrd.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
>
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
>
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
>
> So there are two ways to do this...
> 1) modify things like earlyconsole to protect device specific resource
> (I think this is a bad idea)
> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.

Fixed window is timeout.

Time and time again timeouts break.

How is loading a module from harddisk different form loading from initrd?

How is even the kernel going to tell?

How should systems that run completely off initrd behave?

How should the kernel behave during this 'fixed window'? If it cannot
touch resources that were in enabled or unknown state at boot how can
it allocate resources for newly loaded drivers?

Or to put it differently: when the firmware inserts dynamically at
boot time or the DT writer statically at compile time the resources
which are needed by console then kernel knows that the *other* stuff
that has been enabled by firmware or for which it cannot be determined
if it's enabled or not can be reused.

For example, if the firmware loaded the kernel from mmc or just probed
mmc the mmc clocks have been likely left enabled. You need to
reprogram mmc clocks to access mmc most of the time. If you assume no
knowledge of hardware then you cannot know that mmc clocks are not
used for console and cannot touch them. Hence if loading a kms driver
fails in initrd you are needlessly locked out of loading system from
mmc.

I am sure you can find other examples for both clocks or other
resources so the solution to properly name what you need for the
console to keep running is more scalable.

If your board is simple you might get away with a static DT. If you do
not care about early graphics you can just drop it.

BTW this has *also* been discussed here, at length.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 15:40, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>> ...
>>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>>
>>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>>
>>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>>
>>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>>> and everything will just work.
>>>>>>>>>>>
>>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>>
>>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>>
>>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>>
>>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>>
>>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>>> won't have video output until quite late into the boot process.
>>>>>>>
>>>>>>> You need both.
>>>>>>>
>>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>>
>>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>>> set_console() but it's been a while.
>>>>>>
>>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>>
>>>>> No, that is where you get into trouble. The device specific driver has
>>>>> to go onto initrd where it can be loaded as early in the boot process
>>>>> as possible.
>>>>
>>>> This is an argument in the "you cannot do that" / "your use case is not valid"
>>>> category, IOW this is not a technical argument. You say I cannot do that I
>>>> say I can, deadlock.
>>>
>>> It is certainly possible to extend an earlyframebuffer to be able to
>>> run as a user space console. It is just going to turn into a
>>> Frankenmonster driver with piles of device specific, special case code
>>> in it.
>>
>> There is nothing hardware specific about a framebuffer needing some
>> clocks to not be disabled. Tons of SoC's will have this. Which clocks,
>> that is hardware specific, but the framebuffer driver does not need to
>> worry about that, it just sees a clocks property with some random clocks
>> in there, and that is as generic as it gets.
>>
>>> I think that device specific code belongs in a device specific driver
>>> and earlyframebuffer should handoff to it as soon as possible.
>>>
>>>>
>>>> I've already explained that we not only can do that (we already have working
>>>> code proving that), but also that this is something which we absolutely need:
>>>>
>>>>>> One example why this is necessary is e.g. to debug things where the problem
>>>>>> is that the right module is not included in the initrd.
>>>
>>> A generic earlyframebuffer would show this error.
>>
>> If it reserves the clocks it needs, yes. If it does not then the clocks will
>> be disabled before the initrd starts, and the screen will be black from then
>
> I thought the clock/regulator clean up happened after initrd loading,
> but maybe that is not the case.
>
> A cleaner solution would then be to modify the clock/regulator clean
> up to happen after driver loading is finished from initrd. Deferring
> until after that completes is a fixed limit, everything is sitting
> there in RAM. I would not propose extending it until harddisk based
> loading happens.
>
> So there are two ways to do this...
> 1) modify things like earlyconsole to protect device specific resource
> (I think this is a bad idea)
> 2) delay the clock/regulator cleanup until after there is a fixed
> window for device specific drivers to load in. Loading from initrd is
> a fixed window.

Fixed window is timeout.

Time and time again timeouts break.

How is loading a module from harddisk different form loading from initrd?

How is even the kernel going to tell?

How should systems that run completely off initrd behave?

How should the kernel behave during this 'fixed window'? If it cannot
touch resources that were in enabled or unknown state at boot how can
it allocate resources for newly loaded drivers?

Or to put it differently: when the firmware inserts dynamically at
boot time or the DT writer statically at compile time the resources
which are needed by console then kernel knows that the *other* stuff
that has been enabled by firmware or for which it cannot be determined
if it's enabled or not can be reused.

For example, if the firmware loaded the kernel from mmc or just probed
mmc the mmc clocks have been likely left enabled. You need to
reprogram mmc clocks to access mmc most of the time. If you assume no
knowledge of hardware then you cannot know that mmc clocks are not
used for console and cannot touch them. Hence if loading a kms driver
fails in initrd you are needlessly locked out of loading system from
mmc.

I am sure you can find other examples for both clocks or other
resources so the solution to properly name what you need for the
console to keep running is more scalable.

If your board is simple you might get away with a static DT. If you do
not care about early graphics you can just drop it.

BTW this has *also* been discussed here, at length.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 15:27, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
>
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

What is device specific about code that reads a list of clocks and
just asks tells kernel it uses them all?

That's been discussed to death in this thread already.

>
> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.

Even it that case it needs to tell the kernel it needs the clocks so
that they are not shut of until that handoff happens.

>
>>
>> I've already explained that we not only can do that (we already have working
>> code proving that), but also that this is something which we absolutely need:
>>
>>>> One example why this is necessary is e.g. to debug things where the problem
>>>> is that the right module is not included in the initrd.
>
> A generic earlyframebuffer would show this error.
>
> Just use earlyprintk as a guideline, if earlyprintk shows the error
> earlyframebuffer would also show it.
>

It does not. It hands off to an uart driver built into the kernel. The
handoff is broken on sunxi and the earlyprintk continues to work
indefinitely replicating all kernel messages twice on the serial
console unless something happens to reconfigure the uart used for
earlyprink later on. When that does happen the early console can fail
very early, even way before the time you would load an initrd. It just
happens to work most of the time because when you use earlyprintk most
of the time you also use serial console with the same parameters on
the same pins.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 15:27, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
>
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

What is device specific about code that reads a list of clocks and
just asks tells kernel it uses them all?

That's been discussed to death in this thread already.

>
> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.

Even it that case it needs to tell the kernel it needs the clocks so
that they are not shut of until that handoff happens.

>
>>
>> I've already explained that we not only can do that (we already have working
>> code proving that), but also that this is something which we absolutely need:
>>
>>>> One example why this is necessary is e.g. to debug things where the problem
>>>> is that the right module is not included in the initrd.
>
> A generic earlyframebuffer would show this error.
>
> Just use earlyprintk as a guideline, if earlyprintk shows the error
> earlyframebuffer would also show it.
>

It does not. It hands off to an uart driver built into the kernel. The
handoff is broken on sunxi and the earlyprintk continues to work
indefinitely replicating all kernel messages twice on the serial
console unless something happens to reconfigure the uart used for
earlyprink later on. When that does happen the early console can fail
very early, even way before the time you would load an initrd. It just
happens to work most of the time because when you use earlyprintk most
of the time you also use serial console with the same parameters on
the same pins.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> ...
>>>>>>> We've been over all this again and again and again.
>>>>>>>
>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>
>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>
>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>> and everything will just work.
>>>>>>>
>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>> generic clocks property is about as generic as things come.
>>>>>
>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>
>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>
>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>
>>>> The whole reason why we want to use simplefb is not just to get things
>>>> running until HW specific driver is in place, but also to have early console
>>>> output (to help debugging boot problems on devices without a serial console),
>>>> in a world where most video drivers are build as loadable modules, so we
>>>> won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
>
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.
>
> Trying to indefinitely extend the life of the earlyprintk or
> earlyframeuffer is what causes problems.  Doing that forces you to
> basically turn them into device specific drivers which do things like
> claiming device specific resources and gaining device specific
> dependency knowledge, things that shouldn't be in earlyframebuffer.
>

No. When initrd is running boot has already finished as far as kernel
is concerned.

And you have to extend the life of the simplefb from the time boot has
finished through the time kernel mounts initrd (or other root) and
hands over to userspace found on the initrd, through the time this
userspace searches for the kms driver and until the time it has
finally loaded if that ever succeeds.

From the point of view of kernel once it has handed over to init in
initrd the boot is finished. The init is normal userspace running off
normal filesystem backed by a device-specific driver (initrd).

That some systems do not continue to run off this filesystem
indefinitely and in fact go out of their way to expunge the initrd
filesystem and reclaim its resources by exercising some syscalls
specifically devised for that use case is not relevant to the kernel.
It cannot know when the userspace considers the boot finished enough.
Sometimes even manual steps are required to finish booting when the
automatic scripts fail.

simplefb as early console is meant exactly for diagnosing and fixing
such failures in absence of an uart.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 2 October 2014 14:56, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> ...
>>>>>>> We've been over all this again and again and again.
>>>>>>>
>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>
>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>
>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>> and everything will just work.
>>>>>>>
>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>> generic clocks property is about as generic as things come.
>>>>>
>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>
>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>
>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>
>>>> The whole reason why we want to use simplefb is not just to get things
>>>> running until HW specific driver is in place, but also to have early console
>>>> output (to help debugging boot problems on devices without a serial console),
>>>> in a world where most video drivers are build as loadable modules, so we
>>>> won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
>
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.
>
> Trying to indefinitely extend the life of the earlyprintk or
> earlyframeuffer is what causes problems.  Doing that forces you to
> basically turn them into device specific drivers which do things like
> claiming device specific resources and gaining device specific
> dependency knowledge, things that shouldn't be in earlyframebuffer.
>

No. When initrd is running boot has already finished as far as kernel
is concerned.

And you have to extend the life of the simplefb from the time boot has
finished through the time kernel mounts initrd (or other root) and
hands over to userspace found on the initrd, through the time this
userspace searches for the kms driver and until the time it has
finally loaded if that ever succeeds.

>From the point of view of kernel once it has handed over to init in
initrd the boot is finished. The init is normal userspace running off
normal filesystem backed by a device-specific driver (initrd).

That some systems do not continue to run off this filesystem
indefinitely and in fact go out of their way to expunge the initrd
filesystem and reclaim its resources by exercising some syscalls
specifically devised for that use case is not relevant to the kernel.
It cannot know when the userspace considers the boot finished enough.
Sometimes even manual steps are required to finish booting when the
automatic scripts fail.

simplefb as early console is meant exactly for diagnosing and fixing
such failures in absence of an uart.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> ...
>>>>>>>> We've been over all this again and again and again.
>>>>>>>>
>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>
>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>
>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>> and everything will just work.
>>>>>>>>
>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>
>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>
>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>
>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>
>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>> running until HW specific driver is in place, but also to have early console
>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>> won't have video output until quite late into the boot process.
>>>>
>>>> You need both.
>>>>
>>>> 1) temporary early boot console -- this is nothing but an address in
>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>> process -- the same thing happens with the early printk UART driver.
>>>> EARLYPRINTK on the command line enables this.
>>>>
>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>> soon as possible. The same thing happens with the real UART driver for
>>>> the console. CONSOLE= on the command line causes the transition. There
>>>> is an API in the kernel to do this transition, I believe it is called
>>>> set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>>
>> Trying to indefinitely extend the life of the earlyprintk or
>> earlyframeuffer is what causes problems.  Doing that forces you to
>> basically turn them into device specific drivers which do things like
>> claiming device specific resources and gaining device specific
>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>
>
> No. When initrd is running boot has already finished as far as kernel
> is concerned.
>
> And you have to extend the life of the simplefb from the time boot has
> finished through the time kernel mounts initrd (or other root) and
> hands over to userspace found on the initrd, through the time this
> userspace searches for the kms driver and until the time it has
> finally loaded if that ever succeeds.

Does the clock and regulator cleanup happen before drivers can load
off from initrd? I didn't think it did but I might be wrong.

So maybe a solution to this is to delay that cleanup until after
initrd drivers have a chance to load. Of course it is not possible to
delay it indefinitely (like for disk based loading) but delaying over
initrd is a fixed limit.


>
> From the point of view of kernel once it has handed over to init in
> initrd the boot is finished. The init is normal userspace running off
> normal filesystem backed by a device-specific driver (initrd).
>
> That some systems do not continue to run off this filesystem
> indefinitely and in fact go out of their way to expunge the initrd
> filesystem and reclaim its resources by exercising some syscalls
> specifically devised for that use case is not relevant to the kernel.
> It cannot know when the userspace considers the boot finished enough.
> Sometimes even manual steps are required to finish booting when the
> automatic scripts fail.
>
> simplefb as early console is meant exactly for diagnosing and fixing
> such failures in absence of an uart.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 2 October 2014 14:56, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> ...
>>>>>>>> We've been over all this again and again and again.
>>>>>>>>
>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>
>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>
>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>> and everything will just work.
>>>>>>>>
>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>
>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>
>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>
>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>
>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>> running until HW specific driver is in place, but also to have early console
>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>> won't have video output until quite late into the boot process.
>>>>
>>>> You need both.
>>>>
>>>> 1) temporary early boot console -- this is nothing but an address in
>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>> process -- the same thing happens with the early printk UART driver.
>>>> EARLYPRINTK on the command line enables this.
>>>>
>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>> soon as possible. The same thing happens with the real UART driver for
>>>> the console. CONSOLE= on the command line causes the transition. There
>>>> is an API in the kernel to do this transition, I believe it is called
>>>> set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>>
>> Trying to indefinitely extend the life of the earlyprintk or
>> earlyframeuffer is what causes problems.  Doing that forces you to
>> basically turn them into device specific drivers which do things like
>> claiming device specific resources and gaining device specific
>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>
>
> No. When initrd is running boot has already finished as far as kernel
> is concerned.
>
> And you have to extend the life of the simplefb from the time boot has
> finished through the time kernel mounts initrd (or other root) and
> hands over to userspace found on the initrd, through the time this
> userspace searches for the kms driver and until the time it has
> finally loaded if that ever succeeds.

Does the clock and regulator cleanup happen before drivers can load
off from initrd? I didn't think it did but I might be wrong.

So maybe a solution to this is to delay that cleanup until after
initrd drivers have a chance to load. Of course it is not possible to
delay it indefinitely (like for disk based loading) but delaying over
initrd is a fixed limit.


>
> From the point of view of kernel once it has handed over to init in
> initrd the boot is finished. The init is normal userspace running off
> normal filesystem backed by a device-specific driver (initrd).
>
> That some systems do not continue to run off this filesystem
> indefinitely and in fact go out of their way to expunge the initrd
> filesystem and reclaim its resources by exercising some syscalls
> specifically devised for that use case is not relevant to the kernel.
> It cannot know when the userspace considers the boot finished enough.
> Sometimes even manual steps are required to finish booting when the
> automatic scripts fail.
>
> simplefb as early console is meant exactly for diagnosing and fixing
> such failures in absence of an uart.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:34 PM, jonsmirl@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> ...
>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>
>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>
>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>
>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>> and everything will just work.
>>>>>>>>>
>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>
>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>
>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>
>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>
>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>> won't have video output until quite late into the boot process.
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>>
>>> Trying to indefinitely extend the life of the earlyprintk or
>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>> basically turn them into device specific drivers which do things like
>>> claiming device specific resources and gaining device specific
>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>
>>
>> No. When initrd is running boot has already finished as far as kernel
>> is concerned.
>>
>> And you have to extend the life of the simplefb from the time boot has
>> finished through the time kernel mounts initrd (or other root) and
>> hands over to userspace found on the initrd, through the time this
>> userspace searches for the kms driver and until the time it has
>> finally loaded if that ever succeeds.
> 
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes the cleanup happens before the first userspace process starts, be
that the fake /sbin/init from the initrd, or the real /sbin/init if
no initrd is used.

> So maybe a solution to this is to delay that cleanup until after
> initrd drivers have a chance to load. Of course it is not possible to
> delay it indefinitely (like for disk based loading) but delaying over
> initrd is a fixed limit.

And delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.

So the boot will continue normally with a black screen, and things are
still impossible to debug.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 03:34 PM, jonsmirl at gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>> On 2 October 2014 14:56, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> ...
>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>
>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>
>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>
>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>> and everything will just work.
>>>>>>>>>
>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>
>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>
>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>
>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>
>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>> won't have video output until quite late into the boot process.
>>>>>
>>>>> You need both.
>>>>>
>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>> process -- the same thing happens with the early printk UART driver.
>>>>> EARLYPRINTK on the command line enables this.
>>>>>
>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>> set_console() but it's been a while.
>>>>
>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>>
>>> Trying to indefinitely extend the life of the earlyprintk or
>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>> basically turn them into device specific drivers which do things like
>>> claiming device specific resources and gaining device specific
>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>
>>
>> No. When initrd is running boot has already finished as far as kernel
>> is concerned.
>>
>> And you have to extend the life of the simplefb from the time boot has
>> finished through the time kernel mounts initrd (or other root) and
>> hands over to userspace found on the initrd, through the time this
>> userspace searches for the kms driver and until the time it has
>> finally loaded if that ever succeeds.
> 
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes the cleanup happens before the first userspace process starts, be
that the fake /sbin/init from the initrd, or the real /sbin/init if
no initrd is used.

> So maybe a solution to this is to delay that cleanup until after
> initrd drivers have a chance to load. Of course it is not possible to
> delay it indefinitely (like for disk based loading) but delaying over
> initrd is a fixed limit.

And delaying over the initrd is not helpful. Not having the real driver
load for whatever reasons, is not necessarily a boot blocking event,
and if it us just missing will not lead to any error messages.

So the boot will continue normally with a black screen, and things are
still impossible to debug.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 9:40 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:34 PM, jonsmirl@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>>> On 2 October 2014 14:56, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl@gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl@gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> ...
>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>
>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>
>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>
>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>> and everything will just work.
>>>>>>>>>>
>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>
>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>
>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>
>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>
>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>> won't have video output until quite late into the boot process.
>>>>>>
>>>>>> You need both.
>>>>>>
>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>
>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>> set_console() but it's been a while.
>>>>>
>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>
>>>> No, that is where you get into trouble. The device specific driver has
>>>> to go onto initrd where it can be loaded as early in the boot process
>>>> as possible.
>>>>
>>>> Trying to indefinitely extend the life of the earlyprintk or
>>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>>> basically turn them into device specific drivers which do things like
>>>> claiming device specific resources and gaining device specific
>>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>>
>>>
>>> No. When initrd is running boot has already finished as far as kernel
>>> is concerned.
>>>
>>> And you have to extend the life of the simplefb from the time boot has
>>> finished through the time kernel mounts initrd (or other root) and
>>> hands over to userspace found on the initrd, through the time this
>>> userspace searches for the kms driver and until the time it has
>>> finally loaded if that ever succeeds.
>>
>> Does the clock and regulator cleanup happen before drivers can load
>> off from initrd? I didn't think it did but I might be wrong.
>
> Yes the cleanup happens before the first userspace process starts, be
> that the fake /sbin/init from the initrd, or the real /sbin/init if
> no initrd is used.

Does that init have to be running to get device drivers off from
initrd? I thought the kernel was able to load them directly from
initrd earlier.


>
>> So maybe a solution to this is to delay that cleanup until after
>> initrd drivers have a chance to load. Of course it is not possible to
>> delay it indefinitely (like for disk based loading) but delaying over
>> initrd is a fixed limit.
>
> And delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug.
>
> Regards,
>
> Hans
>



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:40 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/02/2014 03:34 PM, jonsmirl at gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek <hramrach@gmail.com> wrote:
>>> On 2 October 2014 14:56, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/02/2014 02:22 PM, jonsmirl at gmail.com wrote:
>>>>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>>>>>>> On 10/01/2014 11:54 AM, jonsmirl at gmail.com wrote:
>>>>>>>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>> ...
>>>>>>>>>> We've been over all this again and again and again.
>>>>>>>>>>
>>>>>>>>>> AAAARRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!
>>>>>>>>>>
>>>>>>>>>> All solutions provided sofar are both tons more complicated, then the
>>>>>>>>>> simple solution of simply having the simplefb dt node declare which
>>>>>>>>>> clocks it needs. And to make things worse all of them sofar have
>>>>>>>>>> unresolved issues (due to their complexity mostly).
>>>>>>>>>>
>>>>>>>>>> With the clocks in the simplefb node, then all a real driver has to do,
>>>>>>>>>> is claim those same clocks before unregistering the simplefb driver,
>>>>>>>>>> and everything will just work.
>>>>>>>>>>
>>>>>>>>>> Yet we've been discussing this for months, all because of some
>>>>>>>>>> vague worries from Thierry, and *only* from Thierry that this will
>>>>>>>>>> make simplefb less generic / not abstract enough, while a simple
>>>>>>>>>> generic clocks property is about as generic as things come.
>>>>>>>>
>>>>>>>> Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing:
>>>>>>>>
>>>>>>>> As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody
>>>>>>>> other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind.
>>>>>>>>
>>>>>>>> BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow.
>>>>>>>
>>>>>>> The whole reason why we want to use simplefb is not just to get things
>>>>>>> running until HW specific driver is in place, but also to have early console
>>>>>>> output (to help debugging boot problems on devices without a serial console),
>>>>>>> in a world where most video drivers are build as loadable modules, so we
>>>>>>> won't have video output until quite late into the boot process.
>>>>>>
>>>>>> You need both.
>>>>>>
>>>>>> 1) temporary early boot console -- this is nothing but an address in
>>>>>> RAM and the x/y layout. The character set from framebuffer is built
>>>>>> into the kernel.  The parallel to this is early-printk and how it uses
>>>>>> the UARTs without interrupts. This console vaporizes late in the boot
>>>>>> process -- the same thing happens with the early printk UART driver.
>>>>>> EARLYPRINTK on the command line enables this.
>>>>>>
>>>>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>>>>> soon as possible. The same thing happens with the real UART driver for
>>>>>> the console. CONSOLE= on the command line causes the transition. There
>>>>>> is an API in the kernel to do this transition, I believe it is called
>>>>>> set_console() but it's been a while.
>>>>>
>>>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>>>
>>>> No, that is where you get into trouble. The device specific driver has
>>>> to go onto initrd where it can be loaded as early in the boot process
>>>> as possible.
>>>>
>>>> Trying to indefinitely extend the life of the earlyprintk or
>>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>>> basically turn them into device specific drivers which do things like
>>>> claiming device specific resources and gaining device specific
>>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>>
>>>
>>> No. When initrd is running boot has already finished as far as kernel
>>> is concerned.
>>>
>>> And you have to extend the life of the simplefb from the time boot has
>>> finished through the time kernel mounts initrd (or other root) and
>>> hands over to userspace found on the initrd, through the time this
>>> userspace searches for the kms driver and until the time it has
>>> finally loaded if that ever succeeds.
>>
>> Does the clock and regulator cleanup happen before drivers can load
>> off from initrd? I didn't think it did but I might be wrong.
>
> Yes the cleanup happens before the first userspace process starts, be
> that the fake /sbin/init from the initrd, or the real /sbin/init if
> no initrd is used.

Does that init have to be running to get device drivers off from
initrd? I thought the kernel was able to load them directly from
initrd earlier.


>
>> So maybe a solution to this is to delay that cleanup until after
>> initrd drivers have a chance to load. Of course it is not possible to
>> delay it indefinitely (like for disk based loading) but delaying over
>> initrd is a fixed limit.
>
> And delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
>
> So the boot will continue normally with a black screen, and things are
> still impossible to debug.
>
> Regards,
>
> Hans
>



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes

drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes

drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> Does the clock and regulator cleanup happen before drivers can load
>> off from initrd? I didn't think it did but I might be wrong.
>
> Yes
>
> drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
> drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
> drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

I think this is the basic problem, we need to open a window where
drivers can be loaded before the clock/regulator clean up happens.
That window needs to be fixed length (ie Ramdisk based loading).

This is a core problem in a multi-architecture kernel, we need to get
the device specific drivers loaded before this clean up happens.



>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Oct 2, 2014 at 3:34 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> Does the clock and regulator cleanup happen before drivers can load
>> off from initrd? I didn't think it did but I might be wrong.
>
> Yes
>
> drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
> drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
> drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

I think this is the basic problem, we need to open a window where
drivers can be loaded before the clock/regulator clean up happens.
That window needs to be fixed length (ie Ramdisk based loading).

This is a core problem in a multi-architecture kernel, we need to get
the device specific drivers loaded before this clean up happens.



>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 2:22 PM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.

JFYI, the early serial console can also vanish, even very early in the boot
process, before the unused clocks are disabled.
Cfr. http://marc.info/?l=linux-sh&m\x141227657322649&w=2

So there's no safety in this world without calling clk_prepare_enable().

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 2:22 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.

JFYI, the early serial console can also vanish, even very early in the boot
process, before the unused clocks are disabled.
Cfr. http://marc.info/?l=linux-sh&m=141227657322649&w=2

So there's no safety in this world without calling clk_prepare_enable().

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 10/02/2014 12:42 AM, Hans de Goede wrote:
...
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

That's a very different use-case than what was originally envisaged.

...
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?

I have no issue with you being the maintainer.

I would suggest you track down whoever it was that was involved in the 
original discussion and objected to simplefb performing resource 
management, and get their explicit ack for the addition of 
clocks/regulators/... to it. But, that's just a suggestion.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Stephen Warren]

On 10/02/2014 12:42 AM, Hans de Goede wrote:
...
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

That's a very different use-case than what was originally envisaged.

...
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?

I have no issue with you being the maintainer.

I would suggest you track down whoever it was that was involved in the 
original discussion and objected to simplefb performing resource 
management, and get their explicit ack for the addition of 
clocks/regulators/... to it. But, that's just a suggestion.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 05:49 PM, Stephen Warren wrote:
> On 10/02/2014 12:42 AM, Hans de Goede wrote:
> ...
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
> 
> That's a very different use-case than what was originally envisaged.

I realize that, it is always amazing what sort of uses code finds once it is
out there in the wild :)

> 
> ...
>> You indicate that you don't have the time for this discussion, and I note that
>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>> my responsibility (and in my own benefit) to stop this from growing into
>> a monster ?
> 
> I have no issue with you being the maintainer.

Great, I'll send a patch for MAINTAINERS for this then.

> I would suggest you track down whoever it was that was involved in the original discussion and objected to simplefb performing resource management, and get their explicit ack for the addition of clocks/regulators/... to it. But, that's just a suggestion.

I appreciate the suggestion, but various people involved have been discussing this
for over a month now. All arguments in favor and against have been made many times
now, and I doubt that those people (in sofar as they are not already involved in
the discussion) will have anything new to add.

IMHO we've come at a point here where a decision needs to be made how to deal with
this, because any decision, is better then no decision (and thus no progress) at all.

I fully commit myself to actively maintain simplefb, and deal with any fallout, for
the foreseeable future.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 10/02/2014 05:49 PM, Stephen Warren wrote:
> On 10/02/2014 12:42 AM, Hans de Goede wrote:
> ...
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
> 
> That's a very different use-case than what was originally envisaged.

I realize that, it is always amazing what sort of uses code finds once it is
out there in the wild :)

> 
> ...
>> You indicate that you don't have the time for this discussion, and I note that
>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>> my responsibility (and in my own benefit) to stop this from growing into
>> a monster ?
> 
> I have no issue with you being the maintainer.

Great, I'll send a patch for MAINTAINERS for this then.

> I would suggest you track down whoever it was that was involved in the original discussion and objected to simplefb performing resource management, and get their explicit ack for the addition of clocks/regulators/... to it. But, that's just a suggestion.

I appreciate the suggestion, but various people involved have been discussing this
for over a month now. All arguments in favor and against have been made many times
now, and I doubt that those people (in sofar as they are not already involved in
the discussion) will have anything new to add.

IMHO we've come at a point here where a decision needs to be made how to deal with
this, because any decision, is better then no decision (and thus no progress) at all.

I fully commit myself to actively maintain simplefb, and deal with any fallout, for
the foreseeable future.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On 03/10/14 14:16, Hans de Goede wrote:

>>> You indicate that you don't have the time for this discussion, and I note that
>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>> my responsibility (and in my own benefit) to stop this from growing into
>>> a monster ?
>>
>> I have no issue with you being the maintainer.
> 
> Great, I'll send a patch for MAINTAINERS for this then.

In that case, could you, as the maintainer, summarize the plans and/or
biggest issues for simplefb? =)

I've been planning to read this monster thread, but I just haven't found
time.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Tomi Valkeinen]

On 03/10/14 14:16, Hans de Goede wrote:

>>> You indicate that you don't have the time for this discussion, and I note that
>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>> my responsibility (and in my own benefit) to stop this from growing into
>>> a monster ?
>>
>> I have no issue with you being the maintainer.
> 
> Great, I'll send a patch for MAINTAINERS for this then.

In that case, could you, as the maintainer, summarize the plans and/or
biggest issues for simplefb? =)

I've been planning to read this monster thread, but I just haven't found
time.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141003/a28c843c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi Tomi,

On 10/03/2014 01:45 PM, Tomi Valkeinen wrote:
> On 03/10/14 14:16, Hans de Goede wrote:
> 
>>>> You indicate that you don't have the time for this discussion, and I note that
>>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>>> my responsibility (and in my own benefit) to stop this from growing into
>>>> a monster ?
>>>
>>> I have no issue with you being the maintainer.
>>
>> Great, I'll send a patch for MAINTAINERS for this then.
> 
> In that case, could you, as the maintainer, summarize the plans and/or
> biggest issues for simplefb? =)
> 
> I've been planning to read this monster thread, but I just haven't found
> time.

See the cover letter of the patch-set I've just send.

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi Tomi,

On 10/03/2014 01:45 PM, Tomi Valkeinen wrote:
> On 03/10/14 14:16, Hans de Goede wrote:
> 
>>>> You indicate that you don't have the time for this discussion, and I note that
>>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
>>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
>>>> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
>>>> my responsibility (and in my own benefit) to stop this from growing into
>>>> a monster ?
>>>
>>> I have no issue with you being the maintainer.
>>
>> Great, I'll send a patch for MAINTAINERS for this then.
> 
> In that case, could you, as the maintainer, summarize the plans and/or
> biggest issues for simplefb? =)
> 
> I've been planning to read this monster thread, but I just haven't found
> time.

See the cover letter of the patch-set I've just send.

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On Wed, Oct 01, 2014 at 09:41:40AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:

> > No, you don't.  It's only if you start describing the regulators in the
> > PMIC in DT that you run into problems.  Unconfigured regulators won't be
> > touched.

> Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> omit the description of the regulators that it exposes. Unless the
> regulators are truly unused, as in not connected to any peripherals.

Well, if one does decide to add a description of a regulator which is in
use but which hasn't yet been hooked up to users for some reason then it
needs to be marked as always on.

> > > So unless firmware is updated at the same time, regulators will get
> > > disabled because they are unused.

> > That won't happen unless the regulators are explicitly described, if
> > they are described as unused then this will of course happen.

> With described as unused you mean they have a node in DT, so constraints
> are applied and all that, but no driver actually uses them?

Yes.

> The fundamental issue is that if we start describing simplefb nodes with
> an incomplete set of resources then we're bound to run into problems
> where it'll break once these new resources are described in the DTS. If
> the simplefb node was described in the DTS then this would be less of a
> problem because the resources could be added to the simplefb node at the
> same time.

I'm not sure I follow this.  If we add descriptions of new resources
then it shouldn't be hard to also add information about their use (or
that their description is incomplete) at the same time.

> However given that simplefb is supposed to be generated by firmware this
> is no longer possible. It will inevitably break unless you upgrade the
> DTB and the firmware at the same time. And it was already decided long
> ago that upgrading the firmware should never be a requirement for
> keeping things working.

> I don't see any way to prevent that other than ignoring the resources in
> simplefb completely.

One of the approaches that was being talked about was having a
placeholder in DT that the firmware fills in rather than having to
create the node from whole cloth each time, that makes life a lot
easier.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Wed, Oct 01, 2014 at 09:41:40AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote:

> > No, you don't.  It's only if you start describing the regulators in the
> > PMIC in DT that you run into problems.  Unconfigured regulators won't be
> > touched.

> Okay, that's what I meant. It seems rather odd to add a PMIC DT node but
> omit the description of the regulators that it exposes. Unless the
> regulators are truly unused, as in not connected to any peripherals.

Well, if one does decide to add a description of a regulator which is in
use but which hasn't yet been hooked up to users for some reason then it
needs to be marked as always on.

> > > So unless firmware is updated at the same time, regulators will get
> > > disabled because they are unused.

> > That won't happen unless the regulators are explicitly described, if
> > they are described as unused then this will of course happen.

> With described as unused you mean they have a node in DT, so constraints
> are applied and all that, but no driver actually uses them?

Yes.

> The fundamental issue is that if we start describing simplefb nodes with
> an incomplete set of resources then we're bound to run into problems
> where it'll break once these new resources are described in the DTS. If
> the simplefb node was described in the DTS then this would be less of a
> problem because the resources could be added to the simplefb node at the
> same time.

I'm not sure I follow this.  If we add descriptions of new resources
then it shouldn't be hard to also add information about their use (or
that their description is incomplete) at the same time.

> However given that simplefb is supposed to be generated by firmware this
> is no longer possible. It will inevitably break unless you upgrade the
> DTB and the firmware at the same time. And it was already decided long
> ago that upgrading the firmware should never be a requirement for
> keeping things working.

> I don't see any way to prevent that other than ignoring the resources in
> simplefb completely.

One of the approaches that was being talked about was having a
placeholder in DT that the firmware fills in rather than having to
create the node from whole cloth each time, that makes life a lot
easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/a63435f7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 9293 bytes --]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > [...]
> > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > firmware has set up, which is the only reason why it will work for many
> > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > of information needed to draw something into the framebuffer. Also note
> > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > but needs to be dynamically generated by firmware at runtime.
> > > > 
> > > > Which makes the whole even simpler, since the firmware already knows
> > > > all about which clocks it had to enable.
> > > 
> > > It makes things very complicated in the firmware because it now needs to
> > > be able to generate DTB content that we would otherwise be able to do
> > > much easier with a text editor.
> > 
> > Didn't you just say that it was dynamically generated at runtime? So
> > we can just ignore the "text editor" case.
> 
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
> 
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
> 
> > > Why do you think what I proposed isn't going to work or be reliable?
> > > I don't see any arguments in the thread that would imply that.
> > 
> > The fact that it broke in the first place?
> 
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.

This one *is* backward compatible. It doesn't even change the simplefb
behaviour, compared to what it was doing before, if you don't have
this clocks property. What can be a more reasonable default that the
way it used to behave?

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.
> 
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.
>
> And the same will continue to happen for every new type of resource
> you're going to add.

Sure, we can add any resources we will need. Regulators, reset lines,
pm domains, allocated memory, but I'm not really sure this is what you
want, right?

And if you don't do it, you end up in situations where you have to
tell your users "disable the regulator driver in order for your
display to work".
 
> > > > > So how about instead of requiring resources to be explicitly claimed we
> > > > > introduce something like the below patch? The intention being to give
> > > > > "firmware device" drivers a way of signalling to the clock framework
> > > > > that they need rely on clocks set up by firmware and when they no longer
> > > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > > drivers to determine the time when unused clocks are really unused. It
> > > > > will of course only work when used correctly by drivers. For the case of
> > > > > simplefb I'd expect its .probe() implementation to call the new
> > > > > clk_ignore_unused() function and once it has handed over control of the
> > > > > display hardware to the real driver it can call clk_unignore_unused() to
> > > > > signal that all unused clocks that it cares about have now been claimed.
> > > > > This is "reference counted" and can therefore be used by more than a
> > > > > single driver if necessary. Similar functionality could be added for
> > > > > other resource subsystems as needed.
> > > > 
> > > > So, just to be clear, instead of doing a generic clk_get and
> > > > clk_prepare_enable, you're willing to do a just as much generic
> > > > clk_ignore_unused call?
> > > 
> > > Yes.
> > > 
> > > > How is that less generic?
> > > 
> > > It's more generic. That's the whole point.
> > > 
> > > The difference is that with the solution I proposed we don't have to
> > > keep track of all the resources. We know that firmware has set them up
> > > and we know that a real driver will properly take them over at some
> > > point
> > 
> > You keep saying that... and you know that you can't make this
> > assumption.
> 
> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to
> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.

This is a WiP. And I really have the feeling it will be written,
reviewed and merged before we can have the "dirty hack" working.

> > > > You know that you are going to call that for regulator, reset, power
> > > > domains, just as you would have needed to with the proper API, unless
> > > > that with this kind of solution, you would have to modify *every*
> > > > framework that might interact with any resource involved in getting
> > > > simplefb running?
> > > 
> > > We have to add handling for every kind of resource either way. Also if
> > > this evolves into a common pattern we can easily wrap it up in a single
> > > function call.
> > 
> > Unless that in one case, we already have everything needed to handle
> > everything properly, and in another, you keep hacking more and more
> > into the involved frameworks.
> 
> This is a fundamental issue that we are facing and I'm trying to come up
> with a solution that is future-proof and will work for drivers other
> than simplefb.
> 
> Just because we currently lack this functionality doesn't make it a hack
> trying to add it.

Or maybe it's just showing that the trend to rely more and more on the
firmware is a bad idea?

I really start to consider adding a sunxi-uboot-fb, that would just
duplicate the source code of simplefb but also taking the
clocks. Somehow, I feel like it will be easier (and definitely less of
a hack than using the generic common clock API).

> > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > your clock to be shut down as a side effect of a later clk_disable
> > > > call from another driver.
> > > 
> > > If we need to prevent that, then that's something that could be fixed,
> > > too.
> > 
> > See, you keep hacking it more...
> 
> If you don't see this as a problem that exists beyond simplefb then I
> would of course not expect you to think that anything needs fixing.

Then please point me to something else that needs fixing, so that I
can see the whole picture.

> > > But both this and the other thread at least agree on the fact that
> > > simplefb is a shim driver that's going to be replaced by something real
> > > at some point
> > 
> > I think our definition of "at some point" diverges. Yours seem to be
> > "at some point during the boot process", which might not even happen
> > in some platforms (or at least in the foreseeable kernel releases).
> 
> Then instead of hacking existing drivers to work on your particular
> platform you should start looking into hacking your platform drivers to
> cope with the lack of a proper display driver. Or alternatively spend
> the time getting a proper display driver merged.
> 
> Whether simplefb is used as primary framebuffer or just during only boot
> until hand-off to a real driver, it still remains a stop-gap solution.

Then really, simplefb deserves a more appropriate name. Like
uselessfb, tegrafb, DONOTUSEITYOUSTUPIDDEVfb or whatever makes it not
look generic.

> > > so hopefully concurrent users aren't the problem because that would
> > > cause the real driver to break too.
> > > 
> > > Also note that if some other driver could call clk_disable() it could
> > > just as easily call clk_set_rate() and break simplefb.
> > 
> > This is not true, see my other reply.
> 
> If you mean that you could register a clock notifier to prevent clock
> changes, then that's going to lead to other drivers failing since they
> can now no longer set the rate that they need.

But they can recover. Something that simplefb cannot do.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > [...]
> > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > firmware has set up, which is the only reason why it will work for many
> > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > of information needed to draw something into the framebuffer. Also note
> > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > but needs to be dynamically generated by firmware at runtime.
> > > > 
> > > > Which makes the whole even simpler, since the firmware already knows
> > > > all about which clocks it had to enable.
> > > 
> > > It makes things very complicated in the firmware because it now needs to
> > > be able to generate DTB content that we would otherwise be able to do
> > > much easier with a text editor.
> > 
> > Didn't you just say that it was dynamically generated at runtime? So
> > we can just ignore the "text editor" case.
> 
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
> 
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
> 
> > > Why do you think what I proposed isn't going to work or be reliable?
> > > I don't see any arguments in the thread that would imply that.
> > 
> > The fact that it broke in the first place?
> 
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.

This one *is* backward compatible. It doesn't even change the simplefb
behaviour, compared to what it was doing before, if you don't have
this clocks property. What can be a more reasonable default that the
way it used to behave?

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.
> 
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.
>
> And the same will continue to happen for every new type of resource
> you're going to add.

Sure, we can add any resources we will need. Regulators, reset lines,
pm domains, allocated memory, but I'm not really sure this is what you
want, right?

And if you don't do it, you end up in situations where you have to
tell your users "disable the regulator driver in order for your
display to work".
 
> > > > > So how about instead of requiring resources to be explicitly claimed we
> > > > > introduce something like the below patch? The intention being to give
> > > > > "firmware device" drivers a way of signalling to the clock framework
> > > > > that they need rely on clocks set up by firmware and when they no longer
> > > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > > drivers to determine the time when unused clocks are really unused. It
> > > > > will of course only work when used correctly by drivers. For the case of
> > > > > simplefb I'd expect its .probe() implementation to call the new
> > > > > clk_ignore_unused() function and once it has handed over control of the
> > > > > display hardware to the real driver it can call clk_unignore_unused() to
> > > > > signal that all unused clocks that it cares about have now been claimed.
> > > > > This is "reference counted" and can therefore be used by more than a
> > > > > single driver if necessary. Similar functionality could be added for
> > > > > other resource subsystems as needed.
> > > > 
> > > > So, just to be clear, instead of doing a generic clk_get and
> > > > clk_prepare_enable, you're willing to do a just as much generic
> > > > clk_ignore_unused call?
> > > 
> > > Yes.
> > > 
> > > > How is that less generic?
> > > 
> > > It's more generic. That's the whole point.
> > > 
> > > The difference is that with the solution I proposed we don't have to
> > > keep track of all the resources. We know that firmware has set them up
> > > and we know that a real driver will properly take them over at some
> > > point
> > 
> > You keep saying that... and you know that you can't make this
> > assumption.
> 
> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to
> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.

This is a WiP. And I really have the feeling it will be written,
reviewed and merged before we can have the "dirty hack" working.

> > > > You know that you are going to call that for regulator, reset, power
> > > > domains, just as you would have needed to with the proper API, unless
> > > > that with this kind of solution, you would have to modify *every*
> > > > framework that might interact with any resource involved in getting
> > > > simplefb running?
> > > 
> > > We have to add handling for every kind of resource either way. Also if
> > > this evolves into a common pattern we can easily wrap it up in a single
> > > function call.
> > 
> > Unless that in one case, we already have everything needed to handle
> > everything properly, and in another, you keep hacking more and more
> > into the involved frameworks.
> 
> This is a fundamental issue that we are facing and I'm trying to come up
> with a solution that is future-proof and will work for drivers other
> than simplefb.
> 
> Just because we currently lack this functionality doesn't make it a hack
> trying to add it.

Or maybe it's just showing that the trend to rely more and more on the
firmware is a bad idea?

I really start to consider adding a sunxi-uboot-fb, that would just
duplicate the source code of simplefb but also taking the
clocks. Somehow, I feel like it will be easier (and definitely less of
a hack than using the generic common clock API).

> > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > your clock to be shut down as a side effect of a later clk_disable
> > > > call from another driver.
> > > 
> > > If we need to prevent that, then that's something that could be fixed,
> > > too.
> > 
> > See, you keep hacking it more...
> 
> If you don't see this as a problem that exists beyond simplefb then I
> would of course not expect you to think that anything needs fixing.

Then please point me to something else that needs fixing, so that I
can see the whole picture.

> > > But both this and the other thread at least agree on the fact that
> > > simplefb is a shim driver that's going to be replaced by something real
> > > at some point
> > 
> > I think our definition of "at some point" diverges. Yours seem to be
> > "at some point during the boot process", which might not even happen
> > in some platforms (or at least in the foreseeable kernel releases).
> 
> Then instead of hacking existing drivers to work on your particular
> platform you should start looking into hacking your platform drivers to
> cope with the lack of a proper display driver. Or alternatively spend
> the time getting a proper display driver merged.
> 
> Whether simplefb is used as primary framebuffer or just during only boot
> until hand-off to a real driver, it still remains a stop-gap solution.

Then really, simplefb deserves a more appropriate name. Like
uselessfb, tegrafb, DONOTUSEITYOUSTUPIDDEVfb or whatever makes it not
look generic.

> > > so hopefully concurrent users aren't the problem because that would
> > > cause the real driver to break too.
> > > 
> > > Also note that if some other driver could call clk_disable() it could
> > > just as easily call clk_set_rate() and break simplefb.
> > 
> > This is not true, see my other reply.
> 
> If you mean that you could register a clock notifier to prevent clock
> changes, then that's going to lead to other drivers failing since they
> can now no longer set the rate that they need.

But they can recover. Something that simplefb cannot do.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/0bf9ed5d/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?
> 
> I really start to consider adding a sunxi-uboot-fb, that would just
> duplicate the source code of simplefb but also taking the
> clocks. Somehow, I feel like it will be easier (and definitely less of
> a hack than using the generic common clock API).

In the 2nd round of this discussion, i stated that another fb or even a 
drm driver altogether seemed to be the sensible way out of this mess.

I suggest drm_rescue.

> > Then instead of hacking existing drivers to work on your particular
> > platform you should start looking into hacking your platform drivers to
> > cope with the lack of a proper display driver. Or alternatively spend
> > the time getting a proper display driver merged.
> > 
> > Whether simplefb is used as primary framebuffer or just during only boot
> > until hand-off to a real driver, it still remains a stop-gap solution.
> 
> Then really, simplefb deserves a more appropriate name. Like
> uselessfb, tegrafb, DONOTUSEITYOUSTUPIDDEVfb or whatever makes it not
> look generic.

Very early on, now almost two months back, i used the word "denialfb".
rpifb is the real name of this thing though, but then the dt binding 
names would have to change and whatnot.

I don't get the resistance, at least not from a technical point of view. 
And i do not care enough to get properly involved in this pointless and 
endless discussion. drm_rescue it is.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?
> 
> I really start to consider adding a sunxi-uboot-fb, that would just
> duplicate the source code of simplefb but also taking the
> clocks. Somehow, I feel like it will be easier (and definitely less of
> a hack than using the generic common clock API).

In the 2nd round of this discussion, i stated that another fb or even a 
drm driver altogether seemed to be the sensible way out of this mess.

I suggest drm_rescue.

> > Then instead of hacking existing drivers to work on your particular
> > platform you should start looking into hacking your platform drivers to
> > cope with the lack of a proper display driver. Or alternatively spend
> > the time getting a proper display driver merged.
> > 
> > Whether simplefb is used as primary framebuffer or just during only boot
> > until hand-off to a real driver, it still remains a stop-gap solution.
> 
> Then really, simplefb deserves a more appropriate name. Like
> uselessfb, tegrafb, DONOTUSEITYOUSTUPIDDEVfb or whatever makes it not
> look generic.

Very early on, now almost two months back, i used the word "denialfb".
rpifb is the real name of this thing though, but then the dt binding 
names would have to change and whatnot.

I don't get the resistance, at least not from a technical point of view. 
And i do not care enough to get properly involved in this pointless and 
endless discussion. drm_rescue it is.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> 
> In the 2nd round of this discussion, i stated that another fb or even a 
> drm driver altogether seemed to be the sensible way out of this mess.
> 
> I suggest drm_rescue.
> 
> Very early on, now almost two months back, i used the word "denialfb".
> rpifb is the real name of this thing though, but then the dt binding 
> names would have to change and whatnot.
> 
> I don't get the resistance, at least not from a technical point of view. 
> And i do not care enough to get properly involved in this pointless and 
> endless discussion. drm_rescue it is.
> 
> Luc Verhaegen.

So Thierry, let's review what we have achieved here.

1) you keep simplefb absolutely true to the name. Congratulations.
2) Simplefb will only have a single user: the rpi. As the only other 
users i can think of, which does not have a full driver and which does 
not have clocks automatically disabled, are discrete cards. And they do 
not really tend to happen with dt or platform devices.
3) a competing driver will be created, which will do these dt-ishy 
things.
4) it's just a matter of time before the rpi either gets a full driver, 
or switches over to the driver that everyone else is actually using. And 
then the misnomer gets deprecated.

Was that the outcome you were looking for? I think not.

Luc Verhaegen.

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> 
> In the 2nd round of this discussion, i stated that another fb or even a 
> drm driver altogether seemed to be the sensible way out of this mess.
> 
> I suggest drm_rescue.
> 
> Very early on, now almost two months back, i used the word "denialfb".
> rpifb is the real name of this thing though, but then the dt binding 
> names would have to change and whatnot.
> 
> I don't get the resistance, at least not from a technical point of view. 
> And i do not care enough to get properly involved in this pointless and 
> endless discussion. drm_rescue it is.
> 
> Luc Verhaegen.

So Thierry, let's review what we have achieved here.

1) you keep simplefb absolutely true to the name. Congratulations.
2) Simplefb will only have a single user: the rpi. As the only other 
users i can think of, which does not have a full driver and which does 
not have clocks automatically disabled, are discrete cards. And they do 
not really tend to happen with dt or platform devices.
3) a competing driver will be created, which will do these dt-ishy 
things.
4) it's just a matter of time before the rpi either gets a full driver, 
or switches over to the driver that everyone else is actually using. And 
then the misnomer gets deprecated.

Was that the outcome you were looking for? I think not.

Luc Verhaegen.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:
> On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> > 
> > In the 2nd round of this discussion, i stated that another fb or even a 
> > drm driver altogether seemed to be the sensible way out of this mess.
> > 
> > I suggest drm_rescue.
> > 
> > Very early on, now almost two months back, i used the word "denialfb".
> > rpifb is the real name of this thing though, but then the dt binding 
> > names would have to change and whatnot.
> > 
> > I don't get the resistance, at least not from a technical point of view. 
> > And i do not care enough to get properly involved in this pointless and 
> > endless discussion. drm_rescue it is.
> > 
> > Luc Verhaegen.
> 
> So Thierry, let's review what we have achieved here.
> 
> 1) you keep simplefb absolutely true to the name. Congratulations.
> 2) Simplefb will only have a single user: the rpi. As the only other 
> users i can think of, which does not have a full driver and which does 
> not have clocks automatically disabled, are discrete cards. And they do 
> not really tend to happen with dt or platform devices.
> 3) a competing driver will be created, which will do these dt-ishy 
> things.

You clearly haven't bothered to even try and understand what I wanted to
achieve. If you had you'd realize that creating a competing driver isn't
going to change anything.

> 4) it's just a matter of time before the rpi either gets a full driver, 
> or switches over to the driver that everyone else is actually using. And 
> then the misnomer gets deprecated.
> 
> Was that the outcome you were looking for? I think not.

I had, perhaps naively, expected that you guys would be willing to look
beyond your own nose. You clearly aren't. You've been outright
dismissing any proposals beyond what you originally posted.

You keep bringing up the Raspberry Pi for some reason and suggest that
it is somehow inferior to sunxi. What makes you think it's less entitled
to be supported on Linux than sunxi? I don't care about the Raspberry Pi
and I equally don't care about sunxi. I don't own a Raspberry Pi and I
don't own any Allwinner hardware. What I do care about is Linux and I
want it to work well for all SoCs equally.

Perhaps if you could put aside your crusade against the Raspberry Pi for
just a second you'll realize that we're all on the same team. This isn't
a competition and I'm not trying to put a spoke in your wheel. On the
contrary, I'm actually trying to help you.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:
> On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> > 
> > In the 2nd round of this discussion, i stated that another fb or even a 
> > drm driver altogether seemed to be the sensible way out of this mess.
> > 
> > I suggest drm_rescue.
> > 
> > Very early on, now almost two months back, i used the word "denialfb".
> > rpifb is the real name of this thing though, but then the dt binding 
> > names would have to change and whatnot.
> > 
> > I don't get the resistance, at least not from a technical point of view. 
> > And i do not care enough to get properly involved in this pointless and 
> > endless discussion. drm_rescue it is.
> > 
> > Luc Verhaegen.
> 
> So Thierry, let's review what we have achieved here.
> 
> 1) you keep simplefb absolutely true to the name. Congratulations.
> 2) Simplefb will only have a single user: the rpi. As the only other 
> users i can think of, which does not have a full driver and which does 
> not have clocks automatically disabled, are discrete cards. And they do 
> not really tend to happen with dt or platform devices.
> 3) a competing driver will be created, which will do these dt-ishy 
> things.

You clearly haven't bothered to even try and understand what I wanted to
achieve. If you had you'd realize that creating a competing driver isn't
going to change anything.

> 4) it's just a matter of time before the rpi either gets a full driver, 
> or switches over to the driver that everyone else is actually using. And 
> then the misnomer gets deprecated.
> 
> Was that the outcome you were looking for? I think not.

I had, perhaps naively, expected that you guys would be willing to look
beyond your own nose. You clearly aren't. You've been outright
dismissing any proposals beyond what you originally posted.

You keep bringing up the Raspberry Pi for some reason and suggest that
it is somehow inferior to sunxi. What makes you think it's less entitled
to be supported on Linux than sunxi? I don't care about the Raspberry Pi
and I equally don't care about sunxi. I don't own a Raspberry Pi and I
don't own any Allwinner hardware. What I do care about is Linux and I
want it to work well for all SoCs equally.

Perhaps if you could put aside your crusade against the Raspberry Pi for
just a second you'll realize that we're all on the same team. This isn't
a competition and I'm not trying to put a spoke in your wheel. On the
contrary, I'm actually trying to help you.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/c2c88ef1/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote:
> You keep bringing up the Raspberry Pi for some reason and suggest that
> it is somehow inferior to sunxi. What makes you think it's less entitled
> to be supported on Linux than sunxi? I don't care about the Raspberry Pi
> and I equally don't care about sunxi. I don't own a Raspberry Pi and I
> don't own any Allwinner hardware. What I do care about is Linux and I
> want it to work well for all SoCs equally.
> 
> Perhaps if you could put aside your crusade against the Raspberry Pi for
> just a second you'll realize that we're all on the same team. This isn't
> a competition and I'm not trying to put a spoke in your wheel. On the
> contrary, I'm actually trying to help you.

We've been over this already, and I'll tell you again that you're
getting this wrong.

No platform is more entitled to get merged than another one. I do care
about the Allwinner SoCs, and I care just as much about the broader
Linux support for all the other SoCs, be it from nvidia, samsung or
whatever vendor you can come up with.

But you can't hide the fact that the bcm2835 still has a very limited
clock support, and I really don't know about its clock tree, but I
guess that if the times come when they add a more complete clock
support, they will face the same issue.

If the driver would have been developped initially to create a
framebuffer on the Allwinner SoCs, at a time when we didn't have any
clock support too, calling it only usable on sunxi wouldn't have
shocked me tbh.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote:
> You keep bringing up the Raspberry Pi for some reason and suggest that
> it is somehow inferior to sunxi. What makes you think it's less entitled
> to be supported on Linux than sunxi? I don't care about the Raspberry Pi
> and I equally don't care about sunxi. I don't own a Raspberry Pi and I
> don't own any Allwinner hardware. What I do care about is Linux and I
> want it to work well for all SoCs equally.
> 
> Perhaps if you could put aside your crusade against the Raspberry Pi for
> just a second you'll realize that we're all on the same team. This isn't
> a competition and I'm not trying to put a spoke in your wheel. On the
> contrary, I'm actually trying to help you.

We've been over this already, and I'll tell you again that you're
getting this wrong.

No platform is more entitled to get merged than another one. I do care
about the Allwinner SoCs, and I care just as much about the broader
Linux support for all the other SoCs, be it from nvidia, samsung or
whatever vendor you can come up with.

But you can't hide the fact that the bcm2835 still has a very limited
clock support, and I really don't know about its clock tree, but I
guess that if the times come when they add a more complete clock
support, they will face the same issue.

If the driver would have been developped initially to create a
framebuffer on the Allwinner SoCs, at a time when we didn't have any
clock support too, calling it only usable on sunxi wouldn't have
shocked me tbh.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/302037e7/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

On Tue, Sep 30, 2014 at 10:03:54AM +0200, Maxime Ripard wrote:
> On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote:
> > You keep bringing up the Raspberry Pi for some reason and suggest that
> > it is somehow inferior to sunxi. What makes you think it's less entitled
> > to be supported on Linux than sunxi? I don't care about the Raspberry Pi
> > and I equally don't care about sunxi. I don't own a Raspberry Pi and I
> > don't own any Allwinner hardware. What I do care about is Linux and I
> > want it to work well for all SoCs equally.
> > 
> > Perhaps if you could put aside your crusade against the Raspberry Pi for
> > just a second you'll realize that we're all on the same team. This isn't
> > a competition and I'm not trying to put a spoke in your wheel. On the
> > contrary, I'm actually trying to help you.
> 
> We've been over this already, and I'll tell you again that you're
> getting this wrong.
> 
> No platform is more entitled to get merged than another one. I do care
> about the Allwinner SoCs, and I care just as much about the broader
> Linux support for all the other SoCs, be it from nvidia, samsung or
> whatever vendor you can come up with.

Okay, I'm glad our goals aren't that far apart then. It would be helpful
to stop dragging the Raspberry Pi into this, though, since it isn't at
all relevant.

> But you can't hide the fact that the bcm2835 still has a very limited
> clock support, and I really don't know about its clock tree, but I
> guess that if the times come when they add a more complete clock
> support, they will face the same issue.

This isn't at all relevant. And that's exactly why I think it's good to
hide all the resource management behind firmware. That way it becomes
easy to support any SoC with any firmware.

> If the driver would have been developped initially to create a
> framebuffer on the Allwinner SoCs, at a time when we didn't have any
> clock support too, calling it only usable on sunxi wouldn't have
> shocked me tbh.

The functionality that it provides is still very generic. And the
firmware interface is generic too. It is this abstraction that allows
it to be generic. You on the other hand seem to be arguing that by
making it abstract we've made it less generic.

Abstraction is about hiding details to capture commonality.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 10:03:54AM +0200, Maxime Ripard wrote:
> On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote:
> > You keep bringing up the Raspberry Pi for some reason and suggest that
> > it is somehow inferior to sunxi. What makes you think it's less entitled
> > to be supported on Linux than sunxi? I don't care about the Raspberry Pi
> > and I equally don't care about sunxi. I don't own a Raspberry Pi and I
> > don't own any Allwinner hardware. What I do care about is Linux and I
> > want it to work well for all SoCs equally.
> > 
> > Perhaps if you could put aside your crusade against the Raspberry Pi for
> > just a second you'll realize that we're all on the same team. This isn't
> > a competition and I'm not trying to put a spoke in your wheel. On the
> > contrary, I'm actually trying to help you.
> 
> We've been over this already, and I'll tell you again that you're
> getting this wrong.
> 
> No platform is more entitled to get merged than another one. I do care
> about the Allwinner SoCs, and I care just as much about the broader
> Linux support for all the other SoCs, be it from nvidia, samsung or
> whatever vendor you can come up with.

Okay, I'm glad our goals aren't that far apart then. It would be helpful
to stop dragging the Raspberry Pi into this, though, since it isn't at
all relevant.

> But you can't hide the fact that the bcm2835 still has a very limited
> clock support, and I really don't know about its clock tree, but I
> guess that if the times come when they add a more complete clock
> support, they will face the same issue.

This isn't at all relevant. And that's exactly why I think it's good to
hide all the resource management behind firmware. That way it becomes
easy to support any SoC with any firmware.

> If the driver would have been developped initially to create a
> framebuffer on the Allwinner SoCs, at a time when we didn't have any
> clock support too, calling it only usable on sunxi wouldn't have
> shocked me tbh.

The functionality that it provides is still very generic. And the
firmware interface is generic too. It is this abstraction that allows
it to be generic. You on the other hand seem to be arguing that by
making it abstract we've made it less generic.

Abstraction is about hiding details to capture commonality.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/f91b4889/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:

> 2) Simplefb will only have a single user: the rpi. As the only other 
> users i can think of, which does not have a full driver and which does 
> not have clocks automatically disabled, are discrete cards. And they do 
> not really tend to happen with dt or platform devices.

I thought the goal was for other platforms to use simplefb while waiting
for the real drivers to be loaded (so you can get get console output as
early as possible from a built in driver for example)?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:

> 2) Simplefb will only have a single user: the rpi. As the only other 
> users i can think of, which does not have a full driver and which does 
> not have clocks automatically disabled, are discrete cards. And they do 
> not really tend to happen with dt or platform devices.

I thought the goal was for other platforms to use simplefb while waiting
for the real drivers to be loaded (so you can get get console output as
early as possible from a built in driver for example)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/0e1ccc26/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Tue, Sep 30, 2014 at 8:41 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:
>
>> 2) Simplefb will only have a single user: the rpi. As the only other
>> users i can think of, which does not have a full driver and which does
>> not have clocks automatically disabled, are discrete cards. And they do
>> not really tend to happen with dt or platform devices.
>
> I thought the goal was for other platforms to use simplefb while waiting
> for the real drivers to be loaded (so you can get get console output as
> early as possible from a built in driver for example)?

That is an option that might work. Stop trying to make simplefb work
after the system is fully booted. Instead just let it run until the
clocks get shut off. That allows it to go back to being nothing but a
simple pointer to the video buffer.

Then if you want to keep your display going and don't have a KMS
driver written, whip together a device specific framebuffer driver for
your hardware that does the right thing with the clocks, etc. The
device specific framebuffer driver can load later in the boot process
so that it doesn't have to be built into the kernel. This device
specfic driver matches on a compatible string and knows what to do
with all of the device tree info.

-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Tue, Sep 30, 2014 at 8:41 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:
>
>> 2) Simplefb will only have a single user: the rpi. As the only other
>> users i can think of, which does not have a full driver and which does
>> not have clocks automatically disabled, are discrete cards. And they do
>> not really tend to happen with dt or platform devices.
>
> I thought the goal was for other platforms to use simplefb while waiting
> for the real drivers to be loaded (so you can get get console output as
> early as possible from a built in driver for example)?

That is an option that might work. Stop trying to make simplefb work
after the system is fully booted. Instead just let it run until the
clocks get shut off. That allows it to go back to being nothing but a
simple pointer to the video buffer.

Then if you want to keep your display going and don't have a KMS
driver written, whip together a device specific framebuffer driver for
your hardware that does the right thing with the clocks, etc. The
device specific framebuffer driver can load later in the boot process
so that it doesn't have to be built into the kernel. This device
specfic driver matches on a compatible string and knows what to do
with all of the device tree info.

-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6789 bytes --]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > > [...]
> > > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > > firmware has set up, which is the only reason why it will work for many
> > > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > > of information needed to draw something into the framebuffer. Also note
> > > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > > but needs to be dynamically generated by firmware at runtime.
> > > > > 
> > > > > Which makes the whole even simpler, since the firmware already knows
> > > > > all about which clocks it had to enable.
> > > > 
> > > > It makes things very complicated in the firmware because it now needs to
> > > > be able to generate DTB content that we would otherwise be able to do
> > > > much easier with a text editor.
> > > 
> > > Didn't you just say that it was dynamically generated at runtime? So
> > > we can just ignore the "text editor" case.
> > 
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> > 
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> > 
> > > > Why do you think what I proposed isn't going to work or be reliable?
> > > > I don't see any arguments in the thread that would imply that.
> > > 
> > > The fact that it broke in the first place?
> > 
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> 
> This one *is* backward compatible. It doesn't even change the simplefb
> behaviour, compared to what it was doing before, if you don't have
> this clocks property. What can be a more reasonable default that the
> way it used to behave?

My point is that if we decide not to consider all resources handled by
firmware then we need to go all the way. At that point you start having
problems as evidenced by the Snow example.

> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> > 
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> >
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> Sure, we can add any resources we will need. Regulators, reset lines,
> pm domains, allocated memory, but I'm not really sure this is what you
> want, right?

No it's not what I want. *You* want to add resource management to this
driver. What I'm saying is that if we start adding clocks then we can no
longer say no to resets or regulators or power domains either.

> > > > > You know that you are going to call that for regulator, reset, power
> > > > > domains, just as you would have needed to with the proper API, unless
> > > > > that with this kind of solution, you would have to modify *every*
> > > > > framework that might interact with any resource involved in getting
> > > > > simplefb running?
> > > > 
> > > > We have to add handling for every kind of resource either way. Also if
> > > > this evolves into a common pattern we can easily wrap it up in a single
> > > > function call.
> > > 
> > > Unless that in one case, we already have everything needed to handle
> > > everything properly, and in another, you keep hacking more and more
> > > into the involved frameworks.
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?

If you think it's a bad idea to rely on firmware then you shouldn't be
using simplefb in the first place.

> I really start to consider adding a sunxi-uboot-fb, that would just
> duplicate the source code of simplefb but also taking the
> clocks. Somehow, I feel like it will be easier (and definitely less of
> a hack than using the generic common clock API).

You're not getting it are you? What makes you think sunxi-uboot-fb is
going to be any different? This isn't about a name.

> > > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > > your clock to be shut down as a side effect of a later clk_disable
> > > > > call from another driver.
> > > > 
> > > > If we need to prevent that, then that's something that could be fixed,
> > > > too.
> > > 
> > > See, you keep hacking it more...
> > 
> > If you don't see this as a problem that exists beyond simplefb then I
> > would of course not expect you to think that anything needs fixing.
> 
> Then please point me to something else that needs fixing, so that I
> can see the whole picture.

We've been over this before. I'm tired of having to repeat myself.

> > > > so hopefully concurrent users aren't the problem because that would
> > > > cause the real driver to break too.
> > > > 
> > > > Also note that if some other driver could call clk_disable() it could
> > > > just as easily call clk_set_rate() and break simplefb.
> > > 
> > > This is not true, see my other reply.
> > 
> > If you mean that you could register a clock notifier to prevent clock
> > changes, then that's going to lead to other drivers failing since they
> > can now no longer set the rate that they need.
> 
> But they can recover. Something that simplefb cannot do.

Can they? That's a pretty bold assumption.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > > [...]
> > > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > > firmware has set up, which is the only reason why it will work for many
> > > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > > of information needed to draw something into the framebuffer. Also note
> > > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > > but needs to be dynamically generated by firmware at runtime.
> > > > > 
> > > > > Which makes the whole even simpler, since the firmware already knows
> > > > > all about which clocks it had to enable.
> > > > 
> > > > It makes things very complicated in the firmware because it now needs to
> > > > be able to generate DTB content that we would otherwise be able to do
> > > > much easier with a text editor.
> > > 
> > > Didn't you just say that it was dynamically generated at runtime? So
> > > we can just ignore the "text editor" case.
> > 
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> > 
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> > 
> > > > Why do you think what I proposed isn't going to work or be reliable?
> > > > I don't see any arguments in the thread that would imply that.
> > > 
> > > The fact that it broke in the first place?
> > 
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> 
> This one *is* backward compatible. It doesn't even change the simplefb
> behaviour, compared to what it was doing before, if you don't have
> this clocks property. What can be a more reasonable default that the
> way it used to behave?

My point is that if we decide not to consider all resources handled by
firmware then we need to go all the way. At that point you start having
problems as evidenced by the Snow example.

> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> > 
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> >
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> Sure, we can add any resources we will need. Regulators, reset lines,
> pm domains, allocated memory, but I'm not really sure this is what you
> want, right?

No it's not what I want. *You* want to add resource management to this
driver. What I'm saying is that if we start adding clocks then we can no
longer say no to resets or regulators or power domains either.

> > > > > You know that you are going to call that for regulator, reset, power
> > > > > domains, just as you would have needed to with the proper API, unless
> > > > > that with this kind of solution, you would have to modify *every*
> > > > > framework that might interact with any resource involved in getting
> > > > > simplefb running?
> > > > 
> > > > We have to add handling for every kind of resource either way. Also if
> > > > this evolves into a common pattern we can easily wrap it up in a single
> > > > function call.
> > > 
> > > Unless that in one case, we already have everything needed to handle
> > > everything properly, and in another, you keep hacking more and more
> > > into the involved frameworks.
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?

If you think it's a bad idea to rely on firmware then you shouldn't be
using simplefb in the first place.

> I really start to consider adding a sunxi-uboot-fb, that would just
> duplicate the source code of simplefb but also taking the
> clocks. Somehow, I feel like it will be easier (and definitely less of
> a hack than using the generic common clock API).

You're not getting it are you? What makes you think sunxi-uboot-fb is
going to be any different? This isn't about a name.

> > > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > > your clock to be shut down as a side effect of a later clk_disable
> > > > > call from another driver.
> > > > 
> > > > If we need to prevent that, then that's something that could be fixed,
> > > > too.
> > > 
> > > See, you keep hacking it more...
> > 
> > If you don't see this as a problem that exists beyond simplefb then I
> > would of course not expect you to think that anything needs fixing.
> 
> Then please point me to something else that needs fixing, so that I
> can see the whole picture.

We've been over this before. I'm tired of having to repeat myself.

> > > > so hopefully concurrent users aren't the problem because that would
> > > > cause the real driver to break too.
> > > > 
> > > > Also note that if some other driver could call clk_disable() it could
> > > > just as easily call clk_set_rate() and break simplefb.
> > > 
> > > This is not true, see my other reply.
> > 
> > If you mean that you could register a clock notifier to prevent clock
> > changes, then that's going to lead to other drivers failing since they
> > can now no longer set the rate that they need.
> 
> But they can recover. Something that simplefb cannot do.

Can they? That's a pretty bold assumption.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/07ad3f26/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 7728 bytes --]

On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > > > [...]
> > > > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > > > firmware has set up, which is the only reason why it will work for many
> > > > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > > > of information needed to draw something into the framebuffer. Also note
> > > > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > > > but needs to be dynamically generated by firmware at runtime.
> > > > > > 
> > > > > > Which makes the whole even simpler, since the firmware already knows
> > > > > > all about which clocks it had to enable.
> > > > > 
> > > > > It makes things very complicated in the firmware because it now needs to
> > > > > be able to generate DTB content that we would otherwise be able to do
> > > > > much easier with a text editor.
> > > > 
> > > > Didn't you just say that it was dynamically generated at runtime? So
> > > > we can just ignore the "text editor" case.
> > > 
> > > Perhaps read the sentence again. I said "that we would *otherwise* be
> > > able to do much easier with a text editor.".
> > > 
> > > My point remains that there shouldn't be a need to generate DTB content
> > > of this complexity at all.
> > > 
> > > > > Why do you think what I proposed isn't going to work or be reliable?
> > > > > I don't see any arguments in the thread that would imply that.
> > > > 
> > > > The fact that it broke in the first place?
> > > 
> > > That's exactly the point. And it's going to break again and again as
> > > simplefb is extended with new things. Generally DT bindings should be
> > > backwards compatible. When extended they should provide a way to fall
> > > back to a reasonable default. There's simply no way you can do that
> > > with simplefb.
> > 
> > This one *is* backward compatible. It doesn't even change the simplefb
> > behaviour, compared to what it was doing before, if you don't have
> > this clocks property. What can be a more reasonable default that the
> > way it used to behave?
> 
> My point is that if we decide not to consider all resources handled by
> firmware then we need to go all the way. At that point you start having
> problems as evidenced by the Snow example.

Agreed.

> > > What happened in the Snow example is that regulators that were
> > > previously on would all of a sudden be automatically disabled on boot
> > > because there was now a driver that registered them with a generic
> > > framework.
> > > 
> > > The same thing is going to happen with simplefb for your device. If you
> > > later realize that you need a regulator to keep the panel going, you'll
> > > have to add code to your firmware to populate the corresponding
> > > properties, otherwise the regulator will end up unused and will be
> > > automatically disabled. At the same time you're going to break upstream
> > > for all users of your old firmware because it doesn't add that property
> > > yet.
> > >
> > > And the same will continue to happen for every new type of resource
> > > you're going to add.
> > 
> > Sure, we can add any resources we will need. Regulators, reset lines,
> > pm domains, allocated memory, but I'm not really sure this is what you
> > want, right?
> 
> No it's not what I want. *You* want to add resource management to this
> driver. What I'm saying is that if we start adding clocks then we can no
> longer say no to resets or regulators or power domains either.

Yes, because resource management can be more than just "keep the thing
enabled". It might also be about not modifying anything, just like we
saw for the clocks, but that might also apply to regulators voltage.

And the only way I can think of to deal with that properly is to have
resources management in the driver.

> > > > > > You know that you are going to call that for regulator, reset, power
> > > > > > domains, just as you would have needed to with the proper API, unless
> > > > > > that with this kind of solution, you would have to modify *every*
> > > > > > framework that might interact with any resource involved in getting
> > > > > > simplefb running?
> > > > > 
> > > > > We have to add handling for every kind of resource either way. Also if
> > > > > this evolves into a common pattern we can easily wrap it up in a single
> > > > > function call.
> > > > 
> > > > Unless that in one case, we already have everything needed to handle
> > > > everything properly, and in another, you keep hacking more and more
> > > > into the involved frameworks.
> > > 
> > > This is a fundamental issue that we are facing and I'm trying to come up
> > > with a solution that is future-proof and will work for drivers other
> > > than simplefb.
> > > 
> > > Just because we currently lack this functionality doesn't make it a hack
> > > trying to add it.
> > 
> > Or maybe it's just showing that the trend to rely more and more on the
> > firmware is a bad idea?
> 
> If you think it's a bad idea to rely on firmware then you shouldn't be
> using simplefb in the first place.
> 
> > I really start to consider adding a sunxi-uboot-fb, that would just
> > duplicate the source code of simplefb but also taking the
> > clocks. Somehow, I feel like it will be easier (and definitely less of
> > a hack than using the generic common clock API).
> 
> You're not getting it are you? What makes you think sunxi-uboot-fb is
> going to be any different? This isn't about a name.

At least, we would get to do any binding and resource management we
want. And that's a big win.

> > > > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > > > your clock to be shut down as a side effect of a later clk_disable
> > > > > > call from another driver.
> > > > > 
> > > > > If we need to prevent that, then that's something that could be fixed,
> > > > > too.
> > > > 
> > > > See, you keep hacking it more...
> > > 
> > > If you don't see this as a problem that exists beyond simplefb then I
> > > would of course not expect you to think that anything needs fixing.
> > 
> > Then please point me to something else that needs fixing, so that I
> > can see the whole picture.
> 
> We've been over this before. I'm tired of having to repeat myself.
> 
> > > > > so hopefully concurrent users aren't the problem because that would
> > > > > cause the real driver to break too.
> > > > > 
> > > > > Also note that if some other driver could call clk_disable() it could
> > > > > just as easily call clk_set_rate() and break simplefb.
> > > > 
> > > > This is not true, see my other reply.
> > > 
> > > If you mean that you could register a clock notifier to prevent clock
> > > changes, then that's going to lead to other drivers failing since they
> > > can now no longer set the rate that they need.
> > 
> > But they can recover. Something that simplefb cannot do.
> 
> Can they? That's a pretty bold assumption.

* They might recover. Something that simplefb cannot do.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > > > [...]
> > > > > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > > > > firmware has set up, which is the only reason why it will work for many
> > > > > > > people. What is passed in via its device tree node is the minimum amount
> > > > > > > of information needed to draw something into the framebuffer. Also note
> > > > > > > that the simplefb device tree node is not statically added to a DTS file
> > > > > > > but needs to be dynamically generated by firmware at runtime.
> > > > > > 
> > > > > > Which makes the whole even simpler, since the firmware already knows
> > > > > > all about which clocks it had to enable.
> > > > > 
> > > > > It makes things very complicated in the firmware because it now needs to
> > > > > be able to generate DTB content that we would otherwise be able to do
> > > > > much easier with a text editor.
> > > > 
> > > > Didn't you just say that it was dynamically generated at runtime? So
> > > > we can just ignore the "text editor" case.
> > > 
> > > Perhaps read the sentence again. I said "that we would *otherwise* be
> > > able to do much easier with a text editor.".
> > > 
> > > My point remains that there shouldn't be a need to generate DTB content
> > > of this complexity at all.
> > > 
> > > > > Why do you think what I proposed isn't going to work or be reliable?
> > > > > I don't see any arguments in the thread that would imply that.
> > > > 
> > > > The fact that it broke in the first place?
> > > 
> > > That's exactly the point. And it's going to break again and again as
> > > simplefb is extended with new things. Generally DT bindings should be
> > > backwards compatible. When extended they should provide a way to fall
> > > back to a reasonable default. There's simply no way you can do that
> > > with simplefb.
> > 
> > This one *is* backward compatible. It doesn't even change the simplefb
> > behaviour, compared to what it was doing before, if you don't have
> > this clocks property. What can be a more reasonable default that the
> > way it used to behave?
> 
> My point is that if we decide not to consider all resources handled by
> firmware then we need to go all the way. At that point you start having
> problems as evidenced by the Snow example.

Agreed.

> > > What happened in the Snow example is that regulators that were
> > > previously on would all of a sudden be automatically disabled on boot
> > > because there was now a driver that registered them with a generic
> > > framework.
> > > 
> > > The same thing is going to happen with simplefb for your device. If you
> > > later realize that you need a regulator to keep the panel going, you'll
> > > have to add code to your firmware to populate the corresponding
> > > properties, otherwise the regulator will end up unused and will be
> > > automatically disabled. At the same time you're going to break upstream
> > > for all users of your old firmware because it doesn't add that property
> > > yet.
> > >
> > > And the same will continue to happen for every new type of resource
> > > you're going to add.
> > 
> > Sure, we can add any resources we will need. Regulators, reset lines,
> > pm domains, allocated memory, but I'm not really sure this is what you
> > want, right?
> 
> No it's not what I want. *You* want to add resource management to this
> driver. What I'm saying is that if we start adding clocks then we can no
> longer say no to resets or regulators or power domains either.

Yes, because resource management can be more than just "keep the thing
enabled". It might also be about not modifying anything, just like we
saw for the clocks, but that might also apply to regulators voltage.

And the only way I can think of to deal with that properly is to have
resources management in the driver.

> > > > > > You know that you are going to call that for regulator, reset, power
> > > > > > domains, just as you would have needed to with the proper API, unless
> > > > > > that with this kind of solution, you would have to modify *every*
> > > > > > framework that might interact with any resource involved in getting
> > > > > > simplefb running?
> > > > > 
> > > > > We have to add handling for every kind of resource either way. Also if
> > > > > this evolves into a common pattern we can easily wrap it up in a single
> > > > > function call.
> > > > 
> > > > Unless that in one case, we already have everything needed to handle
> > > > everything properly, and in another, you keep hacking more and more
> > > > into the involved frameworks.
> > > 
> > > This is a fundamental issue that we are facing and I'm trying to come up
> > > with a solution that is future-proof and will work for drivers other
> > > than simplefb.
> > > 
> > > Just because we currently lack this functionality doesn't make it a hack
> > > trying to add it.
> > 
> > Or maybe it's just showing that the trend to rely more and more on the
> > firmware is a bad idea?
> 
> If you think it's a bad idea to rely on firmware then you shouldn't be
> using simplefb in the first place.
> 
> > I really start to consider adding a sunxi-uboot-fb, that would just
> > duplicate the source code of simplefb but also taking the
> > clocks. Somehow, I feel like it will be easier (and definitely less of
> > a hack than using the generic common clock API).
> 
> You're not getting it are you? What makes you think sunxi-uboot-fb is
> going to be any different? This isn't about a name.

At least, we would get to do any binding and resource management we
want. And that's a big win.

> > > > > > Plus, speaking more specifically about the clocks, that won't prevent
> > > > > > your clock to be shut down as a side effect of a later clk_disable
> > > > > > call from another driver.
> > > > > 
> > > > > If we need to prevent that, then that's something that could be fixed,
> > > > > too.
> > > > 
> > > > See, you keep hacking it more...
> > > 
> > > If you don't see this as a problem that exists beyond simplefb then I
> > > would of course not expect you to think that anything needs fixing.
> > 
> > Then please point me to something else that needs fixing, so that I
> > can see the whole picture.
> 
> We've been over this before. I'm tired of having to repeat myself.
> 
> > > > > so hopefully concurrent users aren't the problem because that would
> > > > > cause the real driver to break too.
> > > > > 
> > > > > Also note that if some other driver could call clk_disable() it could
> > > > > just as easily call clk_set_rate() and break simplefb.
> > > > 
> > > > This is not true, see my other reply.
> > > 
> > > If you mean that you could register a clock notifier to prevent clock
> > > changes, then that's going to lead to other drivers failing since they
> > > can now no longer set the rate that they need.
> > 
> > But they can recover. Something that simplefb cannot do.
> 
> Can they? That's a pretty bold assumption.

* They might recover. Something that simplefb cannot do.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/7db8c888/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3828 bytes --]

On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
[...]
> > > > What happened in the Snow example is that regulators that were
> > > > previously on would all of a sudden be automatically disabled on boot
> > > > because there was now a driver that registered them with a generic
> > > > framework.
> > > > 
> > > > The same thing is going to happen with simplefb for your device. If you
> > > > later realize that you need a regulator to keep the panel going, you'll
> > > > have to add code to your firmware to populate the corresponding
> > > > properties, otherwise the regulator will end up unused and will be
> > > > automatically disabled. At the same time you're going to break upstream
> > > > for all users of your old firmware because it doesn't add that property
> > > > yet.
> > > >
> > > > And the same will continue to happen for every new type of resource
> > > > you're going to add.
> > > 
> > > Sure, we can add any resources we will need. Regulators, reset lines,
> > > pm domains, allocated memory, but I'm not really sure this is what you
> > > want, right?
> > 
> > No it's not what I want. *You* want to add resource management to this
> > driver. What I'm saying is that if we start adding clocks then we can no
> > longer say no to resets or regulators or power domains either.
> 
> Yes, because resource management can be more than just "keep the thing
> enabled". It might also be about not modifying anything, just like we
> saw for the clocks, but that might also apply to regulators voltage.

We've already determined that simplefb can't do anything meaningful with
the resources other than keep them in the status quo. It simply doesn't
have enough knowledge to do so. It doesn't know the exact pixel clock or
what voltage the attached panel needs.

> And the only way I can think of to deal with that properly is to have
> resources management in the driver.

My point is that if we had a proper way to tell the kernel not to do
anything with resources owned by firmware, then the driver wouldn't
have to do anything with the resources.

> > > I really start to consider adding a sunxi-uboot-fb, that would just
> > > duplicate the source code of simplefb but also taking the
> > > clocks. Somehow, I feel like it will be easier (and definitely less of
> > > a hack than using the generic common clock API).
> > 
> > You're not getting it are you? What makes you think sunxi-uboot-fb is
> > going to be any different? This isn't about a name.
> 
> At least, we would get to do any binding and resource management we
> want. And that's a big win.

So instead of trying to understand the concerns that I've expressed and
constructively contribute to finding a solution that works for everybody
you'd rather go and write a driver from scratch. Way to go.

I've already said that I'm not saying strictly no to these patches, but
what I want to see happen is some constructive discussion about whether
we can find better ways to do it. If we can't then I'm all for merging
these patches. Fortunately other (sub)threads have been somewhat more
constructive and actually come up with alternatives that should make
everyone happier.

If you're going to do SoC-specific bindings and resource management you
are in fact implementing what Grant suggested in a subthread. You're
implementing a dummy driver only for resource management, which isn't
really a bad thing. It can serve as a placeholder for now until you add
the real driver. And you can also use the simplefb driver to provide
the framebuffer.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
[...]
> > > > What happened in the Snow example is that regulators that were
> > > > previously on would all of a sudden be automatically disabled on boot
> > > > because there was now a driver that registered them with a generic
> > > > framework.
> > > > 
> > > > The same thing is going to happen with simplefb for your device. If you
> > > > later realize that you need a regulator to keep the panel going, you'll
> > > > have to add code to your firmware to populate the corresponding
> > > > properties, otherwise the regulator will end up unused and will be
> > > > automatically disabled. At the same time you're going to break upstream
> > > > for all users of your old firmware because it doesn't add that property
> > > > yet.
> > > >
> > > > And the same will continue to happen for every new type of resource
> > > > you're going to add.
> > > 
> > > Sure, we can add any resources we will need. Regulators, reset lines,
> > > pm domains, allocated memory, but I'm not really sure this is what you
> > > want, right?
> > 
> > No it's not what I want. *You* want to add resource management to this
> > driver. What I'm saying is that if we start adding clocks then we can no
> > longer say no to resets or regulators or power domains either.
> 
> Yes, because resource management can be more than just "keep the thing
> enabled". It might also be about not modifying anything, just like we
> saw for the clocks, but that might also apply to regulators voltage.

We've already determined that simplefb can't do anything meaningful with
the resources other than keep them in the status quo. It simply doesn't
have enough knowledge to do so. It doesn't know the exact pixel clock or
what voltage the attached panel needs.

> And the only way I can think of to deal with that properly is to have
> resources management in the driver.

My point is that if we had a proper way to tell the kernel not to do
anything with resources owned by firmware, then the driver wouldn't
have to do anything with the resources.

> > > I really start to consider adding a sunxi-uboot-fb, that would just
> > > duplicate the source code of simplefb but also taking the
> > > clocks. Somehow, I feel like it will be easier (and definitely less of
> > > a hack than using the generic common clock API).
> > 
> > You're not getting it are you? What makes you think sunxi-uboot-fb is
> > going to be any different? This isn't about a name.
> 
> At least, we would get to do any binding and resource management we
> want. And that's a big win.

So instead of trying to understand the concerns that I've expressed and
constructively contribute to finding a solution that works for everybody
you'd rather go and write a driver from scratch. Way to go.

I've already said that I'm not saying strictly no to these patches, but
what I want to see happen is some constructive discussion about whether
we can find better ways to do it. If we can't then I'm all for merging
these patches. Fortunately other (sub)threads have been somewhat more
constructive and actually come up with alternatives that should make
everyone happier.

If you're going to do SoC-specific bindings and resource management you
are in fact implementing what Grant suggested in a subthread. You're
implementing a dummy driver only for resource management, which isn't
really a bad thing. It can serve as a placeholder for now until you add
the real driver. And you can also use the simplefb driver to provide
the framebuffer.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/3d87c500/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
>> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> [...]
>> > > > What happened in the Snow example is that regulators that were
>> > > > previously on would all of a sudden be automatically disabled on boot
>> > > > because there was now a driver that registered them with a generic
>> > > > framework.
>> > > >
>> > > > The same thing is going to happen with simplefb for your device. If you
>> > > > later realize that you need a regulator to keep the panel going, you'll
>> > > > have to add code to your firmware to populate the corresponding
>> > > > properties, otherwise the regulator will end up unused and will be
>> > > > automatically disabled. At the same time you're going to break upstream
>> > > > for all users of your old firmware because it doesn't add that property
>> > > > yet.
>> > > >
>> > > > And the same will continue to happen for every new type of resource
>> > > > you're going to add.
>> > >
>> > > Sure, we can add any resources we will need. Regulators, reset lines,
>> > > pm domains, allocated memory, but I'm not really sure this is what you
>> > > want, right?
>> >
>> > No it's not what I want. *You* want to add resource management to this
>> > driver. What I'm saying is that if we start adding clocks then we can no
>> > longer say no to resets or regulators or power domains either.
>>
>> Yes, because resource management can be more than just "keep the thing
>> enabled". It might also be about not modifying anything, just like we
>> saw for the clocks, but that might also apply to regulators voltage.
>
> We've already determined that simplefb can't do anything meaningful with
> the resources other than keep them in the status quo. It simply doesn't
> have enough knowledge to do so. It doesn't know the exact pixel clock or
> what voltage the attached panel needs.
>
>> And the only way I can think of to deal with that properly is to have
>> resources management in the driver.
>
> My point is that if we had a proper way to tell the kernel not to do
> anything with resources owned by firmware, then the driver wouldn't
> have to do anything with the resources.

The firmware on sunxi does not own any resources whatsoever. It ceases
running once it executes the kernel. This is different from ACPI and
UEFI where you have pieces of the firmware lingering indefinitely and
potentially getting invoked by user pressing some button or some other
hardware event. It is also different from rpi where the Linux kernel
effectively runs in a virtual environment created by the firmware
hypervisor.

So on sunxi and many other ARM machines the Linux kernel is the sole
owner of any resources that might happen to be available on the
machine. There is no firmware owning them when the Linux kernel is
running, ever.

And we do have a proper way to tell to the kernel what these resources
are used for - inserting description of them into the simplefb DT
node. Sure the simplefb cannot manage the resources in any way and but
it does own them. When it is running they are in use, when it stops
they are free to be reclaimed by the platform driver.

But you refuse to marge the kernel change for this proper management to happen.

The alternate proposal to stop the kernel from managing resources
while simplefb is running and refernce count drivers that cannot
manage resources is indeed a workable, general alternative.

It does however switch the kernel into special mode when resources are
not managed and will needlessly hinder eg. development and testing of
powermanagement and hotplug for drivers unrelated to kms in parallel
to kms.

But let's look at this special mode closer.

Under normal boot sequence when the built-in drivers are initialized
or around that time the kernel does a pass in which it disables unused
clocks and possibly reclaims other resources.

The boot has finished for the kernel and now it hands over to
userspace and it is up to the userspace to load any more drivers (such
as kms) or not. If at that point a driver like simplefb exists it
should have called that stop_managing_resources() which should replace
clk_ignore_unused() so that other resources are properly handled
without the driver ever having to know about them.

For clocks this should be simple. At least on sunxi the clock driver
can tell if the clock is gated and can potentially be in use. It can
even mark clocks that are used at this point to know not to ever
disable them. Also it should refuse to ever change a clock frequency
on these clocks since if one of them was used for simplefb it should
break. It does not matter it's a mmc bus clock completely unrelated to
display. If you assume no knowledge you cannot change the mmc clock
when a different card is inserted or when a card is inserted into an
empty slot. If the firmware probed the slot the clock might be running
anyway.

Other resources might be more difficult to tackle. Is it possible to
change voltage regulators? Even the fact that it is set to 0 does not
necessarily mean that it is unused and then other driver claiming it
later can change the voltage. So no changing the regulators, ever.

And there goes gpio. You cannot assume that you can change any pin
muxing or any pin level whatsoever. The pin might be connected to the
display. So no loading of drivers that need any pin assignment
changes.

I guess by now it's clear that if this mode that assumes no knowledge
of the underlying hardware and requires the kernel to not manage
resources in order to keep dumb drivers running  completely paralyzes
the kernel and will among other things prevent loading of the proper
kms driver.

>
>> > > I really start to consider adding a sunxi-uboot-fb, that would just
>> > > duplicate the source code of simplefb but also taking the
>> > > clocks. Somehow, I feel like it will be easier (and definitely less of
>> > > a hack than using the generic common clock API).
>> >
>> > You're not getting it are you? What makes you think sunxi-uboot-fb is
>> > going to be any different? This isn't about a name.
>>
>> At least, we would get to do any binding and resource management we
>> want. And that's a big win.
>
> So instead of trying to understand the concerns that I've expressed and
> constructively contribute to finding a solution that works for everybody
> you'd rather go and write a driver from scratch. Way to go.

It's the constructive thing to do when the existing driver cannot be
extended to work for everybody.

>
> I've already said that I'm not saying strictly no to these patches, but
> what I want to see happen is some constructive discussion about whether
> we can find better ways to do it. If we can't then I'm all for merging
> these patches. Fortunately other (sub)threads have been somewhat more
> constructive and actually come up with alternatives that should make
> everyone happier.

What are those alternatives?

>
> If you're going to do SoC-specific bindings and resource management you
> are in fact implementing what Grant suggested in a subthread. You're
> implementing a dummy driver only for resource management, which isn't
> really a bad thing. It can serve as a placeholder for now until you add
> the real driver. And you can also use the simplefb driver to provide
> the framebuffer.

Oh, so back to the proposal to make a driver that claims the required
resources and then instantiates an unextended simplefb that is
oblivious to the resources to be kept simple?

Did I not propose that way back?

Was it not already rejected?

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
>> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> [...]
>> > > > What happened in the Snow example is that regulators that were
>> > > > previously on would all of a sudden be automatically disabled on boot
>> > > > because there was now a driver that registered them with a generic
>> > > > framework.
>> > > >
>> > > > The same thing is going to happen with simplefb for your device. If you
>> > > > later realize that you need a regulator to keep the panel going, you'll
>> > > > have to add code to your firmware to populate the corresponding
>> > > > properties, otherwise the regulator will end up unused and will be
>> > > > automatically disabled. At the same time you're going to break upstream
>> > > > for all users of your old firmware because it doesn't add that property
>> > > > yet.
>> > > >
>> > > > And the same will continue to happen for every new type of resource
>> > > > you're going to add.
>> > >
>> > > Sure, we can add any resources we will need. Regulators, reset lines,
>> > > pm domains, allocated memory, but I'm not really sure this is what you
>> > > want, right?
>> >
>> > No it's not what I want. *You* want to add resource management to this
>> > driver. What I'm saying is that if we start adding clocks then we can no
>> > longer say no to resets or regulators or power domains either.
>>
>> Yes, because resource management can be more than just "keep the thing
>> enabled". It might also be about not modifying anything, just like we
>> saw for the clocks, but that might also apply to regulators voltage.
>
> We've already determined that simplefb can't do anything meaningful with
> the resources other than keep them in the status quo. It simply doesn't
> have enough knowledge to do so. It doesn't know the exact pixel clock or
> what voltage the attached panel needs.
>
>> And the only way I can think of to deal with that properly is to have
>> resources management in the driver.
>
> My point is that if we had a proper way to tell the kernel not to do
> anything with resources owned by firmware, then the driver wouldn't
> have to do anything with the resources.

The firmware on sunxi does not own any resources whatsoever. It ceases
running once it executes the kernel. This is different from ACPI and
UEFI where you have pieces of the firmware lingering indefinitely and
potentially getting invoked by user pressing some button or some other
hardware event. It is also different from rpi where the Linux kernel
effectively runs in a virtual environment created by the firmware
hypervisor.

So on sunxi and many other ARM machines the Linux kernel is the sole
owner of any resources that might happen to be available on the
machine. There is no firmware owning them when the Linux kernel is
running, ever.

And we do have a proper way to tell to the kernel what these resources
are used for - inserting description of them into the simplefb DT
node. Sure the simplefb cannot manage the resources in any way and but
it does own them. When it is running they are in use, when it stops
they are free to be reclaimed by the platform driver.

But you refuse to marge the kernel change for this proper management to happen.

The alternate proposal to stop the kernel from managing resources
while simplefb is running and refernce count drivers that cannot
manage resources is indeed a workable, general alternative.

It does however switch the kernel into special mode when resources are
not managed and will needlessly hinder eg. development and testing of
powermanagement and hotplug for drivers unrelated to kms in parallel
to kms.

But let's look at this special mode closer.

Under normal boot sequence when the built-in drivers are initialized
or around that time the kernel does a pass in which it disables unused
clocks and possibly reclaims other resources.

The boot has finished for the kernel and now it hands over to
userspace and it is up to the userspace to load any more drivers (such
as kms) or not. If at that point a driver like simplefb exists it
should have called that stop_managing_resources() which should replace
clk_ignore_unused() so that other resources are properly handled
without the driver ever having to know about them.

For clocks this should be simple. At least on sunxi the clock driver
can tell if the clock is gated and can potentially be in use. It can
even mark clocks that are used at this point to know not to ever
disable them. Also it should refuse to ever change a clock frequency
on these clocks since if one of them was used for simplefb it should
break. It does not matter it's a mmc bus clock completely unrelated to
display. If you assume no knowledge you cannot change the mmc clock
when a different card is inserted or when a card is inserted into an
empty slot. If the firmware probed the slot the clock might be running
anyway.

Other resources might be more difficult to tackle. Is it possible to
change voltage regulators? Even the fact that it is set to 0 does not
necessarily mean that it is unused and then other driver claiming it
later can change the voltage. So no changing the regulators, ever.

And there goes gpio. You cannot assume that you can change any pin
muxing or any pin level whatsoever. The pin might be connected to the
display. So no loading of drivers that need any pin assignment
changes.

I guess by now it's clear that if this mode that assumes no knowledge
of the underlying hardware and requires the kernel to not manage
resources in order to keep dumb drivers running  completely paralyzes
the kernel and will among other things prevent loading of the proper
kms driver.

>
>> > > I really start to consider adding a sunxi-uboot-fb, that would just
>> > > duplicate the source code of simplefb but also taking the
>> > > clocks. Somehow, I feel like it will be easier (and definitely less of
>> > > a hack than using the generic common clock API).
>> >
>> > You're not getting it are you? What makes you think sunxi-uboot-fb is
>> > going to be any different? This isn't about a name.
>>
>> At least, we would get to do any binding and resource management we
>> want. And that's a big win.
>
> So instead of trying to understand the concerns that I've expressed and
> constructively contribute to finding a solution that works for everybody
> you'd rather go and write a driver from scratch. Way to go.

It's the constructive thing to do when the existing driver cannot be
extended to work for everybody.

>
> I've already said that I'm not saying strictly no to these patches, but
> what I want to see happen is some constructive discussion about whether
> we can find better ways to do it. If we can't then I'm all for merging
> these patches. Fortunately other (sub)threads have been somewhat more
> constructive and actually come up with alternatives that should make
> everyone happier.

What are those alternatives?

>
> If you're going to do SoC-specific bindings and resource management you
> are in fact implementing what Grant suggested in a subthread. You're
> implementing a dummy driver only for resource management, which isn't
> really a bad thing. It can serve as a placeholder for now until you add
> the real driver. And you can also use the simplefb driver to provide
> the framebuffer.

Oh, so back to the proposal to make a driver that claims the required
resources and then instantiates an unextended simplefb that is
oblivious to the resources to be kept simple?

Did I not propose that way back?

Was it not already rejected?

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 10430 bytes --]

On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote:
> On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> >> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> >> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > [...]
> >> > > > What happened in the Snow example is that regulators that were
> >> > > > previously on would all of a sudden be automatically disabled on boot
> >> > > > because there was now a driver that registered them with a generic
> >> > > > framework.
> >> > > >
> >> > > > The same thing is going to happen with simplefb for your device. If you
> >> > > > later realize that you need a regulator to keep the panel going, you'll
> >> > > > have to add code to your firmware to populate the corresponding
> >> > > > properties, otherwise the regulator will end up unused and will be
> >> > > > automatically disabled. At the same time you're going to break upstream
> >> > > > for all users of your old firmware because it doesn't add that property
> >> > > > yet.
> >> > > >
> >> > > > And the same will continue to happen for every new type of resource
> >> > > > you're going to add.
> >> > >
> >> > > Sure, we can add any resources we will need. Regulators, reset lines,
> >> > > pm domains, allocated memory, but I'm not really sure this is what you
> >> > > want, right?
> >> >
> >> > No it's not what I want. *You* want to add resource management to this
> >> > driver. What I'm saying is that if we start adding clocks then we can no
> >> > longer say no to resets or regulators or power domains either.
> >>
> >> Yes, because resource management can be more than just "keep the thing
> >> enabled". It might also be about not modifying anything, just like we
> >> saw for the clocks, but that might also apply to regulators voltage.
> >
> > We've already determined that simplefb can't do anything meaningful with
> > the resources other than keep them in the status quo. It simply doesn't
> > have enough knowledge to do so. It doesn't know the exact pixel clock or
> > what voltage the attached panel needs.
> >
> >> And the only way I can think of to deal with that properly is to have
> >> resources management in the driver.
> >
> > My point is that if we had a proper way to tell the kernel not to do
> > anything with resources owned by firmware, then the driver wouldn't
> > have to do anything with the resources.
> 
> The firmware on sunxi does not own any resources whatsoever. It ceases
> running once it executes the kernel. This is different from ACPI and
> UEFI where you have pieces of the firmware lingering indefinitely and
> potentially getting invoked by user pressing some button or some other
> hardware event. It is also different from rpi where the Linux kernel
> effectively runs in a virtual environment created by the firmware
> hypervisor.

You know all that because you of course wrote every single firmware
implementation that does and will ever exist for sunxi. There's nothing
keeping anyone from running UEFI on a sunxi SoC.

> So on sunxi and many other ARM machines the Linux kernel is the sole
> owner of any resources that might happen to be available on the
> machine. There is no firmware owning them when the Linux kernel is
> running, ever.

Of course this is part of the abstraction. The idea is that the device
is a virtual one created by firmware. Therefore firmware owns the
resources until the virtual device has been handed over to the kernel.

If you're into splitting hairs, then the simplefb device shouldn't exist
in the first place.

> And we do have a proper way to tell to the kernel what these resources
> are used for - inserting description of them into the simplefb DT
> node. Sure the simplefb cannot manage the resources in any way and but
> it does own them. When it is running they are in use, when it stops
> they are free to be reclaimed by the platform driver.

Yes. And again I'm not saying anything different. What I'm saying is
that we shouldn't need to know about the resources and instead hide that
within the firmware, for the same reason that we're already hiding the
register programming in hardware, namely to create an abstraction that
works irrespective of the underlying hardware.

> But you refuse to marge the kernel change for this proper management
> to happen.

I have no authority to merge these changes nor have I any way of vetoing
them. All I'm saying is that I think it's a bad idea. If nobody else
thinks it is then it will eventually get merged irrespective of what I'm
saying. And when that happens I'll shut up and live happily ever after.
But it doesn't magically convince me that it's a good idea.

> The alternate proposal to stop the kernel from managing resources
> while simplefb is running and refernce count drivers that cannot
> manage resources is indeed a workable, general alternative.
> 
> It does however switch the kernel into special mode when resources are
> not managed and will needlessly hinder eg. development and testing of
> powermanagement and hotplug for drivers unrelated to kms in parallel
> to kms.
> 
> But let's look at this special mode closer.
> 
> Under normal boot sequence when the built-in drivers are initialized
> or around that time the kernel does a pass in which it disables unused
> clocks and possibly reclaims other resources.
> 
> The boot has finished for the kernel and now it hands over to
> userspace and it is up to the userspace to load any more drivers (such
> as kms) or not. If at that point a driver like simplefb exists it
> should have called that stop_managing_resources() which should replace
> clk_ignore_unused() so that other resources are properly handled
> without the driver ever having to know about them.
> 
> For clocks this should be simple. At least on sunxi the clock driver
> can tell if the clock is gated and can potentially be in use. It can
> even mark clocks that are used at this point to know not to ever
> disable them. Also it should refuse to ever change a clock frequency
> on these clocks since if one of them was used for simplefb it should
> break. It does not matter it's a mmc bus clock completely unrelated to
> display. If you assume no knowledge you cannot change the mmc clock
> when a different card is inserted or when a card is inserted into an
> empty slot. If the firmware probed the slot the clock might be running
> anyway.
> 
> Other resources might be more difficult to tackle. Is it possible to
> change voltage regulators? Even the fact that it is set to 0 does not
> necessarily mean that it is unused and then other driver claiming it
> later can change the voltage. So no changing the regulators, ever.
> 
> And there goes gpio. You cannot assume that you can change any pin
> muxing or any pin level whatsoever. The pin might be connected to the
> display. So no loading of drivers that need any pin assignment
> changes.

The original patches don't tackle any of these problems. And in addition
to what's been mentioned elsewhere you're adding two new types of
resources that need to be potentially claimed here. Fortunately for GPIO
and pinmux the default is to not touch them at all unless explicitly
claimed and controlled. At least as far as I know.

> I guess by now it's clear that if this mode that assumes no knowledge
> of the underlying hardware and requires the kernel to not manage
> resources in order to keep dumb drivers running  completely paralyzes
> the kernel and will among other things prevent loading of the proper
> kms driver.

Yes, Geert already made that argument and I admit that it exposes a flaw
in the solution that I proposed.

> >> > > I really start to consider adding a sunxi-uboot-fb, that would just
> >> > > duplicate the source code of simplefb but also taking the
> >> > > clocks. Somehow, I feel like it will be easier (and definitely less of
> >> > > a hack than using the generic common clock API).
> >> >
> >> > You're not getting it are you? What makes you think sunxi-uboot-fb is
> >> > going to be any different? This isn't about a name.
> >>
> >> At least, we would get to do any binding and resource management we
> >> want. And that's a big win.
> >
> > So instead of trying to understand the concerns that I've expressed and
> > constructively contribute to finding a solution that works for everybody
> > you'd rather go and write a driver from scratch. Way to go.
> 
> It's the constructive thing to do when the existing driver cannot be
> extended to work for everybody.

No, it isn't. If a generic driver doesn't work for everybody then it
isn't generic and we should fix it. Not duplicate it and add platform
specific quirks.

> > I've already said that I'm not saying strictly no to these patches, but
> > what I want to see happen is some constructive discussion about whether
> > we can find better ways to do it. If we can't then I'm all for merging
> > these patches. Fortunately other (sub)threads have been somewhat more
> > constructive and actually come up with alternatives that should make
> > everyone happier.
> 
> What are those alternatives?

Sorry, you've got to do some of the work yourself. They've been
mentioned in this thread and the one that Maxime pointed to the other
day.

> > If you're going to do SoC-specific bindings and resource management you
> > are in fact implementing what Grant suggested in a subthread. You're
> > implementing a dummy driver only for resource management, which isn't
> > really a bad thing. It can serve as a placeholder for now until you add
> > the real driver. And you can also use the simplefb driver to provide
> > the framebuffer.
> 
> Oh, so back to the proposal to make a driver that claims the required
> resources and then instantiates an unextended simplefb that is
> oblivious to the resources to be kept simple?

Pretty much, yes.

> Did I not propose that way back?

Yes, I think you did.

> Was it not already rejected?

No, I don't think it was. In fact I don't think anything was really
rejected yet, we're still in the middle of a discussion.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote:
> On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> >> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> >> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > [...]
> >> > > > What happened in the Snow example is that regulators that were
> >> > > > previously on would all of a sudden be automatically disabled on boot
> >> > > > because there was now a driver that registered them with a generic
> >> > > > framework.
> >> > > >
> >> > > > The same thing is going to happen with simplefb for your device. If you
> >> > > > later realize that you need a regulator to keep the panel going, you'll
> >> > > > have to add code to your firmware to populate the corresponding
> >> > > > properties, otherwise the regulator will end up unused and will be
> >> > > > automatically disabled. At the same time you're going to break upstream
> >> > > > for all users of your old firmware because it doesn't add that property
> >> > > > yet.
> >> > > >
> >> > > > And the same will continue to happen for every new type of resource
> >> > > > you're going to add.
> >> > >
> >> > > Sure, we can add any resources we will need. Regulators, reset lines,
> >> > > pm domains, allocated memory, but I'm not really sure this is what you
> >> > > want, right?
> >> >
> >> > No it's not what I want. *You* want to add resource management to this
> >> > driver. What I'm saying is that if we start adding clocks then we can no
> >> > longer say no to resets or regulators or power domains either.
> >>
> >> Yes, because resource management can be more than just "keep the thing
> >> enabled". It might also be about not modifying anything, just like we
> >> saw for the clocks, but that might also apply to regulators voltage.
> >
> > We've already determined that simplefb can't do anything meaningful with
> > the resources other than keep them in the status quo. It simply doesn't
> > have enough knowledge to do so. It doesn't know the exact pixel clock or
> > what voltage the attached panel needs.
> >
> >> And the only way I can think of to deal with that properly is to have
> >> resources management in the driver.
> >
> > My point is that if we had a proper way to tell the kernel not to do
> > anything with resources owned by firmware, then the driver wouldn't
> > have to do anything with the resources.
> 
> The firmware on sunxi does not own any resources whatsoever. It ceases
> running once it executes the kernel. This is different from ACPI and
> UEFI where you have pieces of the firmware lingering indefinitely and
> potentially getting invoked by user pressing some button or some other
> hardware event. It is also different from rpi where the Linux kernel
> effectively runs in a virtual environment created by the firmware
> hypervisor.

You know all that because you of course wrote every single firmware
implementation that does and will ever exist for sunxi. There's nothing
keeping anyone from running UEFI on a sunxi SoC.

> So on sunxi and many other ARM machines the Linux kernel is the sole
> owner of any resources that might happen to be available on the
> machine. There is no firmware owning them when the Linux kernel is
> running, ever.

Of course this is part of the abstraction. The idea is that the device
is a virtual one created by firmware. Therefore firmware owns the
resources until the virtual device has been handed over to the kernel.

If you're into splitting hairs, then the simplefb device shouldn't exist
in the first place.

> And we do have a proper way to tell to the kernel what these resources
> are used for - inserting description of them into the simplefb DT
> node. Sure the simplefb cannot manage the resources in any way and but
> it does own them. When it is running they are in use, when it stops
> they are free to be reclaimed by the platform driver.

Yes. And again I'm not saying anything different. What I'm saying is
that we shouldn't need to know about the resources and instead hide that
within the firmware, for the same reason that we're already hiding the
register programming in hardware, namely to create an abstraction that
works irrespective of the underlying hardware.

> But you refuse to marge the kernel change for this proper management
> to happen.

I have no authority to merge these changes nor have I any way of vetoing
them. All I'm saying is that I think it's a bad idea. If nobody else
thinks it is then it will eventually get merged irrespective of what I'm
saying. And when that happens I'll shut up and live happily ever after.
But it doesn't magically convince me that it's a good idea.

> The alternate proposal to stop the kernel from managing resources
> while simplefb is running and refernce count drivers that cannot
> manage resources is indeed a workable, general alternative.
> 
> It does however switch the kernel into special mode when resources are
> not managed and will needlessly hinder eg. development and testing of
> powermanagement and hotplug for drivers unrelated to kms in parallel
> to kms.
> 
> But let's look at this special mode closer.
> 
> Under normal boot sequence when the built-in drivers are initialized
> or around that time the kernel does a pass in which it disables unused
> clocks and possibly reclaims other resources.
> 
> The boot has finished for the kernel and now it hands over to
> userspace and it is up to the userspace to load any more drivers (such
> as kms) or not. If at that point a driver like simplefb exists it
> should have called that stop_managing_resources() which should replace
> clk_ignore_unused() so that other resources are properly handled
> without the driver ever having to know about them.
> 
> For clocks this should be simple. At least on sunxi the clock driver
> can tell if the clock is gated and can potentially be in use. It can
> even mark clocks that are used at this point to know not to ever
> disable them. Also it should refuse to ever change a clock frequency
> on these clocks since if one of them was used for simplefb it should
> break. It does not matter it's a mmc bus clock completely unrelated to
> display. If you assume no knowledge you cannot change the mmc clock
> when a different card is inserted or when a card is inserted into an
> empty slot. If the firmware probed the slot the clock might be running
> anyway.
> 
> Other resources might be more difficult to tackle. Is it possible to
> change voltage regulators? Even the fact that it is set to 0 does not
> necessarily mean that it is unused and then other driver claiming it
> later can change the voltage. So no changing the regulators, ever.
> 
> And there goes gpio. You cannot assume that you can change any pin
> muxing or any pin level whatsoever. The pin might be connected to the
> display. So no loading of drivers that need any pin assignment
> changes.

The original patches don't tackle any of these problems. And in addition
to what's been mentioned elsewhere you're adding two new types of
resources that need to be potentially claimed here. Fortunately for GPIO
and pinmux the default is to not touch them at all unless explicitly
claimed and controlled. At least as far as I know.

> I guess by now it's clear that if this mode that assumes no knowledge
> of the underlying hardware and requires the kernel to not manage
> resources in order to keep dumb drivers running  completely paralyzes
> the kernel and will among other things prevent loading of the proper
> kms driver.

Yes, Geert already made that argument and I admit that it exposes a flaw
in the solution that I proposed.

> >> > > I really start to consider adding a sunxi-uboot-fb, that would just
> >> > > duplicate the source code of simplefb but also taking the
> >> > > clocks. Somehow, I feel like it will be easier (and definitely less of
> >> > > a hack than using the generic common clock API).
> >> >
> >> > You're not getting it are you? What makes you think sunxi-uboot-fb is
> >> > going to be any different? This isn't about a name.
> >>
> >> At least, we would get to do any binding and resource management we
> >> want. And that's a big win.
> >
> > So instead of trying to understand the concerns that I've expressed and
> > constructively contribute to finding a solution that works for everybody
> > you'd rather go and write a driver from scratch. Way to go.
> 
> It's the constructive thing to do when the existing driver cannot be
> extended to work for everybody.

No, it isn't. If a generic driver doesn't work for everybody then it
isn't generic and we should fix it. Not duplicate it and add platform
specific quirks.

> > I've already said that I'm not saying strictly no to these patches, but
> > what I want to see happen is some constructive discussion about whether
> > we can find better ways to do it. If we can't then I'm all for merging
> > these patches. Fortunately other (sub)threads have been somewhat more
> > constructive and actually come up with alternatives that should make
> > everyone happier.
> 
> What are those alternatives?

Sorry, you've got to do some of the work yourself. They've been
mentioned in this thread and the one that Maxime pointed to the other
day.

> > If you're going to do SoC-specific bindings and resource management you
> > are in fact implementing what Grant suggested in a subthread. You're
> > implementing a dummy driver only for resource management, which isn't
> > really a bad thing. It can serve as a placeholder for now until you add
> > the real driver. And you can also use the simplefb driver to provide
> > the framebuffer.
> 
> Oh, so back to the proposal to make a driver that claims the required
> resources and then instantiates an unextended simplefb that is
> oblivious to the resources to be kept simple?

Pretty much, yes.

> Did I not propose that way back?

Yes, I think you did.

> Was it not already rejected?

No, I don't think it was. In fact I don't think anything was really
rejected yet, we're still in the middle of a discussion.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/4c41b394/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 30 September 2014 13:31, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote:
>> On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
>> >> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
>> >> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
>> >> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
>> > [...]
>> >> > > > What happened in the Snow example is that regulators that were
>> >> > > > previously on would all of a sudden be automatically disabled on boot
>> >> > > > because there was now a driver that registered them with a generic
>> >> > > > framework.
>> >> > > >
>> >> > > > The same thing is going to happen with simplefb for your device. If you
>> >> > > > later realize that you need a regulator to keep the panel going, you'll
>> >> > > > have to add code to your firmware to populate the corresponding
>> >> > > > properties, otherwise the regulator will end up unused and will be
>> >> > > > automatically disabled. At the same time you're going to break upstream
>> >> > > > for all users of your old firmware because it doesn't add that property
>> >> > > > yet.
>> >> > > >
>> >> > > > And the same will continue to happen for every new type of resource
>> >> > > > you're going to add.
>> >> > >
>> >> > > Sure, we can add any resources we will need. Regulators, reset lines,
>> >> > > pm domains, allocated memory, but I'm not really sure this is what you
>> >> > > want, right?
>> >> >
>> >> > No it's not what I want. *You* want to add resource management to this
>> >> > driver. What I'm saying is that if we start adding clocks then we can no
>> >> > longer say no to resets or regulators or power domains either.
>> >>
>> >> Yes, because resource management can be more than just "keep the thing
>> >> enabled". It might also be about not modifying anything, just like we
>> >> saw for the clocks, but that might also apply to regulators voltage.
>> >
>> > We've already determined that simplefb can't do anything meaningful with
>> > the resources other than keep them in the status quo. It simply doesn't
>> > have enough knowledge to do so. It doesn't know the exact pixel clock or
>> > what voltage the attached panel needs.
>> >
>> >> And the only way I can think of to deal with that properly is to have
>> >> resources management in the driver.
>> >
>> > My point is that if we had a proper way to tell the kernel not to do
>> > anything with resources owned by firmware, then the driver wouldn't
>> > have to do anything with the resources.
>>
>> The firmware on sunxi does not own any resources whatsoever. It ceases
>> running once it executes the kernel. This is different from ACPI and
>> UEFI where you have pieces of the firmware lingering indefinitely and
>> potentially getting invoked by user pressing some button or some other
>> hardware event. It is also different from rpi where the Linux kernel
>> effectively runs in a virtual environment created by the firmware
>> hypervisor.
>
> You know all that because you of course wrote every single firmware
> implementation that does and will ever exist for sunxi. There's nothing
> keeping anyone from running UEFI on a sunxi SoC.

The existing 'firmware' or rather loader for sunxi is u-boot.

I am not saying other solutions cannot exist. I am describing the
current situation.

>
>> So on sunxi and many other ARM machines the Linux kernel is the sole
>> owner of any resources that might happen to be available on the
>> machine. There is no firmware owning them when the Linux kernel is
>> running, ever.
>
> Of course this is part of the abstraction. The idea is that the device
> is a virtual one created by firmware. Therefore firmware owns the
> resources until the virtual device has been handed over to the kernel.
>
> If you're into splitting hairs, then the simplefb device shouldn't exist
> in the first place.

Why shoudn't it?

It is properly created by u-boot and handed over to the kernel with
all the required information for the kernel to keep it running or shut
it down as it sees fit.

>
>> And we do have a proper way to tell to the kernel what these resources
>> are used for - inserting description of them into the simplefb DT
>> node. Sure the simplefb cannot manage the resources in any way and but
>> it does own them. When it is running they are in use, when it stops
>> they are free to be reclaimed by the platform driver.
>
> Yes. And again I'm not saying anything different. What I'm saying is
> that we shouldn't need to know about the resources and instead hide that
> within the firmware, for the same reason that we're already hiding the
> register programming in hardware, namely to create an abstraction that
> works irrespective of the underlying hardware.

So then hide those resources in the Linux kernel. Because if you are
into hair splitting then on sunxi currently the Linux kernel is the
firmware and u-boot is only one of the loader stages that ultimately
executes the final firmware which is Linux.

>> >> > > I really start to consider adding a sunxi-uboot-fb, that would just
>> >> > > duplicate the source code of simplefb but also taking the
>> >> > > clocks. Somehow, I feel like it will be easier (and definitely less of
>> >> > > a hack than using the generic common clock API).
>> >> >
>> >> > You're not getting it are you? What makes you think sunxi-uboot-fb is
>> >> > going to be any different? This isn't about a name.
>> >>
>> >> At least, we would get to do any binding and resource management we
>> >> want. And that's a big win.
>> >
>> > So instead of trying to understand the concerns that I've expressed and
>> > constructively contribute to finding a solution that works for everybody
>> > you'd rather go and write a driver from scratch. Way to go.
>>
>> It's the constructive thing to do when the existing driver cannot be
>> extended to work for everybody.
>
> No, it isn't. If a generic driver doesn't work for everybody then it
> isn't generic and we should fix it. Not duplicate it and add platform
> specific quirks.

What was proposed originally is not platform specific quirk.

It was a generic solution what works on every platform when you can
provide a list of resources that are needed for simplefb to run.

It's not like sunxi is the only platform that has exposed display clocks, it it?

>
>> > I've already said that I'm not saying strictly no to these patches, but
>> > what I want to see happen is some constructive discussion about whether
>> > we can find better ways to do it. If we can't then I'm all for merging
>> > these patches. Fortunately other (sub)threads have been somewhat more
>> > constructive and actually come up with alternatives that should make
>> > everyone happier.
>>
>> What are those alternatives?
>
> Sorry, you've got to do some of the work yourself. They've been
> mentioned in this thread and the one that Maxime pointed to the other
> day.

I did not notice any in this thread, sorry.

>
>> > If you're going to do SoC-specific bindings and resource management you
>> > are in fact implementing what Grant suggested in a subthread. You're
>> > implementing a dummy driver only for resource management, which isn't
>> > really a bad thing. It can serve as a placeholder for now until you add
>> > the real driver. And you can also use the simplefb driver to provide
>> > the framebuffer.
>>
>> Oh, so back to the proposal to make a driver that claims the required
>> resources and then instantiates an unextended simplefb that is
>> oblivious to the resources to be kept simple?
>
> Pretty much, yes.
>
>> Did I not propose that way back?
>
> Yes, I think you did.
>
>> Was it not already rejected?
>
> No, I don't think it was. In fact I don't think anything was really
> rejected yet, we're still in the middle of a discussion.
>
> Thierry

You personally were against it ...

Can we agree on that as acceptable solution then?

Thanks

Michal

On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.
>
> Thierry

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 30 September 2014 13:31, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote:
>> On 30 September 2014 10:54, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
>> >> On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
>> >> > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
>> >> > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
>> > [...]
>> >> > > > What happened in the Snow example is that regulators that were
>> >> > > > previously on would all of a sudden be automatically disabled on boot
>> >> > > > because there was now a driver that registered them with a generic
>> >> > > > framework.
>> >> > > >
>> >> > > > The same thing is going to happen with simplefb for your device. If you
>> >> > > > later realize that you need a regulator to keep the panel going, you'll
>> >> > > > have to add code to your firmware to populate the corresponding
>> >> > > > properties, otherwise the regulator will end up unused and will be
>> >> > > > automatically disabled. At the same time you're going to break upstream
>> >> > > > for all users of your old firmware because it doesn't add that property
>> >> > > > yet.
>> >> > > >
>> >> > > > And the same will continue to happen for every new type of resource
>> >> > > > you're going to add.
>> >> > >
>> >> > > Sure, we can add any resources we will need. Regulators, reset lines,
>> >> > > pm domains, allocated memory, but I'm not really sure this is what you
>> >> > > want, right?
>> >> >
>> >> > No it's not what I want. *You* want to add resource management to this
>> >> > driver. What I'm saying is that if we start adding clocks then we can no
>> >> > longer say no to resets or regulators or power domains either.
>> >>
>> >> Yes, because resource management can be more than just "keep the thing
>> >> enabled". It might also be about not modifying anything, just like we
>> >> saw for the clocks, but that might also apply to regulators voltage.
>> >
>> > We've already determined that simplefb can't do anything meaningful with
>> > the resources other than keep them in the status quo. It simply doesn't
>> > have enough knowledge to do so. It doesn't know the exact pixel clock or
>> > what voltage the attached panel needs.
>> >
>> >> And the only way I can think of to deal with that properly is to have
>> >> resources management in the driver.
>> >
>> > My point is that if we had a proper way to tell the kernel not to do
>> > anything with resources owned by firmware, then the driver wouldn't
>> > have to do anything with the resources.
>>
>> The firmware on sunxi does not own any resources whatsoever. It ceases
>> running once it executes the kernel. This is different from ACPI and
>> UEFI where you have pieces of the firmware lingering indefinitely and
>> potentially getting invoked by user pressing some button or some other
>> hardware event. It is also different from rpi where the Linux kernel
>> effectively runs in a virtual environment created by the firmware
>> hypervisor.
>
> You know all that because you of course wrote every single firmware
> implementation that does and will ever exist for sunxi. There's nothing
> keeping anyone from running UEFI on a sunxi SoC.

The existing 'firmware' or rather loader for sunxi is u-boot.

I am not saying other solutions cannot exist. I am describing the
current situation.

>
>> So on sunxi and many other ARM machines the Linux kernel is the sole
>> owner of any resources that might happen to be available on the
>> machine. There is no firmware owning them when the Linux kernel is
>> running, ever.
>
> Of course this is part of the abstraction. The idea is that the device
> is a virtual one created by firmware. Therefore firmware owns the
> resources until the virtual device has been handed over to the kernel.
>
> If you're into splitting hairs, then the simplefb device shouldn't exist
> in the first place.

Why shoudn't it?

It is properly created by u-boot and handed over to the kernel with
all the required information for the kernel to keep it running or shut
it down as it sees fit.

>
>> And we do have a proper way to tell to the kernel what these resources
>> are used for - inserting description of them into the simplefb DT
>> node. Sure the simplefb cannot manage the resources in any way and but
>> it does own them. When it is running they are in use, when it stops
>> they are free to be reclaimed by the platform driver.
>
> Yes. And again I'm not saying anything different. What I'm saying is
> that we shouldn't need to know about the resources and instead hide that
> within the firmware, for the same reason that we're already hiding the
> register programming in hardware, namely to create an abstraction that
> works irrespective of the underlying hardware.

So then hide those resources in the Linux kernel. Because if you are
into hair splitting then on sunxi currently the Linux kernel is the
firmware and u-boot is only one of the loader stages that ultimately
executes the final firmware which is Linux.

>> >> > > I really start to consider adding a sunxi-uboot-fb, that would just
>> >> > > duplicate the source code of simplefb but also taking the
>> >> > > clocks. Somehow, I feel like it will be easier (and definitely less of
>> >> > > a hack than using the generic common clock API).
>> >> >
>> >> > You're not getting it are you? What makes you think sunxi-uboot-fb is
>> >> > going to be any different? This isn't about a name.
>> >>
>> >> At least, we would get to do any binding and resource management we
>> >> want. And that's a big win.
>> >
>> > So instead of trying to understand the concerns that I've expressed and
>> > constructively contribute to finding a solution that works for everybody
>> > you'd rather go and write a driver from scratch. Way to go.
>>
>> It's the constructive thing to do when the existing driver cannot be
>> extended to work for everybody.
>
> No, it isn't. If a generic driver doesn't work for everybody then it
> isn't generic and we should fix it. Not duplicate it and add platform
> specific quirks.

What was proposed originally is not platform specific quirk.

It was a generic solution what works on every platform when you can
provide a list of resources that are needed for simplefb to run.

It's not like sunxi is the only platform that has exposed display clocks, it it?

>
>> > I've already said that I'm not saying strictly no to these patches, but
>> > what I want to see happen is some constructive discussion about whether
>> > we can find better ways to do it. If we can't then I'm all for merging
>> > these patches. Fortunately other (sub)threads have been somewhat more
>> > constructive and actually come up with alternatives that should make
>> > everyone happier.
>>
>> What are those alternatives?
>
> Sorry, you've got to do some of the work yourself. They've been
> mentioned in this thread and the one that Maxime pointed to the other
> day.

I did not notice any in this thread, sorry.

>
>> > If you're going to do SoC-specific bindings and resource management you
>> > are in fact implementing what Grant suggested in a subthread. You're
>> > implementing a dummy driver only for resource management, which isn't
>> > really a bad thing. It can serve as a placeholder for now until you add
>> > the real driver. And you can also use the simplefb driver to provide
>> > the framebuffer.
>>
>> Oh, so back to the proposal to make a driver that claims the required
>> resources and then instantiates an unextended simplefb that is
>> oblivious to the resources to be kept simple?
>
> Pretty much, yes.
>
>> Did I not propose that way back?
>
> Yes, I think you did.
>
>> Was it not already rejected?
>
> No, I don't think it was. In fact I don't think anything was really
> rejected yet, we're still in the middle of a discussion.
>
> Thierry

You personally were against it ...

Can we agree on that as acceptable solution then?

Thanks

Michal

On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.
>
> Thierry

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 5963 bytes --]

On Tue, Sep 30, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> > On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> [...]
> > > > > What happened in the Snow example is that regulators that were
> > > > > previously on would all of a sudden be automatically disabled on boot
> > > > > because there was now a driver that registered them with a generic
> > > > > framework.
> > > > > 
> > > > > The same thing is going to happen with simplefb for your device. If you
> > > > > later realize that you need a regulator to keep the panel going, you'll
> > > > > have to add code to your firmware to populate the corresponding
> > > > > properties, otherwise the regulator will end up unused and will be
> > > > > automatically disabled. At the same time you're going to break upstream
> > > > > for all users of your old firmware because it doesn't add that property
> > > > > yet.
> > > > >
> > > > > And the same will continue to happen for every new type of resource
> > > > > you're going to add.
> > > > 
> > > > Sure, we can add any resources we will need. Regulators, reset lines,
> > > > pm domains, allocated memory, but I'm not really sure this is what you
> > > > want, right?
> > > 
> > > No it's not what I want. *You* want to add resource management to this
> > > driver. What I'm saying is that if we start adding clocks then we can no
> > > longer say no to resets or regulators or power domains either.
> > 
> > Yes, because resource management can be more than just "keep the thing
> > enabled". It might also be about not modifying anything, just like we
> > saw for the clocks, but that might also apply to regulators voltage.
> 
> We've already determined that simplefb can't do anything meaningful with
> the resources other than keep them in the status quo. It simply doesn't
> have enough knowledge to do so. It doesn't know the exact pixel clock or
> what voltage the attached panel needs.

We do agree that it doesn't care, doesn't need to know it, or doesn't
need to do anything about it, but what it needs is that they stay the
same. That means both keeping a clock or a regulator enabled, but also
preventing any other user (direct, as in a shared regulator, or
indirect, as in two clocks sharing the same parent) to change that
voltage or pixel clock.

You were trying to address the former in your patch, but you
completely ignore the second one, which is just as important.

> > And the only way I can think of to deal with that properly is to have
> > resources management in the driver.
> 
> My point is that if we had a proper way to tell the kernel not to do
> anything with resources owned by firmware, then the driver wouldn't
> have to do anything with the resources.

Yes, but at least for the clocks, and I guess it might be true in some
sick way for regulators too, the fact that it's a tree doesn't make
this easy at all. If they were completely independant clocks, yeah,
sure, we could do that. But it's almost never the case, and all clocks
share parents with other at some degree.

I guess you could do it using clock flags of some sort, but that would
require traversing the clock tree for almost any operation, which
doesn't look very reasonable.

> > > > I really start to consider adding a sunxi-uboot-fb, that would just
> > > > duplicate the source code of simplefb but also taking the
> > > > clocks. Somehow, I feel like it will be easier (and definitely less of
> > > > a hack than using the generic common clock API).
> > > 
> > > You're not getting it are you? What makes you think sunxi-uboot-fb is
> > > going to be any different? This isn't about a name.
> > 
> > At least, we would get to do any binding and resource management we
> > want. And that's a big win.
> 
> So instead of trying to understand the concerns that I've expressed and
> constructively contribute to finding a solution that works for everybody
> you'd rather go and write a driver from scratch. Way to go.

Hey, you haven't really contributed either to finding a solution to
the fact that we need not only to prevent the clocks from being
touched during the framework initcall, but also from other related
users.

> I've already said that I'm not saying strictly no to these patches, but
> what I want to see happen is some constructive discussion about whether
> we can find better ways to do it. If we can't then I'm all for merging
> these patches. Fortunately other (sub)threads have been somewhat more
> constructive and actually come up with alternatives that should make
> everyone happier.

I didn't see where you said that you were not strictly against
them. But ok.

I guess your concerns all boil down to 1) do not break DT backward
compatibility, 2) do not break what the firmware has set up, even on
older firmwares.

We got 1 covered already, but in order to cover 2, I guess we would
need both our solutions, that I don't really see as orthogonal.

How would something like adding optional clocks property, and if
found, doing the regular clk_* calls, and if not found, relying on
your solution work for you?

> If you're going to do SoC-specific bindings and resource management
> you are in fact implementing what Grant suggested in a
> subthread. You're implementing a dummy driver only for resource
> management, which isn't really a bad thing. It can serve as a
> placeholder for now until you add the real driver. And you can also
> use the simplefb driver to provide the framebuffer.

That could be an option too, but I'd rather avoid it if possible.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Sep 30, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote:
> > On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> [...]
> > > > > What happened in the Snow example is that regulators that were
> > > > > previously on would all of a sudden be automatically disabled on boot
> > > > > because there was now a driver that registered them with a generic
> > > > > framework.
> > > > > 
> > > > > The same thing is going to happen with simplefb for your device. If you
> > > > > later realize that you need a regulator to keep the panel going, you'll
> > > > > have to add code to your firmware to populate the corresponding
> > > > > properties, otherwise the regulator will end up unused and will be
> > > > > automatically disabled. At the same time you're going to break upstream
> > > > > for all users of your old firmware because it doesn't add that property
> > > > > yet.
> > > > >
> > > > > And the same will continue to happen for every new type of resource
> > > > > you're going to add.
> > > > 
> > > > Sure, we can add any resources we will need. Regulators, reset lines,
> > > > pm domains, allocated memory, but I'm not really sure this is what you
> > > > want, right?
> > > 
> > > No it's not what I want. *You* want to add resource management to this
> > > driver. What I'm saying is that if we start adding clocks then we can no
> > > longer say no to resets or regulators or power domains either.
> > 
> > Yes, because resource management can be more than just "keep the thing
> > enabled". It might also be about not modifying anything, just like we
> > saw for the clocks, but that might also apply to regulators voltage.
> 
> We've already determined that simplefb can't do anything meaningful with
> the resources other than keep them in the status quo. It simply doesn't
> have enough knowledge to do so. It doesn't know the exact pixel clock or
> what voltage the attached panel needs.

We do agree that it doesn't care, doesn't need to know it, or doesn't
need to do anything about it, but what it needs is that they stay the
same. That means both keeping a clock or a regulator enabled, but also
preventing any other user (direct, as in a shared regulator, or
indirect, as in two clocks sharing the same parent) to change that
voltage or pixel clock.

You were trying to address the former in your patch, but you
completely ignore the second one, which is just as important.

> > And the only way I can think of to deal with that properly is to have
> > resources management in the driver.
> 
> My point is that if we had a proper way to tell the kernel not to do
> anything with resources owned by firmware, then the driver wouldn't
> have to do anything with the resources.

Yes, but at least for the clocks, and I guess it might be true in some
sick way for regulators too, the fact that it's a tree doesn't make
this easy at all. If they were completely independant clocks, yeah,
sure, we could do that. But it's almost never the case, and all clocks
share parents with other at some degree.

I guess you could do it using clock flags of some sort, but that would
require traversing the clock tree for almost any operation, which
doesn't look very reasonable.

> > > > I really start to consider adding a sunxi-uboot-fb, that would just
> > > > duplicate the source code of simplefb but also taking the
> > > > clocks. Somehow, I feel like it will be easier (and definitely less of
> > > > a hack than using the generic common clock API).
> > > 
> > > You're not getting it are you? What makes you think sunxi-uboot-fb is
> > > going to be any different? This isn't about a name.
> > 
> > At least, we would get to do any binding and resource management we
> > want. And that's a big win.
> 
> So instead of trying to understand the concerns that I've expressed and
> constructively contribute to finding a solution that works for everybody
> you'd rather go and write a driver from scratch. Way to go.

Hey, you haven't really contributed either to finding a solution to
the fact that we need not only to prevent the clocks from being
touched during the framework initcall, but also from other related
users.

> I've already said that I'm not saying strictly no to these patches, but
> what I want to see happen is some constructive discussion about whether
> we can find better ways to do it. If we can't then I'm all for merging
> these patches. Fortunately other (sub)threads have been somewhat more
> constructive and actually come up with alternatives that should make
> everyone happier.

I didn't see where you said that you were not strictly against
them. But ok.

I guess your concerns all boil down to 1) do not break DT backward
compatibility, 2) do not break what the firmware has set up, even on
older firmwares.

We got 1 covered already, but in order to cover 2, I guess we would
need both our solutions, that I don't really see as orthogonal.

How would something like adding optional clocks property, and if
found, doing the regular clk_* calls, and if not found, relying on
your solution work for you?

> If you're going to do SoC-specific bindings and resource management
> you are in fact implementing what Grant suggested in a
> subthread. You're implementing a dummy driver only for resource
> management, which isn't really a bad thing. It can serve as a
> placeholder for now until you add the real driver. And you can also
> use the simplefb driver to provide the framebuffer.

That could be an option too, but I'd rather avoid it if possible.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/b0ed6518/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:

> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.

> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Not really thought this through fully yet but would having phandles to
the relevant devices do the job?  Kind of lines up with Grant's idea of
having dummy drivers.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

We might want to do that in the future, though it's not always the case
that reset is the lowest power state.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

One thing that makes me a bit nervous about this approach in the context
of the regulator API is the frequency with which one finds shared
supplies.  I'm not sure if it's actually a big problem in practice but
it makes me worry a bit.  We could probably just do something like make
refcounting down to zero not actually disable anything for standard
regulators to deal with it which might be an idea anyway in the context
of this sort of dodge.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:

> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.

> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Not really thought this through fully yet but would having phandles to
the relevant devices do the job?  Kind of lines up with Grant's idea of
having dummy drivers.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

We might want to do that in the future, though it's not always the case
that reset is the lowest power state.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

One thing that makes me a bit nervous about this approach in the context
of the regulator API is the frequency with which one finds shared
supplies.  I'm not sure if it's actually a big problem in practice but
it makes me worry a bit.  We could probably just do something like make
refcounting down to zero not actually disable anything for standard
regulators to deal with it which might be an idea anyway in the context
of this sort of dodge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/c154322c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5421 bytes --]

On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> 
> > > With that said I think that Luc's approach is very sensible. I'm not
> > > sure what purpose in the universe DT is supposed to serve if not for
> > > _this_exact_case_. We have a nice abstracted driver, usable by many
> > > people. The hardware details of how it is hooked up at the board level
> > > can all be hidden behind stable DT bindings that everyone already uses.
> 
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Not really thought this through fully yet but would having phandles to
> the relevant devices do the job?  Kind of lines up with Grant's idea of
> having dummy drivers.

One of the arguments that came up during the discussion of the sunxi
patches is that simplefb is going to be used precisely because there is
no real driver for the display part of the SoC yet and nobody knows what
the binding will look like. So there's nothing to point at currently and
for the same reason having a dummy driver won't work. There's simply no
definition of what resources are needed.

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> We might want to do that in the future, though it's not always the case
> that reset is the lowest power state.

That proves my point. If we ever decide to assert resets by default
we'll have yet another subsystem that can potentially break existing
DTs.

In the end it brings us back to the very fundamental principles of DT
that's been causing so much pain. For things to work properly and in a
stable way you have to get the bindings right and complete from the
start. That is, it needs to describe every aspect of the hardware block
and all links to other components.

But there is no way you can do that for a virtual device like simplefb
because it is a generic abstraction for hardware that varies wildly. The
only way to make it work is to abstract away all the resource management
and consider it to be done elsewhere.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> One thing that makes me a bit nervous about this approach in the context
> of the regulator API is the frequency with which one finds shared
> supplies.  I'm not sure if it's actually a big problem in practice but
> it makes me worry a bit.  We could probably just do something like make
> refcounting down to zero not actually disable anything for standard
> regulators to deal with it which might be an idea anyway in the context
> of this sort of dodge.

Yes, that's sort of how I expected clk_ignore_unused to work. The way I
understood it, it would cause all unused clocks to be ignored (that is
stay enabled if they are).

Of course as Geert pointed out in another subthread, taking this all the
way means that we have to disable all power management because the
firmware device may be sharing resources with other devices and which
therefore are not unused. That's a pretty strong argument and I don't
have a solution for that. It is only really a problem for cases where
the firmware virtual device isn't taken over by a proper driver at some
point, though.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> 
> > > With that said I think that Luc's approach is very sensible. I'm not
> > > sure what purpose in the universe DT is supposed to serve if not for
> > > _this_exact_case_. We have a nice abstracted driver, usable by many
> > > people. The hardware details of how it is hooked up at the board level
> > > can all be hidden behind stable DT bindings that everyone already uses.
> 
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Not really thought this through fully yet but would having phandles to
> the relevant devices do the job?  Kind of lines up with Grant's idea of
> having dummy drivers.

One of the arguments that came up during the discussion of the sunxi
patches is that simplefb is going to be used precisely because there is
no real driver for the display part of the SoC yet and nobody knows what
the binding will look like. So there's nothing to point at currently and
for the same reason having a dummy driver won't work. There's simply no
definition of what resources are needed.

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> We might want to do that in the future, though it's not always the case
> that reset is the lowest power state.

That proves my point. If we ever decide to assert resets by default
we'll have yet another subsystem that can potentially break existing
DTs.

In the end it brings us back to the very fundamental principles of DT
that's been causing so much pain. For things to work properly and in a
stable way you have to get the bindings right and complete from the
start. That is, it needs to describe every aspect of the hardware block
and all links to other components.

But there is no way you can do that for a virtual device like simplefb
because it is a generic abstraction for hardware that varies wildly. The
only way to make it work is to abstract away all the resource management
and consider it to be done elsewhere.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> One thing that makes me a bit nervous about this approach in the context
> of the regulator API is the frequency with which one finds shared
> supplies.  I'm not sure if it's actually a big problem in practice but
> it makes me worry a bit.  We could probably just do something like make
> refcounting down to zero not actually disable anything for standard
> regulators to deal with it which might be an idea anyway in the context
> of this sort of dodge.

Yes, that's sort of how I expected clk_ignore_unused to work. The way I
understood it, it would cause all unused clocks to be ignored (that is
stay enabled if they are).

Of course as Geert pointed out in another subthread, taking this all the
way means that we have to disable all power management because the
firmware device may be sharing resources with other devices and which
therefore are not unused. That's a pretty strong argument and I don't
have a solution for that. It is only really a problem for cases where
the firmware virtual device isn't taken over by a proper driver at some
point, though.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/6c7f2fe8/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]

On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:

> > Not really thought this through fully yet but would having phandles to
> > the relevant devices do the job?  Kind of lines up with Grant's idea of
> > having dummy drivers.

> One of the arguments that came up during the discussion of the sunxi
> patches is that simplefb is going to be used precisely because there is
> no real driver for the display part of the SoC yet and nobody knows what
> the binding will look like. So there's nothing to point at currently and
> for the same reason having a dummy driver won't work. There's simply no
> definition of what resources are needed.

You may well need to extend the binding in future for an actual driver
but from the point of view of what's going into the block it really
should just be a case of reading the datasheet and mechanically typing
that in.  If we can work out how to say where the framebuffer is we
really ought to be able to work this stuff out.

> > > There may be also resets involved. Fortunately the reset framework is
> > > minimalistic enough not to care about asserting all unused resets at
> > > late_initcall. And other things like power domains may also need to be
> > > kept on.

> > We might want to do that in the future, though it's not always the case
> > that reset is the lowest power state.

> That proves my point. If we ever decide to assert resets by default
> we'll have yet another subsystem that can potentially break existing
> DTs.

OTOH given the level of breakage that's like to introduce we might just
decide not to do that...

> In the end it brings us back to the very fundamental principles of DT
> that's been causing so much pain. For things to work properly and in a
> stable way you have to get the bindings right and complete from the
> start. That is, it needs to describe every aspect of the hardware block
> and all links to other components.

Or we ned to introduce things in a conservative fashion which does cope
with backwards compatibility; it's definitely more work but it is
doable.

> > One thing that makes me a bit nervous about this approach in the context
> > of the regulator API is the frequency with which one finds shared
> > supplies.  I'm not sure if it's actually a big problem in practice but
> > it makes me worry a bit.  We could probably just do something like make
> > refcounting down to zero not actually disable anything for standard
> > regulators to deal with it which might be an idea anyway in the context
> > of this sort of dodge.

> Yes, that's sort of how I expected clk_ignore_unused to work. The way I
> understood it, it would cause all unused clocks to be ignored (that is
> stay enabled if they are).

> Of course as Geert pointed out in another subthread, taking this all the
> way means that we have to disable all power management because the
> firmware device may be sharing resources with other devices and which
> therefore are not unused. That's a pretty strong argument and I don't
> have a solution for that. It is only really a problem for cases where
> the firmware virtual device isn't taken over by a proper driver at some
> point, though.

Indeed, and we also run into trouble for things where we actually need
to really turn off the resource for some reason (MMC has some needs here
for example).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:

> > Not really thought this through fully yet but would having phandles to
> > the relevant devices do the job?  Kind of lines up with Grant's idea of
> > having dummy drivers.

> One of the arguments that came up during the discussion of the sunxi
> patches is that simplefb is going to be used precisely because there is
> no real driver for the display part of the SoC yet and nobody knows what
> the binding will look like. So there's nothing to point at currently and
> for the same reason having a dummy driver won't work. There's simply no
> definition of what resources are needed.

You may well need to extend the binding in future for an actual driver
but from the point of view of what's going into the block it really
should just be a case of reading the datasheet and mechanically typing
that in.  If we can work out how to say where the framebuffer is we
really ought to be able to work this stuff out.

> > > There may be also resets involved. Fortunately the reset framework is
> > > minimalistic enough not to care about asserting all unused resets at
> > > late_initcall. And other things like power domains may also need to be
> > > kept on.

> > We might want to do that in the future, though it's not always the case
> > that reset is the lowest power state.

> That proves my point. If we ever decide to assert resets by default
> we'll have yet another subsystem that can potentially break existing
> DTs.

OTOH given the level of breakage that's like to introduce we might just
decide not to do that...

> In the end it brings us back to the very fundamental principles of DT
> that's been causing so much pain. For things to work properly and in a
> stable way you have to get the bindings right and complete from the
> start. That is, it needs to describe every aspect of the hardware block
> and all links to other components.

Or we ned to introduce things in a conservative fashion which does cope
with backwards compatibility; it's definitely more work but it is
doable.

> > One thing that makes me a bit nervous about this approach in the context
> > of the regulator API is the frequency with which one finds shared
> > supplies.  I'm not sure if it's actually a big problem in practice but
> > it makes me worry a bit.  We could probably just do something like make
> > refcounting down to zero not actually disable anything for standard
> > regulators to deal with it which might be an idea anyway in the context
> > of this sort of dodge.

> Yes, that's sort of how I expected clk_ignore_unused to work. The way I
> understood it, it would cause all unused clocks to be ignored (that is
> stay enabled if they are).

> Of course as Geert pointed out in another subthread, taking this all the
> way means that we have to disable all power management because the
> firmware device may be sharing resources with other devices and which
> therefore are not unused. That's a pretty strong argument and I don't
> have a solution for that. It is only really a problem for cases where
> the firmware virtual device isn't taken over by a proper driver at some
> point, though.

Indeed, and we also run into trouble for things where we actually need
to really turn off the resource for some reason (MMC has some needs here
for example).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140930/004a1194/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6798 bytes --]

On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:
> 
> > > Not really thought this through fully yet but would having phandles to
> > > the relevant devices do the job?  Kind of lines up with Grant's idea of
> > > having dummy drivers.
> 
> > One of the arguments that came up during the discussion of the sunxi
> > patches is that simplefb is going to be used precisely because there is
> > no real driver for the display part of the SoC yet and nobody knows what
> > the binding will look like. So there's nothing to point at currently and
> > for the same reason having a dummy driver won't work. There's simply no
> > definition of what resources are needed.
> 
> You may well need to extend the binding in future for an actual driver
> but from the point of view of what's going into the block it really
> should just be a case of reading the datasheet and mechanically typing
> that in.  If we can work out how to say where the framebuffer is we
> really ought to be able to work this stuff out.

I agree from a technical point of view. However given the dynamically
generated nature of the node the problem is more of a logistical nature.
As we've seen U-Boot is being enabled to add clocks to the simplefb node
but I'm fairly certain that there's a regulator somewhere that needs to
be enabled too, be it for powering the display controller, the panel or
the backlight. I wouldn't even be surprised if there were one for each
of those. If so simplefb on this board will break when the regulators
are described in the kernel's DTS.

If we don't consider this a problem then the whole DT ABI stability
business is a farce.

> > > > There may be also resets involved. Fortunately the reset framework is
> > > > minimalistic enough not to care about asserting all unused resets at
> > > > late_initcall. And other things like power domains may also need to be
> > > > kept on.
> 
> > > We might want to do that in the future, though it's not always the case
> > > that reset is the lowest power state.
> 
> > That proves my point. If we ever decide to assert resets by default
> > we'll have yet another subsystem that can potentially break existing
> > DTs.
> 
> OTOH given the level of breakage that's like to introduce we might just
> decide not to do that...

It might be the sensible thing to do in most cases. I think there's a
legitimate reason not to trust firmware. However in case of simplefb we
already do, so I think having a sort of flag to signal that we do trust
firmware would allow us to cope with these situation much better.

> > In the end it brings us back to the very fundamental principles of DT
> > that's been causing so much pain. For things to work properly and in a
> > stable way you have to get the bindings right and complete from the
> > start. That is, it needs to describe every aspect of the hardware block
> > and all links to other components.
> 
> Or we ned to introduce things in a conservative fashion which does cope
> with backwards compatibility; it's definitely more work but it is
> doable.

Is it? I thought the only way to keep backwards compatibility was by
making any new properties optional. But if those properties add vital
information for the device to work you have to come up with a sensible
default to keep existing setups working that lack the new properties.
Doing that is not going to scale very well. It has a chance of working
for hardware-specific drivers because we may be able to derive the
default from the SoC generation or even the machine compatible. But I
don't see how it could work for something that's supposed to be generic
like simplefb.

I'm hoping that there's a better way that I don't know about, because it
would certainly make a lot of things much easier.

> > > One thing that makes me a bit nervous about this approach in the context
> > > of the regulator API is the frequency with which one finds shared
> > > supplies.  I'm not sure if it's actually a big problem in practice but
> > > it makes me worry a bit.  We could probably just do something like make
> > > refcounting down to zero not actually disable anything for standard
> > > regulators to deal with it which might be an idea anyway in the context
> > > of this sort of dodge.
> 
> > Yes, that's sort of how I expected clk_ignore_unused to work. The way I
> > understood it, it would cause all unused clocks to be ignored (that is
> > stay enabled if they are).
> 
> > Of course as Geert pointed out in another subthread, taking this all the
> > way means that we have to disable all power management because the
> > firmware device may be sharing resources with other devices and which
> > therefore are not unused. That's a pretty strong argument and I don't
> > have a solution for that. It is only really a problem for cases where
> > the firmware virtual device isn't taken over by a proper driver at some
> > point, though.
> 
> Indeed, and we also run into trouble for things where we actually need
> to really turn off the resource for some reason (MMC has some needs here
> for example).

So if disabling power management wholesale isn't going to be an option,
what's the alternative? I originally proposed that the clock drivers
could be modified to not disable clocks that are known to be problematic
with simplefb. People objected to that because they thought it would be
impractical to determine which clocks are involved with display across
various boards.

Handling this in the clock driver has worked remarkably well for us on
Tegra, but perhaps that's just because Tegra is an unusually sane design
to begin with.

On the other hand you cannot do that for regulators in the drivers
because they can be used on a wide variety of boards. But at least for
regulators there's a way to handle that kind of thing in DT by marking
the regulators always-on. That allows this to become a board-integration
issue and we can actually stage things in piece by piece. For example as
long as the board doesn't support a proper display driver with all the
needed resources hooked up the regulators would be marked always-on and
allow display to keep running as set up by firmware. But once they are
properly hooked up with the real driver the always-on property can be
removed and things will keep working.

What the above doesn't handle well is seamless transition from simplefb
to a real driver, which I think is going to be a useful feature to have
and it will need to keep working for much longer than the other use-case
where simplefb is the primary framebuffer.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:
> 
> > > Not really thought this through fully yet but would having phandles to
> > > the relevant devices do the job?  Kind of lines up with Grant's idea of
> > > having dummy drivers.
> 
> > One of the arguments that came up during the discussion of the sunxi
> > patches is that simplefb is going to be used precisely because there is
> > no real driver for the display part of the SoC yet and nobody knows what
> > the binding will look like. So there's nothing to point at currently and
> > for the same reason having a dummy driver won't work. There's simply no
> > definition of what resources are needed.
> 
> You may well need to extend the binding in future for an actual driver
> but from the point of view of what's going into the block it really
> should just be a case of reading the datasheet and mechanically typing
> that in.  If we can work out how to say where the framebuffer is we
> really ought to be able to work this stuff out.

I agree from a technical point of view. However given the dynamically
generated nature of the node the problem is more of a logistical nature.
As we've seen U-Boot is being enabled to add clocks to the simplefb node
but I'm fairly certain that there's a regulator somewhere that needs to
be enabled too, be it for powering the display controller, the panel or
the backlight. I wouldn't even be surprised if there were one for each
of those. If so simplefb on this board will break when the regulators
are described in the kernel's DTS.

If we don't consider this a problem then the whole DT ABI stability
business is a farce.

> > > > There may be also resets involved. Fortunately the reset framework is
> > > > minimalistic enough not to care about asserting all unused resets at
> > > > late_initcall. And other things like power domains may also need to be
> > > > kept on.
> 
> > > We might want to do that in the future, though it's not always the case
> > > that reset is the lowest power state.
> 
> > That proves my point. If we ever decide to assert resets by default
> > we'll have yet another subsystem that can potentially break existing
> > DTs.
> 
> OTOH given the level of breakage that's like to introduce we might just
> decide not to do that...

It might be the sensible thing to do in most cases. I think there's a
legitimate reason not to trust firmware. However in case of simplefb we
already do, so I think having a sort of flag to signal that we do trust
firmware would allow us to cope with these situation much better.

> > In the end it brings us back to the very fundamental principles of DT
> > that's been causing so much pain. For things to work properly and in a
> > stable way you have to get the bindings right and complete from the
> > start. That is, it needs to describe every aspect of the hardware block
> > and all links to other components.
> 
> Or we ned to introduce things in a conservative fashion which does cope
> with backwards compatibility; it's definitely more work but it is
> doable.

Is it? I thought the only way to keep backwards compatibility was by
making any new properties optional. But if those properties add vital
information for the device to work you have to come up with a sensible
default to keep existing setups working that lack the new properties.
Doing that is not going to scale very well. It has a chance of working
for hardware-specific drivers because we may be able to derive the
default from the SoC generation or even the machine compatible. But I
don't see how it could work for something that's supposed to be generic
like simplefb.

I'm hoping that there's a better way that I don't know about, because it
would certainly make a lot of things much easier.

> > > One thing that makes me a bit nervous about this approach in the context
> > > of the regulator API is the frequency with which one finds shared
> > > supplies.  I'm not sure if it's actually a big problem in practice but
> > > it makes me worry a bit.  We could probably just do something like make
> > > refcounting down to zero not actually disable anything for standard
> > > regulators to deal with it which might be an idea anyway in the context
> > > of this sort of dodge.
> 
> > Yes, that's sort of how I expected clk_ignore_unused to work. The way I
> > understood it, it would cause all unused clocks to be ignored (that is
> > stay enabled if they are).
> 
> > Of course as Geert pointed out in another subthread, taking this all the
> > way means that we have to disable all power management because the
> > firmware device may be sharing resources with other devices and which
> > therefore are not unused. That's a pretty strong argument and I don't
> > have a solution for that. It is only really a problem for cases where
> > the firmware virtual device isn't taken over by a proper driver at some
> > point, though.
> 
> Indeed, and we also run into trouble for things where we actually need
> to really turn off the resource for some reason (MMC has some needs here
> for example).

So if disabling power management wholesale isn't going to be an option,
what's the alternative? I originally proposed that the clock drivers
could be modified to not disable clocks that are known to be problematic
with simplefb. People objected to that because they thought it would be
impractical to determine which clocks are involved with display across
various boards.

Handling this in the clock driver has worked remarkably well for us on
Tegra, but perhaps that's just because Tegra is an unusually sane design
to begin with.

On the other hand you cannot do that for regulators in the drivers
because they can be used on a wide variety of boards. But at least for
regulators there's a way to handle that kind of thing in DT by marking
the regulators always-on. That allows this to become a board-integration
issue and we can actually stage things in piece by piece. For example as
long as the board doesn't support a proper display driver with all the
needed resources hooked up the regulators would be marked always-on and
allow display to keep running as set up by firmware. But once they are
properly hooked up with the real driver the always-on property can be
removed and things will keep working.

What the above doesn't handle well is seamless transition from simplefb
to a real driver, which I think is going to be a useful feature to have
and it will need to keep working for much longer than the other use-case
where simplefb is the primary framebuffer.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/93026c37/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:

> > You may well need to extend the binding in future for an actual driver
> > but from the point of view of what's going into the block it really
> > should just be a case of reading the datasheet and mechanically typing
> > that in.  If we can work out how to say where the framebuffer is we
> > really ought to be able to work this stuff out.

> I agree from a technical point of view. However given the dynamically
> generated nature of the node the problem is more of a logistical nature.
> As we've seen U-Boot is being enabled to add clocks to the simplefb node
> but I'm fairly certain that there's a regulator somewhere that needs to
> be enabled too, be it for powering the display controller, the panel or
> the backlight. I wouldn't even be surprised if there were one for each
> of those. If so simplefb on this board will break when the regulators
> are described in the kernel's DTS.

> If we don't consider this a problem then the whole DT ABI stability
> business is a farce.

I think you're setting constraints on the implementation you want to see
which make it unworkable but I don't think those constraints are needed.
You're starting from the position that the DT needs to be updated without
the bootloader and that the DT must not contain any hint of simplefb as
shipped separately.  That's never going to work well as far as I can see
but doesn't seem like an ABI stability issue, or at least not a
reasonable one.

Either the bootloader needs to be updated along with the DT or the DT
needs to offer the bootloader a stable interface of its own for adding
the description of what it has set up (like a default disabled node
with the FB description, I'm sure other ideas are possible).  Obviously
the goal with the stable ABI is that the DT will be distributed along
with the platform.

> > > Of course as Geert pointed out in another subthread, taking this all the
> > > way means that we have to disable all power management because the
> > > firmware device may be sharing resources with other devices and which
> > > therefore are not unused. That's a pretty strong argument and I don't
> > > have a solution for that. It is only really a problem for cases where
> > > the firmware virtual device isn't taken over by a proper driver at some
> > > point, though.

> > Indeed, and we also run into trouble for things where we actually need
> > to really turn off the resource for some reason (MMC has some needs here
> > for example).

> So if disabling power management wholesale isn't going to be an option,
> what's the alternative? I originally proposed that the clock drivers
> could be modified to not disable clocks that are known to be problematic
> with simplefb. People objected to that because they thought it would be
> impractical to determine which clocks are involved with display across
> various boards.

> Handling this in the clock driver has worked remarkably well for us on
> Tegra, but perhaps that's just because Tegra is an unusually sane design
> to begin with.

It's probably more that you've just not run into the corner cases yet -
if the display is mostly driven from the standard controller on the SoC
you've got a pretty good idea what's going to be happening.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
> On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:

> > You may well need to extend the binding in future for an actual driver
> > but from the point of view of what's going into the block it really
> > should just be a case of reading the datasheet and mechanically typing
> > that in.  If we can work out how to say where the framebuffer is we
> > really ought to be able to work this stuff out.

> I agree from a technical point of view. However given the dynamically
> generated nature of the node the problem is more of a logistical nature.
> As we've seen U-Boot is being enabled to add clocks to the simplefb node
> but I'm fairly certain that there's a regulator somewhere that needs to
> be enabled too, be it for powering the display controller, the panel or
> the backlight. I wouldn't even be surprised if there were one for each
> of those. If so simplefb on this board will break when the regulators
> are described in the kernel's DTS.

> If we don't consider this a problem then the whole DT ABI stability
> business is a farce.

I think you're setting constraints on the implementation you want to see
which make it unworkable but I don't think those constraints are needed.
You're starting from the position that the DT needs to be updated without
the bootloader and that the DT must not contain any hint of simplefb as
shipped separately.  That's never going to work well as far as I can see
but doesn't seem like an ABI stability issue, or at least not a
reasonable one.

Either the bootloader needs to be updated along with the DT or the DT
needs to offer the bootloader a stable interface of its own for adding
the description of what it has set up (like a default disabled node
with the FB description, I'm sure other ideas are possible).  Obviously
the goal with the stable ABI is that the DT will be distributed along
with the platform.

> > > Of course as Geert pointed out in another subthread, taking this all the
> > > way means that we have to disable all power management because the
> > > firmware device may be sharing resources with other devices and which
> > > therefore are not unused. That's a pretty strong argument and I don't
> > > have a solution for that. It is only really a problem for cases where
> > > the firmware virtual device isn't taken over by a proper driver at some
> > > point, though.

> > Indeed, and we also run into trouble for things where we actually need
> > to really turn off the resource for some reason (MMC has some needs here
> > for example).

> So if disabling power management wholesale isn't going to be an option,
> what's the alternative? I originally proposed that the clock drivers
> could be modified to not disable clocks that are known to be problematic
> with simplefb. People objected to that because they thought it would be
> impractical to determine which clocks are involved with display across
> various boards.

> Handling this in the clock driver has worked remarkably well for us on
> Tegra, but perhaps that's just because Tegra is an unusually sane design
> to begin with.

It's probably more that you've just not run into the corner cases yet -
if the display is mostly driven from the standard controller on the SoC
you've got a pretty good idea what's going to be happening.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/09e50061/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]

On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> 
> > > You may well need to extend the binding in future for an actual driver
> > > but from the point of view of what's going into the block it really
> > > should just be a case of reading the datasheet and mechanically typing
> > > that in.  If we can work out how to say where the framebuffer is we
> > > really ought to be able to work this stuff out.
> 
> > I agree from a technical point of view. However given the dynamically
> > generated nature of the node the problem is more of a logistical nature.
> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
> > but I'm fairly certain that there's a regulator somewhere that needs to
> > be enabled too, be it for powering the display controller, the panel or
> > the backlight. I wouldn't even be surprised if there were one for each
> > of those. If so simplefb on this board will break when the regulators
> > are described in the kernel's DTS.
> 
> > If we don't consider this a problem then the whole DT ABI stability
> > business is a farce.
> 
> I think you're setting constraints on the implementation you want to see
> which make it unworkable but I don't think those constraints are needed.
> You're starting from the position that the DT needs to be updated without
> the bootloader

No, what I'm saying is that what the simplefb driver expects and what
the bootloader sets up may diverge as resource drivers are added to the
kernel. The DT /could/ be updated without the bootloader. You may only
be able to replace the DTB but not the bootloader on a given platform.

>                and that the DT must not contain any hint of simplefb as
> shipped separately.

Well, I don't think it should because it describes the same resources
that the device tree node for the real device already describes. But
perhaps this is one of the cases where duplication isn't all that bad?

>                     That's never going to work well as far as I can see
> but doesn't seem like an ABI stability issue, or at least not a
> reasonable one.

It would work well under the assumption that the kernel wouldn't be
touching any of the resources that simplefb depends on. If that's not a
reasonable assumption then I think we can't make simplefb work the way
it's currently written.

> Either the bootloader needs to be updated along with the DT

I thought we had decided that this was one of the big no-nos. But
perhaps I'm misremembering.

>                                                             or the DT
> needs to offer the bootloader a stable interface of its own for adding
> the description of what it has set up (like a default disabled node
> with the FB description, I'm sure other ideas are possible).  Obviously
> the goal with the stable ABI is that the DT will be distributed along
> with the platform.

So instead of pretending that this is in any way generic, maybe a better
idea would be to provide code in DRM/KMS drivers that is called early,
grabs all the resources as defined in the binding for the device and
then instantiates simplefb using the parsed information. Which is kind
of the stub driver that Grant had suggested.

Of course that means duplicating most of the resource handling from the
real driver into this stub driver. And it means that this part of the
driver would have to be built into the kernel and bloat it some more.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> 
> > > You may well need to extend the binding in future for an actual driver
> > > but from the point of view of what's going into the block it really
> > > should just be a case of reading the datasheet and mechanically typing
> > > that in.  If we can work out how to say where the framebuffer is we
> > > really ought to be able to work this stuff out.
> 
> > I agree from a technical point of view. However given the dynamically
> > generated nature of the node the problem is more of a logistical nature.
> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
> > but I'm fairly certain that there's a regulator somewhere that needs to
> > be enabled too, be it for powering the display controller, the panel or
> > the backlight. I wouldn't even be surprised if there were one for each
> > of those. If so simplefb on this board will break when the regulators
> > are described in the kernel's DTS.
> 
> > If we don't consider this a problem then the whole DT ABI stability
> > business is a farce.
> 
> I think you're setting constraints on the implementation you want to see
> which make it unworkable but I don't think those constraints are needed.
> You're starting from the position that the DT needs to be updated without
> the bootloader

No, what I'm saying is that what the simplefb driver expects and what
the bootloader sets up may diverge as resource drivers are added to the
kernel. The DT /could/ be updated without the bootloader. You may only
be able to replace the DTB but not the bootloader on a given platform.

>                and that the DT must not contain any hint of simplefb as
> shipped separately.

Well, I don't think it should because it describes the same resources
that the device tree node for the real device already describes. But
perhaps this is one of the cases where duplication isn't all that bad?

>                     That's never going to work well as far as I can see
> but doesn't seem like an ABI stability issue, or at least not a
> reasonable one.

It would work well under the assumption that the kernel wouldn't be
touching any of the resources that simplefb depends on. If that's not a
reasonable assumption then I think we can't make simplefb work the way
it's currently written.

> Either the bootloader needs to be updated along with the DT

I thought we had decided that this was one of the big no-nos. But
perhaps I'm misremembering.

>                                                             or the DT
> needs to offer the bootloader a stable interface of its own for adding
> the description of what it has set up (like a default disabled node
> with the FB description, I'm sure other ideas are possible).  Obviously
> the goal with the stable ABI is that the DT will be distributed along
> with the platform.

So instead of pretending that this is in any way generic, maybe a better
idea would be to provide code in DRM/KMS drivers that is called early,
grabs all the resources as defined in the binding for the device and
then instantiates simplefb using the parsed information. Which is kind
of the stub driver that Grant had suggested.

Of course that means duplicating most of the resource handling from the
real driver into this stub driver. And it means that this part of the
driver would have to be built into the kernel and bloat it some more.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/7c272c8c/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>
>> > > You may well need to extend the binding in future for an actual driver
>> > > but from the point of view of what's going into the block it really
>> > > should just be a case of reading the datasheet and mechanically typing
>> > > that in.  If we can work out how to say where the framebuffer is we
>> > > really ought to be able to work this stuff out.
>>
>> > I agree from a technical point of view. However given the dynamically
>> > generated nature of the node the problem is more of a logistical nature.
>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>> > but I'm fairly certain that there's a regulator somewhere that needs to
>> > be enabled too, be it for powering the display controller, the panel or
>> > the backlight. I wouldn't even be surprised if there were one for each
>> > of those. If so simplefb on this board will break when the regulators
>> > are described in the kernel's DTS.
>>
>> > If we don't consider this a problem then the whole DT ABI stability
>> > business is a farce.
>>
>> I think you're setting constraints on the implementation you want to see
>> which make it unworkable but I don't think those constraints are needed.
>> You're starting from the position that the DT needs to be updated without
>> the bootloader
>
> No, what I'm saying is that what the simplefb driver expects and what
> the bootloader sets up may diverge as resource drivers are added to the
> kernel. The DT /could/ be updated without the bootloader. You may only
> be able to replace the DTB but not the bootloader on a given platform.

simplefb should be a boot console and not survive past the boot
process. Trying to get a 'generic' console driver to survive the boot
process is not a generic problem. There are about 1,000 messages in
these threads explaining why this is not a generic problem.

All of these clock and regulator issues would go away by building a
device specific framebuffer driver.  A device specific framebuffer
driver can be written in a day or two, it is far simpler than a KMS
driver. This driver would how to parse the device specific device tree
node and do the right thing with the regulators/clocks.

So simplefb is built-in and used for early boot.  During the boot
process a device specific framebuffer driver loads.  This device
specific driver takes over for simplefb and can become the user space
console.

If the device specific framebuffer does not get loaded, then simplefb
is going to stop working when the clocks and regulators get shut off.
But that is what should happen.



>
>>                and that the DT must not contain any hint of simplefb as
>> shipped separately.
>
> Well, I don't think it should because it describes the same resources
> that the device tree node for the real device already describes. But
> perhaps this is one of the cases where duplication isn't all that bad?
>
>>                     That's never going to work well as far as I can see
>> but doesn't seem like an ABI stability issue, or at least not a
>> reasonable one.
>
> It would work well under the assumption that the kernel wouldn't be
> touching any of the resources that simplefb depends on. If that's not a
> reasonable assumption then I think we can't make simplefb work the way
> it's currently written.
>
>> Either the bootloader needs to be updated along with the DT
>
> I thought we had decided that this was one of the big no-nos. But
> perhaps I'm misremembering.
>
>>                                                             or the DT
>> needs to offer the bootloader a stable interface of its own for adding
>> the description of what it has set up (like a default disabled node
>> with the FB description, I'm sure other ideas are possible).  Obviously
>> the goal with the stable ABI is that the DT will be distributed along
>> with the platform.
>
> So instead of pretending that this is in any way generic, maybe a better
> idea would be to provide code in DRM/KMS drivers that is called early,
> grabs all the resources as defined in the binding for the device and
> then instantiates simplefb using the parsed information. Which is kind
> of the stub driver that Grant had suggested.
>
> Of course that means duplicating most of the resource handling from the
> real driver into this stub driver. And it means that this part of the
> driver would have to be built into the kernel and bloat it some more.
>
> Thierry



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>
>> > > You may well need to extend the binding in future for an actual driver
>> > > but from the point of view of what's going into the block it really
>> > > should just be a case of reading the datasheet and mechanically typing
>> > > that in.  If we can work out how to say where the framebuffer is we
>> > > really ought to be able to work this stuff out.
>>
>> > I agree from a technical point of view. However given the dynamically
>> > generated nature of the node the problem is more of a logistical nature.
>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>> > but I'm fairly certain that there's a regulator somewhere that needs to
>> > be enabled too, be it for powering the display controller, the panel or
>> > the backlight. I wouldn't even be surprised if there were one for each
>> > of those. If so simplefb on this board will break when the regulators
>> > are described in the kernel's DTS.
>>
>> > If we don't consider this a problem then the whole DT ABI stability
>> > business is a farce.
>>
>> I think you're setting constraints on the implementation you want to see
>> which make it unworkable but I don't think those constraints are needed.
>> You're starting from the position that the DT needs to be updated without
>> the bootloader
>
> No, what I'm saying is that what the simplefb driver expects and what
> the bootloader sets up may diverge as resource drivers are added to the
> kernel. The DT /could/ be updated without the bootloader. You may only
> be able to replace the DTB but not the bootloader on a given platform.

simplefb should be a boot console and not survive past the boot
process. Trying to get a 'generic' console driver to survive the boot
process is not a generic problem. There are about 1,000 messages in
these threads explaining why this is not a generic problem.

All of these clock and regulator issues would go away by building a
device specific framebuffer driver.  A device specific framebuffer
driver can be written in a day or two, it is far simpler than a KMS
driver. This driver would how to parse the device specific device tree
node and do the right thing with the regulators/clocks.

So simplefb is built-in and used for early boot.  During the boot
process a device specific framebuffer driver loads.  This device
specific driver takes over for simplefb and can become the user space
console.

If the device specific framebuffer does not get loaded, then simplefb
is going to stop working when the clocks and regulators get shut off.
But that is what should happen.



>
>>                and that the DT must not contain any hint of simplefb as
>> shipped separately.
>
> Well, I don't think it should because it describes the same resources
> that the device tree node for the real device already describes. But
> perhaps this is one of the cases where duplication isn't all that bad?
>
>>                     That's never going to work well as far as I can see
>> but doesn't seem like an ABI stability issue, or at least not a
>> reasonable one.
>
> It would work well under the assumption that the kernel wouldn't be
> touching any of the resources that simplefb depends on. If that's not a
> reasonable assumption then I think we can't make simplefb work the way
> it's currently written.
>
>> Either the bootloader needs to be updated along with the DT
>
> I thought we had decided that this was one of the big no-nos. But
> perhaps I'm misremembering.
>
>>                                                             or the DT
>> needs to offer the bootloader a stable interface of its own for adding
>> the description of what it has set up (like a default disabled node
>> with the FB description, I'm sure other ideas are possible).  Obviously
>> the goal with the stable ABI is that the DT will be distributed along
>> with the platform.
>
> So instead of pretending that this is in any way generic, maybe a better
> idea would be to provide code in DRM/KMS drivers that is called early,
> grabs all the resources as defined in the binding for the device and
> then instantiates simplefb using the parsed information. Which is kind
> of the stub driver that Grant had suggested.
>
> Of course that means duplicating most of the resource handling from the
> real driver into this stub driver. And it means that this part of the
> driver would have to be built into the kernel and bloat it some more.
>
> Thierry



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 1 October 2014 15:01, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
>> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>>
>>> > > You may well need to extend the binding in future for an actual driver
>>> > > but from the point of view of what's going into the block it really
>>> > > should just be a case of reading the datasheet and mechanically typing
>>> > > that in.  If we can work out how to say where the framebuffer is we
>>> > > really ought to be able to work this stuff out.
>>>
>>> > I agree from a technical point of view. However given the dynamically
>>> > generated nature of the node the problem is more of a logistical nature.
>>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>>> > but I'm fairly certain that there's a regulator somewhere that needs to
>>> > be enabled too, be it for powering the display controller, the panel or
>>> > the backlight. I wouldn't even be surprised if there were one for each
>>> > of those. If so simplefb on this board will break when the regulators
>>> > are described in the kernel's DTS.
>>>
>>> > If we don't consider this a problem then the whole DT ABI stability
>>> > business is a farce.
>>>
>>> I think you're setting constraints on the implementation you want to see
>>> which make it unworkable but I don't think those constraints are needed.
>>> You're starting from the position that the DT needs to be updated without
>>> the bootloader
>>
>> No, what I'm saying is that what the simplefb driver expects and what
>> the bootloader sets up may diverge as resource drivers are added to the
>> kernel. The DT /could/ be updated without the bootloader. You may only
>> be able to replace the DTB but not the bootloader on a given platform.
>
> simplefb should be a boot console and not survive past the boot
> process. Trying to get a 'generic' console driver to survive the boot
> process is not a generic problem. There are about 1,000 messages in
> these threads explaining why this is not a generic problem.
>
> All of these clock and regulator issues would go away by building a
> device specific framebuffer driver.  A device specific framebuffer
> driver can be written in a day or two, it is far simpler than a KMS
> driver. This driver would how to parse the device specific device tree
> node and do the right thing with the regulators/clocks.

How it would know?

You need different clocks for LCD and different clocks for HDMI.

Unless it is a real driver that can drive either it can tell which is
enabled or u-boot has to tell it or you have to write a fixed entry
for the configuration you want in the DT and configure u-boot
accordingly by hand as well.

>
> So simplefb is built-in and used for early boot.  During the boot
> process a device specific framebuffer driver loads.  This device
> specific driver takes over for simplefb and can become the user space
> console.
>
> If the device specific framebuffer does not get loaded, then simplefb
> is going to stop working when the clocks and regulators get shut off.
> But that is what should happen.

Why it should be so?

It is reasonable to want working console on device which has u-boot or
other firmware graphics support but the support in kernel is still
under development.

Also the 'boot end' for kernel when it frees the clocks is way earlier
than the 'boot end' for the distribution which ends when you reach
certain init goal like multiuser environment. There is a lot between
and once the kernel hands over to init it can never tell what's going
on.

Since a modular KMS driver would load way later than the moment when
'boot end' is reached for kernel the simple function as early console
would break.

Also if you prevented resource management from happening during this
'booting' stage you could not safely load drivers during that time
which kind of defeats the purpose of this stage.

Because either the kernel can do resource management and give
resources to drivers that are loaded or it cannot do either.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 1 October 2014 15:01, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
>> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>>
>>> > > You may well need to extend the binding in future for an actual driver
>>> > > but from the point of view of what's going into the block it really
>>> > > should just be a case of reading the datasheet and mechanically typing
>>> > > that in.  If we can work out how to say where the framebuffer is we
>>> > > really ought to be able to work this stuff out.
>>>
>>> > I agree from a technical point of view. However given the dynamically
>>> > generated nature of the node the problem is more of a logistical nature.
>>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>>> > but I'm fairly certain that there's a regulator somewhere that needs to
>>> > be enabled too, be it for powering the display controller, the panel or
>>> > the backlight. I wouldn't even be surprised if there were one for each
>>> > of those. If so simplefb on this board will break when the regulators
>>> > are described in the kernel's DTS.
>>>
>>> > If we don't consider this a problem then the whole DT ABI stability
>>> > business is a farce.
>>>
>>> I think you're setting constraints on the implementation you want to see
>>> which make it unworkable but I don't think those constraints are needed.
>>> You're starting from the position that the DT needs to be updated without
>>> the bootloader
>>
>> No, what I'm saying is that what the simplefb driver expects and what
>> the bootloader sets up may diverge as resource drivers are added to the
>> kernel. The DT /could/ be updated without the bootloader. You may only
>> be able to replace the DTB but not the bootloader on a given platform.
>
> simplefb should be a boot console and not survive past the boot
> process. Trying to get a 'generic' console driver to survive the boot
> process is not a generic problem. There are about 1,000 messages in
> these threads explaining why this is not a generic problem.
>
> All of these clock and regulator issues would go away by building a
> device specific framebuffer driver.  A device specific framebuffer
> driver can be written in a day or two, it is far simpler than a KMS
> driver. This driver would how to parse the device specific device tree
> node and do the right thing with the regulators/clocks.

How it would know?

You need different clocks for LCD and different clocks for HDMI.

Unless it is a real driver that can drive either it can tell which is
enabled or u-boot has to tell it or you have to write a fixed entry
for the configuration you want in the DT and configure u-boot
accordingly by hand as well.

>
> So simplefb is built-in and used for early boot.  During the boot
> process a device specific framebuffer driver loads.  This device
> specific driver takes over for simplefb and can become the user space
> console.
>
> If the device specific framebuffer does not get loaded, then simplefb
> is going to stop working when the clocks and regulators get shut off.
> But that is what should happen.

Why it should be so?

It is reasonable to want working console on device which has u-boot or
other firmware graphics support but the support in kernel is still
under development.

Also the 'boot end' for kernel when it frees the clocks is way earlier
than the 'boot end' for the distribution which ends when you reach
certain init goal like multiuser environment. There is a lot between
and once the kernel hands over to init it can never tell what's going
on.

Since a modular KMS driver would load way later than the moment when
'boot end' is reached for kernel the simple function as early console
would break.

Also if you prevented resource management from happening during this
'booting' stage you could not safely load drivers during that time
which kind of defeats the purpose of this stage.

Because either the kernel can do resource management and give
resources to drivers that are loaded or it cannot do either.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Wed, Oct 1, 2014 at 9:17 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 1 October 2014 15:01, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
>>> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>>>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>>>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>>>
>>>> > > You may well need to extend the binding in future for an actual driver
>>>> > > but from the point of view of what's going into the block it really
>>>> > > should just be a case of reading the datasheet and mechanically typing
>>>> > > that in.  If we can work out how to say where the framebuffer is we
>>>> > > really ought to be able to work this stuff out.
>>>>
>>>> > I agree from a technical point of view. However given the dynamically
>>>> > generated nature of the node the problem is more of a logistical nature.
>>>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>>>> > but I'm fairly certain that there's a regulator somewhere that needs to
>>>> > be enabled too, be it for powering the display controller, the panel or
>>>> > the backlight. I wouldn't even be surprised if there were one for each
>>>> > of those. If so simplefb on this board will break when the regulators
>>>> > are described in the kernel's DTS.
>>>>
>>>> > If we don't consider this a problem then the whole DT ABI stability
>>>> > business is a farce.
>>>>
>>>> I think you're setting constraints on the implementation you want to see
>>>> which make it unworkable but I don't think those constraints are needed.
>>>> You're starting from the position that the DT needs to be updated without
>>>> the bootloader
>>>
>>> No, what I'm saying is that what the simplefb driver expects and what
>>> the bootloader sets up may diverge as resource drivers are added to the
>>> kernel. The DT /could/ be updated without the bootloader. You may only
>>> be able to replace the DTB but not the bootloader on a given platform.
>>
>> simplefb should be a boot console and not survive past the boot
>> process. Trying to get a 'generic' console driver to survive the boot
>> process is not a generic problem. There are about 1,000 messages in
>> these threads explaining why this is not a generic problem.
>>
>> All of these clock and regulator issues would go away by building a
>> device specific framebuffer driver.  A device specific framebuffer
>> driver can be written in a day or two, it is far simpler than a KMS
>> driver. This driver would how to parse the device specific device tree
>> node and do the right thing with the regulators/clocks.
>
> How it would know?
>
> You need different clocks for LCD and different clocks for HDMI.
>
> Unless it is a real driver that can drive either it can tell which is
> enabled or u-boot has to tell it or you have to write a fixed entry
> for the configuration you want in the DT and configure u-boot
> accordingly by hand as well.

Start building all of that very device specific support inside the
device specific framebuffer driver.  The device specific framebuffer
driver will be on initrd and it will get loaded as soon as possible by
the kernel.

Inside the device node for the video device there should be a sub-node
or phandle indicating the presence of the LCD or HDMI jack.  That is a
valid hardware description and it should always be there.  You can
also add a 'chosen' node to indicate how these have been programmed.

----------------------------------------

Two solutions --
1) Build in all of the device specific KMS/framebuffer drivers into
the kernel. Now there is no need for simplefb. But.... that wastes a
lot of memory with code that will never get executed.

2) Early boot off from simplefb. Have all of the graphics drivers on
initrd. Load the right one. Device specific graphic driver now owns
hardware. When KMS is missing, write a much smaller framebuffer
driver. You can start by copying simplefb and then add in the device
specific bits.

The option of fully booting on simplefb up to user space console is
not a good one. It requires that simplefb be taught about all of the
crazy and very complex clock and regulator environments for all of the
random graphics systems. And we're just getting started on enumerating
all of those crazy configurations. You haven't wandered into the area
of the video hardware living on a different bus and having a bus
controller in the way yet. Now you have to figure out how to keep that
bus from being turned off (there are SGI systems like this).


>
>>
>> So simplefb is built-in and used for early boot.  During the boot
>> process a device specific framebuffer driver loads.  This device
>> specific driver takes over for simplefb and can become the user space
>> console.
>>
>> If the device specific framebuffer does not get loaded, then simplefb
>> is going to stop working when the clocks and regulators get shut off.
>> But that is what should happen.
>
> Why it should be so?
>
> It is reasonable to want working console on device which has u-boot or
> other firmware graphics support but the support in kernel is still
> under development.

For the last 30 years this has been handled by using a UART console.
It is almost impossible to develop a framebuffer console driver while
also using the framebuffer for your UI.

>
> Also the 'boot end' for kernel when it frees the clocks is way earlier
> than the 'boot end' for the distribution which ends when you reach

simplefb just has to last until the kernel can modprobe in the device
specific framebuffer driver from initrd.

> certain init goal like multiuser environment. There is a lot between
> and once the kernel hands over to init it can never tell what's going
> on.
>
> Since a modular KMS driver would load way later than the moment when
> 'boot end' is reached for kernel the simple function as early console
> would break.

Whenever KMS gets written the base piece of it should going into
initrd and replace the device specific framebuffer driver. The device
specific framebuffer driver is just a filler until the real KMS driver
gets written. It needs to be a good filler since it may be years until
the KMS driver shows up.

>
> Also if you prevented resource management from happening during this
> 'booting' stage you could not safely load drivers during that time
> which kind of defeats the purpose of this stage.
>
> Because either the kernel can do resource management and give
> resources to drivers that are loaded or it cannot do either.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Wed, Oct 1, 2014 at 9:17 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> On 1 October 2014 15:01, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
>>> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
>>>> On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote:
>>>> > On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
>>>>
>>>> > > You may well need to extend the binding in future for an actual driver
>>>> > > but from the point of view of what's going into the block it really
>>>> > > should just be a case of reading the datasheet and mechanically typing
>>>> > > that in.  If we can work out how to say where the framebuffer is we
>>>> > > really ought to be able to work this stuff out.
>>>>
>>>> > I agree from a technical point of view. However given the dynamically
>>>> > generated nature of the node the problem is more of a logistical nature.
>>>> > As we've seen U-Boot is being enabled to add clocks to the simplefb node
>>>> > but I'm fairly certain that there's a regulator somewhere that needs to
>>>> > be enabled too, be it for powering the display controller, the panel or
>>>> > the backlight. I wouldn't even be surprised if there were one for each
>>>> > of those. If so simplefb on this board will break when the regulators
>>>> > are described in the kernel's DTS.
>>>>
>>>> > If we don't consider this a problem then the whole DT ABI stability
>>>> > business is a farce.
>>>>
>>>> I think you're setting constraints on the implementation you want to see
>>>> which make it unworkable but I don't think those constraints are needed.
>>>> You're starting from the position that the DT needs to be updated without
>>>> the bootloader
>>>
>>> No, what I'm saying is that what the simplefb driver expects and what
>>> the bootloader sets up may diverge as resource drivers are added to the
>>> kernel. The DT /could/ be updated without the bootloader. You may only
>>> be able to replace the DTB but not the bootloader on a given platform.
>>
>> simplefb should be a boot console and not survive past the boot
>> process. Trying to get a 'generic' console driver to survive the boot
>> process is not a generic problem. There are about 1,000 messages in
>> these threads explaining why this is not a generic problem.
>>
>> All of these clock and regulator issues would go away by building a
>> device specific framebuffer driver.  A device specific framebuffer
>> driver can be written in a day or two, it is far simpler than a KMS
>> driver. This driver would how to parse the device specific device tree
>> node and do the right thing with the regulators/clocks.
>
> How it would know?
>
> You need different clocks for LCD and different clocks for HDMI.
>
> Unless it is a real driver that can drive either it can tell which is
> enabled or u-boot has to tell it or you have to write a fixed entry
> for the configuration you want in the DT and configure u-boot
> accordingly by hand as well.

Start building all of that very device specific support inside the
device specific framebuffer driver.  The device specific framebuffer
driver will be on initrd and it will get loaded as soon as possible by
the kernel.

Inside the device node for the video device there should be a sub-node
or phandle indicating the presence of the LCD or HDMI jack.  That is a
valid hardware description and it should always be there.  You can
also add a 'chosen' node to indicate how these have been programmed.

----------------------------------------

Two solutions --
1) Build in all of the device specific KMS/framebuffer drivers into
the kernel. Now there is no need for simplefb. But.... that wastes a
lot of memory with code that will never get executed.

2) Early boot off from simplefb. Have all of the graphics drivers on
initrd. Load the right one. Device specific graphic driver now owns
hardware. When KMS is missing, write a much smaller framebuffer
driver. You can start by copying simplefb and then add in the device
specific bits.

The option of fully booting on simplefb up to user space console is
not a good one. It requires that simplefb be taught about all of the
crazy and very complex clock and regulator environments for all of the
random graphics systems. And we're just getting started on enumerating
all of those crazy configurations. You haven't wandered into the area
of the video hardware living on a different bus and having a bus
controller in the way yet. Now you have to figure out how to keep that
bus from being turned off (there are SGI systems like this).


>
>>
>> So simplefb is built-in and used for early boot.  During the boot
>> process a device specific framebuffer driver loads.  This device
>> specific driver takes over for simplefb and can become the user space
>> console.
>>
>> If the device specific framebuffer does not get loaded, then simplefb
>> is going to stop working when the clocks and regulators get shut off.
>> But that is what should happen.
>
> Why it should be so?
>
> It is reasonable to want working console on device which has u-boot or
> other firmware graphics support but the support in kernel is still
> under development.

For the last 30 years this has been handled by using a UART console.
It is almost impossible to develop a framebuffer console driver while
also using the framebuffer for your UI.

>
> Also the 'boot end' for kernel when it frees the clocks is way earlier
> than the 'boot end' for the distribution which ends when you reach

simplefb just has to last until the kernel can modprobe in the device
specific framebuffer driver from initrd.

> certain init goal like multiuser environment. There is a lot between
> and once the kernel hands over to init it can never tell what's going
> on.
>
> Since a modular KMS driver would load way later than the moment when
> 'boot end' is reached for kernel the simple function as early console
> would break.

Whenever KMS gets written the base piece of it should going into
initrd and replace the device specific framebuffer driver. The device
specific framebuffer driver is just a filler until the real KMS driver
gets written. It needs to be a good filler since it may be years until
the KMS driver shows up.

>
> Also if you prevented resource management from happening during this
> 'booting' stage you could not safely load drivers during that time
> which kind of defeats the purpose of this stage.
>
> Because either the kernel can do resource management and give
> resources to drivers that are loaded or it cannot do either.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:

> > I think you're setting constraints on the implementation you want to see
> > which make it unworkable but I don't think those constraints are needed.
> > You're starting from the position that the DT needs to be updated without
> > the bootloader

> No, what I'm saying is that what the simplefb driver expects and what
> the bootloader sets up may diverge as resource drivers are added to the
> kernel. The DT /could/ be updated without the bootloader. You may only
> be able to replace the DTB but not the bootloader on a given platform.

Sure, but doing that and also having the bootloader write part of the DT
from scratch with no cooperation from the rest of the DT doesn't seem
like the way to robustness.

> >                and that the DT must not contain any hint of simplefb as
> > shipped separately.

> Well, I don't think it should because it describes the same resources
> that the device tree node for the real device already describes. But
> perhaps this is one of the cases where duplication isn't all that bad?

If we were worried about this wecould also do it by referring to
those nodes and saying "get all the resources these things need" rather
than duplicating the references (this might make it easier to work out
when the system is ready to hand off to the real drivers).

> >                     That's never going to work well as far as I can see
> > but doesn't seem like an ABI stability issue, or at least not a
> > reasonable one.

> It would work well under the assumption that the kernel wouldn't be
> touching any of the resources that simplefb depends on. If that's not a
> reasonable assumption then I think we can't make simplefb work the way
> it's currently written.

I can't see how that's reasonable unless the kernel has some way of
figuring out what it shouldn't be touching.

> > Either the bootloader needs to be updated along with the DT

> I thought we had decided that this was one of the big no-nos. But
> perhaps I'm misremembering.

It makes things more fragile so it's not desirable, no.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown]

On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:

> > I think you're setting constraints on the implementation you want to see
> > which make it unworkable but I don't think those constraints are needed.
> > You're starting from the position that the DT needs to be updated without
> > the bootloader

> No, what I'm saying is that what the simplefb driver expects and what
> the bootloader sets up may diverge as resource drivers are added to the
> kernel. The DT /could/ be updated without the bootloader. You may only
> be able to replace the DTB but not the bootloader on a given platform.

Sure, but doing that and also having the bootloader write part of the DT
from scratch with no cooperation from the rest of the DT doesn't seem
like the way to robustness.

> >                and that the DT must not contain any hint of simplefb as
> > shipped separately.

> Well, I don't think it should because it describes the same resources
> that the device tree node for the real device already describes. But
> perhaps this is one of the cases where duplication isn't all that bad?

If we were worried about this wecould also do it by referring to
those nodes and saying "get all the resources these things need" rather
than duplicating the references (this might make it easier to work out
when the system is ready to hand off to the real drivers).

> >                     That's never going to work well as far as I can see
> > but doesn't seem like an ABI stability issue, or at least not a
> > reasonable one.

> It would work well under the assumption that the kernel wouldn't be
> touching any of the resources that simplefb depends on. If that's not a
> reasonable assumption then I think we can't make simplefb work the way
> it's currently written.

I can't see how that's reasonable unless the kernel has some way of
figuring out what it shouldn't be touching.

> > Either the bootloader needs to be updated along with the DT

> I thought we had decided that this was one of the big no-nos. But
> perhaps I'm misremembering.

It makes things more fragile so it's not desirable, no.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/f3dc3840/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown <broonie@kernel.org> wrote:
>> Well, I don't think it should because it describes the same resources
>> that the device tree node for the real device already describes. But
>> perhaps this is one of the cases where duplication isn't all that bad?
>
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).

You can have a single node for both simplefb and the later "real" driver.
DT describes the hardware, not the software ecosystem running on the
hardware. Clock, regulators, etc. don't change from a hardware point of
view.

If the firmware initialized a suitable graphics mode, it just has to add
"linux,simplefb" to the compatible property (and perhaps a few other
simplefb-specific properties).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown <broonie@kernel.org> wrote:
>> Well, I don't think it should because it describes the same resources
>> that the device tree node for the real device already describes. But
>> perhaps this is one of the cases where duplication isn't all that bad?
>
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).

You can have a single node for both simplefb and the later "real" driver.
DT describes the hardware, not the software ecosystem running on the
hardware. Clock, regulators, etc. don't change from a hardware point of
view.

If the firmware initialized a suitable graphics mode, it just has to add
"linux,simplefb" to the compatible property (and perhaps a few other
simplefb-specific properties).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Wed, Oct 01, 2014 at 08:43:27PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown <broonie@kernel.org> wrote:
> >> Well, I don't think it should because it describes the same resources
> >> that the device tree node for the real device already describes. But
> >> perhaps this is one of the cases where duplication isn't all that bad?
> >
> > If we were worried about this wecould also do it by referring to
> > those nodes and saying "get all the resources these things need" rather
> > than duplicating the references (this might make it easier to work out
> > when the system is ready to hand off to the real drivers).
> 
> You can have a single node for both simplefb and the later "real" driver.
> DT describes the hardware, not the software ecosystem running on the
> hardware. Clock, regulators, etc. don't change from a hardware point of
> view.
> 
> If the firmware initialized a suitable graphics mode, it just has to add
> "linux,simplefb" to the compatible property (and perhaps a few other
> simplefb-specific properties).

Unfortunately I don't think that's going to work. Especially on ARM SoCs
there is no single node for a display device. The display device is
typically composed of several subdevices.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Oct 01, 2014 at 08:43:27PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown <broonie@kernel.org> wrote:
> >> Well, I don't think it should because it describes the same resources
> >> that the device tree node for the real device already describes. But
> >> perhaps this is one of the cases where duplication isn't all that bad?
> >
> > If we were worried about this wecould also do it by referring to
> > those nodes and saying "get all the resources these things need" rather
> > than duplicating the references (this might make it easier to work out
> > when the system is ready to hand off to the real drivers).
> 
> You can have a single node for both simplefb and the later "real" driver.
> DT describes the hardware, not the software ecosystem running on the
> hardware. Clock, regulators, etc. don't change from a hardware point of
> view.
> 
> If the firmware initialized a suitable graphics mode, it just has to add
> "linux,simplefb" to the compatible property (and perhaps a few other
> simplefb-specific properties).

Unfortunately I don't think that's going to work. Especially on ARM SoCs
there is no single node for a display device. The display device is
typically composed of several subdevices.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141002/2d4f759b/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

On Wed, Oct 01, 2014 at 06:17:04PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> > On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
[...]
> > >                and that the DT must not contain any hint of simplefb as
> > > shipped separately.
> 
> > Well, I don't think it should because it describes the same resources
> > that the device tree node for the real device already describes. But
> > perhaps this is one of the cases where duplication isn't all that bad?
> 
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).

That's problematic to some degree because not all resource types may
have a binding that allows them to be automatically probed, so it could
be difficult to implement "get all the resources this thing needs". But
perhaps we can come up with good enough heuristics to make that work
reliably.

One downside of that is that there may be a lot of components involved
in getting display to work and not all resources may be needed to keep
the current state running, so we may be claiming too many. But given
that we'd eventually release all of them anyway this shouldn't be too
much of an issue.

> > >                     That's never going to work well as far as I can see
> > > but doesn't seem like an ABI stability issue, or at least not a
> > > reasonable one.
> 
> > It would work well under the assumption that the kernel wouldn't be
> > touching any of the resources that simplefb depends on. If that's not a
> > reasonable assumption then I think we can't make simplefb work the way
> > it's currently written.
> 
> I can't see how that's reasonable unless the kernel has some way of
> figuring out what it shouldn't be touching.

Agreed. It's become clear in this discussion that we can't do this in
the way x86 and other more firmware-oriented architectures do it. They
get away with it because they in fact hide all of this in the firmware
or don't provide a way to control the resources in such a fine-grained
manner to begin with.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Oct 01, 2014 at 06:17:04PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> > On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
[...]
> > >                and that the DT must not contain any hint of simplefb as
> > > shipped separately.
> 
> > Well, I don't think it should because it describes the same resources
> > that the device tree node for the real device already describes. But
> > perhaps this is one of the cases where duplication isn't all that bad?
> 
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).

That's problematic to some degree because not all resource types may
have a binding that allows them to be automatically probed, so it could
be difficult to implement "get all the resources this thing needs". But
perhaps we can come up with good enough heuristics to make that work
reliably.

One downside of that is that there may be a lot of components involved
in getting display to work and not all resources may be needed to keep
the current state running, so we may be claiming too many. But given
that we'd eventually release all of them anyway this shouldn't be too
much of an issue.

> > >                     That's never going to work well as far as I can see
> > > but doesn't seem like an ABI stability issue, or at least not a
> > > reasonable one.
> 
> > It would work well under the assumption that the kernel wouldn't be
> > touching any of the resources that simplefb depends on. If that's not a
> > reasonable assumption then I think we can't make simplefb work the way
> > it's currently written.
> 
> I can't see how that's reasonable unless the kernel has some way of
> figuring out what it shouldn't be touching.

Agreed. It's become clear in this discussion that we can't do this in
the way x86 and other more firmware-oriented architectures do it. They
get away with it because they in fact hide all of this in the firmware
or don't provide a way to control the resources in such a fine-grained
manner to begin with.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141002/24e38157/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
[...]
> > Of course as Geert pointed out in another subthread, taking this all the
> > way means that we have to disable all power management because the
> > firmware device may be sharing resources with other devices and which
> > therefore are not unused. That's a pretty strong argument and I don't
> > have a solution for that. It is only really a problem for cases where
> > the firmware virtual device isn't taken over by a proper driver at some
> > point, though.
> 
> Indeed, and we also run into trouble for things where we actually need
> to really turn off the resource for some reason (MMC has some needs here
> for example).

Perhaps an alternative would be to just keep power management going and
hope for the best. This may turn out not to be as much of a problem for
many SoCs or boards as people make it out to be.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote:
[...]
> > Of course as Geert pointed out in another subthread, taking this all the
> > way means that we have to disable all power management because the
> > firmware device may be sharing resources with other devices and which
> > therefore are not unused. That's a pretty strong argument and I don't
> > have a solution for that. It is only really a problem for cases where
> > the firmware virtual device isn't taken over by a proper driver at some
> > point, though.
> 
> Indeed, and we also run into trouble for things where we actually need
> to really turn off the resource for some reason (MMC has some needs here
> for example).

Perhaps an alternative would be to just keep power management going and
hope for the best. This may turn out not to be as much of a problem for
many SoCs or boards as people make it out to be.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141001/22e0c1c8/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl]

On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. So
> > > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > > the clocks.
> > > > >
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > >
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > >
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > >
> > > > > > It doesn't know what frequency they should be running at
> > > > >
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > >
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > >
> > > > > > or what they're used for
> > > > >
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > >
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > >
> > > > Including clocks.
> > >
> > > We're really discussing in circles here.
> > >
> > > Mike?
> > >
> >
> > -EHIGHLATENCYRESPONSE
> >
> > I forgot about this thread. Sorry.
> >
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> >
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> >
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> >
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> >
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> >
> > That is how it should be done. Period.
> >
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.
>
> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be


This is the key point -- if a design requires duplicating information
in the device tree, the design is broken. The list of clocks is being
duplicated, that is broken design.

Device trees are supposed to reflect the hardware. They are not
supposed to be manipulated into supporting a specific feature on a
single OS.

>
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.
>
> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.
>
> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.
>
> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.
>
> Thierry




-- 
Jon Smirl
jonsmirl@gmail.com

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[jonsmirl at gmail.com]

On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. So
> > > > > > the point I was trying to make is that we can't treat the memory in the
> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > > the clocks.
> > > > >
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > >
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > >
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > >
> > > > > > It doesn't know what frequency they should be running at
> > > > >
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > >
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > >
> > > > > > or what they're used for
> > > > >
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > >
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > >
> > > > Including clocks.
> > >
> > > We're really discussing in circles here.
> > >
> > > Mike?
> > >
> >
> > -EHIGHLATENCYRESPONSE
> >
> > I forgot about this thread. Sorry.
> >
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> >
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> >
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> >
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> >
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> >
> > That is how it should be done. Period.
> >
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.
>
> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be


This is the key point -- if a design requires duplicating information
in the device tree, the design is broken. The list of clocks is being
duplicated, that is broken design.

Device trees are supposed to reflect the hardware. They are not
supposed to be manipulated into supporting a specific feature on a
single OS.

>
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.
>
> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.
>
> Passing in clock information via the device tree already requires a non-
> trivial amount of code in the firmware. A similar amount of code would
> be necessary for each type of resource that needs to be kept enabled. In
> addition to the above some devices may also require resources that have
> no generic bindings. That just doesn't scale.
>
> The only reasonable thing for simplefb to do is not deal with any kind
> of resource at all (except perhaps area that contains the framebuffer
> memory).
>
> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.
>
> Thierry




-- 
Jon Smirl
jonsmirl at gmail.com

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 19:51, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>>
>> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> > Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > > the clocks.
>> > > > >
>> > > > > You agreed on the fact that the only thing we need to do with the
>> > > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > > (or not generic).
>> > > >
>> > > > That's not what I agreed on. What I said is that the only thing we need
>> > > > to do with the clocks is nothing. They are already in the state that
>> > > > they need to be.
>> > >
>> > > Claim was probably a poor choice of words, but still. We have to keep
>> > > the clock running, and both the solution you've been giving and this
>> > > patch do so in a generic way.
>> > >
>> > > > > > It doesn't know what frequency they should be running at
>> > > > >
>> > > > > We don't care about that. Just like we don't care about which
>> > > > > frequency is the memory bus running at. It will just run at whatever
>> > > > > frequency is appropriate.
>> > > >
>> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > > already configured the clocks to run at the correct frequencies, and it
>> > > > has made sure that they are enabled.
>> > > >
>> > > > > > or what they're used for
>> > > > >
>> > > > > And we don't care about that either. You're not interested in what
>> > > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > > here, this is the same thing here.
>> > > >
>> > > > That's precisely what I've been saying. The only thing that simplefb
>> > > > cares about is the memory it should be using and the format of the
>> > > > pixels (and how many of them) it writes into that memory. Everything
>> > > > else is assumed to have been set up.
>> > > >
>> > > > Including clocks.
>> > >
>> > > We're really discussing in circles here.
>> > >
>> > > Mike?
>> > >
>> >
>> > -EHIGHLATENCYRESPONSE
>> >
>> > I forgot about this thread. Sorry.
>> >
>> > In an attempt to provide the least helpful answer possible, I will stay
>> > clear of all of the stuff relating to "how simple should simplefb be"
>> > and the related reserved memory discussion.
>> >
>> > A few times in this thread it is stated that we can't prevent unused
>> > clocks from being disabled. That is only partially true.
>> >
>> > The clock framework DOES provide a flag to prevent UNUSED clocks from
>> > being disabled at late_initcall-time by a clock "garbage collector"
>> > mechanism. Maxime and others familiar with the clock framework are aware
>> > of this.
>> >
>> > What the framework doesn't do is to allow for a magic flag in DT, in
>> > platform_data or elsewhere that says, "don't let me get turned off until
>> > the right driver claims me". That would be an external or alternative
>> > method for preventing a clock from being disabled. We have a method for
>> > preventing clocks from being disabled. It is as follows:
>> >
>> > struct clk *my_clk = clk_get(...);
>> > clk_prepare_enable(my_clk);
>> >
>> > That is how it should be done. Period.
>> >
>> > With that said I think that Luc's approach is very sensible. I'm not
>> > sure what purpose in the universe DT is supposed to serve if not for
>> > _this_exact_case_. We have a nice abstracted driver, usable by many
>> > people. The hardware details of how it is hooked up at the board level
>> > can all be hidden behind stable DT bindings that everyone already uses.
>>
>> simplefb doesn't deal at all with hardware details. It simply uses what
>> firmware has set up, which is the only reason why it will work for many
>> people. What is passed in via its device tree node is the minimum amount
>> of information needed to draw something into the framebuffer. Also note
>> that the simplefb device tree node is not statically added to a DTS file
>> but needs to be dynamically generated by firmware at runtime.
>>
>> If we start extending the binding with board-level details we end up
>> duplicating the device tree node for the proper video device. Also note
>> that it won't stop at clocks. Other setups will require regulators to be
>
>
> This is the key point -- if a design requires duplicating information
> in the device tree, the design is broken. The list of clocks is being
> duplicated, that is broken design.
>
> Device trees are supposed to reflect the hardware. They are not
> supposed to be manipulated into supporting a specific feature on a
> single OS.

Where is the duplication?

If the firmware sets up some clocks in order to scan out a memory
buffer to a display the firmware knows which clocks it used and can
record this in the DT. Presumably the OS then does not need to know
about display hardware and can just read the list. If the OS happens
to have (or later load) a KMS driver that driver has a list of clocks
it uses for driving the display. This will be a superset of what the
firmware used to set up the scanout buffer - for example, the firmware
will probably not turn on any graphics accelerator, and it will
probably configure only one of multiple possible output
configurations.

You can, of course, record some or all of this information statically
and just have the firmware set up what is in the DT without even
reading it. This is however not very flexible - if the firmware can
select to enable different display outputs or set different resolution
it should record that in the DT so that the kernel knows what it set
up. Also if the DT does not match your firmware settings you have a
problem. That's why it is more desirable for the firmware to be able
to record the hardware state it hands over in the DT at boot time.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 September 2014 19:51, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
>>
>> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> > Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > > the point I was trying to make is that we can't treat the memory in the
>> > > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > > clocks don't. The driver is simply too generic to know what to do with
>> > > > > > the clocks.
>> > > > >
>> > > > > You agreed on the fact that the only thing we need to do with the
>> > > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > > (or not generic).
>> > > >
>> > > > That's not what I agreed on. What I said is that the only thing we need
>> > > > to do with the clocks is nothing. They are already in the state that
>> > > > they need to be.
>> > >
>> > > Claim was probably a poor choice of words, but still. We have to keep
>> > > the clock running, and both the solution you've been giving and this
>> > > patch do so in a generic way.
>> > >
>> > > > > > It doesn't know what frequency they should be running at
>> > > > >
>> > > > > We don't care about that. Just like we don't care about which
>> > > > > frequency is the memory bus running at. It will just run at whatever
>> > > > > frequency is appropriate.
>> > > >
>> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > > already configured the clocks to run at the correct frequencies, and it
>> > > > has made sure that they are enabled.
>> > > >
>> > > > > > or what they're used for
>> > > > >
>> > > > > And we don't care about that either. You're not interested in what
>> > > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > > here, this is the same thing here.
>> > > >
>> > > > That's precisely what I've been saying. The only thing that simplefb
>> > > > cares about is the memory it should be using and the format of the
>> > > > pixels (and how many of them) it writes into that memory. Everything
>> > > > else is assumed to have been set up.
>> > > >
>> > > > Including clocks.
>> > >
>> > > We're really discussing in circles here.
>> > >
>> > > Mike?
>> > >
>> >
>> > -EHIGHLATENCYRESPONSE
>> >
>> > I forgot about this thread. Sorry.
>> >
>> > In an attempt to provide the least helpful answer possible, I will stay
>> > clear of all of the stuff relating to "how simple should simplefb be"
>> > and the related reserved memory discussion.
>> >
>> > A few times in this thread it is stated that we can't prevent unused
>> > clocks from being disabled. That is only partially true.
>> >
>> > The clock framework DOES provide a flag to prevent UNUSED clocks from
>> > being disabled at late_initcall-time by a clock "garbage collector"
>> > mechanism. Maxime and others familiar with the clock framework are aware
>> > of this.
>> >
>> > What the framework doesn't do is to allow for a magic flag in DT, in
>> > platform_data or elsewhere that says, "don't let me get turned off until
>> > the right driver claims me". That would be an external or alternative
>> > method for preventing a clock from being disabled. We have a method for
>> > preventing clocks from being disabled. It is as follows:
>> >
>> > struct clk *my_clk = clk_get(...);
>> > clk_prepare_enable(my_clk);
>> >
>> > That is how it should be done. Period.
>> >
>> > With that said I think that Luc's approach is very sensible. I'm not
>> > sure what purpose in the universe DT is supposed to serve if not for
>> > _this_exact_case_. We have a nice abstracted driver, usable by many
>> > people. The hardware details of how it is hooked up at the board level
>> > can all be hidden behind stable DT bindings that everyone already uses.
>>
>> simplefb doesn't deal at all with hardware details. It simply uses what
>> firmware has set up, which is the only reason why it will work for many
>> people. What is passed in via its device tree node is the minimum amount
>> of information needed to draw something into the framebuffer. Also note
>> that the simplefb device tree node is not statically added to a DTS file
>> but needs to be dynamically generated by firmware at runtime.
>>
>> If we start extending the binding with board-level details we end up
>> duplicating the device tree node for the proper video device. Also note
>> that it won't stop at clocks. Other setups will require regulators to be
>
>
> This is the key point -- if a design requires duplicating information
> in the device tree, the design is broken. The list of clocks is being
> duplicated, that is broken design.
>
> Device trees are supposed to reflect the hardware. They are not
> supposed to be manipulated into supporting a specific feature on a
> single OS.

Where is the duplication?

If the firmware sets up some clocks in order to scan out a memory
buffer to a display the firmware knows which clocks it used and can
record this in the DT. Presumably the OS then does not need to know
about display hardware and can just read the list. If the OS happens
to have (or later load) a KMS driver that driver has a list of clocks
it uses for driving the display. This will be a superset of what the
firmware used to set up the scanout buffer - for example, the firmware
will probably not turn on any graphics accelerator, and it will
probably configure only one of multiple possible output
configurations.

You can, of course, record some or all of this information statically
and just have the firmware set up what is in the DT without even
reading it. This is however not very flexible - if the firmware can
select to enable different display outputs or set different resolution
it should record that in the DT so that the kernel knows what it set
up. Also if the DT does not match your firmware settings you have a
problem. That's why it is more desirable for the firmware to be able
to record the hardware state it hands over in the DT at boot time.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 11763 bytes --]

On Wed, Aug 27, 2014 at 02:56:14PM +0200, Thierry Reding wrote:
> > >> So second of all, Thierry, what exactly is the technical argument against
> > >> adding support for dealing with clocks to simplefb ?
> > > 
> > > I've already stated technical arguments against it. You could just go
> > > back and read the thread again, or would you rather want me to repeat
> > > them for your convenience?
> > 
> > It is a long thread, IIRC your main arguments against this are:
> > 
> > 1) You don't want this kind of platform-specific knowledge in simplefb
> > 2) That simplefb is supposed to be simple, and this is not simple
> > 
> > As for 1. several people have already argued that clocks as such are
> > an abstract concept, found one many platforms and as such are not
> > platform specific.
> 
> That alone doesn't justify this patch. SoCs often have a requirement to
> enable clocks in a specific order, for example. Other systems may need
> to coordinate clocks with resets in a specific order or enable power
> domains and such. All that is very SoC specific and if we don't make it
> very clear what this driver assumes about the state of the system, then
> we can't object to anybody adding support for those later on either. The
> result of that is going to be a driver that needs to handle all kinds of
> combinations of resources.

Which is not an issue in our case, since the firmware enabled them
already.

> So while clocks themselves are fairly generic the way in which they need
> to be used is highly platform-specific.
> 
> Let me also reiterate what I've said a couple of times already. The
> issue here isn't that simplefb needs to manage these clocks in any way.
> Firmware has already set them up so that display works. The reason why
> you need this patch is so that the clock framework doesn't automatically
> turn them off. With the proposed patch the driver enables these clocks,
> but that's not what it needs to do, they are already on. It's a work
> around to prevent the clock framework into not disabling them.
> 
> So as far as I'm concerned this points to a fundamental issue with how
> the clock framework handles unused clocks. Therefore that is the problem
> that should be solved, not worked around.

Well, this is again a philosophical difference them. I find like the
right thing to do for the clock framework to disable the clocks that
are enabled if no one reports them as used. That also comes down to
all the drivers that require a clock to stay enabled should report to
the clock framework to tell that it uses this clock. Fortunately, we
have everything in place to do so.

> > Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> > ehci, etc. has ended up adding abstract support for things like clocks
> > (and other resources). I say abstract support here, since to all these
> > drivers the support was added in a way that no platform specific knowledge
> > is necessary, they just deal with clocks not caring about the specific
> > underlying clock implementation, clock names, etc.
> 
> Yes, I know that. You and I both had a very similar discussion not so
> long ago. But the above aren't quite the same as simplefb. The devices
> follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> bound to be more commonalities between them than between the various
> display devices that simplefb potentially can support.
> 
> Interestingly though, if you look at what hardware really is supported
> by the generic drivers that deal with embedded platforms, there isn't
> all that much diversity (I've manually stripped out non-DTS occurrences
> since they aren't relevant for this discussion):
> 
> 	$ git grep -n generic-ohci
> 	arch/arm/boot/dts/sun4i-a10.dtsi:451:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:492:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun5i-a10s.dtsi:403:          compatible = "allwinner,sun5i-a10s-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun5i-a13.dtsi:376:           compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:410:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:432:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:443:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:535:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:576:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
> 	arch/powerpc/boot/dts/akebono.dts:144:          compatible = "ibm,476gtr-ohci", "generic-ohci";
> 	arch/powerpc/boot/dts/akebono.dts:151:          compatible = "ibm,476gtr-ohci", "generic-ohci";
> 
> 	$ git grep -n generic-ehci
> 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:441:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:482:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun5i-a10s.dtsi:393:          compatible = "allwinner,sun5i-a10s-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun5i-a13.dtsi:366:           compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:399:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:421:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:525:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:566:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
> 	arch/powerpc/boot/dts/akebono.dts:130:          compatible = "ibm,476gtr-ehci", "generic-ehci";
> 
> For generic-ahci there aren't any matches, but here are a few that are
> marked compatible with it using different compatible strings:
> 
> 	$ git grep -n snps,spear-ahci
> 	arch/arm/boot/dts/spear1310.dtsi:60:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1310.dtsi:69:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1310.dtsi:78:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1340.dtsi:43:            compatible = "snps,spear-ahci";
> 
> 	$ git grep -n snps,exynos5440-ahci
> 	arch/arm/boot/dts/exynos5440.dtsi:241:          compatible = "snps,exynos5440-ahci";
> 
> 	$ git grep -n 'ibm,476gtr-ahci'
> 	arch/powerpc/boot/dts/akebono.dts:123:          compatible = "ibm,476gtr-ahci";
> 
> 	$ git grep -n 'snps,dwc-ahci'
> 	arch/arm/boot/dts/dra7.dtsi:1049:               compatible = "snps,dwc-ahci";
> 	arch/arm/boot/dts/exynos5250.dtsi:265:          compatible = "snps,dwc-ahci";
> 	arch/arm/boot/dts/omap5.dtsi:919:               compatible = "snps,dwc-ahci";
> 
> That looks fairly homogenous to me. There are also things like this
> (from the ahci_platform.c driver):
> 
> 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
> 
> With more supported hardware there's bound to be more quirks like that.
> 
> So there's a couple of SoCs and boards that actually are generic enough
> to work with a generic driver. And then there's a whole bunch of other
> drivers for hardware that's compliant with the same standard yet needs
> different drivers. To me that's a clear indication that there isn't
> enough genericity to warrant a generic driver in the first place.
> 
> The commonality is in the functionality and defined by the standard
> registers. But there's little to no commonality in how that interface is
> glued into the SoC. Luckily the above subsystems implement the standard
> hardware programming in a library, so that non-generic drivers can still
> make use of most of the generic code.


To be fair, these additions are a couple of release old, and are quite
recent. You can't really make any judgement based on barely 2 releases
of history.

> > If you look at how almost all dt bindings work, then the dt node for
> > a device specifies the resources needed, I don't see why simplefb would
> > be so special that it should be different here. I agree that it is
> > important to get the abstractions right here, but to me it seems that
> > the right abstraction is to be consistent with how all other devices
> > are abstracted and to add needed resources to the dt node for the
> > simplefb.
> 
> But simplefb is fundamentally different from other devices. It isn't a
> physical device at all. It's a virtual device that reuses resources as
> set up by some other piece of code (firmware). It implies that there's
> nothing that needs to be managed. It should only create a framebuffer
> with the given parameters and allow the kernel (and userspace) to render
> into it.

Nothing should be managed, but everything should stay as is. Again,
this is something that we all seem to agree on, yet differ completely
on how to implement that.

> The only way you can deal with such virtual, completely generic devices
> is by being very explicit about the requirements. For simplefb the
> assumptions are that firmware set everything up and passes information
> about what it set up to the kernel so that it can be reused. None of the
> resources need to be explicitly managed because they have all been
> properly configured. For that reason, again, I think the right way is
> for the kernel not to switch off any of the used resources.

So, you're saying that the firmware should inform the kernel about
what clocks it has set up?

I do agree on that too.

And it looks like we reached an agreement then, since it's exactly
what this patch is relying on.

> If you want to equate simplefb to other drivers then it is fundamentally
> broken anyway. Given only what's in the DTB the simplefb driver won't be
> able to do anything useful. Consider what would happen if the firmware
> didn't set up all the resources. Then the DT is missing resets, power
> supplies and all that to make it work.

That would mean that the framebuffer wasn't working in the first
place, which breaks the initial assumption, doesn't it?

> > > so I think we should keep the discussion going for a bit and
> > > see if we really can't come up with something that will fix this for a
> > > more general case rather than just your particular use-case. It's
> > > evidently a recurring problem that others suffer from, too.
> > 
> > Yes needing resources despite the device being behind some generic
> > interface where the main driver code for that interface has no knowledge
> > about such resources sofar, because e.g. on PC-s this was not necessary
> > is a recurring problem, which has been solved already 3 times at least,
> > see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
> > was that the best solution was to simple add the resources to the dt-node,
> > and add code to claim and enable them.
> 
> And as I pointed out above in all three cases the generic platform
> driver is only marginally useful because many SoCs have specific
> requirements that make them incompatible with the generic driver.

s/marginally useful/marginally used/

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 27, 2014 at 02:56:14PM +0200, Thierry Reding wrote:
> > >> So second of all, Thierry, what exactly is the technical argument against
> > >> adding support for dealing with clocks to simplefb ?
> > > 
> > > I've already stated technical arguments against it. You could just go
> > > back and read the thread again, or would you rather want me to repeat
> > > them for your convenience?
> > 
> > It is a long thread, IIRC your main arguments against this are:
> > 
> > 1) You don't want this kind of platform-specific knowledge in simplefb
> > 2) That simplefb is supposed to be simple, and this is not simple
> > 
> > As for 1. several people have already argued that clocks as such are
> > an abstract concept, found one many platforms and as such are not
> > platform specific.
> 
> That alone doesn't justify this patch. SoCs often have a requirement to
> enable clocks in a specific order, for example. Other systems may need
> to coordinate clocks with resets in a specific order or enable power
> domains and such. All that is very SoC specific and if we don't make it
> very clear what this driver assumes about the state of the system, then
> we can't object to anybody adding support for those later on either. The
> result of that is going to be a driver that needs to handle all kinds of
> combinations of resources.

Which is not an issue in our case, since the firmware enabled them
already.

> So while clocks themselves are fairly generic the way in which they need
> to be used is highly platform-specific.
> 
> Let me also reiterate what I've said a couple of times already. The
> issue here isn't that simplefb needs to manage these clocks in any way.
> Firmware has already set them up so that display works. The reason why
> you need this patch is so that the clock framework doesn't automatically
> turn them off. With the proposed patch the driver enables these clocks,
> but that's not what it needs to do, they are already on. It's a work
> around to prevent the clock framework into not disabling them.
> 
> So as far as I'm concerned this points to a fundamental issue with how
> the clock framework handles unused clocks. Therefore that is the problem
> that should be solved, not worked around.

Well, this is again a philosophical difference them. I find like the
right thing to do for the clock framework to disable the clocks that
are enabled if no one reports them as used. That also comes down to
all the drivers that require a clock to stay enabled should report to
the clock framework to tell that it uses this clock. Fortunately, we
have everything in place to do so.

> > Any generic hw driver dealing with embedded platforms, be it ahci, ohci,
> > ehci, etc. has ended up adding abstract support for things like clocks
> > (and other resources). I say abstract support here, since to all these
> > drivers the support was added in a way that no platform specific knowledge
> > is necessary, they just deal with clocks not caring about the specific
> > underlying clock implementation, clock names, etc.
> 
> Yes, I know that. You and I both had a very similar discussion not so
> long ago. But the above aren't quite the same as simplefb. The devices
> follow at least a well-known standard (EHCI, OHCI, AHCI), so there's
> bound to be more commonalities between them than between the various
> display devices that simplefb potentially can support.
> 
> Interestingly though, if you look at what hardware really is supported
> by the generic drivers that deal with embedded platforms, there isn't
> all that much diversity (I've manually stripped out non-DTS occurrences
> since they aren't relevant for this discussion):
> 
> 	$ git grep -n generic-ohci
> 	arch/arm/boot/dts/sun4i-a10.dtsi:451:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:492:           compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun5i-a10s.dtsi:403:          compatible = "allwinner,sun5i-a10s-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun5i-a13.dtsi:376:           compatible = "allwinner,sun5i-a13-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:410:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:432:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:443:           compatible = "allwinner,sun6i-a31-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:535:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:576:           compatible = "allwinner,sun7i-a20-ohci", "generic-ohci";
> 	arch/powerpc/boot/dts/akebono.dts:144:          compatible = "ibm,476gtr-ohci", "generic-ohci";
> 	arch/powerpc/boot/dts/akebono.dts:151:          compatible = "ibm,476gtr-ohci", "generic-ohci";
> 
> 	$ git grep -n generic-ehci
> 	arch/arm/boot/dts/rk3288.dtsi:199:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/rk3288.dtsi:210:              compatible = "generic-ehci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:441:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun4i-a10.dtsi:482:           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun5i-a10s.dtsi:393:          compatible = "allwinner,sun5i-a10s-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun5i-a13.dtsi:366:           compatible = "allwinner,sun5i-a13-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:399:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun6i-a31.dtsi:421:           compatible = "allwinner,sun6i-a31-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:525:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
> 	arch/arm/boot/dts/sun7i-a20.dtsi:566:           compatible = "allwinner,sun7i-a20-ehci", "generic-ehci";
> 	arch/powerpc/boot/dts/akebono.dts:130:          compatible = "ibm,476gtr-ehci", "generic-ehci";
> 
> For generic-ahci there aren't any matches, but here are a few that are
> marked compatible with it using different compatible strings:
> 
> 	$ git grep -n snps,spear-ahci
> 	arch/arm/boot/dts/spear1310.dtsi:60:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1310.dtsi:69:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1310.dtsi:78:            compatible = "snps,spear-ahci";
> 	arch/arm/boot/dts/spear1340.dtsi:43:            compatible = "snps,spear-ahci";
> 
> 	$ git grep -n snps,exynos5440-ahci
> 	arch/arm/boot/dts/exynos5440.dtsi:241:          compatible = "snps,exynos5440-ahci";
> 
> 	$ git grep -n 'ibm,476gtr-ahci'
> 	arch/powerpc/boot/dts/akebono.dts:123:          compatible = "ibm,476gtr-ahci";
> 
> 	$ git grep -n 'snps,dwc-ahci'
> 	arch/arm/boot/dts/dra7.dtsi:1049:               compatible = "snps,dwc-ahci";
> 	arch/arm/boot/dts/exynos5250.dtsi:265:          compatible = "snps,dwc-ahci";
> 	arch/arm/boot/dts/omap5.dtsi:919:               compatible = "snps,dwc-ahci";
> 
> That looks fairly homogenous to me. There are also things like this
> (from the ahci_platform.c driver):
> 
> 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
> 
> With more supported hardware there's bound to be more quirks like that.
> 
> So there's a couple of SoCs and boards that actually are generic enough
> to work with a generic driver. And then there's a whole bunch of other
> drivers for hardware that's compliant with the same standard yet needs
> different drivers. To me that's a clear indication that there isn't
> enough genericity to warrant a generic driver in the first place.
> 
> The commonality is in the functionality and defined by the standard
> registers. But there's little to no commonality in how that interface is
> glued into the SoC. Luckily the above subsystems implement the standard
> hardware programming in a library, so that non-generic drivers can still
> make use of most of the generic code.


To be fair, these additions are a couple of release old, and are quite
recent. You can't really make any judgement based on barely 2 releases
of history.

> > If you look at how almost all dt bindings work, then the dt node for
> > a device specifies the resources needed, I don't see why simplefb would
> > be so special that it should be different here. I agree that it is
> > important to get the abstractions right here, but to me it seems that
> > the right abstraction is to be consistent with how all other devices
> > are abstracted and to add needed resources to the dt node for the
> > simplefb.
> 
> But simplefb is fundamentally different from other devices. It isn't a
> physical device at all. It's a virtual device that reuses resources as
> set up by some other piece of code (firmware). It implies that there's
> nothing that needs to be managed. It should only create a framebuffer
> with the given parameters and allow the kernel (and userspace) to render
> into it.

Nothing should be managed, but everything should stay as is. Again,
this is something that we all seem to agree on, yet differ completely
on how to implement that.

> The only way you can deal with such virtual, completely generic devices
> is by being very explicit about the requirements. For simplefb the
> assumptions are that firmware set everything up and passes information
> about what it set up to the kernel so that it can be reused. None of the
> resources need to be explicitly managed because they have all been
> properly configured. For that reason, again, I think the right way is
> for the kernel not to switch off any of the used resources.

So, you're saying that the firmware should inform the kernel about
what clocks it has set up?

I do agree on that too.

And it looks like we reached an agreement then, since it's exactly
what this patch is relying on.

> If you want to equate simplefb to other drivers then it is fundamentally
> broken anyway. Given only what's in the DTB the simplefb driver won't be
> able to do anything useful. Consider what would happen if the firmware
> didn't set up all the resources. Then the DT is missing resets, power
> supplies and all that to make it work.

That would mean that the framebuffer wasn't working in the first
place, which breaks the initial assumption, doesn't it?

> > > so I think we should keep the discussion going for a bit and
> > > see if we really can't come up with something that will fix this for a
> > > more general case rather than just your particular use-case. It's
> > > evidently a recurring problem that others suffer from, too.
> > 
> > Yes needing resources despite the device being behind some generic
> > interface where the main driver code for that interface has no knowledge
> > about such resources sofar, because e.g. on PC-s this was not necessary
> > is a recurring problem, which has been solved already 3 times at least,
> > see the ohci-, ehci- and ahci-platform drivers, and for all 3 the conclusion
> > was that the best solution was to simple add the resources to the dt-node,
> > and add code to claim and enable them.
> 
> And as I pointed out above in all three cases the generic platform
> driver is only marginally useful because many SoCs have specific
> requirements that make them incompatible with the generic driver.

s/marginally useful/marginally used/

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/af20f5d3/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5509 bytes --]

On Wed, Aug 27, 2014 at 03:56:09PM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 02:56:14PM +0200, Thierry Reding wrote:
> > > >> So second of all, Thierry, what exactly is the technical argument against
> > > >> adding support for dealing with clocks to simplefb ?
> > > > 
> > > > I've already stated technical arguments against it. You could just go
> > > > back and read the thread again, or would you rather want me to repeat
> > > > them for your convenience?
> > > 
> > > It is a long thread, IIRC your main arguments against this are:
> > > 
> > > 1) You don't want this kind of platform-specific knowledge in simplefb
> > > 2) That simplefb is supposed to be simple, and this is not simple
> > > 
> > > As for 1. several people have already argued that clocks as such are
> > > an abstract concept, found one many platforms and as such are not
> > > platform specific.
> > 
> > That alone doesn't justify this patch. SoCs often have a requirement to
> > enable clocks in a specific order, for example. Other systems may need
> > to coordinate clocks with resets in a specific order or enable power
> > domains and such. All that is very SoC specific and if we don't make it
> > very clear what this driver assumes about the state of the system, then
> > we can't object to anybody adding support for those later on either. The
> > result of that is going to be a driver that needs to handle all kinds of
> > combinations of resources.
> 
> Which is not an issue in our case, since the firmware enabled them
> already.

Exactly, so why do you need them at all? You shouldn't have to.

> > So there's a couple of SoCs and boards that actually are generic enough
> > to work with a generic driver. And then there's a whole bunch of other
> > drivers for hardware that's compliant with the same standard yet needs
> > different drivers. To me that's a clear indication that there isn't
> > enough genericity to warrant a generic driver in the first place.
> > 
> > The commonality is in the functionality and defined by the standard
> > registers. But there's little to no commonality in how that interface is
> > glued into the SoC. Luckily the above subsystems implement the standard
> > hardware programming in a library, so that non-generic drivers can still
> > make use of most of the generic code.
> 
> To be fair, these additions are a couple of release old, and are quite
> recent. You can't really make any judgement based on barely 2 releases
> of history.

Okay, fair enough. Time will tell. It's still kind of odd to declare a
driver to be generic without attempting to make the majority of existing
drivers work with it.

> > > If you look at how almost all dt bindings work, then the dt node for
> > > a device specifies the resources needed, I don't see why simplefb would
> > > be so special that it should be different here. I agree that it is
> > > important to get the abstractions right here, but to me it seems that
> > > the right abstraction is to be consistent with how all other devices
> > > are abstracted and to add needed resources to the dt node for the
> > > simplefb.
> > 
> > But simplefb is fundamentally different from other devices. It isn't a
> > physical device at all. It's a virtual device that reuses resources as
> > set up by some other piece of code (firmware). It implies that there's
> > nothing that needs to be managed. It should only create a framebuffer
> > with the given parameters and allow the kernel (and userspace) to render
> > into it.
> 
> Nothing should be managed, but everything should stay as is. Again,
> this is something that we all seem to agree on, yet differ completely
> on how to implement that.

I'm arguing that if everything should stay as is, then nobody should
have to do anything.

> > The only way you can deal with such virtual, completely generic devices
> > is by being very explicit about the requirements. For simplefb the
> > assumptions are that firmware set everything up and passes information
> > about what it set up to the kernel so that it can be reused. None of the
> > resources need to be explicitly managed because they have all been
> > properly configured. For that reason, again, I think the right way is
> > for the kernel not to switch off any of the used resources.
> 
> So, you're saying that the firmware should inform the kernel about
> what clocks it has set up?

Yes. The problem is that even if we tell the kernel that clocks have
been set up it may still decide to disable them when they are unused.
That's the whole purpose of clk_disable_unused() as I understand it.
Whatever mechanism we introduce needs to specifically imply that the
clock must stay enabled.

> > If you want to equate simplefb to other drivers then it is fundamentally
> > broken anyway. Given only what's in the DTB the simplefb driver won't be
> > able to do anything useful. Consider what would happen if the firmware
> > didn't set up all the resources. Then the DT is missing resets, power
> > supplies and all that to make it work.
> 
> That would mean that the framebuffer wasn't working in the first
> place, which breaks the initial assumption, doesn't it?

Exactly. simplefb gets away with an incomplete description of the
hardware in DT because of these assumptions. So you can't draw parallels
to other drivers since they don't make these assumptions and need to be
described completely.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 03:56:09PM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 02:56:14PM +0200, Thierry Reding wrote:
> > > >> So second of all, Thierry, what exactly is the technical argument against
> > > >> adding support for dealing with clocks to simplefb ?
> > > > 
> > > > I've already stated technical arguments against it. You could just go
> > > > back and read the thread again, or would you rather want me to repeat
> > > > them for your convenience?
> > > 
> > > It is a long thread, IIRC your main arguments against this are:
> > > 
> > > 1) You don't want this kind of platform-specific knowledge in simplefb
> > > 2) That simplefb is supposed to be simple, and this is not simple
> > > 
> > > As for 1. several people have already argued that clocks as such are
> > > an abstract concept, found one many platforms and as such are not
> > > platform specific.
> > 
> > That alone doesn't justify this patch. SoCs often have a requirement to
> > enable clocks in a specific order, for example. Other systems may need
> > to coordinate clocks with resets in a specific order or enable power
> > domains and such. All that is very SoC specific and if we don't make it
> > very clear what this driver assumes about the state of the system, then
> > we can't object to anybody adding support for those later on either. The
> > result of that is going to be a driver that needs to handle all kinds of
> > combinations of resources.
> 
> Which is not an issue in our case, since the firmware enabled them
> already.

Exactly, so why do you need them at all? You shouldn't have to.

> > So there's a couple of SoCs and boards that actually are generic enough
> > to work with a generic driver. And then there's a whole bunch of other
> > drivers for hardware that's compliant with the same standard yet needs
> > different drivers. To me that's a clear indication that there isn't
> > enough genericity to warrant a generic driver in the first place.
> > 
> > The commonality is in the functionality and defined by the standard
> > registers. But there's little to no commonality in how that interface is
> > glued into the SoC. Luckily the above subsystems implement the standard
> > hardware programming in a library, so that non-generic drivers can still
> > make use of most of the generic code.
> 
> To be fair, these additions are a couple of release old, and are quite
> recent. You can't really make any judgement based on barely 2 releases
> of history.

Okay, fair enough. Time will tell. It's still kind of odd to declare a
driver to be generic without attempting to make the majority of existing
drivers work with it.

> > > If you look at how almost all dt bindings work, then the dt node for
> > > a device specifies the resources needed, I don't see why simplefb would
> > > be so special that it should be different here. I agree that it is
> > > important to get the abstractions right here, but to me it seems that
> > > the right abstraction is to be consistent with how all other devices
> > > are abstracted and to add needed resources to the dt node for the
> > > simplefb.
> > 
> > But simplefb is fundamentally different from other devices. It isn't a
> > physical device at all. It's a virtual device that reuses resources as
> > set up by some other piece of code (firmware). It implies that there's
> > nothing that needs to be managed. It should only create a framebuffer
> > with the given parameters and allow the kernel (and userspace) to render
> > into it.
> 
> Nothing should be managed, but everything should stay as is. Again,
> this is something that we all seem to agree on, yet differ completely
> on how to implement that.

I'm arguing that if everything should stay as is, then nobody should
have to do anything.

> > The only way you can deal with such virtual, completely generic devices
> > is by being very explicit about the requirements. For simplefb the
> > assumptions are that firmware set everything up and passes information
> > about what it set up to the kernel so that it can be reused. None of the
> > resources need to be explicitly managed because they have all been
> > properly configured. For that reason, again, I think the right way is
> > for the kernel not to switch off any of the used resources.
> 
> So, you're saying that the firmware should inform the kernel about
> what clocks it has set up?

Yes. The problem is that even if we tell the kernel that clocks have
been set up it may still decide to disable them when they are unused.
That's the whole purpose of clk_disable_unused() as I understand it.
Whatever mechanism we introduce needs to specifically imply that the
clock must stay enabled.

> > If you want to equate simplefb to other drivers then it is fundamentally
> > broken anyway. Given only what's in the DTB the simplefb driver won't be
> > able to do anything useful. Consider what would happen if the firmware
> > didn't set up all the resources. Then the DT is missing resets, power
> > supplies and all that to make it work.
> 
> That would mean that the framebuffer wasn't working in the first
> place, which breaks the initial assumption, doesn't it?

Exactly. simplefb gets away with an incomplete description of the
hardware in DT because of these assumptions. So you can't draw parallels
to other drivers since they don't make these assumptions and need to be
described completely.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/114481a1/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Hi,

On Wed, Aug 27, 2014 at 11:31:24AM +0200, Thierry Reding wrote:
> > and only pretty much you against it,
> 
> At least Stephen also spoke out about it. But this quickly devolved into
> the kind of thread you want to get out of as quickly as possible, so I
> can't blame him for not continuing this discussion. In fact I'm very
> much regretting getting into this in the first place. You clearly have
> no intention to even consider any possible other solution that what was
> posted, so it's pretty useless to try and convince you.

No. I'm ready to consider any solution that doesn't involve hardcoding
these clocks in the kernel clock driver. I believe that is a pretty
similar, yet opposite, stance than the one you're currently making.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

Hi,

On Wed, Aug 27, 2014 at 11:31:24AM +0200, Thierry Reding wrote:
> > and only pretty much you against it,
> 
> At least Stephen also spoke out about it. But this quickly devolved into
> the kind of thread you want to get out of as quickly as possible, so I
> can't blame him for not continuing this discussion. In fact I'm very
> much regretting getting into this in the first place. You clearly have
> no intention to even consider any possible other solution that what was
> posted, so it's pretty useless to try and convince you.

No. I'm ready to consider any solution that doesn't involve hardcoding
these clocks in the kernel clock driver. I believe that is a pretty
similar, yet opposite, stance than the one you're currently making.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/9f791d2c/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4447 bytes --]

On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > clocks will be turned off...
> > > 
> > > There are other devices besides ARM SoCs that may want to use this
> > > driver and that don't have clock support.
> > 
> > And in this case, with this patch, simplefb will not claim any clock,
> > nor will fail probing.
> > 
> > > But you're missing my point. What I'm saying is that the simplefb driver
> > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > set up. Therefore I think it makes the most sense to assume that nothing
> > > needs to be controlled in any way since already been set up by firmware.
> > > Eventually there should be a driver that takes over from simplefb that
> > > knows how to properly handle the device's specifics, but that's not
> > > simplefb.
> > 
> > I guess such a hand over if it were to happen in the kernel would
> > involve the second driver claiming the resources before the first one
> > release them. How is that different in this case?
> 
> It's different in that that driver will be hardware specific and know
> exactly what clock and other resources are required. It will have a
> device-specific binding.

Except that you made simplefb a generic driver. So we have two choices
here: either we don't anything but the trivial case, and no one with a
rather more advanced hardware will be able to use it, or we try to
grab any resource that might be of use, which means clocks,
regulators, reserved memory region, or whatever, so that we pretty
much cover all cases. It really is as simple as that.

> > > The goal of this patch series is to keep clocks from being turned off.
> > > But that's not what it does. What it does is turn clocks on to prevent
> > > them from being turned off. In my opinion that's a workaround for a
> > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > it should be fixed at the root. So a much better solution would be to
> > > establish a way for firmware to communicate to the kernel that a given
> > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > solution can be implement for all types of resources and can be reused
> > > by all drivers since they don't have to worry about these details.
> > 
> > Mike Turquette repeatedly said that he was against such a DT property:
> > https://lkml.org/lkml/2014/5/12/693
> 
> Mike says in that email that he's opposing the addition of a property
> for clocks that is the equivalent of regulator-always-on. That's not
> what this is about. If at all it'd be a property to mark a clock that
> should not be disabled by default because it's essential.

It's just semantic. How is "a clock that should not be disabled by
default because it's essential" not a clock that stays always on?

Plus, you should read the mail further. It's clearly said that
consumer drivers should call clk_prepare_enable themselves, and that
the only exception to that is the case where we don't have such a
driver (and only valid as a temporary exception, which I guess you'll
soon turn into temporary-until-a-drm-kms-driver-is-merged).

> Adding Mike on this subthread too.
> 
> Either way, Mark already suggested a different alternative in another
> subthread, namely to add a new kind of checkpoint at which subsystems
> can call a "disable unused" function that's called later than a late
> initcall. This is not going to fix things for you immediately because
> the clocks will still be switched off (only later) if you don't have
> a real driver that's claiming the clocks.

Great, I'm glad we found a solution for a completely unrelated issue.

> But you can work around that for now by making the relevant clocks
> always on and remove that workaround once a real driver is loaded
> that knows how to handle them properly.

So, let me get this straight. The clock provider driver should behave
as a clock consumer because it knows that in some cases, it might not
have any willingful enough consumer? Doesn't that even ring your
this-is-a-clear-abstraction-violation-bell just a tiny bit?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > clocks will be turned off...
> > > 
> > > There are other devices besides ARM SoCs that may want to use this
> > > driver and that don't have clock support.
> > 
> > And in this case, with this patch, simplefb will not claim any clock,
> > nor will fail probing.
> > 
> > > But you're missing my point. What I'm saying is that the simplefb driver
> > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > set up. Therefore I think it makes the most sense to assume that nothing
> > > needs to be controlled in any way since already been set up by firmware.
> > > Eventually there should be a driver that takes over from simplefb that
> > > knows how to properly handle the device's specifics, but that's not
> > > simplefb.
> > 
> > I guess such a hand over if it were to happen in the kernel would
> > involve the second driver claiming the resources before the first one
> > release them. How is that different in this case?
> 
> It's different in that that driver will be hardware specific and know
> exactly what clock and other resources are required. It will have a
> device-specific binding.

Except that you made simplefb a generic driver. So we have two choices
here: either we don't anything but the trivial case, and no one with a
rather more advanced hardware will be able to use it, or we try to
grab any resource that might be of use, which means clocks,
regulators, reserved memory region, or whatever, so that we pretty
much cover all cases. It really is as simple as that.

> > > The goal of this patch series is to keep clocks from being turned off.
> > > But that's not what it does. What it does is turn clocks on to prevent
> > > them from being turned off. In my opinion that's a workaround for a
> > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > it should be fixed at the root. So a much better solution would be to
> > > establish a way for firmware to communicate to the kernel that a given
> > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > solution can be implement for all types of resources and can be reused
> > > by all drivers since they don't have to worry about these details.
> > 
> > Mike Turquette repeatedly said that he was against such a DT property:
> > https://lkml.org/lkml/2014/5/12/693
> 
> Mike says in that email that he's opposing the addition of a property
> for clocks that is the equivalent of regulator-always-on. That's not
> what this is about. If at all it'd be a property to mark a clock that
> should not be disabled by default because it's essential.

It's just semantic. How is "a clock that should not be disabled by
default because it's essential" not a clock that stays always on?

Plus, you should read the mail further. It's clearly said that
consumer drivers should call clk_prepare_enable themselves, and that
the only exception to that is the case where we don't have such a
driver (and only valid as a temporary exception, which I guess you'll
soon turn into temporary-until-a-drm-kms-driver-is-merged).

> Adding Mike on this subthread too.
> 
> Either way, Mark already suggested a different alternative in another
> subthread, namely to add a new kind of checkpoint at which subsystems
> can call a "disable unused" function that's called later than a late
> initcall. This is not going to fix things for you immediately because
> the clocks will still be switched off (only later) if you don't have
> a real driver that's claiming the clocks.

Great, I'm glad we found a solution for a completely unrelated issue.

> But you can work around that for now by making the relevant clocks
> always on and remove that workaround once a real driver is loaded
> that knows how to handle them properly.

So, let me get this straight. The clock provider driver should behave
as a clock consumer because it knows that in some cases, it might not
have any willingful enough consumer? Doesn't that even ring your
this-is-a-clear-abstraction-violation-bell just a tiny bit?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/93b97b74/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6360 bytes --]

On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > > clocks will be turned off...
> > > > 
> > > > There are other devices besides ARM SoCs that may want to use this
> > > > driver and that don't have clock support.
> > > 
> > > And in this case, with this patch, simplefb will not claim any clock,
> > > nor will fail probing.
> > > 
> > > > But you're missing my point. What I'm saying is that the simplefb driver
> > > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > > set up. Therefore I think it makes the most sense to assume that nothing
> > > > needs to be controlled in any way since already been set up by firmware.
> > > > Eventually there should be a driver that takes over from simplefb that
> > > > knows how to properly handle the device's specifics, but that's not
> > > > simplefb.
> > > 
> > > I guess such a hand over if it were to happen in the kernel would
> > > involve the second driver claiming the resources before the first one
> > > release them. How is that different in this case?
> > 
> > It's different in that that driver will be hardware specific and know
> > exactly what clock and other resources are required. It will have a
> > device-specific binding.
> 
> Except that you made simplefb a generic driver. So we have two choices
> here: either we don't anything but the trivial case, and no one with a
> rather more advanced hardware will be able to use it, or we try to
> grab any resource that might be of use, which means clocks,
> regulators, reserved memory region, or whatever, so that we pretty
> much cover all cases. It really is as simple as that.

No, it should be even simpler. simplefb shouldn't have to know any of
this. It's just taking what firmware has set up and uses that. It's a
stop-gap solution to provide information on the display until a real
driver can be loaded and initializes the display hardware properly.

> > > > The goal of this patch series is to keep clocks from being turned off.
> > > > But that's not what it does. What it does is turn clocks on to prevent
> > > > them from being turned off. In my opinion that's a workaround for a
> > > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > > it should be fixed at the root. So a much better solution would be to
> > > > establish a way for firmware to communicate to the kernel that a given
> > > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > > solution can be implement for all types of resources and can be reused
> > > > by all drivers since they don't have to worry about these details.
> > > 
> > > Mike Turquette repeatedly said that he was against such a DT property:
> > > https://lkml.org/lkml/2014/5/12/693
> > 
> > Mike says in that email that he's opposing the addition of a property
> > for clocks that is the equivalent of regulator-always-on. That's not
> > what this is about. If at all it'd be a property to mark a clock that
> > should not be disabled by default because it's essential.
> 
> It's just semantic. How is "a clock that should not be disabled by
> default because it's essential" not a clock that stays always on?

Because a clock that should not be disabled by default can be turned off
when appropriate. A clock that is always on can't be turned off.

> Plus, you should read the mail further. It's clearly said that
> consumer drivers should call clk_prepare_enable themselves, and that
> the only exception to that is the case where we don't have such a
> driver (and only valid as a temporary exception, which I guess you'll
> soon turn into temporary-until-a-drm-kms-driver-is-merged).

Exactly. simplefb is only a temporary measure. It's not meant to be used
as a full-blown framebuffer driver. There are two use-cases where it is
an appropriate solution:

  1) As a stop-gap solution for when the platform doesn't support a full
     display driver yet. In that case you will want simplefb to stay
     around forever.

  2) To get early boot output before a full display driver can be loaded
     in which case simplefb should go away after the display driver has
     taken over.

In case of 2) the most straightforward solution is to not disable any
clocks until all drivers have had a chance to claim them. When the full
driver has been probed it should have claimed the clocks so they would
no longer get disabled.

For 1) I think it's fair to say that it's only a temporary solution to
get something on the screen. There won't be any kind of acceleration at
all, no power saving. Nothing but a dumb framebuffer. In that case it
should be a simple matter of keeping a select number of clocks always on
in the clock driver until support is more complete and it can be
properly handled. It's not like it's going to make a difference anyway
since simplefb won't ever disable them either.

> > Adding Mike on this subthread too.
> > 
> > Either way, Mark already suggested a different alternative in another
> > subthread, namely to add a new kind of checkpoint at which subsystems
> > can call a "disable unused" function that's called later than a late
> > initcall. This is not going to fix things for you immediately because
> > the clocks will still be switched off (only later) if you don't have
> > a real driver that's claiming the clocks.
> 
> Great, I'm glad we found a solution for a completely unrelated issue.

It's not at all unrelated. See above.

> > But you can work around that for now by making the relevant clocks
> > always on and remove that workaround once a real driver is loaded
> > that knows how to handle them properly.
> 
> So, let me get this straight. The clock provider driver should behave
> as a clock consumer because it knows that in some cases, it might not
> have any willingful enough consumer? Doesn't that even ring your
> this-is-a-clear-abstraction-violation-bell just a tiny bit?

No. The clock driver should simply not allow the clocks to be disabled
if it isn't safe to do so.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > > clocks will be turned off...
> > > > 
> > > > There are other devices besides ARM SoCs that may want to use this
> > > > driver and that don't have clock support.
> > > 
> > > And in this case, with this patch, simplefb will not claim any clock,
> > > nor will fail probing.
> > > 
> > > > But you're missing my point. What I'm saying is that the simplefb driver
> > > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > > set up. Therefore I think it makes the most sense to assume that nothing
> > > > needs to be controlled in any way since already been set up by firmware.
> > > > Eventually there should be a driver that takes over from simplefb that
> > > > knows how to properly handle the device's specifics, but that's not
> > > > simplefb.
> > > 
> > > I guess such a hand over if it were to happen in the kernel would
> > > involve the second driver claiming the resources before the first one
> > > release them. How is that different in this case?
> > 
> > It's different in that that driver will be hardware specific and know
> > exactly what clock and other resources are required. It will have a
> > device-specific binding.
> 
> Except that you made simplefb a generic driver. So we have two choices
> here: either we don't anything but the trivial case, and no one with a
> rather more advanced hardware will be able to use it, or we try to
> grab any resource that might be of use, which means clocks,
> regulators, reserved memory region, or whatever, so that we pretty
> much cover all cases. It really is as simple as that.

No, it should be even simpler. simplefb shouldn't have to know any of
this. It's just taking what firmware has set up and uses that. It's a
stop-gap solution to provide information on the display until a real
driver can be loaded and initializes the display hardware properly.

> > > > The goal of this patch series is to keep clocks from being turned off.
> > > > But that's not what it does. What it does is turn clocks on to prevent
> > > > them from being turned off. In my opinion that's a workaround for a
> > > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > > it should be fixed at the root. So a much better solution would be to
> > > > establish a way for firmware to communicate to the kernel that a given
> > > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > > solution can be implement for all types of resources and can be reused
> > > > by all drivers since they don't have to worry about these details.
> > > 
> > > Mike Turquette repeatedly said that he was against such a DT property:
> > > https://lkml.org/lkml/2014/5/12/693
> > 
> > Mike says in that email that he's opposing the addition of a property
> > for clocks that is the equivalent of regulator-always-on. That's not
> > what this is about. If at all it'd be a property to mark a clock that
> > should not be disabled by default because it's essential.
> 
> It's just semantic. How is "a clock that should not be disabled by
> default because it's essential" not a clock that stays always on?

Because a clock that should not be disabled by default can be turned off
when appropriate. A clock that is always on can't be turned off.

> Plus, you should read the mail further. It's clearly said that
> consumer drivers should call clk_prepare_enable themselves, and that
> the only exception to that is the case where we don't have such a
> driver (and only valid as a temporary exception, which I guess you'll
> soon turn into temporary-until-a-drm-kms-driver-is-merged).

Exactly. simplefb is only a temporary measure. It's not meant to be used
as a full-blown framebuffer driver. There are two use-cases where it is
an appropriate solution:

  1) As a stop-gap solution for when the platform doesn't support a full
     display driver yet. In that case you will want simplefb to stay
     around forever.

  2) To get early boot output before a full display driver can be loaded
     in which case simplefb should go away after the display driver has
     taken over.

In case of 2) the most straightforward solution is to not disable any
clocks until all drivers have had a chance to claim them. When the full
driver has been probed it should have claimed the clocks so they would
no longer get disabled.

For 1) I think it's fair to say that it's only a temporary solution to
get something on the screen. There won't be any kind of acceleration at
all, no power saving. Nothing but a dumb framebuffer. In that case it
should be a simple matter of keeping a select number of clocks always on
in the clock driver until support is more complete and it can be
properly handled. It's not like it's going to make a difference anyway
since simplefb won't ever disable them either.

> > Adding Mike on this subthread too.
> > 
> > Either way, Mark already suggested a different alternative in another
> > subthread, namely to add a new kind of checkpoint at which subsystems
> > can call a "disable unused" function that's called later than a late
> > initcall. This is not going to fix things for you immediately because
> > the clocks will still be switched off (only later) if you don't have
> > a real driver that's claiming the clocks.
> 
> Great, I'm glad we found a solution for a completely unrelated issue.

It's not at all unrelated. See above.

> > But you can work around that for now by making the relevant clocks
> > always on and remove that workaround once a real driver is loaded
> > that knows how to handle them properly.
> 
> So, let me get this straight. The clock provider driver should behave
> as a clock consumer because it knows that in some cases, it might not
> have any willingful enough consumer? Doesn't that even ring your
> this-is-a-clear-abstraction-violation-bell just a tiny bit?

No. The clock driver should simply not allow the clocks to be disabled
if it isn't safe to do so.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/612db42c/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 08:54 AM, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>>>>>> Any decent enough SoC, with a decent support in the kernel will have
>>>>>> clocks for this, and I really wonder how simplefb will behave once its
>>>>>> clocks will be turned off...
>>>>>
>>>>> There are other devices besides ARM SoCs that may want to use this
>>>>> driver and that don't have clock support.
>>>>
>>>> And in this case, with this patch, simplefb will not claim any clock,
>>>> nor will fail probing.
>>>>
>>>>> But you're missing my point. What I'm saying is that the simplefb driver
>>>>> is meant to serve as a way to take over whatever framebuffer a firmware
>>>>> set up. Therefore I think it makes the most sense to assume that nothing
>>>>> needs to be controlled in any way since already been set up by firmware.
>>>>> Eventually there should be a driver that takes over from simplefb that
>>>>> knows how to properly handle the device's specifics, but that's not
>>>>> simplefb.
>>>>
>>>> I guess such a hand over if it were to happen in the kernel would
>>>> involve the second driver claiming the resources before the first one
>>>> release them. How is that different in this case?
>>>
>>> It's different in that that driver will be hardware specific and know
>>> exactly what clock and other resources are required. It will have a
>>> device-specific binding.
>>
>> Except that you made simplefb a generic driver. So we have two choices
>> here: either we don't anything but the trivial case, and no one with a
>> rather more advanced hardware will be able to use it, or we try to
>> grab any resource that might be of use, which means clocks,
>> regulators, reserved memory region, or whatever, so that we pretty
>> much cover all cases. It really is as simple as that.
> 
> No, it should be even simpler. simplefb shouldn't have to know any of
> this. It's just taking what firmware has set up and uses that. It's a
> stop-gap solution to provide information on the display until a real
> driver can be loaded and initializes the display hardware properly.
> 
>>>>> The goal of this patch series is to keep clocks from being turned off.
>>>>> But that's not what it does. What it does is turn clocks on to prevent
>>>>> them from being turned off. In my opinion that's a workaround for a
>>>>> deficiency in the kernel (and the firmware/kernel interface) and I think
>>>>> it should be fixed at the root. So a much better solution would be to
>>>>> establish a way for firmware to communicate to the kernel that a given
>>>>> resource has been enabled by firmware and shouldn't be disabled. Such a
>>>>> solution can be implement for all types of resources and can be reused
>>>>> by all drivers since they don't have to worry about these details.
>>>>
>>>> Mike Turquette repeatedly said that he was against such a DT property:
>>>> https://lkml.org/lkml/2014/5/12/693
>>>
>>> Mike says in that email that he's opposing the addition of a property
>>> for clocks that is the equivalent of regulator-always-on. That's not
>>> what this is about. If at all it'd be a property to mark a clock that
>>> should not be disabled by default because it's essential.
>>
>> It's just semantic. How is "a clock that should not be disabled by
>> default because it's essential" not a clock that stays always on?
> 
> Because a clock that should not be disabled by default can be turned off
> when appropriate. A clock that is always on can't be turned off.
> 
>> Plus, you should read the mail further. It's clearly said that
>> consumer drivers should call clk_prepare_enable themselves, and that
>> the only exception to that is the case where we don't have such a
>> driver (and only valid as a temporary exception, which I guess you'll
>> soon turn into temporary-until-a-drm-kms-driver-is-merged).
> 
> Exactly. simplefb is only a temporary measure. It's not meant to be used
> as a full-blown framebuffer driver. There are two use-cases where it is
> an appropriate solution:
> 
>   1) As a stop-gap solution for when the platform doesn't support a full
>      display driver yet. In that case you will want simplefb to stay
>      around forever.
> 
>   2) To get early boot output before a full display driver can be loaded
>      in which case simplefb should go away after the display driver has
>      taken over.
> 
> In case of 2) the most straightforward solution is to not disable any
> clocks until all drivers have had a chance to claim them. When the full
> driver has been probed it should have claimed the clocks so they would
> no longer get disabled.

Please read my long reply from yesterday evening why this will never
work, as there is not a well defined moment when "all drivers have had a
chance to claim them"

I've been doing low level Linux development for 10 years now and I've
worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.

We've been down this road before, and all it leads to is pain, some more
pain and then even more pain. Followed by the conclusion that everything
needed to be refactored to use a hotplug model, and that instead of
waiting for hardware / disk-enumeration to be done (so we can mount
filesystems), the right thing to do is to actually wait for the block
device(s) holding said filesystems to show up.

The same applies here, the right thing to do is to wait for the kms
driver claiming the clocks to actually show up. And the easiest and
cleanest way to do that is to have simplefb claim the clocks, and
have it release them when the kms driver loads and asks simplefb
to unload.

Oh and one more thing, this whole make a list of special clocks which
should be disabled later model is flawed too, because it assumes a
fixed list of clocks, but which clocks actually get used may very well
depend on whether e.g. a vga or hdmi monitor is attached, so u-boot
would then still need to communicate the list of clocks actually used
somehow, and if it needs to pass a list of clocks, the most natural
way to do so is through a clocks property...

Regards,

Hans

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 08:54 AM, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>>>>>> Any decent enough SoC, with a decent support in the kernel will have
>>>>>> clocks for this, and I really wonder how simplefb will behave once its
>>>>>> clocks will be turned off...
>>>>>
>>>>> There are other devices besides ARM SoCs that may want to use this
>>>>> driver and that don't have clock support.
>>>>
>>>> And in this case, with this patch, simplefb will not claim any clock,
>>>> nor will fail probing.
>>>>
>>>>> But you're missing my point. What I'm saying is that the simplefb driver
>>>>> is meant to serve as a way to take over whatever framebuffer a firmware
>>>>> set up. Therefore I think it makes the most sense to assume that nothing
>>>>> needs to be controlled in any way since already been set up by firmware.
>>>>> Eventually there should be a driver that takes over from simplefb that
>>>>> knows how to properly handle the device's specifics, but that's not
>>>>> simplefb.
>>>>
>>>> I guess such a hand over if it were to happen in the kernel would
>>>> involve the second driver claiming the resources before the first one
>>>> release them. How is that different in this case?
>>>
>>> It's different in that that driver will be hardware specific and know
>>> exactly what clock and other resources are required. It will have a
>>> device-specific binding.
>>
>> Except that you made simplefb a generic driver. So we have two choices
>> here: either we don't anything but the trivial case, and no one with a
>> rather more advanced hardware will be able to use it, or we try to
>> grab any resource that might be of use, which means clocks,
>> regulators, reserved memory region, or whatever, so that we pretty
>> much cover all cases. It really is as simple as that.
> 
> No, it should be even simpler. simplefb shouldn't have to know any of
> this. It's just taking what firmware has set up and uses that. It's a
> stop-gap solution to provide information on the display until a real
> driver can be loaded and initializes the display hardware properly.
> 
>>>>> The goal of this patch series is to keep clocks from being turned off.
>>>>> But that's not what it does. What it does is turn clocks on to prevent
>>>>> them from being turned off. In my opinion that's a workaround for a
>>>>> deficiency in the kernel (and the firmware/kernel interface) and I think
>>>>> it should be fixed at the root. So a much better solution would be to
>>>>> establish a way for firmware to communicate to the kernel that a given
>>>>> resource has been enabled by firmware and shouldn't be disabled. Such a
>>>>> solution can be implement for all types of resources and can be reused
>>>>> by all drivers since they don't have to worry about these details.
>>>>
>>>> Mike Turquette repeatedly said that he was against such a DT property:
>>>> https://lkml.org/lkml/2014/5/12/693
>>>
>>> Mike says in that email that he's opposing the addition of a property
>>> for clocks that is the equivalent of regulator-always-on. That's not
>>> what this is about. If at all it'd be a property to mark a clock that
>>> should not be disabled by default because it's essential.
>>
>> It's just semantic. How is "a clock that should not be disabled by
>> default because it's essential" not a clock that stays always on?
> 
> Because a clock that should not be disabled by default can be turned off
> when appropriate. A clock that is always on can't be turned off.
> 
>> Plus, you should read the mail further. It's clearly said that
>> consumer drivers should call clk_prepare_enable themselves, and that
>> the only exception to that is the case where we don't have such a
>> driver (and only valid as a temporary exception, which I guess you'll
>> soon turn into temporary-until-a-drm-kms-driver-is-merged).
> 
> Exactly. simplefb is only a temporary measure. It's not meant to be used
> as a full-blown framebuffer driver. There are two use-cases where it is
> an appropriate solution:
> 
>   1) As a stop-gap solution for when the platform doesn't support a full
>      display driver yet. In that case you will want simplefb to stay
>      around forever.
> 
>   2) To get early boot output before a full display driver can be loaded
>      in which case simplefb should go away after the display driver has
>      taken over.
> 
> In case of 2) the most straightforward solution is to not disable any
> clocks until all drivers have had a chance to claim them. When the full
> driver has been probed it should have claimed the clocks so they would
> no longer get disabled.

Please read my long reply from yesterday evening why this will never
work, as there is not a well defined moment when "all drivers have had a
chance to claim them"

I've been doing low level Linux development for 10 years now and I've
worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.

We've been down this road before, and all it leads to is pain, some more
pain and then even more pain. Followed by the conclusion that everything
needed to be refactored to use a hotplug model, and that instead of
waiting for hardware / disk-enumeration to be done (so we can mount
filesystems), the right thing to do is to actually wait for the block
device(s) holding said filesystems to show up.

The same applies here, the right thing to do is to wait for the kms
driver claiming the clocks to actually show up. And the easiest and
cleanest way to do that is to have simplefb claim the clocks, and
have it release them when the kms driver loads and asks simplefb
to unload.

Oh and one more thing, this whole make a list of special clocks which
should be disabled later model is flawed too, because it assumes a
fixed list of clocks, but which clocks actually get used may very well
depend on whether e.g. a vga or hdmi monitor is attached, so u-boot
would then still need to communicate the list of clocks actually used
somehow, and if it needs to pass a list of clocks, the most natural
way to do so is through a clocks property...

Regards,

Hans

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5411 bytes --]

On Wed, Aug 27, 2014 at 10:00:23AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 08:54 AM, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >>>>>> Any decent enough SoC, with a decent support in the kernel will have
> >>>>>> clocks for this, and I really wonder how simplefb will behave once its
> >>>>>> clocks will be turned off...
> >>>>>
> >>>>> There are other devices besides ARM SoCs that may want to use this
> >>>>> driver and that don't have clock support.
> >>>>
> >>>> And in this case, with this patch, simplefb will not claim any clock,
> >>>> nor will fail probing.
> >>>>
> >>>>> But you're missing my point. What I'm saying is that the simplefb driver
> >>>>> is meant to serve as a way to take over whatever framebuffer a firmware
> >>>>> set up. Therefore I think it makes the most sense to assume that nothing
> >>>>> needs to be controlled in any way since already been set up by firmware.
> >>>>> Eventually there should be a driver that takes over from simplefb that
> >>>>> knows how to properly handle the device's specifics, but that's not
> >>>>> simplefb.
> >>>>
> >>>> I guess such a hand over if it were to happen in the kernel would
> >>>> involve the second driver claiming the resources before the first one
> >>>> release them. How is that different in this case?
> >>>
> >>> It's different in that that driver will be hardware specific and know
> >>> exactly what clock and other resources are required. It will have a
> >>> device-specific binding.
> >>
> >> Except that you made simplefb a generic driver. So we have two choices
> >> here: either we don't anything but the trivial case, and no one with a
> >> rather more advanced hardware will be able to use it, or we try to
> >> grab any resource that might be of use, which means clocks,
> >> regulators, reserved memory region, or whatever, so that we pretty
> >> much cover all cases. It really is as simple as that.
> > 
> > No, it should be even simpler. simplefb shouldn't have to know any of
> > this. It's just taking what firmware has set up and uses that. It's a
> > stop-gap solution to provide information on the display until a real
> > driver can be loaded and initializes the display hardware properly.
> > 
> >>>>> The goal of this patch series is to keep clocks from being turned off.
> >>>>> But that's not what it does. What it does is turn clocks on to prevent
> >>>>> them from being turned off. In my opinion that's a workaround for a
> >>>>> deficiency in the kernel (and the firmware/kernel interface) and I think
> >>>>> it should be fixed at the root. So a much better solution would be to
> >>>>> establish a way for firmware to communicate to the kernel that a given
> >>>>> resource has been enabled by firmware and shouldn't be disabled. Such a
> >>>>> solution can be implement for all types of resources and can be reused
> >>>>> by all drivers since they don't have to worry about these details.
> >>>>
> >>>> Mike Turquette repeatedly said that he was against such a DT property:
> >>>> https://lkml.org/lkml/2014/5/12/693
> >>>
> >>> Mike says in that email that he's opposing the addition of a property
> >>> for clocks that is the equivalent of regulator-always-on. That's not
> >>> what this is about. If at all it'd be a property to mark a clock that
> >>> should not be disabled by default because it's essential.
> >>
> >> It's just semantic. How is "a clock that should not be disabled by
> >> default because it's essential" not a clock that stays always on?
> > 
> > Because a clock that should not be disabled by default can be turned off
> > when appropriate. A clock that is always on can't be turned off.
> > 
> >> Plus, you should read the mail further. It's clearly said that
> >> consumer drivers should call clk_prepare_enable themselves, and that
> >> the only exception to that is the case where we don't have such a
> >> driver (and only valid as a temporary exception, which I guess you'll
> >> soon turn into temporary-until-a-drm-kms-driver-is-merged).
> > 
> > Exactly. simplefb is only a temporary measure. It's not meant to be used
> > as a full-blown framebuffer driver. There are two use-cases where it is
> > an appropriate solution:
> > 
> >   1) As a stop-gap solution for when the platform doesn't support a full
> >      display driver yet. In that case you will want simplefb to stay
> >      around forever.
> > 
> >   2) To get early boot output before a full display driver can be loaded
> >      in which case simplefb should go away after the display driver has
> >      taken over.
> > 
> > In case of 2) the most straightforward solution is to not disable any
> > clocks until all drivers have had a chance to claim them. When the full
> > driver has been probed it should have claimed the clocks so they would
> > no longer get disabled.
> 
> Please read my long reply from yesterday evening why this will never
> work, as there is not a well defined moment when "all drivers have had a
> chance to claim them"
> 
> I've been doing low level Linux development for 10 years now and I've
> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.

Ah, so this is now officially a pissing contest, is it?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 10:00:23AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/27/2014 08:54 AM, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >>>>>> Any decent enough SoC, with a decent support in the kernel will have
> >>>>>> clocks for this, and I really wonder how simplefb will behave once its
> >>>>>> clocks will be turned off...
> >>>>>
> >>>>> There are other devices besides ARM SoCs that may want to use this
> >>>>> driver and that don't have clock support.
> >>>>
> >>>> And in this case, with this patch, simplefb will not claim any clock,
> >>>> nor will fail probing.
> >>>>
> >>>>> But you're missing my point. What I'm saying is that the simplefb driver
> >>>>> is meant to serve as a way to take over whatever framebuffer a firmware
> >>>>> set up. Therefore I think it makes the most sense to assume that nothing
> >>>>> needs to be controlled in any way since already been set up by firmware.
> >>>>> Eventually there should be a driver that takes over from simplefb that
> >>>>> knows how to properly handle the device's specifics, but that's not
> >>>>> simplefb.
> >>>>
> >>>> I guess such a hand over if it were to happen in the kernel would
> >>>> involve the second driver claiming the resources before the first one
> >>>> release them. How is that different in this case?
> >>>
> >>> It's different in that that driver will be hardware specific and know
> >>> exactly what clock and other resources are required. It will have a
> >>> device-specific binding.
> >>
> >> Except that you made simplefb a generic driver. So we have two choices
> >> here: either we don't anything but the trivial case, and no one with a
> >> rather more advanced hardware will be able to use it, or we try to
> >> grab any resource that might be of use, which means clocks,
> >> regulators, reserved memory region, or whatever, so that we pretty
> >> much cover all cases. It really is as simple as that.
> > 
> > No, it should be even simpler. simplefb shouldn't have to know any of
> > this. It's just taking what firmware has set up and uses that. It's a
> > stop-gap solution to provide information on the display until a real
> > driver can be loaded and initializes the display hardware properly.
> > 
> >>>>> The goal of this patch series is to keep clocks from being turned off.
> >>>>> But that's not what it does. What it does is turn clocks on to prevent
> >>>>> them from being turned off. In my opinion that's a workaround for a
> >>>>> deficiency in the kernel (and the firmware/kernel interface) and I think
> >>>>> it should be fixed at the root. So a much better solution would be to
> >>>>> establish a way for firmware to communicate to the kernel that a given
> >>>>> resource has been enabled by firmware and shouldn't be disabled. Such a
> >>>>> solution can be implement for all types of resources and can be reused
> >>>>> by all drivers since they don't have to worry about these details.
> >>>>
> >>>> Mike Turquette repeatedly said that he was against such a DT property:
> >>>> https://lkml.org/lkml/2014/5/12/693
> >>>
> >>> Mike says in that email that he's opposing the addition of a property
> >>> for clocks that is the equivalent of regulator-always-on. That's not
> >>> what this is about. If at all it'd be a property to mark a clock that
> >>> should not be disabled by default because it's essential.
> >>
> >> It's just semantic. How is "a clock that should not be disabled by
> >> default because it's essential" not a clock that stays always on?
> > 
> > Because a clock that should not be disabled by default can be turned off
> > when appropriate. A clock that is always on can't be turned off.
> > 
> >> Plus, you should read the mail further. It's clearly said that
> >> consumer drivers should call clk_prepare_enable themselves, and that
> >> the only exception to that is the case where we don't have such a
> >> driver (and only valid as a temporary exception, which I guess you'll
> >> soon turn into temporary-until-a-drm-kms-driver-is-merged).
> > 
> > Exactly. simplefb is only a temporary measure. It's not meant to be used
> > as a full-blown framebuffer driver. There are two use-cases where it is
> > an appropriate solution:
> > 
> >   1) As a stop-gap solution for when the platform doesn't support a full
> >      display driver yet. In that case you will want simplefb to stay
> >      around forever.
> > 
> >   2) To get early boot output before a full display driver can be loaded
> >      in which case simplefb should go away after the display driver has
> >      taken over.
> > 
> > In case of 2) the most straightforward solution is to not disable any
> > clocks until all drivers have had a chance to claim them. When the full
> > driver has been probed it should have claimed the clocks so they would
> > no longer get disabled.
> 
> Please read my long reply from yesterday evening why this will never
> work, as there is not a well defined moment when "all drivers have had a
> chance to claim them"
> 
> I've been doing low level Linux development for 10 years now and I've
> worked a lot on storage (raid, iscsi, fcoe support, etc.) in the past.

Ah, so this is now officially a pissing contest, is it?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/e93f0c96/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 9067 bytes --]

On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > > > clocks will be turned off...
> > > > > 
> > > > > There are other devices besides ARM SoCs that may want to use this
> > > > > driver and that don't have clock support.
> > > > 
> > > > And in this case, with this patch, simplefb will not claim any clock,
> > > > nor will fail probing.
> > > > 
> > > > > But you're missing my point. What I'm saying is that the simplefb driver
> > > > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > > > set up. Therefore I think it makes the most sense to assume that nothing
> > > > > needs to be controlled in any way since already been set up by firmware.
> > > > > Eventually there should be a driver that takes over from simplefb that
> > > > > knows how to properly handle the device's specifics, but that's not
> > > > > simplefb.
> > > > 
> > > > I guess such a hand over if it were to happen in the kernel would
> > > > involve the second driver claiming the resources before the first one
> > > > release them. How is that different in this case?
> > > 
> > > It's different in that that driver will be hardware specific and know
> > > exactly what clock and other resources are required. It will have a
> > > device-specific binding.
> > 
> > Except that you made simplefb a generic driver. So we have two choices
> > here: either we don't anything but the trivial case, and no one with a
> > rather more advanced hardware will be able to use it, or we try to
> > grab any resource that might be of use, which means clocks,
> > regulators, reserved memory region, or whatever, so that we pretty
> > much cover all cases. It really is as simple as that.
> 
> No, it should be even simpler. simplefb shouldn't have to know any of
> this. It's just taking what firmware has set up and uses that. It's a
> stop-gap solution to provide information on the display until a real
> driver can be loaded and initializes the display hardware properly.

That was not the original intention of this driver then. Stephen's
commit log (commit 26549c8d36a6) was even mentionning some use cases:

"
    Examples use-cases include:

    * The built-in LCD panels on the Samsung ARM chromebook, and Tegra
      devices, and likely many other ARM or embedded systems.  These cannot
      yet be supported using a full graphics driver, since the panel control
      should be provided by the CDF (Common Display Framework), which has been
      stuck in design/review for quite some time.  One could support these
      panels using custom SoC-specific code, but there is a desire to use
      common infra-structure rather than having each SoC vendor invent their
      own code, hence the desire to wait for CDF.

    * Hardware for which a full graphics driver is not yet available, and
      the path to obtain one upstream isn't yet clear.  For example, the
      Raspberry Pi.
    
    * Any hardware in early stages of upstreaming, before a full graphics
      driver has been tackled.  This driver can provide a graphical boot
      console (even full X support) much earlier in the upstreaming process,
      thus making new SoC or board support more generally useful earlier.
"

We're clearly in the use cases 2 and 3.

I understand that you're suggesting a 4th use-case, which seems
totally valid, but let's not forget the reasons why it has been merged
in the first place.

> > > > > The goal of this patch series is to keep clocks from being turned off.
> > > > > But that's not what it does. What it does is turn clocks on to prevent
> > > > > them from being turned off. In my opinion that's a workaround for a
> > > > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > > > it should be fixed at the root. So a much better solution would be to
> > > > > establish a way for firmware to communicate to the kernel that a given
> > > > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > > > solution can be implement for all types of resources and can be reused
> > > > > by all drivers since they don't have to worry about these details.
> > > > 
> > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > https://lkml.org/lkml/2014/5/12/693
> > > 
> > > Mike says in that email that he's opposing the addition of a property
> > > for clocks that is the equivalent of regulator-always-on. That's not
> > > what this is about. If at all it'd be a property to mark a clock that
> > > should not be disabled by default because it's essential.
> > 
> > It's just semantic. How is "a clock that should not be disabled by
> > default because it's essential" not a clock that stays always on?
> 
> Because a clock that should not be disabled by default can be turned off
> when appropriate. A clock that is always on can't be turned off.

If a clock is essential, then it should never be disabled. Or we don't
share the same meaning of essential.

> > Plus, you should read the mail further. It's clearly said that
> > consumer drivers should call clk_prepare_enable themselves, and that
> > the only exception to that is the case where we don't have such a
> > driver (and only valid as a temporary exception, which I guess you'll
> > soon turn into temporary-until-a-drm-kms-driver-is-merged).
> 
> Exactly. simplefb is only a temporary measure. It's not meant to be used
> as a full-blown framebuffer driver. There are two use-cases where it is
> an appropriate solution:
> 
>   1) As a stop-gap solution for when the platform doesn't support a full
>      display driver yet. In that case you will want simplefb to stay
>      around forever.
> 
>   2) To get early boot output before a full display driver can be loaded
>      in which case simplefb should go away after the display driver has
>      taken over.
>
> In case of 2) the most straightforward solution is to not disable any
> clocks until all drivers have had a chance to claim them. When the full
> driver has been probed it should have claimed the clocks so they would
> no longer get disabled.
> 
> For 1) I think it's fair to say that it's only a temporary solution to
> get something on the screen. There won't be any kind of acceleration at
> all, no power saving. Nothing but a dumb framebuffer. In that case it
> should be a simple matter of keeping a select number of clocks always on
> in the clock driver until support is more complete and it can be
> properly handled. It's not like it's going to make a difference anyway
> since simplefb won't ever disable them either.

We do agree on that. The only thing we seem to disagree on is how to
keep these clocks running.

> > > Adding Mike on this subthread too.
> > > 
> > > Either way, Mark already suggested a different alternative in another
> > > subthread, namely to add a new kind of checkpoint at which subsystems
> > > can call a "disable unused" function that's called later than a late
> > > initcall. This is not going to fix things for you immediately because
> > > the clocks will still be switched off (only later) if you don't have
> > > a real driver that's claiming the clocks.
> > 
> > Great, I'm glad we found a solution for a completely unrelated issue.
> 
> It's not at all unrelated. See above.

Kind of, these patches were about the first use case you mentionned,
and your solution tackles the second one.

> > > But you can work around that for now by making the relevant clocks
> > > always on and remove that workaround once a real driver is loaded
> > > that knows how to handle them properly.
> > 
> > So, let me get this straight. The clock provider driver should behave
> > as a clock consumer because it knows that in some cases, it might not
> > have any willingful enough consumer? Doesn't that even ring your
> > this-is-a-clear-abstraction-violation-bell just a tiny bit?
> 
> No. The clock driver should simply not allow the clocks to be disabled
> if it isn't safe to do so.

Again, we do seem to differ on our interpretation of an essential
clock. To me, it is perfectly safe to disable the clocks. The system
will still be responding, the memory will be there, the CPU will keep
running, and we do have a way to recover from that disabled to clock
(for example to enable it back).

Plus, again, in Mike's mail, it's clearly said that adding hacks like
this to the clock driver should only be considered in the case where
we don't have a consuming driver, which is not our case here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > > > > Any decent enough SoC, with a decent support in the kernel will have
> > > > > > clocks for this, and I really wonder how simplefb will behave once its
> > > > > > clocks will be turned off...
> > > > > 
> > > > > There are other devices besides ARM SoCs that may want to use this
> > > > > driver and that don't have clock support.
> > > > 
> > > > And in this case, with this patch, simplefb will not claim any clock,
> > > > nor will fail probing.
> > > > 
> > > > > But you're missing my point. What I'm saying is that the simplefb driver
> > > > > is meant to serve as a way to take over whatever framebuffer a firmware
> > > > > set up. Therefore I think it makes the most sense to assume that nothing
> > > > > needs to be controlled in any way since already been set up by firmware.
> > > > > Eventually there should be a driver that takes over from simplefb that
> > > > > knows how to properly handle the device's specifics, but that's not
> > > > > simplefb.
> > > > 
> > > > I guess such a hand over if it were to happen in the kernel would
> > > > involve the second driver claiming the resources before the first one
> > > > release them. How is that different in this case?
> > > 
> > > It's different in that that driver will be hardware specific and know
> > > exactly what clock and other resources are required. It will have a
> > > device-specific binding.
> > 
> > Except that you made simplefb a generic driver. So we have two choices
> > here: either we don't anything but the trivial case, and no one with a
> > rather more advanced hardware will be able to use it, or we try to
> > grab any resource that might be of use, which means clocks,
> > regulators, reserved memory region, or whatever, so that we pretty
> > much cover all cases. It really is as simple as that.
> 
> No, it should be even simpler. simplefb shouldn't have to know any of
> this. It's just taking what firmware has set up and uses that. It's a
> stop-gap solution to provide information on the display until a real
> driver can be loaded and initializes the display hardware properly.

That was not the original intention of this driver then. Stephen's
commit log (commit 26549c8d36a6) was even mentionning some use cases:

"
    Examples use-cases include:

    * The built-in LCD panels on the Samsung ARM chromebook, and Tegra
      devices, and likely many other ARM or embedded systems.  These cannot
      yet be supported using a full graphics driver, since the panel control
      should be provided by the CDF (Common Display Framework), which has been
      stuck in design/review for quite some time.  One could support these
      panels using custom SoC-specific code, but there is a desire to use
      common infra-structure rather than having each SoC vendor invent their
      own code, hence the desire to wait for CDF.

    * Hardware for which a full graphics driver is not yet available, and
      the path to obtain one upstream isn't yet clear.  For example, the
      Raspberry Pi.
    
    * Any hardware in early stages of upstreaming, before a full graphics
      driver has been tackled.  This driver can provide a graphical boot
      console (even full X support) much earlier in the upstreaming process,
      thus making new SoC or board support more generally useful earlier.
"

We're clearly in the use cases 2 and 3.

I understand that you're suggesting a 4th use-case, which seems
totally valid, but let's not forget the reasons why it has been merged
in the first place.

> > > > > The goal of this patch series is to keep clocks from being turned off.
> > > > > But that's not what it does. What it does is turn clocks on to prevent
> > > > > them from being turned off. In my opinion that's a workaround for a
> > > > > deficiency in the kernel (and the firmware/kernel interface) and I think
> > > > > it should be fixed at the root. So a much better solution would be to
> > > > > establish a way for firmware to communicate to the kernel that a given
> > > > > resource has been enabled by firmware and shouldn't be disabled. Such a
> > > > > solution can be implement for all types of resources and can be reused
> > > > > by all drivers since they don't have to worry about these details.
> > > > 
> > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > https://lkml.org/lkml/2014/5/12/693
> > > 
> > > Mike says in that email that he's opposing the addition of a property
> > > for clocks that is the equivalent of regulator-always-on. That's not
> > > what this is about. If at all it'd be a property to mark a clock that
> > > should not be disabled by default because it's essential.
> > 
> > It's just semantic. How is "a clock that should not be disabled by
> > default because it's essential" not a clock that stays always on?
> 
> Because a clock that should not be disabled by default can be turned off
> when appropriate. A clock that is always on can't be turned off.

If a clock is essential, then it should never be disabled. Or we don't
share the same meaning of essential.

> > Plus, you should read the mail further. It's clearly said that
> > consumer drivers should call clk_prepare_enable themselves, and that
> > the only exception to that is the case where we don't have such a
> > driver (and only valid as a temporary exception, which I guess you'll
> > soon turn into temporary-until-a-drm-kms-driver-is-merged).
> 
> Exactly. simplefb is only a temporary measure. It's not meant to be used
> as a full-blown framebuffer driver. There are two use-cases where it is
> an appropriate solution:
> 
>   1) As a stop-gap solution for when the platform doesn't support a full
>      display driver yet. In that case you will want simplefb to stay
>      around forever.
> 
>   2) To get early boot output before a full display driver can be loaded
>      in which case simplefb should go away after the display driver has
>      taken over.
>
> In case of 2) the most straightforward solution is to not disable any
> clocks until all drivers have had a chance to claim them. When the full
> driver has been probed it should have claimed the clocks so they would
> no longer get disabled.
> 
> For 1) I think it's fair to say that it's only a temporary solution to
> get something on the screen. There won't be any kind of acceleration at
> all, no power saving. Nothing but a dumb framebuffer. In that case it
> should be a simple matter of keeping a select number of clocks always on
> in the clock driver until support is more complete and it can be
> properly handled. It's not like it's going to make a difference anyway
> since simplefb won't ever disable them either.

We do agree on that. The only thing we seem to disagree on is how to
keep these clocks running.

> > > Adding Mike on this subthread too.
> > > 
> > > Either way, Mark already suggested a different alternative in another
> > > subthread, namely to add a new kind of checkpoint at which subsystems
> > > can call a "disable unused" function that's called later than a late
> > > initcall. This is not going to fix things for you immediately because
> > > the clocks will still be switched off (only later) if you don't have
> > > a real driver that's claiming the clocks.
> > 
> > Great, I'm glad we found a solution for a completely unrelated issue.
> 
> It's not at all unrelated. See above.

Kind of, these patches were about the first use case you mentionned,
and your solution tackles the second one.

> > > But you can work around that for now by making the relevant clocks
> > > always on and remove that workaround once a real driver is loaded
> > > that knows how to handle them properly.
> > 
> > So, let me get this straight. The clock provider driver should behave
> > as a clock consumer because it knows that in some cases, it might not
> > have any willingful enough consumer? Doesn't that even ring your
> > this-is-a-clear-abstraction-violation-bell just a tiny bit?
> 
> No. The clock driver should simply not allow the clocks to be disabled
> if it isn't safe to do so.

Again, we do seem to differ on our interpretation of an essential
clock. To me, it is perfectly safe to disable the clocks. The system
will still be responding, the memory will be there, the CPU will keep
running, and we do have a way to recover from that disabled to clock
(for example to enable it back).

Plus, again, in Mike's mail, it's clearly said that adding hacks like
this to the clock driver should only be considered in the case where
we don't have a consuming driver, which is not our case here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/59a6d89c/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
[...]
> > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > https://lkml.org/lkml/2014/5/12/693
> > > > 
> > > > Mike says in that email that he's opposing the addition of a property
> > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > what this is about. If at all it'd be a property to mark a clock that
> > > > should not be disabled by default because it's essential.
> > > 
> > > It's just semantic. How is "a clock that should not be disabled by
> > > default because it's essential" not a clock that stays always on?
> > 
> > Because a clock that should not be disabled by default can be turned off
> > when appropriate. A clock that is always on can't be turned off.
> 
> If a clock is essential, then it should never be disabled. Or we don't
> share the same meaning of essential.

Essential for the particular use-case.

> > > > But you can work around that for now by making the relevant clocks
> > > > always on and remove that workaround once a real driver is loaded
> > > > that knows how to handle them properly.
> > > 
> > > So, let me get this straight. The clock provider driver should behave
> > > as a clock consumer because it knows that in some cases, it might not
> > > have any willingful enough consumer? Doesn't that even ring your
> > > this-is-a-clear-abstraction-violation-bell just a tiny bit?
> > 
> > No. The clock driver should simply not allow the clocks to be disabled
> > if it isn't safe to do so.
> 
> Again, we do seem to differ on our interpretation of an essential
> clock. To me, it is perfectly safe to disable the clocks. The system
> will still be responding, the memory will be there, the CPU will keep
> running, and we do have a way to recover from that disabled to clock
> (for example to enable it back).
> 
> Plus, again, in Mike's mail, it's clearly said that adding hacks like
> this to the clock driver should only be considered in the case where
> we don't have a consuming driver, which is not our case here.

Well, that depends on what you mean by the consuming driver. simplefb
isn't a traditional driver in that sense. There will eventually, in a
more fully-featured system, be a driver that properly consumes the
clocks. Now, since this is only a temporary measure I think it's one of
the cases where having this encoded in the clock driver would be
appropriate.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
[...]
> > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > https://lkml.org/lkml/2014/5/12/693
> > > > 
> > > > Mike says in that email that he's opposing the addition of a property
> > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > what this is about. If at all it'd be a property to mark a clock that
> > > > should not be disabled by default because it's essential.
> > > 
> > > It's just semantic. How is "a clock that should not be disabled by
> > > default because it's essential" not a clock that stays always on?
> > 
> > Because a clock that should not be disabled by default can be turned off
> > when appropriate. A clock that is always on can't be turned off.
> 
> If a clock is essential, then it should never be disabled. Or we don't
> share the same meaning of essential.

Essential for the particular use-case.

> > > > But you can work around that for now by making the relevant clocks
> > > > always on and remove that workaround once a real driver is loaded
> > > > that knows how to handle them properly.
> > > 
> > > So, let me get this straight. The clock provider driver should behave
> > > as a clock consumer because it knows that in some cases, it might not
> > > have any willingful enough consumer? Doesn't that even ring your
> > > this-is-a-clear-abstraction-violation-bell just a tiny bit?
> > 
> > No. The clock driver should simply not allow the clocks to be disabled
> > if it isn't safe to do so.
> 
> Again, we do seem to differ on our interpretation of an essential
> clock. To me, it is perfectly safe to disable the clocks. The system
> will still be responding, the memory will be there, the CPU will keep
> running, and we do have a way to recover from that disabled to clock
> (for example to enable it back).
> 
> Plus, again, in Mike's mail, it's clearly said that adding hacks like
> this to the clock driver should only be considered in the case where
> we don't have a consuming driver, which is not our case here.

Well, that depends on what you mean by the consuming driver. simplefb
isn't a traditional driver in that sense. There will eventually, in a
more fully-featured system, be a driver that properly consumes the
clocks. Now, since this is only a temporary measure I think it's one of
the cases where having this encoded in the clock driver would be
appropriate.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/4d523abb/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> [...]
> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > 
> > > > > Mike says in that email that he's opposing the addition of a property
> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > should not be disabled by default because it's essential.
> > > > 
> > > > It's just semantic. How is "a clock that should not be disabled by
> > > > default because it's essential" not a clock that stays always on?
> > > 
> > > Because a clock that should not be disabled by default can be turned off
> > > when appropriate. A clock that is always on can't be turned off.
> > 
> > If a clock is essential, then it should never be disabled. Or we don't
> > share the same meaning of essential.
> 
> Essential for the particular use-case.

So, how would the clock driver would know about which use case we're
in? How would it know about which display engine is currently running?
How would it know about which video output is being set?

Currently, we have two separate display engines, which can each output
either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
one of these combinations would require different clocks. What clocks
will we put in the driver? All of them?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> [...]
> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > 
> > > > > Mike says in that email that he's opposing the addition of a property
> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > should not be disabled by default because it's essential.
> > > > 
> > > > It's just semantic. How is "a clock that should not be disabled by
> > > > default because it's essential" not a clock that stays always on?
> > > 
> > > Because a clock that should not be disabled by default can be turned off
> > > when appropriate. A clock that is always on can't be turned off.
> > 
> > If a clock is essential, then it should never be disabled. Or we don't
> > share the same meaning of essential.
> 
> Essential for the particular use-case.

So, how would the clock driver would know about which use case we're
in? How would it know about which display engine is currently running?
How would it know about which video output is being set?

Currently, we have two separate display engines, which can each output
either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
one of these combinations would require different clocks. What clocks
will we put in the driver? All of them?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140827/d9967896/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

Hello,

On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> [...]
>> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> > > > > > https://lkml.org/lkml/2014/5/12/693
>> > > > >
>> > > > > Mike says in that email that he's opposing the addition of a property
>> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> > > > > what this is about. If at all it'd be a property to mark a clock that
>> > > > > should not be disabled by default because it's essential.
>> > > >
>> > > > It's just semantic. How is "a clock that should not be disabled by
>> > > > default because it's essential" not a clock that stays always on?
>> > >
>> > > Because a clock that should not be disabled by default can be turned off
>> > > when appropriate. A clock that is always on can't be turned off.
>> >
>> > If a clock is essential, then it should never be disabled. Or we don't
>> > share the same meaning of essential.
>>
>> Essential for the particular use-case.
>
> So, how would the clock driver would know about which use case we're
> in? How would it know about which display engine is currently running?
> How would it know about which video output is being set?
>
> Currently, we have two separate display engines, which can each output
> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> one of these combinations would require different clocks. What clocks
> will we put in the driver? All of them?
>

since simplefb cannot be extended how about adding, say, dtfb which
claims the resources from dt and then instantiates a simplefb once the
resources are claimed? That is have a dtfb which has the clocks
assigned and has simplefb as child dt node.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

Hello,

On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> [...]
>> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> > > > > > https://lkml.org/lkml/2014/5/12/693
>> > > > >
>> > > > > Mike says in that email that he's opposing the addition of a property
>> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> > > > > what this is about. If at all it'd be a property to mark a clock that
>> > > > > should not be disabled by default because it's essential.
>> > > >
>> > > > It's just semantic. How is "a clock that should not be disabled by
>> > > > default because it's essential" not a clock that stays always on?
>> > >
>> > > Because a clock that should not be disabled by default can be turned off
>> > > when appropriate. A clock that is always on can't be turned off.
>> >
>> > If a clock is essential, then it should never be disabled. Or we don't
>> > share the same meaning of essential.
>>
>> Essential for the particular use-case.
>
> So, how would the clock driver would know about which use case we're
> in? How would it know about which display engine is currently running?
> How would it know about which video output is being set?
>
> Currently, we have two separate display engines, which can each output
> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> one of these combinations would require different clocks. What clocks
> will we put in the driver? All of them?
>

since simplefb cannot be extended how about adding, say, dtfb which
claims the resources from dt and then instantiates a simplefb once the
resources are claimed? That is have a dtfb which has the clocks
assigned and has simplefb as child dt node.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> [...]
> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> > > > >
> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> > > > > should not be disabled by default because it's essential.
> >> > > >
> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> > > > default because it's essential" not a clock that stays always on?
> >> > >
> >> > > Because a clock that should not be disabled by default can be turned off
> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >
> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> > share the same meaning of essential.
> >>
> >> Essential for the particular use-case.
> >
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> >
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> >
> 
> since simplefb cannot be extended how about adding, say, dtfb which
> claims the resources from dt and then instantiates a simplefb once the
> resources are claimed? That is have a dtfb which has the clocks
> assigned and has simplefb as child dt node.

I don't see how that changes anything. All you do is add another layer
of indirection. The fundamental problem remains the same and isn't
solved.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> [...]
> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> > > > >
> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> > > > > should not be disabled by default because it's essential.
> >> > > >
> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> > > > default because it's essential" not a clock that stays always on?
> >> > >
> >> > > Because a clock that should not be disabled by default can be turned off
> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >
> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> > share the same meaning of essential.
> >>
> >> Essential for the particular use-case.
> >
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> >
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> >
> 
> since simplefb cannot be extended how about adding, say, dtfb which
> claims the resources from dt and then instantiates a simplefb once the
> resources are claimed? That is have a dtfb which has the clocks
> assigned and has simplefb as child dt node.

I don't see how that changes anything. All you do is add another layer
of indirection. The fundamental problem remains the same and isn't
solved.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140828/f3eec559/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> [...]
>> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> > > > >
>> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> > > > > should not be disabled by default because it's essential.
>> >> > > >
>> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> > > > default because it's essential" not a clock that stays always on?
>> >> > >
>> >> > > Because a clock that should not be disabled by default can be turned off
>> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >
>> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> > share the same meaning of essential.
>> >>
>> >> Essential for the particular use-case.
>> >
>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.

It keeps clock code out of simplefb and provides driver for the kind
of framebuffer set up by firmware that exists on sunxi, exynos, and
probably many other SoCs. That is a framebuffer that needs some clocks
and possibly regulators enabled to keep running because the reality of
the platform is that it has clocks and regulators unlike some other
platforms that do not.

These clocks and regulators are used but not configured by the
framebuffer and should be reclaimed when firmware framebuffer is
disabled. This is the same as the chunk of  memory used by simplefb
which is currently lost but should be reclaimed when simplefb is
disabled.

This memory is not 'reserved for firmware' and unusable but reserved
for framebuffer and the regulators are not 'always on' or 'should
never be disabled' but should be enabled while framebuffer is used.

As far as I can tell in DT this is expressed by creating a DT node
associated with the framebuffer driver that tells the kernel that this
memory, clocks and regulators are associated with the framebuffer
driver and can be reclaimed if this driver is stopped or not enabled
in the kernel at all. If you are going to be asinine about simplefb
not getting support for managing any resource other than the memory
chunk then another layer of indirection is required for platforms that
have more resources to manage.

If there is another way to associate resources with a driver in DT
then please enlighten me.

AFAICT simplefb is the framebuffer driver already in kernel closest to
the driver that is required for sunxi - simplefb also relies on
firmware to set up the framebuffer but unlike vesafb or efifb it
already has DT integration. So the most efficient way to implement
framebuffer for sunxi is to extend simplefb or if necessary add
another layer of indirection under simplefb. If there is a better
fitting driver in the kernel then please enlighten me and the
developer that wrote this patch what driver it would be.

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> [...]
>> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> > > > >
>> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> > > > > should not be disabled by default because it's essential.
>> >> > > >
>> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> > > > default because it's essential" not a clock that stays always on?
>> >> > >
>> >> > > Because a clock that should not be disabled by default can be turned off
>> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >
>> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> > share the same meaning of essential.
>> >>
>> >> Essential for the particular use-case.
>> >
>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.

It keeps clock code out of simplefb and provides driver for the kind
of framebuffer set up by firmware that exists on sunxi, exynos, and
probably many other SoCs. That is a framebuffer that needs some clocks
and possibly regulators enabled to keep running because the reality of
the platform is that it has clocks and regulators unlike some other
platforms that do not.

These clocks and regulators are used but not configured by the
framebuffer and should be reclaimed when firmware framebuffer is
disabled. This is the same as the chunk of  memory used by simplefb
which is currently lost but should be reclaimed when simplefb is
disabled.

This memory is not 'reserved for firmware' and unusable but reserved
for framebuffer and the regulators are not 'always on' or 'should
never be disabled' but should be enabled while framebuffer is used.

As far as I can tell in DT this is expressed by creating a DT node
associated with the framebuffer driver that tells the kernel that this
memory, clocks and regulators are associated with the framebuffer
driver and can be reclaimed if this driver is stopped or not enabled
in the kernel at all. If you are going to be asinine about simplefb
not getting support for managing any resource other than the memory
chunk then another layer of indirection is required for platforms that
have more resources to manage.

If there is another way to associate resources with a driver in DT
then please enlighten me.

AFAICT simplefb is the framebuffer driver already in kernel closest to
the driver that is required for sunxi - simplefb also relies on
firmware to set up the framebuffer but unlike vesafb or efifb it
already has DT integration. So the most efficient way to implement
framebuffer for sunxi is to extend simplefb or if necessary add
another layer of indirection under simplefb. If there is a better
fitting driver in the kernel then please enlighten me and the
developer that wrote this patch what driver it would be.

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5621 bytes --]

On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> Hello,
> >>
> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> [...]
> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> > > > >
> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> > > > > should not be disabled by default because it's essential.
> >> >> > > >
> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> > >
> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >
> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> > share the same meaning of essential.
> >> >>
> >> >> Essential for the particular use-case.
> >> >
> >> > So, how would the clock driver would know about which use case we're
> >> > in? How would it know about which display engine is currently running?
> >> > How would it know about which video output is being set?
> >> >
> >> > Currently, we have two separate display engines, which can each output
> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> > one of these combinations would require different clocks. What clocks
> >> > will we put in the driver? All of them?
> >> >
> >>
> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> claims the resources from dt and then instantiates a simplefb once the
> >> resources are claimed? That is have a dtfb which has the clocks
> >> assigned and has simplefb as child dt node.
> >
> > I don't see how that changes anything. All you do is add another layer
> > of indirection. The fundamental problem remains the same and isn't
> > solved.
> 
> It keeps clock code out of simplefb and provides driver for the kind
> of framebuffer set up by firmware that exists on sunxi, exynos, and
> probably many other SoCs. That is a framebuffer that needs some clocks
> and possibly regulators enabled to keep running because the reality of
> the platform is that it has clocks and regulators unlike some other
> platforms that do not.
> 
> These clocks and regulators are used but not configured by the
> framebuffer and should be reclaimed when firmware framebuffer is
> disabled. This is the same as the chunk of  memory used by simplefb
> which is currently lost but should be reclaimed when simplefb is
> disabled.
> 
> This memory is not 'reserved for firmware' and unusable but reserved
> for framebuffer and the regulators are not 'always on' or 'should
> never be disabled' but should be enabled while framebuffer is used.
> 
> As far as I can tell in DT this is expressed by creating a DT node
> associated with the framebuffer driver that tells the kernel that this
> memory, clocks and regulators are associated with the framebuffer
> driver and can be reclaimed if this driver is stopped or not enabled
> in the kernel at all. If you are going to be asinine about simplefb
> not getting support for managing any resource other than the memory
> chunk then another layer of indirection is required for platforms that
> have more resources to manage.
> 
> If there is another way to associate resources with a driver in DT
> then please enlighten me.
> 
> AFAICT simplefb is the framebuffer driver already in kernel closest to
> the driver that is required for sunxi - simplefb also relies on
> firmware to set up the framebuffer but unlike vesafb or efifb it
> already has DT integration. So the most efficient way to implement
> framebuffer for sunxi is to extend simplefb or if necessary add
> another layer of indirection under simplefb. If there is a better
> fitting driver in the kernel then please enlighten me and the
> developer that wrote this patch what driver it would be.

I think simplefb is exactly the right driver to use for this case. But I
don't think making it manage all the resources is the right thing to do.
While it's fairly easy to do it, it's also something that needs to be
done for every other driver with similar requirements. Consider for
example what happens if you want to play some welcome sound in the
bootloader and keep it playing while the kernel is booting. You'd need
to repeat exactly what this driver does to keep clocks for audio
hardware running. And there are possibly other similar use-cases as
well.

One other issue with simplefb is that it isn't a real device to begin
with. It's completely virtual, so in the same way that it doesn't
program any device-specific registers I don't think it should claim any
resources.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> Hello,
> >>
> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> [...]
> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> > > > >
> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> > > > > should not be disabled by default because it's essential.
> >> >> > > >
> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> > >
> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >
> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> > share the same meaning of essential.
> >> >>
> >> >> Essential for the particular use-case.
> >> >
> >> > So, how would the clock driver would know about which use case we're
> >> > in? How would it know about which display engine is currently running?
> >> > How would it know about which video output is being set?
> >> >
> >> > Currently, we have two separate display engines, which can each output
> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> > one of these combinations would require different clocks. What clocks
> >> > will we put in the driver? All of them?
> >> >
> >>
> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> claims the resources from dt and then instantiates a simplefb once the
> >> resources are claimed? That is have a dtfb which has the clocks
> >> assigned and has simplefb as child dt node.
> >
> > I don't see how that changes anything. All you do is add another layer
> > of indirection. The fundamental problem remains the same and isn't
> > solved.
> 
> It keeps clock code out of simplefb and provides driver for the kind
> of framebuffer set up by firmware that exists on sunxi, exynos, and
> probably many other SoCs. That is a framebuffer that needs some clocks
> and possibly regulators enabled to keep running because the reality of
> the platform is that it has clocks and regulators unlike some other
> platforms that do not.
> 
> These clocks and regulators are used but not configured by the
> framebuffer and should be reclaimed when firmware framebuffer is
> disabled. This is the same as the chunk of  memory used by simplefb
> which is currently lost but should be reclaimed when simplefb is
> disabled.
> 
> This memory is not 'reserved for firmware' and unusable but reserved
> for framebuffer and the regulators are not 'always on' or 'should
> never be disabled' but should be enabled while framebuffer is used.
> 
> As far as I can tell in DT this is expressed by creating a DT node
> associated with the framebuffer driver that tells the kernel that this
> memory, clocks and regulators are associated with the framebuffer
> driver and can be reclaimed if this driver is stopped or not enabled
> in the kernel at all. If you are going to be asinine about simplefb
> not getting support for managing any resource other than the memory
> chunk then another layer of indirection is required for platforms that
> have more resources to manage.
> 
> If there is another way to associate resources with a driver in DT
> then please enlighten me.
> 
> AFAICT simplefb is the framebuffer driver already in kernel closest to
> the driver that is required for sunxi - simplefb also relies on
> firmware to set up the framebuffer but unlike vesafb or efifb it
> already has DT integration. So the most efficient way to implement
> framebuffer for sunxi is to extend simplefb or if necessary add
> another layer of indirection under simplefb. If there is a better
> fitting driver in the kernel then please enlighten me and the
> developer that wrote this patch what driver it would be.

I think simplefb is exactly the right driver to use for this case. But I
don't think making it manage all the resources is the right thing to do.
While it's fairly easy to do it, it's also something that needs to be
done for every other driver with similar requirements. Consider for
example what happens if you want to play some welcome sound in the
bootloader and keep it playing while the kernel is booting. You'd need
to repeat exactly what this driver does to keep clocks for audio
hardware running. And there are possibly other similar use-cases as
well.

One other issue with simplefb is that it isn't a real device to begin
with. It's completely virtual, so in the same way that it doesn't
program any device-specific registers I don't think it should claim any
resources.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/159b89e4/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
>> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> >> [...]
>> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> >> > > > >
>> >> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> >> > > > > should not be disabled by default because it's essential.
>> >> >> > > >
>> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> >> > > > default because it's essential" not a clock that stays always on?
>> >> >> > >
>> >> >> > > Because a clock that should not be disabled by default can be turned off
>> >> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >> >
>> >> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> >> > share the same meaning of essential.
>> >> >>
>> >> >> Essential for the particular use-case.
>> >> >
>> >> > So, how would the clock driver would know about which use case we're
>> >> > in? How would it know about which display engine is currently running?
>> >> > How would it know about which video output is being set?
>> >> >
>> >> > Currently, we have two separate display engines, which can each output
>> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> >> > one of these combinations would require different clocks. What clocks
>> >> > will we put in the driver? All of them?
>> >> >
>> >>
>> >> since simplefb cannot be extended how about adding, say, dtfb which
>> >> claims the resources from dt and then instantiates a simplefb once the
>> >> resources are claimed? That is have a dtfb which has the clocks
>> >> assigned and has simplefb as child dt node.
>> >
>> > I don't see how that changes anything. All you do is add another layer
>> > of indirection. The fundamental problem remains the same and isn't
>> > solved.
>>
>> It keeps clock code out of simplefb and provides driver for the kind
>> of framebuffer set up by firmware that exists on sunxi, exynos, and
>> probably many other SoCs. That is a framebuffer that needs some clocks
>> and possibly regulators enabled to keep running because the reality of
>> the platform is that it has clocks and regulators unlike some other
>> platforms that do not.
>>
>> These clocks and regulators are used but not configured by the
>> framebuffer and should be reclaimed when firmware framebuffer is
>> disabled. This is the same as the chunk of  memory used by simplefb
>> which is currently lost but should be reclaimed when simplefb is
>> disabled.
>>
>> This memory is not 'reserved for firmware' and unusable but reserved
>> for framebuffer and the regulators are not 'always on' or 'should
>> never be disabled' but should be enabled while framebuffer is used.
>>
>> As far as I can tell in DT this is expressed by creating a DT node
>> associated with the framebuffer driver that tells the kernel that this
>> memory, clocks and regulators are associated with the framebuffer
>> driver and can be reclaimed if this driver is stopped or not enabled
>> in the kernel at all. If you are going to be asinine about simplefb
>> not getting support for managing any resource other than the memory
>> chunk then another layer of indirection is required for platforms that
>> have more resources to manage.
>>
>> If there is another way to associate resources with a driver in DT
>> then please enlighten me.
>>
>> AFAICT simplefb is the framebuffer driver already in kernel closest to
>> the driver that is required for sunxi - simplefb also relies on
>> firmware to set up the framebuffer but unlike vesafb or efifb it
>> already has DT integration. So the most efficient way to implement
>> framebuffer for sunxi is to extend simplefb or if necessary add
>> another layer of indirection under simplefb. If there is a better
>> fitting driver in the kernel then please enlighten me and the
>> developer that wrote this patch what driver it would be.
>
> I think simplefb is exactly the right driver to use for this case. But I
> don't think making it manage all the resources is the right thing to do.

And what is supposed to manage resources used by simplefb when not simplefb?

> While it's fairly easy to do it, it's also something that needs to be
> done for every other driver with similar requirements.

Other drivers that require clocks do manage them, yes. And some
drivers that did not do that in the past were extended for that.

> Consider for
> example what happens if you want to play some welcome sound in the
> bootloader and keep it playing while the kernel is booting. You'd need
> to repeat exactly what this driver does to keep clocks for audio
> hardware running. And there are possibly other similar use-cases as
> well.

Why would you want to do that? If the kernel boots fast the welcome
sound can be played from userspace when all drivers all in place. If
it boots slow you can just play the sound and let the kernel boot.

If you implement enough of audio driver that the kernel can actually
change the startup sound then there is not much left out. You cannot
just place random data in a buffer but have to synchronize with the
hardware for audio playback to work.

>
> One other issue with simplefb is that it isn't a real device to begin
> with. It's completely virtual, so in the same way that it doesn't
> program any device-specific registers I don't think it should claim any
> resources.

OK, so the framebuffer memory that simplefb uses for scanout should
not be claimed by it ever, either?

So how is it supposed to be handled? Reserved as unusable memory
forever as it is now?

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
>> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
>> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> >> [...]
>> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> >> > > > >
>> >> >> > > > > Mike says in that email that he's opposing the addition of a property
>> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
>> >> >> > > > > should not be disabled by default because it's essential.
>> >> >> > > >
>> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> >> > > > default because it's essential" not a clock that stays always on?
>> >> >> > >
>> >> >> > > Because a clock that should not be disabled by default can be turned off
>> >> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >> >
>> >> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> >> > share the same meaning of essential.
>> >> >>
>> >> >> Essential for the particular use-case.
>> >> >
>> >> > So, how would the clock driver would know about which use case we're
>> >> > in? How would it know about which display engine is currently running?
>> >> > How would it know about which video output is being set?
>> >> >
>> >> > Currently, we have two separate display engines, which can each output
>> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> >> > one of these combinations would require different clocks. What clocks
>> >> > will we put in the driver? All of them?
>> >> >
>> >>
>> >> since simplefb cannot be extended how about adding, say, dtfb which
>> >> claims the resources from dt and then instantiates a simplefb once the
>> >> resources are claimed? That is have a dtfb which has the clocks
>> >> assigned and has simplefb as child dt node.
>> >
>> > I don't see how that changes anything. All you do is add another layer
>> > of indirection. The fundamental problem remains the same and isn't
>> > solved.
>>
>> It keeps clock code out of simplefb and provides driver for the kind
>> of framebuffer set up by firmware that exists on sunxi, exynos, and
>> probably many other SoCs. That is a framebuffer that needs some clocks
>> and possibly regulators enabled to keep running because the reality of
>> the platform is that it has clocks and regulators unlike some other
>> platforms that do not.
>>
>> These clocks and regulators are used but not configured by the
>> framebuffer and should be reclaimed when firmware framebuffer is
>> disabled. This is the same as the chunk of  memory used by simplefb
>> which is currently lost but should be reclaimed when simplefb is
>> disabled.
>>
>> This memory is not 'reserved for firmware' and unusable but reserved
>> for framebuffer and the regulators are not 'always on' or 'should
>> never be disabled' but should be enabled while framebuffer is used.
>>
>> As far as I can tell in DT this is expressed by creating a DT node
>> associated with the framebuffer driver that tells the kernel that this
>> memory, clocks and regulators are associated with the framebuffer
>> driver and can be reclaimed if this driver is stopped or not enabled
>> in the kernel at all. If you are going to be asinine about simplefb
>> not getting support for managing any resource other than the memory
>> chunk then another layer of indirection is required for platforms that
>> have more resources to manage.
>>
>> If there is another way to associate resources with a driver in DT
>> then please enlighten me.
>>
>> AFAICT simplefb is the framebuffer driver already in kernel closest to
>> the driver that is required for sunxi - simplefb also relies on
>> firmware to set up the framebuffer but unlike vesafb or efifb it
>> already has DT integration. So the most efficient way to implement
>> framebuffer for sunxi is to extend simplefb or if necessary add
>> another layer of indirection under simplefb. If there is a better
>> fitting driver in the kernel then please enlighten me and the
>> developer that wrote this patch what driver it would be.
>
> I think simplefb is exactly the right driver to use for this case. But I
> don't think making it manage all the resources is the right thing to do.

And what is supposed to manage resources used by simplefb when not simplefb?

> While it's fairly easy to do it, it's also something that needs to be
> done for every other driver with similar requirements.

Other drivers that require clocks do manage them, yes. And some
drivers that did not do that in the past were extended for that.

> Consider for
> example what happens if you want to play some welcome sound in the
> bootloader and keep it playing while the kernel is booting. You'd need
> to repeat exactly what this driver does to keep clocks for audio
> hardware running. And there are possibly other similar use-cases as
> well.

Why would you want to do that? If the kernel boots fast the welcome
sound can be played from userspace when all drivers all in place. If
it boots slow you can just play the sound and let the kernel boot.

If you implement enough of audio driver that the kernel can actually
change the startup sound then there is not much left out. You cannot
just place random data in a buffer but have to synchronize with the
hardware for audio playback to work.

>
> One other issue with simplefb is that it isn't a real device to begin
> with. It's completely virtual, so in the same way that it doesn't
> program any device-specific registers I don't think it should claim any
> resources.

OK, so the framebuffer memory that simplefb uses for scanout should
not be claimed by it ever, either?

So how is it supposed to be handled? Reserved as unusable memory
forever as it is now?

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 7403 bytes --]

On Fri, Aug 29, 2014 at 08:48:42AM +0200, Michal Suchanek wrote:
> On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> >> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> >> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> >> Hello,
> >> >>
> >> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> >> [...]
> >> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> >> > > > >
> >> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> >> > > > > should not be disabled by default because it's essential.
> >> >> >> > > >
> >> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> >> > >
> >> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >> >
> >> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> >> > share the same meaning of essential.
> >> >> >>
> >> >> >> Essential for the particular use-case.
> >> >> >
> >> >> > So, how would the clock driver would know about which use case we're
> >> >> > in? How would it know about which display engine is currently running?
> >> >> > How would it know about which video output is being set?
> >> >> >
> >> >> > Currently, we have two separate display engines, which can each output
> >> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> >> > one of these combinations would require different clocks. What clocks
> >> >> > will we put in the driver? All of them?
> >> >> >
> >> >>
> >> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> >> claims the resources from dt and then instantiates a simplefb once the
> >> >> resources are claimed? That is have a dtfb which has the clocks
> >> >> assigned and has simplefb as child dt node.
> >> >
> >> > I don't see how that changes anything. All you do is add another layer
> >> > of indirection. The fundamental problem remains the same and isn't
> >> > solved.
> >>
> >> It keeps clock code out of simplefb and provides driver for the kind
> >> of framebuffer set up by firmware that exists on sunxi, exynos, and
> >> probably many other SoCs. That is a framebuffer that needs some clocks
> >> and possibly regulators enabled to keep running because the reality of
> >> the platform is that it has clocks and regulators unlike some other
> >> platforms that do not.
> >>
> >> These clocks and regulators are used but not configured by the
> >> framebuffer and should be reclaimed when firmware framebuffer is
> >> disabled. This is the same as the chunk of  memory used by simplefb
> >> which is currently lost but should be reclaimed when simplefb is
> >> disabled.
> >>
> >> This memory is not 'reserved for firmware' and unusable but reserved
> >> for framebuffer and the regulators are not 'always on' or 'should
> >> never be disabled' but should be enabled while framebuffer is used.
> >>
> >> As far as I can tell in DT this is expressed by creating a DT node
> >> associated with the framebuffer driver that tells the kernel that this
> >> memory, clocks and regulators are associated with the framebuffer
> >> driver and can be reclaimed if this driver is stopped or not enabled
> >> in the kernel at all. If you are going to be asinine about simplefb
> >> not getting support for managing any resource other than the memory
> >> chunk then another layer of indirection is required for platforms that
> >> have more resources to manage.
> >>
> >> If there is another way to associate resources with a driver in DT
> >> then please enlighten me.
> >>
> >> AFAICT simplefb is the framebuffer driver already in kernel closest to
> >> the driver that is required for sunxi - simplefb also relies on
> >> firmware to set up the framebuffer but unlike vesafb or efifb it
> >> already has DT integration. So the most efficient way to implement
> >> framebuffer for sunxi is to extend simplefb or if necessary add
> >> another layer of indirection under simplefb. If there is a better
> >> fitting driver in the kernel then please enlighten me and the
> >> developer that wrote this patch what driver it would be.
> >
> > I think simplefb is exactly the right driver to use for this case. But I
> > don't think making it manage all the resources is the right thing to do.
> 
> And what is supposed to manage resources used by simplefb when not simplefb?

Nothing should be managing them. There's no need to manage them at all.
The issue that this patch works around is that the clock framework is
trying to be smart and turning all unused clocks off and making
incomplete assumptions about what "all unused clocks" means.

> > While it's fairly easy to do it, it's also something that needs to be
> > done for every other driver with similar requirements.
> 
> Other drivers that require clocks do manage them, yes. And some
> drivers that did not do that in the past were extended for that.

Not generic drivers. Not drivers that take over something that firmware
has set up.

> > Consider for
> > example what happens if you want to play some welcome sound in the
> > bootloader and keep it playing while the kernel is booting. You'd need
> > to repeat exactly what this driver does to keep clocks for audio
> > hardware running. And there are possibly other similar use-cases as
> > well.
> 
> Why would you want to do that? If the kernel boots fast the welcome
> sound can be played from userspace when all drivers all in place.

In that case you don't need simplefb either. Just use a real driver.

> If it boots slow you can just play the sound and let the kernel boot.

And have audio interrupted by the kernel booting and disabling the
clocks?

> > One other issue with simplefb is that it isn't a real device to begin
> > with. It's completely virtual, so in the same way that it doesn't
> > program any device-specific registers I don't think it should claim any
> > resources.
> 
> OK, so the framebuffer memory that simplefb uses for scanout should
> not be claimed by it ever, either?

No. simplefb needs to manage the framebuffer memory because it needs
explicit access to it. The contents of that memory need to be modified.
The frequency of the clocks don't need to be modified. They don't need
to be enabled or disabled either.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 08:48:42AM +0200, Michal Suchanek wrote:
> On 29 August 2014 08:19, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> >> On 28 August 2014 12:08, Thierry Reding <thierry.reding@gmail.com> wrote:
> >> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> >> Hello,
> >> >>
> >> >> On 27 August 2014 17:42, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> >> [...]
> >> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> >> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> >> > > > >
> >> >> >> > > > > Mike says in that email that he's opposing the addition of a property
> >> >> >> > > > > for clocks that is the equivalent of regulator-always-on. That's not
> >> >> >> > > > > what this is about. If at all it'd be a property to mark a clock that
> >> >> >> > > > > should not be disabled by default because it's essential.
> >> >> >> > > >
> >> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> >> > >
> >> >> >> > > Because a clock that should not be disabled by default can be turned off
> >> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >> >
> >> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> >> > share the same meaning of essential.
> >> >> >>
> >> >> >> Essential for the particular use-case.
> >> >> >
> >> >> > So, how would the clock driver would know about which use case we're
> >> >> > in? How would it know about which display engine is currently running?
> >> >> > How would it know about which video output is being set?
> >> >> >
> >> >> > Currently, we have two separate display engines, which can each output
> >> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> >> > one of these combinations would require different clocks. What clocks
> >> >> > will we put in the driver? All of them?
> >> >> >
> >> >>
> >> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> >> claims the resources from dt and then instantiates a simplefb once the
> >> >> resources are claimed? That is have a dtfb which has the clocks
> >> >> assigned and has simplefb as child dt node.
> >> >
> >> > I don't see how that changes anything. All you do is add another layer
> >> > of indirection. The fundamental problem remains the same and isn't
> >> > solved.
> >>
> >> It keeps clock code out of simplefb and provides driver for the kind
> >> of framebuffer set up by firmware that exists on sunxi, exynos, and
> >> probably many other SoCs. That is a framebuffer that needs some clocks
> >> and possibly regulators enabled to keep running because the reality of
> >> the platform is that it has clocks and regulators unlike some other
> >> platforms that do not.
> >>
> >> These clocks and regulators are used but not configured by the
> >> framebuffer and should be reclaimed when firmware framebuffer is
> >> disabled. This is the same as the chunk of  memory used by simplefb
> >> which is currently lost but should be reclaimed when simplefb is
> >> disabled.
> >>
> >> This memory is not 'reserved for firmware' and unusable but reserved
> >> for framebuffer and the regulators are not 'always on' or 'should
> >> never be disabled' but should be enabled while framebuffer is used.
> >>
> >> As far as I can tell in DT this is expressed by creating a DT node
> >> associated with the framebuffer driver that tells the kernel that this
> >> memory, clocks and regulators are associated with the framebuffer
> >> driver and can be reclaimed if this driver is stopped or not enabled
> >> in the kernel at all. If you are going to be asinine about simplefb
> >> not getting support for managing any resource other than the memory
> >> chunk then another layer of indirection is required for platforms that
> >> have more resources to manage.
> >>
> >> If there is another way to associate resources with a driver in DT
> >> then please enlighten me.
> >>
> >> AFAICT simplefb is the framebuffer driver already in kernel closest to
> >> the driver that is required for sunxi - simplefb also relies on
> >> firmware to set up the framebuffer but unlike vesafb or efifb it
> >> already has DT integration. So the most efficient way to implement
> >> framebuffer for sunxi is to extend simplefb or if necessary add
> >> another layer of indirection under simplefb. If there is a better
> >> fitting driver in the kernel then please enlighten me and the
> >> developer that wrote this patch what driver it would be.
> >
> > I think simplefb is exactly the right driver to use for this case. But I
> > don't think making it manage all the resources is the right thing to do.
> 
> And what is supposed to manage resources used by simplefb when not simplefb?

Nothing should be managing them. There's no need to manage them at all.
The issue that this patch works around is that the clock framework is
trying to be smart and turning all unused clocks off and making
incomplete assumptions about what "all unused clocks" means.

> > While it's fairly easy to do it, it's also something that needs to be
> > done for every other driver with similar requirements.
> 
> Other drivers that require clocks do manage them, yes. And some
> drivers that did not do that in the past were extended for that.

Not generic drivers. Not drivers that take over something that firmware
has set up.

> > Consider for
> > example what happens if you want to play some welcome sound in the
> > bootloader and keep it playing while the kernel is booting. You'd need
> > to repeat exactly what this driver does to keep clocks for audio
> > hardware running. And there are possibly other similar use-cases as
> > well.
> 
> Why would you want to do that? If the kernel boots fast the welcome
> sound can be played from userspace when all drivers all in place.

In that case you don't need simplefb either. Just use a real driver.

> If it boots slow you can just play the sound and let the kernel boot.

And have audio interrupted by the kernel booting and disabling the
clocks?

> > One other issue with simplefb is that it isn't a real device to begin
> > with. It's completely virtual, so in the same way that it doesn't
> > program any device-specific registers I don't think it should claim any
> > resources.
> 
> OK, so the framebuffer memory that simplefb uses for scanout should
> not be claimed by it ever, either?

No. simplefb needs to manage the framebuffer memory because it needs
explicit access to it. The contents of that memory need to be modified.
The frequency of the clocks don't need to be modified. They don't need
to be enabled or disabled either.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/bb51bd61/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > [...]
> > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > 
> > > > > > Mike says in that email that he's opposing the addition of a property
> > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > > should not be disabled by default because it's essential.
> > > > > 
> > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > default because it's essential" not a clock that stays always on?
> > > > 
> > > > Because a clock that should not be disabled by default can be turned off
> > > > when appropriate. A clock that is always on can't be turned off.
> > > 
> > > If a clock is essential, then it should never be disabled. Or we don't
> > > share the same meaning of essential.
> > 
> > Essential for the particular use-case.
> 
> So, how would the clock driver would know about which use case we're
> in? How would it know about which display engine is currently running?
> How would it know about which video output is being set?
> 
> Currently, we have two separate display engines, which can each output
> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> one of these combinations would require different clocks. What clocks
> will we put in the driver? All of them?

Ideally the solution wouldn't involve hard-coding this into the clock
driver at all. There should be a way for firmware to communicate to the
kernel that a given clock shouldn't be disabled. Then since firmware
already knows what it set up it can tell the kernel to not touch those.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > [...]
> > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > 
> > > > > > Mike says in that email that he's opposing the addition of a property
> > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > > should not be disabled by default because it's essential.
> > > > > 
> > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > default because it's essential" not a clock that stays always on?
> > > > 
> > > > Because a clock that should not be disabled by default can be turned off
> > > > when appropriate. A clock that is always on can't be turned off.
> > > 
> > > If a clock is essential, then it should never be disabled. Or we don't
> > > share the same meaning of essential.
> > 
> > Essential for the particular use-case.
> 
> So, how would the clock driver would know about which use case we're
> in? How would it know about which display engine is currently running?
> How would it know about which video output is being set?
> 
> Currently, we have two separate display engines, which can each output
> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> one of these combinations would require different clocks. What clocks
> will we put in the driver? All of them?

Ideally the solution wouldn't involve hard-coding this into the clock
driver at all. There should be a way for firmware to communicate to the
kernel that a given clock shouldn't be disabled. Then since firmware
already knows what it set up it can tell the kernel to not touch those.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140828/6599c7b1/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:11, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
>> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> > [...]
>> > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> > > > > > > https://lkml.org/lkml/2014/5/12/693
>> > > > > >
>> > > > > > Mike says in that email that he's opposing the addition of a property
>> > > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> > > > > > what this is about. If at all it'd be a property to mark a clock that
>> > > > > > should not be disabled by default because it's essential.
>> > > > >
>> > > > > It's just semantic. How is "a clock that should not be disabled by
>> > > > > default because it's essential" not a clock that stays always on?
>> > > >
>> > > > Because a clock that should not be disabled by default can be turned off
>> > > > when appropriate. A clock that is always on can't be turned off.
>> > >
>> > > If a clock is essential, then it should never be disabled. Or we don't
>> > > share the same meaning of essential.
>> >
>> > Essential for the particular use-case.
>>
>> So, how would the clock driver would know about which use case we're
>> in? How would it know about which display engine is currently running?
>> How would it know about which video output is being set?
>>
>> Currently, we have two separate display engines, which can each output
>> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> one of these combinations would require different clocks. What clocks
>> will we put in the driver? All of them?
>
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all. There should be a way for firmware to communicate to the
> kernel that a given clock shouldn't be disabled. Then since firmware
> already knows what it set up it can tell the kernel to not touch those.
>

And that way is that it inserts into the simplefb node or whatever
node the list of clocks that it programmed in order to make the
framebuffer work. Do you know a better, more generic way than that?

Thanks

Michal

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:11, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
>> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> > [...]
>> > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
>> > > > > > > https://lkml.org/lkml/2014/5/12/693
>> > > > > >
>> > > > > > Mike says in that email that he's opposing the addition of a property
>> > > > > > for clocks that is the equivalent of regulator-always-on. That's not
>> > > > > > what this is about. If at all it'd be a property to mark a clock that
>> > > > > > should not be disabled by default because it's essential.
>> > > > >
>> > > > > It's just semantic. How is "a clock that should not be disabled by
>> > > > > default because it's essential" not a clock that stays always on?
>> > > >
>> > > > Because a clock that should not be disabled by default can be turned off
>> > > > when appropriate. A clock that is always on can't be turned off.
>> > >
>> > > If a clock is essential, then it should never be disabled. Or we don't
>> > > share the same meaning of essential.
>> >
>> > Essential for the particular use-case.
>>
>> So, how would the clock driver would know about which use case we're
>> in? How would it know about which display engine is currently running?
>> How would it know about which video output is being set?
>>
>> Currently, we have two separate display engines, which can each output
>> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> one of these combinations would require different clocks. What clocks
>> will we put in the driver? All of them?
>
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all. There should be a way for firmware to communicate to the
> kernel that a given clock shouldn't be disabled. Then since firmware
> already knows what it set up it can tell the kernel to not touch those.
>

And that way is that it inserts into the simplefb node or whatever
node the list of clocks that it programmed in order to make the
framebuffer work. Do you know a better, more generic way than that?

Thanks

Michal

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3316 bytes --]

On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > [...]
> > > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > > 
> > > > > > > Mike says in that email that he's opposing the addition of a property
> > > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > > > should not be disabled by default because it's essential.
> > > > > > 
> > > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > > default because it's essential" not a clock that stays always on?
> > > > > 
> > > > > Because a clock that should not be disabled by default can be turned off
> > > > > when appropriate. A clock that is always on can't be turned off.
> > > > 
> > > > If a clock is essential, then it should never be disabled. Or we don't
> > > > share the same meaning of essential.
> > > 
> > > Essential for the particular use-case.
> > 
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> > 
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> 
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all.

Cool, so we do agree on that too :)

> There should be a way for firmware to communicate to the kernel that
> a given clock shouldn't be disabled.

And this patch was such an attempt. I guess it wasn't that far off
then.

> Then since firmware already knows what it set up it can tell the
> kernel to not touch those.

Somehow, I've been raised kernel-wise into thinking that you can never
fully trust your firmware. Or at least that you should have a way to
recover from any bug/bad behaviour from it.

Moreover, the way I see it, there's a major flaw in having an
attribute in the clock node: you don't even know if the clock is ever
going to be used.

If simplefb is not compiled in, you won't claim the clocks, and they
will be disabled, which is imho a good thing. This case wouldn't be
covered with an attribute at the clock node, because you don't have a
link to what device/feature actually uses it in the system, and so you
have to make the assumption that it will be used. And you will end up
with clocks with a rather high rate running for nothing.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > [...]
> > > > > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > > 
> > > > > > > Mike says in that email that he's opposing the addition of a property
> > > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > > what this is about. If at all it'd be a property to mark a clock that
> > > > > > > should not be disabled by default because it's essential.
> > > > > > 
> > > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > > default because it's essential" not a clock that stays always on?
> > > > > 
> > > > > Because a clock that should not be disabled by default can be turned off
> > > > > when appropriate. A clock that is always on can't be turned off.
> > > > 
> > > > If a clock is essential, then it should never be disabled. Or we don't
> > > > share the same meaning of essential.
> > > 
> > > Essential for the particular use-case.
> > 
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> > 
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> 
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all.

Cool, so we do agree on that too :)

> There should be a way for firmware to communicate to the kernel that
> a given clock shouldn't be disabled.

And this patch was such an attempt. I guess it wasn't that far off
then.

> Then since firmware already knows what it set up it can tell the
> kernel to not touch those.

Somehow, I've been raised kernel-wise into thinking that you can never
fully trust your firmware. Or at least that you should have a way to
recover from any bug/bad behaviour from it.

Moreover, the way I see it, there's a major flaw in having an
attribute in the clock node: you don't even know if the clock is ever
going to be used.

If simplefb is not compiled in, you won't claim the clocks, and they
will be disabled, which is imho a good thing. This case wouldn't be
covered with an attribute at the clock node, because you don't have a
link to what device/feature actually uses it in the system, and so you
have to make the assumption that it will be used. And you will end up
with clocks with a rather high rate running for nothing.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140828/b7fc73ce/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
[...]
> > Then since firmware already knows what it set up it can tell the
> > kernel to not touch those.
> 
> Somehow, I've been raised kernel-wise into thinking that you can never
> fully trust your firmware. Or at least that you should have a way to
> recover from any bug/bad behaviour from it.

If you don't trust your firmware then you shouldn't be taking over a
device that it's set up for you. Rather you should write a proper driver
that sets things up from the start.

This whole "we don't trust firmware" isn't going to work if we want to
have hand-off from firmware to kernel. And it's already been decided in
other threads that moving more code out of the kernel and into firmware
is a requirement (c.f. ARM64).

Also in this case you wrote the firmware, so why wouldn't you trust it?

> Moreover, the way I see it, there's a major flaw in having an
> attribute in the clock node: you don't even know if the clock is ever
> going to be used.
> 
> If simplefb is not compiled in, you won't claim the clocks, and they
> will be disabled, which is imho a good thing. This case wouldn't be
> covered with an attribute at the clock node, because you don't have a
> link to what device/feature actually uses it in the system, and so you
> have to make the assumption that it will be used. And you will end up
> with clocks with a rather high rate running for nothing.

That's completely hypothetical. If simplefb isn't enabled and the clock
isn't claimed there's probably still going to be some other driver
taking over eventually. If there isn't, what's the point of firmware
setting up display in the first case?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
[...]
> > Then since firmware already knows what it set up it can tell the
> > kernel to not touch those.
> 
> Somehow, I've been raised kernel-wise into thinking that you can never
> fully trust your firmware. Or at least that you should have a way to
> recover from any bug/bad behaviour from it.

If you don't trust your firmware then you shouldn't be taking over a
device that it's set up for you. Rather you should write a proper driver
that sets things up from the start.

This whole "we don't trust firmware" isn't going to work if we want to
have hand-off from firmware to kernel. And it's already been decided in
other threads that moving more code out of the kernel and into firmware
is a requirement (c.f. ARM64).

Also in this case you wrote the firmware, so why wouldn't you trust it?

> Moreover, the way I see it, there's a major flaw in having an
> attribute in the clock node: you don't even know if the clock is ever
> going to be used.
> 
> If simplefb is not compiled in, you won't claim the clocks, and they
> will be disabled, which is imho a good thing. This case wouldn't be
> covered with an attribute at the clock node, because you don't have a
> link to what device/feature actually uses it in the system, and so you
> have to make the assumption that it will be used. And you will end up
> with clocks with a rather high rate running for nothing.

That's completely hypothetical. If simplefb isn't enabled and the clock
isn't claimed there's probably still going to be some other driver
taking over eventually. If there isn't, what's the point of firmware
setting up display in the first case?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/98a81fed/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

On Fri, Aug 29, 2014 at 08:29:33AM +0200, Thierry Reding wrote:
> On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> > On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> [...]
> > > Then since firmware already knows what it set up it can tell the
> > > kernel to not touch those.
> > 
> > Somehow, I've been raised kernel-wise into thinking that you can never
> > fully trust your firmware. Or at least that you should have a way to
> > recover from any bug/bad behaviour from it.
> 
> If you don't trust your firmware then you shouldn't be taking over a
> device that it's set up for you. Rather you should write a proper driver
> that sets things up from the start.
> 
> This whole "we don't trust firmware" isn't going to work if we want to
> have hand-off from firmware to kernel. And it's already been decided in
> other threads that moving more code out of the kernel and into firmware
> is a requirement (c.f. ARM64).

Except that in ARM64 case, it has been asked before having any
SoC/boards out. We're definitely not in this situation there.

> Also in this case you wrote the firmware, so why wouldn't you trust it?

We partly wrote the firmware, on some of the available SoCs. Some
other just have allwinner's own. But yeah, in this case they wouldn't
even set up the framebuffer in the first place.

> > Moreover, the way I see it, there's a major flaw in having an
> > attribute in the clock node: you don't even know if the clock is ever
> > going to be used.
> > 
> > If simplefb is not compiled in, you won't claim the clocks, and they
> > will be disabled, which is imho a good thing. This case wouldn't be
> > covered with an attribute at the clock node, because you don't have a
> > link to what device/feature actually uses it in the system, and so you
> > have to make the assumption that it will be used. And you will end up
> > with clocks with a rather high rate running for nothing.
> 
> That's completely hypothetical. If simplefb isn't enabled and the clock
> isn't claimed there's probably still going to be some other driver
> taking over eventually. If there isn't, what's the point of firmware
> setting up display in the first case?

And now, here is a new requirement for the firmware: that in addition
to being reliable, that it must not be dumb, or take shortcuts, like
setting up the framebuffer in every case, no matter wether there's a
screen or not.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Fri, Aug 29, 2014 at 08:29:33AM +0200, Thierry Reding wrote:
> On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> > On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> [...]
> > > Then since firmware already knows what it set up it can tell the
> > > kernel to not touch those.
> > 
> > Somehow, I've been raised kernel-wise into thinking that you can never
> > fully trust your firmware. Or at least that you should have a way to
> > recover from any bug/bad behaviour from it.
> 
> If you don't trust your firmware then you shouldn't be taking over a
> device that it's set up for you. Rather you should write a proper driver
> that sets things up from the start.
> 
> This whole "we don't trust firmware" isn't going to work if we want to
> have hand-off from firmware to kernel. And it's already been decided in
> other threads that moving more code out of the kernel and into firmware
> is a requirement (c.f. ARM64).

Except that in ARM64 case, it has been asked before having any
SoC/boards out. We're definitely not in this situation there.

> Also in this case you wrote the firmware, so why wouldn't you trust it?

We partly wrote the firmware, on some of the available SoCs. Some
other just have allwinner's own. But yeah, in this case they wouldn't
even set up the framebuffer in the first place.

> > Moreover, the way I see it, there's a major flaw in having an
> > attribute in the clock node: you don't even know if the clock is ever
> > going to be used.
> > 
> > If simplefb is not compiled in, you won't claim the clocks, and they
> > will be disabled, which is imho a good thing. This case wouldn't be
> > covered with an attribute at the clock node, because you don't have a
> > link to what device/feature actually uses it in the system, and so you
> > have to make the assumption that it will be used. And you will end up
> > with clocks with a rather high rate running for nothing.
> 
> That's completely hypothetical. If simplefb isn't enabled and the clock
> isn't claimed there's probably still going to be some other driver
> taking over eventually. If there isn't, what's the point of firmware
> setting up display in the first case?

And now, here is a new requirement for the firmware: that in addition
to being reliable, that it must not be dumb, or take shortcuts, like
setting up the framebuffer in every case, no matter wether there's a
screen or not.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/c00013f8/attachment.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

On Fri, Aug 29, 2014 at 03:57:08PM +0200, Maxime Ripard wrote:
> On Fri, Aug 29, 2014 at 08:29:33AM +0200, Thierry Reding wrote:
> > On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> > > On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> > [...]
> > > > Then since firmware already knows what it set up it can tell the
> > > > kernel to not touch those.
> > > 
> > > Somehow, I've been raised kernel-wise into thinking that you can never
> > > fully trust your firmware. Or at least that you should have a way to
> > > recover from any bug/bad behaviour from it.
> > 
> > If you don't trust your firmware then you shouldn't be taking over a
> > device that it's set up for you. Rather you should write a proper driver
> > that sets things up from the start.
> > 
> > This whole "we don't trust firmware" isn't going to work if we want to
> > have hand-off from firmware to kernel. And it's already been decided in
> > other threads that moving more code out of the kernel and into firmware
> > is a requirement (c.f. ARM64).
> 
> Except that in ARM64 case, it has been asked before having any
> SoC/boards out. We're definitely not in this situation there.

You're still in the situation where you need to trust your firmware, so
my point remains valid.

> > Also in this case you wrote the firmware, so why wouldn't you trust it?
> 
> We partly wrote the firmware, on some of the available SoCs. Some
> other just have allwinner's own. But yeah, in this case they wouldn't
> even set up the framebuffer in the first place.

Even if you didn't write it, you could still trust it provided that you
had the source code for it. The whole argument of "never trust firmware"
is based on the assumption that you can't fix it. And even if that's the
case, it's still perfectly acceptable to not trust firmware. But if you
don't trust firmware then you really shouldn't be using simplefb in the
first place and do everything in the kernel.

> > > Moreover, the way I see it, there's a major flaw in having an
> > > attribute in the clock node: you don't even know if the clock is ever
> > > going to be used.
> > > 
> > > If simplefb is not compiled in, you won't claim the clocks, and they
> > > will be disabled, which is imho a good thing. This case wouldn't be
> > > covered with an attribute at the clock node, because you don't have a
> > > link to what device/feature actually uses it in the system, and so you
> > > have to make the assumption that it will be used. And you will end up
> > > with clocks with a rather high rate running for nothing.
> > 
> > That's completely hypothetical. If simplefb isn't enabled and the clock
> > isn't claimed there's probably still going to be some other driver
> > taking over eventually. If there isn't, what's the point of firmware
> > setting up display in the first case?
> 
> And now, here is a new requirement for the firmware: that in addition
> to being reliable, that it must not be dumb, or take shortcuts, like
> setting up the framebuffer in every case, no matter wether there's a
> screen or not.

Firmware should never do that anyway. The whole point of firmware is to
be device-specific and therefore it already knows when there's a need to
activate a framebuffer or not.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 03:57:08PM +0200, Maxime Ripard wrote:
> On Fri, Aug 29, 2014 at 08:29:33AM +0200, Thierry Reding wrote:
> > On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> > > On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> > [...]
> > > > Then since firmware already knows what it set up it can tell the
> > > > kernel to not touch those.
> > > 
> > > Somehow, I've been raised kernel-wise into thinking that you can never
> > > fully trust your firmware. Or at least that you should have a way to
> > > recover from any bug/bad behaviour from it.
> > 
> > If you don't trust your firmware then you shouldn't be taking over a
> > device that it's set up for you. Rather you should write a proper driver
> > that sets things up from the start.
> > 
> > This whole "we don't trust firmware" isn't going to work if we want to
> > have hand-off from firmware to kernel. And it's already been decided in
> > other threads that moving more code out of the kernel and into firmware
> > is a requirement (c.f. ARM64).
> 
> Except that in ARM64 case, it has been asked before having any
> SoC/boards out. We're definitely not in this situation there.

You're still in the situation where you need to trust your firmware, so
my point remains valid.

> > Also in this case you wrote the firmware, so why wouldn't you trust it?
> 
> We partly wrote the firmware, on some of the available SoCs. Some
> other just have allwinner's own. But yeah, in this case they wouldn't
> even set up the framebuffer in the first place.

Even if you didn't write it, you could still trust it provided that you
had the source code for it. The whole argument of "never trust firmware"
is based on the assumption that you can't fix it. And even if that's the
case, it's still perfectly acceptable to not trust firmware. But if you
don't trust firmware then you really shouldn't be using simplefb in the
first place and do everything in the kernel.

> > > Moreover, the way I see it, there's a major flaw in having an
> > > attribute in the clock node: you don't even know if the clock is ever
> > > going to be used.
> > > 
> > > If simplefb is not compiled in, you won't claim the clocks, and they
> > > will be disabled, which is imho a good thing. This case wouldn't be
> > > covered with an attribute at the clock node, because you don't have a
> > > link to what device/feature actually uses it in the system, and so you
> > > have to make the assumption that it will be used. And you will end up
> > > with clocks with a rather high rate running for nothing.
> > 
> > That's completely hypothetical. If simplefb isn't enabled and the clock
> > isn't claimed there's probably still going to be some other driver
> > taking over eventually. If there isn't, what's the point of firmware
> > setting up display in the first case?
> 
> And now, here is a new requirement for the firmware: that in addition
> to being reliable, that it must not be dumb, or take shortcuts, like
> setting up the framebuffer in every case, no matter wether there's a
> screen or not.

Firmware should never do that anyway. The whole point of firmware is to
be device-specific and therefore it already knows when there's a need to
activate a framebuffer or not.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140829/7e24e17e/attachment-0001.sig>

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

tis 2014-08-26 klockan 15:53 +0200 skrev Maxime Ripard:
> > it should be fixed at the root. So a much better solution would be to
> > establish a way for firmware to communicate to the kernel that a given
> > resource has been enabled by firmware and shouldn't be disabled. Such a
> > solution can be implement for all types of resources and can be reused
> > by all drivers since they don't have to worry about these details.
> 
> Mike Turquette repeatedly said that he was against such a DT property:
> https://lkml.org/lkml/2014/5/12/693

And not really what we want here. The clocks should be turned off if not
in use, i.e. when simplefb is unbound from the device and no other
driver has taken over. Maybe even in the case where there is no simplefb
driver in-kernel, but if the use case is to be generalized then this
kind of resources need to be held until explicitly released to allow
resources to be held until their driver is loaded, which may happen long
after kernel bootup.

But again, for many use cases it is a virtual hardware property, not
really hardware in it's own but still smells a lot like hardware. These
parameters is only valid until the hardware have been reconfigured.

Regards
Henrik

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Henrik Nordström]

tis 2014-08-26 klockan 15:53 +0200 skrev Maxime Ripard:
> > it should be fixed at the root. So a much better solution would be to
> > establish a way for firmware to communicate to the kernel that a given
> > resource has been enabled by firmware and shouldn't be disabled. Such a
> > solution can be implement for all types of resources and can be reused
> > by all drivers since they don't have to worry about these details.
> 
> Mike Turquette repeatedly said that he was against such a DT property:
> https://lkml.org/lkml/2014/5/12/693

And not really what we want here. The clocks should be turned off if not
in use, i.e. when simplefb is unbound from the device and no other
driver has taken over. Maybe even in the case where there is no simplefb
driver in-kernel, but if the use case is to be generalized then this
kind of resources need to be held until explicitly released to allow
resources to be held until their driver is loaded, which may happen long
after kernel bootup.

But again, for many use cases it is a virtual hardware property, not
really hardware in it's own but still smells a lot like hardware. These
parameters is only valid until the hardware have been reconfigured.

Regards
Henrik

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Andreas Färber]

Hi,

Am 25.08.2014 15:47, schrieb Hans de Goede:
> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
[...]
> As for the suggestion to simply never disable the plls / ahb gates by blocking
> them from ever being disabled in the sunxi clock driver, that is not really
> a solution either, as we want to be able to turn these things off to safe
> power on screen blank once control has been turned over to the kms driver.

Without wanting to take sides on the simplefb matter, can't you just use
clk_ignore_unused in bootargs to work around the issue at hand?
That's what I do on the Spring Chromebook.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Andreas Färber]

Hi,

Am 25.08.2014 15:47, schrieb Hans de Goede:
> On 08/25/2014 03:39 PM, Thierry Reding wrote:
>> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
>>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
>>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
>>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
>>>>>> If not, perhaps the clock driver should force the clock to be
>>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
[...]
> As for the suggestion to simply never disable the plls / ahb gates by blocking
> them from ever being disabled in the sunxi clock driver, that is not really
> a solution either, as we want to be able to turn these things off to safe
> power on screen blank once control has been turned over to the kms driver.

Without wanting to take sides on the simplefb matter, can't you just use
clk_ignore_unused in bootargs to work around the issue at hand?
That's what I do on the Spring Chromebook.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

Hi,

On Mon, Aug 25, 2014 at 05:25:18PM +0200, Andreas Färber wrote:
> Hi,
> 
> Am 25.08.2014 15:47, schrieb Hans de Goede:
> > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> [...]
> > As for the suggestion to simply never disable the plls / ahb gates by blocking
> > them from ever being disabled in the sunxi clock driver, that is not really
> > a solution either, as we want to be able to turn these things off to safe
> > power on screen blank once control has been turned over to the kms driver.
> 
> Without wanting to take sides on the simplefb matter, can't you just use
> clk_ignore_unused in bootargs to work around the issue at hand?
> That's what I do on the Spring Chromebook.

Leaving *all* the clocks enabled just to workaround a driver failing
to grab its clocks doesn't look like a solution either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

Hi,

On Mon, Aug 25, 2014 at 05:25:18PM +0200, Andreas F?rber wrote:
> Hi,
> 
> Am 25.08.2014 15:47, schrieb Hans de Goede:
> > On 08/25/2014 03:39 PM, Thierry Reding wrote:
> >> On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote:
> >>> On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote:
> >>>> On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote:
> >>>>> On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote:
> >>>>>> If not, perhaps the clock driver should force the clock to be
> >>>>>> enabled (perhaps only if the DRM/KMS driver isn't enabled?).
> [...]
> > As for the suggestion to simply never disable the plls / ahb gates by blocking
> > them from ever being disabled in the sunxi clock driver, that is not really
> > a solution either, as we want to be able to turn these things off to safe
> > power on screen blank once control has been turned over to the kms driver.
> 
> Without wanting to take sides on the simplefb matter, can't you just use
> clk_ignore_unused in bootargs to work around the issue at hand?
> That's what I do on the Spring Chromebook.

Leaving *all* the clocks enabled just to workaround a driver failing
to grab its clocks doesn't look like a solution either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140826/67dbc617/attachment.sig>

Re: simplefb: add clock handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> This is needed for the sunxi platform, where the u-boot initialized display
> engine gets disabled by the clocks framework if certain clocks are not
> claimed. Once these clocks are disabled, register content is lost, and there
> is no turning back unless a full display driver is loaded, which kind of
> beats the purpose of having simplefb running.
>
> The lack of clock handling should plague more hardware, but so far rpi is the
> best known user of simplefb, and its stepmotherly handling of the arm core
> has kept these sort of issues from the kernel.
>
> The sunxi u-boot side code can be found here:
> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>
> Patch 3 might be controversial, as this does not achieve anything real today,
> since the status property in dt is only really evaluated when dealing with a
> nodes memory. It still seems like a good idea to at least flag this memory or
> node as disabled, as we really have no way back when the clocks get disabled.

Hans de Goede shortly told me about this and, tbh, I am not very
pleased. Stephen tried to keep simplefd "as simple as possible", your
patch now adds hardware-specific features. To be fair, the patch is
simple and clocks are easy to handle, but I somehow fear we have to
add more and more hardware-support that is required to keep the
framebuffer active. This really defeats the purpose of simplefb.

The biggest question I have, is why do you add the clocks to your DT
at all? The framebuffer is set up by your boot-loader (or maybe
platform code) and should prepare the clocks. I don't see why we add
the clocks to DT now. If they're not added, then no-one will disable
them and simplefb works just fine, right?

Or is there some requirement to make DT a _complete_ hw-description?
Or is there some parent clock which might be used by other drivers and
controls the clock used for your display?

The only reason I see to add the clocks, is to support both, simplefb
*and* a hardware-driver. However, fbdev hand-over is horribly racy and
I'd much rather prefer a solution like sysfb that does proper handover
from primitive firmware-FBs to real hardware-drivers. In that case,
we'd have to figure out how to deal with clocks, but we could do it in
sysfb (which is meant to deal with those issues) with the benefit of
controlling hand-over directly, and allowing hw-dependent features.

My sysfb patches haven't been updated for a while, though, and you
have a working solution here. So I'm not going to NAK this, I
appreciate people working on this. But I'd like to get a discussion
started so we can at least figure out some nicer solution for the
future which might replace your code.

Btw., my current idea was to destroy the platform-devices of EFI/VGA
framebuffers during hand-over (because usually the underlying hw is
shutdown/modified). This automatically unloads simplefb and makes sure
the real hw-driver can be probed without other drivers touching the
hardware in parallel. Iff you unload the hw-driver afterwards, it can
re-create the firmware framebuffer and add a platform-device to make
simplefb load again (in case anyone really needs this).
Looking at your 3rd patch, I wonder whether this works with DT based
machines, or whether we'd have to use the "disable" mechanism you
chose. Any reason destroying the device would not work there? If yes,
I will look into the "disable-idea".

Thanks
David

simplefb: add clock handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
> This is needed for the sunxi platform, where the u-boot initialized display
> engine gets disabled by the clocks framework if certain clocks are not
> claimed. Once these clocks are disabled, register content is lost, and there
> is no turning back unless a full display driver is loaded, which kind of
> beats the purpose of having simplefb running.
>
> The lack of clock handling should plague more hardware, but so far rpi is the
> best known user of simplefb, and its stepmotherly handling of the arm core
> has kept these sort of issues from the kernel.
>
> The sunxi u-boot side code can be found here:
> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>
> Patch 3 might be controversial, as this does not achieve anything real today,
> since the status property in dt is only really evaluated when dealing with a
> nodes memory. It still seems like a good idea to at least flag this memory or
> node as disabled, as we really have no way back when the clocks get disabled.

Hans de Goede shortly told me about this and, tbh, I am not very
pleased. Stephen tried to keep simplefd "as simple as possible", your
patch now adds hardware-specific features. To be fair, the patch is
simple and clocks are easy to handle, but I somehow fear we have to
add more and more hardware-support that is required to keep the
framebuffer active. This really defeats the purpose of simplefb.

The biggest question I have, is why do you add the clocks to your DT
at all? The framebuffer is set up by your boot-loader (or maybe
platform code) and should prepare the clocks. I don't see why we add
the clocks to DT now. If they're not added, then no-one will disable
them and simplefb works just fine, right?

Or is there some requirement to make DT a _complete_ hw-description?
Or is there some parent clock which might be used by other drivers and
controls the clock used for your display?

The only reason I see to add the clocks, is to support both, simplefb
*and* a hardware-driver. However, fbdev hand-over is horribly racy and
I'd much rather prefer a solution like sysfb that does proper handover
from primitive firmware-FBs to real hardware-drivers. In that case,
we'd have to figure out how to deal with clocks, but we could do it in
sysfb (which is meant to deal with those issues) with the benefit of
controlling hand-over directly, and allowing hw-dependent features.

My sysfb patches haven't been updated for a while, though, and you
have a working solution here. So I'm not going to NAK this, I
appreciate people working on this. But I'd like to get a discussion
started so we can at least figure out some nicer solution for the
future which might replace your code.

Btw., my current idea was to destroy the platform-devices of EFI/VGA
framebuffers during hand-over (because usually the underlying hw is
shutdown/modified). This automatically unloads simplefb and makes sure
the real hw-driver can be probed without other drivers touching the
hardware in parallel. Iff you unload the hw-driver afterwards, it can
re-create the firmware framebuffer and add a platform-device to make
simplefb load again (in case anyone really needs this).
Looking at your 3rd patch, I wonder whether this works with DT based
machines, or whether we'd have to use the "disable" mechanism you
chose. Any reason destroying the device would not work there? If yes,
I will look into the "disable-idea".

Thanks
David

Re: simplefb: add clock handling

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:54:21AM +0200, David Herrmann wrote:
> Hi
> 
> Hans de Goede shortly told me about this and, tbh, I am not very
> pleased. Stephen tried to keep simplefd "as simple as possible", your
> patch now adds hardware-specific features. To be fair, the patch is
> simple and clocks are easy to handle, but I somehow fear we have to
> add more and more hardware-support that is required to keep the
> framebuffer active. This really defeats the purpose of simplefb.

SimpleFB is a really deceptive name. If you lie to your ARM core all the 
time, and do most things behind its back, like RPi does, then you can 
get away with simplefb.

If not, it quickly becomes a lot more complicated, fast. This should've 
been called rpibootfb or something.

How does one deal with this dealbreaker issue of clocks? Or memory, 
apart from telling the kernel that the fb area is simple not accessible 
as normal ram. Or dpms?

> The biggest question I have, is why do you add the clocks to your DT
> at all?

I didn't, someone else did.

> The framebuffer is set up by your boot-loader (or maybe
> platform code) and should prepare the clocks. I don't see why we add
> the clocks to DT now. If they're not added, then no-one will disable
> them and simplefb works just fine, right?
> 
> Or is there some requirement to make DT a _complete_ hw-description?

Again, i am not responsible for that part. But my impression is that it 
should be absolutely complete, and i have been whining about actual bit 
offsets into registers being provided from the dt :(

> Or is there some parent clock which might be used by other drivers and
> controls the clock used for your display?

Not at this point for sunxi, but there will be.

> The only reason I see to add the clocks, is to support both, simplefb
> *and* a hardware-driver. However, fbdev hand-over is horribly racy and
> I'd much rather prefer a solution like sysfb that does proper handover
> from primitive firmware-FBs to real hardware-drivers. In that case,
> we'd have to figure out how to deal with clocks, but we could do it in
> sysfb (which is meant to deal with those issues) with the benefit of
> controlling hand-over directly, and allowing hw-dependent features.

Yes, a KMS driver is being worked on. I was, as a first order 
approximation (when i move it to mainline code), going to manually do 
some of this handover from simplefb.

> My sysfb patches haven't been updated for a while, though, and you
> have a working solution here. So I'm not going to NAK this, I
> appreciate people working on this. But I'd like to get a discussion
> started so we can at least figure out some nicer solution for the
> future which might replace your code.

So much for this being simple. again :)

> Btw., my current idea was to destroy the platform-devices of EFI/VGA
> framebuffers during hand-over (because usually the underlying hw is
> shutdown/modified). This automatically unloads simplefb and makes sure
> the real hw-driver can be probed without other drivers touching the
> hardware in parallel. Iff you unload the hw-driver afterwards, it can
> re-create the firmware framebuffer and add a platform-device to make
> simplefb load again (in case anyone really needs this).
> Looking at your 3rd patch, I wonder whether this works with DT based
> machines, or whether we'd have to use the "disable" mechanism you
> chose. Any reason destroying the device would not work there? If yes,
> I will look into the "disable-idea".

The clocks we currently claim handle the ahb gating of different display 
engines. Disable the gating bit, and all power is lost to the respective 
engine, and register content vanishes. So there is absolutely no coming 
back from that, apart from starting a proper display driver.

Luc Verhaegen.

simplefb: add clock handling

[Luc Verhaegen]

On Wed, Aug 13, 2014 at 09:54:21AM +0200, David Herrmann wrote:
> Hi
> 
> Hans de Goede shortly told me about this and, tbh, I am not very
> pleased. Stephen tried to keep simplefd "as simple as possible", your
> patch now adds hardware-specific features. To be fair, the patch is
> simple and clocks are easy to handle, but I somehow fear we have to
> add more and more hardware-support that is required to keep the
> framebuffer active. This really defeats the purpose of simplefb.

SimpleFB is a really deceptive name. If you lie to your ARM core all the 
time, and do most things behind its back, like RPi does, then you can 
get away with simplefb.

If not, it quickly becomes a lot more complicated, fast. This should've 
been called rpibootfb or something.

How does one deal with this dealbreaker issue of clocks? Or memory, 
apart from telling the kernel that the fb area is simple not accessible 
as normal ram. Or dpms?

> The biggest question I have, is why do you add the clocks to your DT
> at all?

I didn't, someone else did.

> The framebuffer is set up by your boot-loader (or maybe
> platform code) and should prepare the clocks. I don't see why we add
> the clocks to DT now. If they're not added, then no-one will disable
> them and simplefb works just fine, right?
> 
> Or is there some requirement to make DT a _complete_ hw-description?

Again, i am not responsible for that part. But my impression is that it 
should be absolutely complete, and i have been whining about actual bit 
offsets into registers being provided from the dt :(

> Or is there some parent clock which might be used by other drivers and
> controls the clock used for your display?

Not at this point for sunxi, but there will be.

> The only reason I see to add the clocks, is to support both, simplefb
> *and* a hardware-driver. However, fbdev hand-over is horribly racy and
> I'd much rather prefer a solution like sysfb that does proper handover
> from primitive firmware-FBs to real hardware-drivers. In that case,
> we'd have to figure out how to deal with clocks, but we could do it in
> sysfb (which is meant to deal with those issues) with the benefit of
> controlling hand-over directly, and allowing hw-dependent features.

Yes, a KMS driver is being worked on. I was, as a first order 
approximation (when i move it to mainline code), going to manually do 
some of this handover from simplefb.

> My sysfb patches haven't been updated for a while, though, and you
> have a working solution here. So I'm not going to NAK this, I
> appreciate people working on this. But I'd like to get a discussion
> started so we can at least figure out some nicer solution for the
> future which might replace your code.

So much for this being simple. again :)

> Btw., my current idea was to destroy the platform-devices of EFI/VGA
> framebuffers during hand-over (because usually the underlying hw is
> shutdown/modified). This automatically unloads simplefb and makes sure
> the real hw-driver can be probed without other drivers touching the
> hardware in parallel. Iff you unload the hw-driver afterwards, it can
> re-create the firmware framebuffer and add a platform-device to make
> simplefb load again (in case anyone really needs this).
> Looking at your 3rd patch, I wonder whether this works with DT based
> machines, or whether we'd have to use the "disable" mechanism you
> chose. Any reason destroying the device would not work there? If yes,
> I will look into the "disable-idea".

The clocks we currently claim handle the ahb gating of different display 
engines. Disable the gating bit, and all power is lost to the respective 
engine, and register content vanishes. So there is absolutely no coming 
back from that, apart from starting a proper display driver.

Luc Verhaegen.

Re: [linux-sunxi] simplefb: add clock handling

[Koen Kooi]

Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:

> Hi
> 
> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> This is needed for the sunxi platform, where the u-boot initialized display
>> engine gets disabled by the clocks framework if certain clocks are not
>> claimed. Once these clocks are disabled, register content is lost, and there
>> is no turning back unless a full display driver is loaded, which kind of
>> beats the purpose of having simplefb running.
>> 
>> The lack of clock handling should plague more hardware, but so far rpi is the
>> best known user of simplefb, and its stepmotherly handling of the arm core
>> has kept these sort of issues from the kernel.
>> 
>> The sunxi u-boot side code can be found here:
>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>> 
>> Patch 3 might be controversial, as this does not achieve anything real today,
>> since the status property in dt is only really evaluated when dealing with a
>> nodes memory. It still seems like a good idea to at least flag this memory or
>> node as disabled, as we really have no way back when the clocks get disabled.
> 
> Hans de Goede shortly told me about this and, tbh, I am not very
> pleased. Stephen tried to keep simplefd "as simple as possible", your
> patch now adds hardware-specific features. To be fair, the patch is
> simple and clocks are easy to handle, but I somehow fear we have to
> add more and more hardware-support that is required to keep the
> framebuffer active. This really defeats the purpose of simplefb.
> 
> The biggest question I have, is why do you add the clocks to your DT
> at all? The framebuffer is set up by your boot-loader (or maybe
> platform code) and should prepare the clocks. I don't see why we add
> the clocks to DT now. If they're not added, then no-one will disable
> them and simplefb works just fine, right?

All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 

regards,

Koen

[linux-sunxi] simplefb: add clock handling

[Koen Kooi]

Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:

> Hi
> 
> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>> This is needed for the sunxi platform, where the u-boot initialized display
>> engine gets disabled by the clocks framework if certain clocks are not
>> claimed. Once these clocks are disabled, register content is lost, and there
>> is no turning back unless a full display driver is loaded, which kind of
>> beats the purpose of having simplefb running.
>> 
>> The lack of clock handling should plague more hardware, but so far rpi is the
>> best known user of simplefb, and its stepmotherly handling of the arm core
>> has kept these sort of issues from the kernel.
>> 
>> The sunxi u-boot side code can be found here:
>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>> 
>> Patch 3 might be controversial, as this does not achieve anything real today,
>> since the status property in dt is only really evaluated when dealing with a
>> nodes memory. It still seems like a good idea to at least flag this memory or
>> node as disabled, as we really have no way back when the clocks get disabled.
> 
> Hans de Goede shortly told me about this and, tbh, I am not very
> pleased. Stephen tried to keep simplefd "as simple as possible", your
> patch now adds hardware-specific features. To be fair, the patch is
> simple and clocks are easy to handle, but I somehow fear we have to
> add more and more hardware-support that is required to keep the
> framebuffer active. This really defeats the purpose of simplefb.
> 
> The biggest question I have, is why do you add the clocks to your DT
> at all? The framebuffer is set up by your boot-loader (or maybe
> platform code) and should prepare the clocks. I don't see why we add
> the clocks to DT now. If they're not added, then no-one will disable
> them and simplefb works just fine, right?

All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 

regards,

Koen

Re: [linux-sunxi] simplefb: add clock handling

[Hans de Goede]

Hi,

On 08/13/2014 10:21 AM, Koen Kooi wrote:
> 
> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
> 
>> Hi
>>
>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> This is needed for the sunxi platform, where the u-boot initialized display
>>> engine gets disabled by the clocks framework if certain clocks are not
>>> claimed. Once these clocks are disabled, register content is lost, and there
>>> is no turning back unless a full display driver is loaded, which kind of
>>> beats the purpose of having simplefb running.
>>>
>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>> has kept these sort of issues from the kernel.
>>>
>>> The sunxi u-boot side code can be found here:
>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>
>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>> since the status property in dt is only really evaluated when dealing with a
>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>> node as disabled, as we really have no way back when the clocks get disabled.
>>
>> Hans de Goede shortly told me about this and, tbh, I am not very
>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>> patch now adds hardware-specific features. To be fair, the patch is
>> simple and clocks are easy to handle, but I somehow fear we have to
>> add more and more hardware-support that is required to keep the
>> framebuffer active. This really defeats the purpose of simplefb.
>>
>> The biggest question I have, is why do you add the clocks to your DT
>> at all? The framebuffer is set up by your boot-loader (or maybe
>> platform code) and should prepare the clocks. I don't see why we add
>> the clocks to DT now. If they're not added, then no-one will disable
>> them and simplefb works just fine, right?
> 
> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 

I believe that having some simple generic fb driver will be useful
on non x86, since we don't have vga-console there, and most distros
will build kms drivers as modules. Having the kernel / initrd code being
able to show output (like e.g. missing symbols in the kms drivers) seems
a very useful feature to me.

The way I envision this to work is:

u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
it can show this on the display

kernel takes over using something like simplefb (built into the kernel)
for its initial output / any error messages.

initrd loads kms, kms takes over.

This way we've a way to show error messages during boot at all times.

As we start supporting more ARM htpc boxes out of the box, telling the
user to hook up a serial console (which often involves soldering wires
to some test points) when things don't work really is not a viable
answer.

Regards,

Hans

[linux-sunxi] simplefb: add clock handling

[Hans de Goede]

Hi,

On 08/13/2014 10:21 AM, Koen Kooi wrote:
> 
> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
> 
>> Hi
>>
>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>> This is needed for the sunxi platform, where the u-boot initialized display
>>> engine gets disabled by the clocks framework if certain clocks are not
>>> claimed. Once these clocks are disabled, register content is lost, and there
>>> is no turning back unless a full display driver is loaded, which kind of
>>> beats the purpose of having simplefb running.
>>>
>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>> has kept these sort of issues from the kernel.
>>>
>>> The sunxi u-boot side code can be found here:
>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>
>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>> since the status property in dt is only really evaluated when dealing with a
>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>> node as disabled, as we really have no way back when the clocks get disabled.
>>
>> Hans de Goede shortly told me about this and, tbh, I am not very
>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>> patch now adds hardware-specific features. To be fair, the patch is
>> simple and clocks are easy to handle, but I somehow fear we have to
>> add more and more hardware-support that is required to keep the
>> framebuffer active. This really defeats the purpose of simplefb.
>>
>> The biggest question I have, is why do you add the clocks to your DT
>> at all? The framebuffer is set up by your boot-loader (or maybe
>> platform code) and should prepare the clocks. I don't see why we add
>> the clocks to DT now. If they're not added, then no-one will disable
>> them and simplefb works just fine, right?
> 
> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 

I believe that having some simple generic fb driver will be useful
on non x86, since we don't have vga-console there, and most distros
will build kms drivers as modules. Having the kernel / initrd code being
able to show output (like e.g. missing symbols in the kms drivers) seems
a very useful feature to me.

The way I envision this to work is:

u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
it can show this on the display

kernel takes over using something like simplefb (built into the kernel)
for its initial output / any error messages.

initrd loads kms, kms takes over.

This way we've a way to show error messages during boot at all times.

As we start supporting more ARM htpc boxes out of the box, telling the
user to hook up a serial console (which often involves soldering wires
to some test points) when things don't work really is not a viable
answer.

Regards,

Hans

Re: [linux-sunxi] simplefb: add clock handling

[Koen Kooi]

Op 13 aug. 2014, om 10:36 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:

> Hi,
> 
> On 08/13/2014 10:21 AM, Koen Kooi wrote:
>> 
>> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
>> 
>>> Hi
>>> 
>>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>> This is needed for the sunxi platform, where the u-boot initialized display
>>>> engine gets disabled by the clocks framework if certain clocks are not
>>>> claimed. Once these clocks are disabled, register content is lost, and there
>>>> is no turning back unless a full display driver is loaded, which kind of
>>>> beats the purpose of having simplefb running.
>>>> 
>>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>>> has kept these sort of issues from the kernel.
>>>> 
>>>> The sunxi u-boot side code can be found here:
>>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>> 
>>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>>> since the status property in dt is only really evaluated when dealing with a
>>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>>> node as disabled, as we really have no way back when the clocks get disabled.
>>> 
>>> Hans de Goede shortly told me about this and, tbh, I am not very
>>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>>> patch now adds hardware-specific features. To be fair, the patch is
>>> simple and clocks are easy to handle, but I somehow fear we have to
>>> add more and more hardware-support that is required to keep the
>>> framebuffer active. This really defeats the purpose of simplefb.
>>> 
>>> The biggest question I have, is why do you add the clocks to your DT
>>> at all? The framebuffer is set up by your boot-loader (or maybe
>>> platform code) and should prepare the clocks. I don't see why we add
>>> the clocks to DT now. If they're not added, then no-one will disable
>>> them and simplefb works just fine, right?
>> 
>> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
>> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 
> 
> I believe that having some simple generic fb driver will be useful
> on non x86, since we don't have vga-console there, and most distros
> will build kms drivers as modules. Having the kernel / initrd code being
> able to show output (like e.g. missing symbols in the kms drivers) seems
> a very useful feature to me.
> 
> The way I envision this to work is:
> 
> u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
> it can show this on the display
> 
> kernel takes over using something like simplefb (built into the kernel)
> for its initial output / any error messages.
> 
> initrd loads kms, kms takes over.
> 
> This way we've a way to show error messages during boot at all times.
> 
> As we start supporting more ARM htpc boxes out of the box, telling the
> user to hook up a serial console (which often involves soldering wires
> to some test points) when things don't work really is not a viable
> answer.

So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?
Worse, the experience I have with ARM DRM drivers is that they fail horrible when being built as modules, but that's a different problem.

regards,

Koen

[linux-sunxi] simplefb: add clock handling

[Koen Kooi]

Op 13 aug. 2014, om 10:36 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:

> Hi,
> 
> On 08/13/2014 10:21 AM, Koen Kooi wrote:
>> 
>> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
>> 
>>> Hi
>>> 
>>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>> This is needed for the sunxi platform, where the u-boot initialized display
>>>> engine gets disabled by the clocks framework if certain clocks are not
>>>> claimed. Once these clocks are disabled, register content is lost, and there
>>>> is no turning back unless a full display driver is loaded, which kind of
>>>> beats the purpose of having simplefb running.
>>>> 
>>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>>> has kept these sort of issues from the kernel.
>>>> 
>>>> The sunxi u-boot side code can be found here:
>>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>> 
>>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>>> since the status property in dt is only really evaluated when dealing with a
>>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>>> node as disabled, as we really have no way back when the clocks get disabled.
>>> 
>>> Hans de Goede shortly told me about this and, tbh, I am not very
>>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>>> patch now adds hardware-specific features. To be fair, the patch is
>>> simple and clocks are easy to handle, but I somehow fear we have to
>>> add more and more hardware-support that is required to keep the
>>> framebuffer active. This really defeats the purpose of simplefb.
>>> 
>>> The biggest question I have, is why do you add the clocks to your DT
>>> at all? The framebuffer is set up by your boot-loader (or maybe
>>> platform code) and should prepare the clocks. I don't see why we add
>>> the clocks to DT now. If they're not added, then no-one will disable
>>> them and simplefb works just fine, right?
>> 
>> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
>> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 
> 
> I believe that having some simple generic fb driver will be useful
> on non x86, since we don't have vga-console there, and most distros
> will build kms drivers as modules. Having the kernel / initrd code being
> able to show output (like e.g. missing symbols in the kms drivers) seems
> a very useful feature to me.
> 
> The way I envision this to work is:
> 
> u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
> it can show this on the display
> 
> kernel takes over using something like simplefb (built into the kernel)
> for its initial output / any error messages.
> 
> initrd loads kms, kms takes over.
> 
> This way we've a way to show error messages during boot at all times.
> 
> As we start supporting more ARM htpc boxes out of the box, telling the
> user to hook up a serial console (which often involves soldering wires
> to some test points) when things don't work really is not a viable
> answer.

So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?
Worse, the experience I have with ARM DRM drivers is that they fail horrible when being built as modules, but that's a different problem.

regards,

Koen

Re: [linux-sunxi] simplefb: add clock handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 12:16 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?
> Worse, the experience I have with ARM DRM drivers is that they fail horrible when being built as modules, but that's a different problem.

Exactly. But there's no intention to stop building them as modules.
Imagine you build a kernel that's supposed to run on multiple
different platforms (like x86), you really don't want all DRM drivers
built-in. Instead, you load the correct driver during boot-up. To
still provide early graphics access, we use simplefb.

Note that there might be legitimate reasons to make DRM drivers
built-in. But at least general purpose distros avoid that.

Thanks
David

[linux-sunxi] simplefb: add clock handling

[David Herrmann]

Hi

On Wed, Aug 13, 2014 at 12:16 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?
> Worse, the experience I have with ARM DRM drivers is that they fail horrible when being built as modules, but that's a different problem.

Exactly. But there's no intention to stop building them as modules.
Imagine you build a kernel that's supposed to run on multiple
different platforms (like x86), you really don't want all DRM drivers
built-in. Instead, you load the correct driver during boot-up. To
still provide early graphics access, we use simplefb.

Note that there might be legitimate reasons to make DRM drivers
built-in. But at least general purpose distros avoid that.

Thanks
David

Re: [linux-sunxi] simplefb: add clock handling

[Hans de Goede]

Hi,

On 08/13/2014 12:16 PM, Koen Kooi wrote:
> 
> Op 13 aug. 2014, om 10:36 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:
> 
>> Hi,
>>
>> On 08/13/2014 10:21 AM, Koen Kooi wrote:
>>>
>>> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
>>>
>>>> Hi
>>>>
>>>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>> This is needed for the sunxi platform, where the u-boot initialized display
>>>>> engine gets disabled by the clocks framework if certain clocks are not
>>>>> claimed. Once these clocks are disabled, register content is lost, and there
>>>>> is no turning back unless a full display driver is loaded, which kind of
>>>>> beats the purpose of having simplefb running.
>>>>>
>>>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>>>> has kept these sort of issues from the kernel.
>>>>>
>>>>> The sunxi u-boot side code can be found here:
>>>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>>>
>>>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>>>> since the status property in dt is only really evaluated when dealing with a
>>>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>>>> node as disabled, as we really have no way back when the clocks get disabled.
>>>>
>>>> Hans de Goede shortly told me about this and, tbh, I am not very
>>>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>>>> patch now adds hardware-specific features. To be fair, the patch is
>>>> simple and clocks are easy to handle, but I somehow fear we have to
>>>> add more and more hardware-support that is required to keep the
>>>> framebuffer active. This really defeats the purpose of simplefb.
>>>>
>>>> The biggest question I have, is why do you add the clocks to your DT
>>>> at all? The framebuffer is set up by your boot-loader (or maybe
>>>> platform code) and should prepare the clocks. I don't see why we add
>>>> the clocks to DT now. If they're not added, then no-one will disable
>>>> them and simplefb works just fine, right?
>>>
>>> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
>>> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 
>>
>> I believe that having some simple generic fb driver will be useful
>> on non x86, since we don't have vga-console there, and most distros
>> will build kms drivers as modules. Having the kernel / initrd code being
>> able to show output (like e.g. missing symbols in the kms drivers) seems
>> a very useful feature to me.
>>
>> The way I envision this to work is:
>>
>> u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
>> it can show this on the display
>>
>> kernel takes over using something like simplefb (built into the kernel)
>> for its initial output / any error messages.
>>
>> initrd loads kms, kms takes over.
>>
>> This way we've a way to show error messages during boot at all times.
>>
>> As we start supporting more ARM htpc boxes out of the box, telling the
>> user to hook up a serial console (which often involves soldering wires
>> to some test points) when things don't work really is not a viable
>> answer.
> 
> So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?

Right, except that that is not going to happen, see David's reply also.

Regards,

Hans

[linux-sunxi] simplefb: add clock handling

[Hans de Goede]

Hi,

On 08/13/2014 12:16 PM, Koen Kooi wrote:
> 
> Op 13 aug. 2014, om 10:36 heeft Hans de Goede <hdegoede@redhat.com> het volgende geschreven:
> 
>> Hi,
>>
>> On 08/13/2014 10:21 AM, Koen Kooi wrote:
>>>
>>> Op 13 aug. 2014, om 09:54 heeft David Herrmann <dh.herrmann@gmail.com> het volgende geschreven:
>>>
>>>> Hi
>>>>
>>>> On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen <libv@skynet.be> wrote:
>>>>> This is needed for the sunxi platform, where the u-boot initialized display
>>>>> engine gets disabled by the clocks framework if certain clocks are not
>>>>> claimed. Once these clocks are disabled, register content is lost, and there
>>>>> is no turning back unless a full display driver is loaded, which kind of
>>>>> beats the purpose of having simplefb running.
>>>>>
>>>>> The lack of clock handling should plague more hardware, but so far rpi is the
>>>>> best known user of simplefb, and its stepmotherly handling of the arm core
>>>>> has kept these sort of issues from the kernel.
>>>>>
>>>>> The sunxi u-boot side code can be found here:
>>>>> https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY
>>>>>
>>>>> Patch 3 might be controversial, as this does not achieve anything real today,
>>>>> since the status property in dt is only really evaluated when dealing with a
>>>>> nodes memory. It still seems like a good idea to at least flag this memory or
>>>>> node as disabled, as we really have no way back when the clocks get disabled.
>>>>
>>>> Hans de Goede shortly told me about this and, tbh, I am not very
>>>> pleased. Stephen tried to keep simplefd "as simple as possible", your
>>>> patch now adds hardware-specific features. To be fair, the patch is
>>>> simple and clocks are easy to handle, but I somehow fear we have to
>>>> add more and more hardware-support that is required to keep the
>>>> framebuffer active. This really defeats the purpose of simplefb.
>>>>
>>>> The biggest question I have, is why do you add the clocks to your DT
>>>> at all? The framebuffer is set up by your boot-loader (or maybe
>>>> platform code) and should prepare the clocks. I don't see why we add
>>>> the clocks to DT now. If they're not added, then no-one will disable
>>>> them and simplefb works just fine, right?
>>>
>>> All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
>>> To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 
>>
>> I believe that having some simple generic fb driver will be useful
>> on non x86, since we don't have vga-console there, and most distros
>> will build kms drivers as modules. Having the kernel / initrd code being
>> able to show output (like e.g. missing symbols in the kms drivers) seems
>> a very useful feature to me.
>>
>> The way I envision this to work is:
>>
>> u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
>> it can show this on the display
>>
>> kernel takes over using something like simplefb (built into the kernel)
>> for its initial output / any error messages.
>>
>> initrd loads kms, kms takes over.
>>
>> This way we've a way to show error messages during boot at all times.
>>
>> As we start supporting more ARM htpc boxes out of the box, telling the
>> user to hook up a serial console (which often involves soldering wires
>> to some test points) when things don't work really is not a viable
>> answer.
> 
> So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?

Right, except that that is not going to happen, see David's reply also.

Regards,

Hans

[linux-sunxi] simplefb: add clock handling

[Koen Kooi]

Op 13 aug. 2014, om 14:17 heeft Stefan Monnier <monnier@iro.umontreal.ca> het volgende geschreven:

>> So what you are saying is that the only reason it is needed is because some
>> distros choose to build DRM drivers as modules.  So as soon as they stop
>> doing that the problem goes away, right?
> 
> I think many people will be very happy to be able to get some visual
> feedback on their boot problems.  Having to connect a serial console is
> a deal breaker for most people.

As was said earlier in the thread, a proper DRM/KMS driver doesn't prevent that. The only thing preventing that would be:

a) kernels with graphics drivers disabled
b) kernels with graphics drivers as modules that get loaded late.

Please stop insinuation that DRM/KMS drivers can't handle boot messages.