From: Jani Nikula <jani.nikula@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Hans de Goede <hdegoede@redhat.com>
Cc: "Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
"Lee Jones" <lee.jones@linaro.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings
Date: Thu, 02 Jan 2020 11:04:43 +0200 [thread overview]
Message-ID: <875zhuut3o.fsf@intel.com> (raw)
In-Reply-To: <CACRpkdaXFSJVkWJGzsVcvbUA9gpgP0Vbkwf1H-HWw8s35R9XYQ@mail.gmail.com>
On Mon, 30 Dec 2019, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Currently only the drivers/pinctrl/devicetree.c code allows registering
>> pinctrl-mappings which may later be unregistered, all other mappings
>> are assumed to be permanent.
>>
>> Non-dt platforms may also want to register pinctrl mappings from code which
>> is build as a module, which requires being able to unregister the mapping
>> when the module is unloaded to avoid dangling pointers.
>>
>> To allow unregistering the mappings the devicetree code uses 2 internal
>> functions: pinctrl_register_map and pinctrl_unregister_map.
>>
>> pinctrl_register_map allows the devicetree code to tell the core to
>> not memdup the mappings as it retains ownership of them and
>> pinctrl_unregister_map does the unregistering, note this only works
>> when the mappings where not memdupped.
>>
>> The only code relying on the memdup/shallow-copy done by
>> pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit
>> replaces the __initdata with const, so that the shallow-copy is no
>> longer necessary.
>>
>> After that we can get rid of the internal pinctrl_unregister_map function
>> and just use pinctrl_register_mappings directly everywhere.
>>
>> This commit also renames pinctrl_unregister_map to
>> pinctrl_unregister_mappings so that its naming matches its
>> pinctrl_register_mappings counter-part and exports it.
>>
>> Together these 2 changes will allow non-dt platform code to
>> register pinctrl-mappings from modules without breaking things on
>> module unload (as they can now unregister the mapping on unload).
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> This v2 works fine for me, I applied it to this immutable branch in the
> pinctrl tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-pinctrl-unreg-mappings
>
> And pulled that into the pinctrl "devel" branch for v5.6.
>
> Please pull this immutable branch into the Intel DRM tree and apply
> the rest of the stuff on top!
Thanks, pulled to drm-intel-next-queued.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Hans de Goede <hdegoede@redhat.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings
Date: Thu, 02 Jan 2020 11:04:43 +0200 [thread overview]
Message-ID: <875zhuut3o.fsf@intel.com> (raw)
In-Reply-To: <CACRpkdaXFSJVkWJGzsVcvbUA9gpgP0Vbkwf1H-HWw8s35R9XYQ@mail.gmail.com>
On Mon, 30 Dec 2019, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Currently only the drivers/pinctrl/devicetree.c code allows registering
>> pinctrl-mappings which may later be unregistered, all other mappings
>> are assumed to be permanent.
>>
>> Non-dt platforms may also want to register pinctrl mappings from code which
>> is build as a module, which requires being able to unregister the mapping
>> when the module is unloaded to avoid dangling pointers.
>>
>> To allow unregistering the mappings the devicetree code uses 2 internal
>> functions: pinctrl_register_map and pinctrl_unregister_map.
>>
>> pinctrl_register_map allows the devicetree code to tell the core to
>> not memdup the mappings as it retains ownership of them and
>> pinctrl_unregister_map does the unregistering, note this only works
>> when the mappings where not memdupped.
>>
>> The only code relying on the memdup/shallow-copy done by
>> pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit
>> replaces the __initdata with const, so that the shallow-copy is no
>> longer necessary.
>>
>> After that we can get rid of the internal pinctrl_unregister_map function
>> and just use pinctrl_register_mappings directly everywhere.
>>
>> This commit also renames pinctrl_unregister_map to
>> pinctrl_unregister_mappings so that its naming matches its
>> pinctrl_register_mappings counter-part and exports it.
>>
>> Together these 2 changes will allow non-dt platform code to
>> register pinctrl-mappings from modules without breaking things on
>> module unload (as they can now unregister the mapping on unload).
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> This v2 works fine for me, I applied it to this immutable branch in the
> pinctrl tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-pinctrl-unreg-mappings
>
> And pulled that into the pinctrl "devel" branch for v5.6.
>
> Please pull this immutable branch into the Intel DRM tree and apply
> the rest of the stuff on top!
Thanks, pulled to drm-intel-next-queued.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Hans de Goede <hdegoede@redhat.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [Intel-gfx] [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings
Date: Thu, 02 Jan 2020 11:04:43 +0200 [thread overview]
Message-ID: <875zhuut3o.fsf@intel.com> (raw)
In-Reply-To: <CACRpkdaXFSJVkWJGzsVcvbUA9gpgP0Vbkwf1H-HWw8s35R9XYQ@mail.gmail.com>
On Mon, 30 Dec 2019, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Currently only the drivers/pinctrl/devicetree.c code allows registering
>> pinctrl-mappings which may later be unregistered, all other mappings
>> are assumed to be permanent.
>>
>> Non-dt platforms may also want to register pinctrl mappings from code which
>> is build as a module, which requires being able to unregister the mapping
>> when the module is unloaded to avoid dangling pointers.
>>
>> To allow unregistering the mappings the devicetree code uses 2 internal
>> functions: pinctrl_register_map and pinctrl_unregister_map.
>>
>> pinctrl_register_map allows the devicetree code to tell the core to
>> not memdup the mappings as it retains ownership of them and
>> pinctrl_unregister_map does the unregistering, note this only works
>> when the mappings where not memdupped.
>>
>> The only code relying on the memdup/shallow-copy done by
>> pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit
>> replaces the __initdata with const, so that the shallow-copy is no
>> longer necessary.
>>
>> After that we can get rid of the internal pinctrl_unregister_map function
>> and just use pinctrl_register_mappings directly everywhere.
>>
>> This commit also renames pinctrl_unregister_map to
>> pinctrl_unregister_mappings so that its naming matches its
>> pinctrl_register_mappings counter-part and exports it.
>>
>> Together these 2 changes will allow non-dt platform code to
>> register pinctrl-mappings from modules without breaking things on
>> module unload (as they can now unregister the mapping on unload).
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> This v2 works fine for me, I applied it to this immutable branch in the
> pinctrl tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-pinctrl-unreg-mappings
>
> And pulled that into the pinctrl "devel" branch for v5.6.
>
> Please pull this immutable branch into the Intel DRM tree and apply
> the rest of the stuff on top!
Thanks, pulled to drm-intel-next-queued.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-01-02 9:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 20:51 [PATCH v2 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2019-12-16 20:51 ` [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2019-12-30 13:31 ` Linus Walleij
2019-12-30 13:31 ` [Intel-gfx] " Linus Walleij
2019-12-30 13:31 ` Linus Walleij
2020-01-01 13:04 ` Hans de Goede
2020-01-01 13:04 ` [Intel-gfx] " Hans de Goede
2020-01-01 13:04 ` Hans de Goede
2020-01-02 9:04 ` Jani Nikula [this message]
2020-01-02 9:04 ` [Intel-gfx] " Jani Nikula
2020-01-02 9:04 ` Jani Nikula
2019-12-16 20:51 ` [PATCH v2 2/5] drm/i915/dsi: Move poking of panel-enable GPIO to intel_dsi_vbt.c Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2019-12-16 20:51 ` [PATCH v2 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off (v2) Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2020-01-02 9:14 ` Jani Nikula
2020-01-02 9:14 ` [Intel-gfx] " Jani Nikula
2020-01-02 9:14 ` Jani Nikula
2019-12-16 20:51 ` [PATCH v2 4/5] drm/i915/dsi: Move Crystal Cove PMIC panel GPIO lookup from mfd to the i915 driver Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2019-12-17 8:05 ` Lee Jones
2019-12-17 8:05 ` [Intel-gfx] " Lee Jones
2019-12-17 8:05 ` Lee Jones
2019-12-16 20:51 ` [PATCH v2 5/5] drm/i915/dsi: Control panel and backlight enable GPIOs on BYT Hans de Goede
2019-12-16 20:51 ` [Intel-gfx] " Hans de Goede
2019-12-16 20:51 ` Hans de Goede
2019-12-17 3:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsi: Control panel and backlight enable GPIOs from VBT (rev2) Patchwork
2019-12-17 4:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2019-12-17 10:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zhuut3o.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.