All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: Lee Jones <lee.jones@linaro.org>
Cc: Michal Simek <michal.simek@xilinx.com>,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>,
	Samuel Ortiz <sameo@linux.intel.com>,
	linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: Re: [RFC PATCH 2/3] mfd: syscon: Support early initialization
Date: Wed, 12 Feb 2014 11:51:11 +0100	[thread overview]
Message-ID: <52FB521F.5040006@monstr.eu> (raw)
In-Reply-To: <20140212095424.GV15081@lee--X1>

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

On 02/12/2014 10:54 AM, Lee Jones wrote:
> On Mon, 10 Feb 2014, Michal Simek wrote:
> 
>> Some platforms need to get system controller
>> ready as soon as possible.
>> The patch provides early_syscon_initialization
>> which create early mapping for all syscon compatible
>> devices in early_syscon_probe.
>> Regmap is get via syscon_early_regmap_lookup_by_phandle()
>>
>> Regular device probes attach device to regmap
>> via regmap_attach_dev().
>>
>> For early syscon initialization is necessary to extend
>> struct syscon and provide remove function
>> which unmap all early init structures.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>>  drivers/mfd/syscon.c       | 126 +++++++++++++++++++++++++++++++++++++++------
>>  include/linux/mfd/syscon.h |  11 ++++
>>  2 files changed, 120 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> 
> <snip>
> 
>>  struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
>>  					const char *property)
>>  {
>> @@ -128,40 +149,110 @@ static int syscon_probe(struct platform_device *pdev)
>>  	struct device *dev = &pdev->dev;
>>  	struct syscon *syscon;
>>  	struct resource *res;
>> -	void __iomem *base;
>>
>> -	syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
>> +	/* Early syscon init */
>> +	if (pdev->dev.of_node && pdev->dev.of_node->data) {
>> +		syscon = pdev->dev.of_node->data;
>> +		res = &syscon->res;
>> +		regmap_attach_dev(dev, syscon->regmap, &syscon_regmap_config);
> 
> Instead of duplicating all of the init code with early and late
> versions of each, is there any reason why we can't always do the early
> stuff early and then connect it to the dev infrastructure when it
> becomes available?

I am waiting for Arnd and Mark opinions regarding this.
That's why it was just RFC.
There the next question is if this should still stay
in mfd or moved to base.

I wanted to keep this to be driver compatible
that's why I have done it in this way.

We will see.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: monstr@monstr.eu (Michal Simek)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/3] mfd: syscon: Support early initialization
Date: Wed, 12 Feb 2014 11:51:11 +0100	[thread overview]
Message-ID: <52FB521F.5040006@monstr.eu> (raw)
In-Reply-To: <20140212095424.GV15081@lee--X1>

On 02/12/2014 10:54 AM, Lee Jones wrote:
> On Mon, 10 Feb 2014, Michal Simek wrote:
> 
>> Some platforms need to get system controller
>> ready as soon as possible.
>> The patch provides early_syscon_initialization
>> which create early mapping for all syscon compatible
>> devices in early_syscon_probe.
>> Regmap is get via syscon_early_regmap_lookup_by_phandle()
>>
>> Regular device probes attach device to regmap
>> via regmap_attach_dev().
>>
>> For early syscon initialization is necessary to extend
>> struct syscon and provide remove function
>> which unmap all early init structures.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>>  drivers/mfd/syscon.c       | 126 +++++++++++++++++++++++++++++++++++++++------
>>  include/linux/mfd/syscon.h |  11 ++++
>>  2 files changed, 120 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> 
> <snip>
> 
>>  struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
>>  					const char *property)
>>  {
>> @@ -128,40 +149,110 @@ static int syscon_probe(struct platform_device *pdev)
>>  	struct device *dev = &pdev->dev;
>>  	struct syscon *syscon;
>>  	struct resource *res;
>> -	void __iomem *base;
>>
>> -	syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
>> +	/* Early syscon init */
>> +	if (pdev->dev.of_node && pdev->dev.of_node->data) {
>> +		syscon = pdev->dev.of_node->data;
>> +		res = &syscon->res;
>> +		regmap_attach_dev(dev, syscon->regmap, &syscon_regmap_config);
> 
> Instead of duplicating all of the init code with early and late
> versions of each, is there any reason why we can't always do the early
> stuff early and then connect it to the dev infrastructure when it
> becomes available?

I am waiting for Arnd and Mark opinions regarding this.
That's why it was just RFC.
There the next question is if this should still stay
in mfd or moved to base.

I wanted to keep this to be driver compatible
that's why I have done it in this way.

We will see.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/3f71a6b5/attachment.sig>

  reply	other threads:[~2014-02-12 10:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 15:22 [RFC PATCH 0/3] Syscon early initialization Michal Simek
2014-02-10 15:22 ` Michal Simek
2014-02-10 15:22 ` Michal Simek
2014-02-10 15:22 ` [RFC PATCH 1/3] regmap: Separate regmap dev initialization Michal Simek
2014-02-10 15:22   ` Michal Simek
2014-02-16  1:58   ` Mark Brown
2014-02-16  1:58     ` Mark Brown
2014-02-10 15:22 ` [RFC PATCH 2/3] mfd: syscon: Support early initialization Michal Simek
2014-02-10 15:22   ` Michal Simek
2014-02-10 15:42   ` Michal Simek
2014-02-10 15:42     ` Michal Simek
2014-02-12  9:54   ` Lee Jones
2014-02-12  9:54     ` Lee Jones
2014-02-12 10:51     ` Michal Simek [this message]
2014-02-12 10:51       ` Michal Simek
2014-02-10 15:22 ` [RFC PATCH 3/3] ARM: zynq: Use early syscon initialization Michal Simek
2014-02-10 15:22   ` Michal Simek
2014-02-10 15:22   ` Michal Simek

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=52FB521F.5040006@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=sameo@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.