Re: [PATCH v2] drm/simpledrm: Add support for multiple "power-domains"

2023-09-12 Thread Eric Curtin
On Tue, 12 Sept 2023 at 21:30, Janne Grunau via B4 Relay
 wrote:
>
> From: Janne Grunau 
>
> Multiple power domains need to be handled explicitly in each driver. The
> driver core can not handle it automatically since it is not aware of
> power sequencing requirements the hardware might have. This is not a
> problem for simpledrm since everything is expected to be powered on by
> the bootloader. simpledrm has just ensure it remains powered on during
> its lifetime.
> This is required on Apple silicon M2 and M2 Pro/Max/Ultra desktop
> systems. The HDMI output initialized by the bootloader requires keeping
> the display controller and a DP phy power domain on.
>
> Signed-off-by: Janne Grunau 

Reviewed-by: Eric Curtin 

Is mise le meas/Regards,

Eric Curtin

> ---
> Changes in v2:
> - removed broken drm_err() log statement only ment for debugging
> - removed commented cast
> - use correct format spcifier for 'int' in log statement
> - add 'continue;' after failure to get device for power_domain
> - use drm_warn() in non fatal error cases
> - removed duplicate PTR_ERR conversion
> - Link to v1: 
> https://lore.kernel.org/r/20230910-simpledrm-multiple-power-domains-v1-1-f8718aefc...@jannau.net
> ---
>  drivers/gpu/drm/tiny/simpledrm.c | 105 
> +++
>  1 file changed, 105 insertions(+)
>
> diff --git a/drivers/gpu/drm/tiny/simpledrm.c 
> b/drivers/gpu/drm/tiny/simpledrm.c
> index ff86ba1ae1b8..9c597461d1e2 100644
> --- a/drivers/gpu/drm/tiny/simpledrm.c
> +++ b/drivers/gpu/drm/tiny/simpledrm.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -227,6 +228,12 @@ struct simpledrm_device {
> unsigned int regulator_count;
> struct regulator **regulators;
>  #endif
> +   /* power-domains */
> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
> +   int pwr_dom_count;
> +   struct device **pwr_dom_devs;
> +   struct device_link **pwr_dom_links;
> +#endif
>
> /* simplefb settings */
> struct drm_display_mode mode;
> @@ -468,6 +475,101 @@ static int simpledrm_device_init_regulators(struct 
> simpledrm_device *sdev)
>  }
>  #endif
>
> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
> +/*
> + * Generic power domain handling code.
> + *
> + * Here we handle the power-domains properties of our "simple-framebuffer"
> + * dt node. This is only necessary if there is more than one power-domain.
> + * A single power-domains is handled automatically by the driver core. 
> Multiple
> + * power-domains have to be handled by drivers since the driver core can't 
> know
> + * the correct power sequencing. Power sequencing is not an issue for 
> simpledrm
> + * since the bootloader has put the power domains already in the correct 
> state.
> + * simpledrm has only to ensure they remain active for its lifetime.
> + *
> + * When the driver unloads, we detach from the power-domains.
> + *
> + * 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 the "simple-framebuffer" dt node, and the PM domain providers 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 simpledrm_device_detach_genpd(void *res)
> +{
> +   int i;
> +   struct simpledrm_device *sdev = res;
> +
> +   if (sdev->pwr_dom_count <= 1)
> +   return;
> +
> +   for (i = sdev->pwr_dom_count - 1; i >= 0; i--) {
> +   if (!sdev->pwr_dom_links[i])
> +   device_link_del(sdev->pwr_dom_links[i]);
> +   if (!IS_ERR_OR_NULL(sdev->pwr_dom_devs[i]))
> +   dev_pm_domain_detach(sdev->pwr_dom_devs[i], true);
> +   }
> +}
> +
> +static int simpledrm_device_attach_genpd(struct simpledrm_device *sdev)
> +{
> +   struct device *dev = sdev->dev.dev;
> +   int i;
> +
> +   sdev->pwr_dom_count = of_count_phandle_with_args(dev->of_node, 
> "power-domains",
> +
> "#power-domain-cells");
> +   /*
> +* Single power-domain devices are handled by driver core nothing to 
> do
> +* here. The same for device nodes without "power-domains"

[PATCH libdrm] tests/util: Add simpledrm driver

2022-06-13 Thread Eric Curtin
From: Eric Curtin 

Add an entry for the "simpledrm" driver, so that the test utilities
work with the simpledrm driver without passing the -M argument.

Signed-off-by: Eric Curtin 
---
- It's also here, was unsure whether to use MR or email submission
  https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/243
---
 tests/util/kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/util/kms.c b/tests/util/kms.c
index 39a93866..21a61a77 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -150,6 +150,7 @@ static const char * const modules[] = {
"komeda",
"imx-dcss",
"mxsfb-drm",
+   "simpledrm",
 };
 
 int util_open(const char *device, const char *module)
-- 
2.35.3



Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

2018-12-10 Thread Eric Curtin
Hi Guys,

I initially thought these patches were a joke. But I guess they are
not. I suppose 2018 is the year everything became offensive.

Could we avoid the s/fuck/hug/g though? I have nothing against
re-wording this stuff to remove the curse word, but it should at least
make sense.

What's going to happen is someone is a newbie is going to see a comment
like "We found an mark in the idr at the right wd, but it's not the
mark we were told to remove. eparis seriously hugged up somewhere",
probably google the term as they are unfamiliar with it, find out it's
an alias for "fucked" and if they are sensitive get offended anyway.

On Sat, 1 Dec 2018 at 08:20, Geert Uytterhoeven  wrote:
>
> Hi Jon,
>
> On Fri, Nov 30, 2018 at 11:15 PM Jonathan Corbet  wrote:
> > On Fri, 30 Nov 2018 14:12:19 -0800
> > Jarkko Sakkinen  wrote:
> >
> > > As a maintainer myself (and based on somewhat disturbed feedback from
> > > other maintainers) I can only make the conclusion that nobody knows what
> > > the responsibility part here means.
> > >
> > > I would interpret, if I read it like at lawyer at least, that even for
> > > existing code you would need to do the changes postmorterm.
> > >
> > > Is this wrong interpretation?  Should I conclude that I made a mistake
> > > by reading the CoC and trying to understand what it *actually* says?
> > > After this discussion, I can say that I understand it less than before.
> >
> > Have you read Documentation/process/code-of-conduct-interpretation.rst?
> > As has been pointed out, it contains a clear answer to how things should
> > be interpreted here.
>
> Indeed:
>
> | Contributions submitted for the kernel should use appropriate language.
> | Content that already exists predating the Code of Conduct will not be
> | addressed now as a violation.
>
> However:
>
> | Inappropriate language can be seen as a
> | bug, though; such bugs will be fixed more quickly if any interested
> | parties submit patches to that effect.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel