All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <lauraa@codeaurora.org>
To: Grant Likely <grant.likely@linaro.org>,
	Tushar Behera <trblinux@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Kevin Hilman <khilman@linaro.org>,
	Rob Herring <robherring2@gmail.com>
Cc: linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linaro-kernel@lists.linaro.org, afaerber@suse.de,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] arm: Add back maximum bank limit
Date: Mon, 30 Jun 2014 11:03:10 -0700	[thread overview]
Message-ID: <53B1A65E.6050806@codeaurora.org> (raw)
In-Reply-To: <20140630104350.600EDC40F52@trevor.secretlab.ca>

On 6/30/2014 3:43 AM, Grant Likely wrote:
> 
> Instead of splitting early_init_dt_scan(), the call to
> early_init_dt_scan() could probably be moved after the
> of_flat_dt_match_machine() call. It's at least worth a try. Looking at
> the code I don't see anything obvious that requires the
> early_init_dt_scan() code to run first.
>

of_flat_dt_match_machine -> of_flat_dt_match which uses
initial_boot_params which isn't set until early_init_dt_scan. I had the
same thought about just rearranging but we still need something to be
set before doing the scan, hence the split.
 
> Once you've got the mdesc pointer, you've could set the limit before
> doing the full scan. Or, better yet because this is a fix for broken
> data, you could call a dt_fixup hook on the mdesc. Then exynos is the
> only platform that needs special treatment. The best thing for exynos to
> do is fix the buggy data by clearing the bogus entries. Then there's no
> need to reintroduce early_init_dt_add_memory_arch() for ARM.
> 

The fixup hook does sound better. The flow would become

setup_machine_fdt
	- early_init_dt_verify
	- of_flat_dt_match_machine
	- mdesc->dt_fixup
	- early_init_dt_scan_all

I notice that powerpc already has a DT fixup infrastructure but I don't see
any such thing for ARM. How much of that do you think could and should be
leveraged for ARM?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm: Add back maximum bank limit
Date: Mon, 30 Jun 2014 11:03:10 -0700	[thread overview]
Message-ID: <53B1A65E.6050806@codeaurora.org> (raw)
In-Reply-To: <20140630104350.600EDC40F52@trevor.secretlab.ca>

On 6/30/2014 3:43 AM, Grant Likely wrote:
> 
> Instead of splitting early_init_dt_scan(), the call to
> early_init_dt_scan() could probably be moved after the
> of_flat_dt_match_machine() call. It's at least worth a try. Looking at
> the code I don't see anything obvious that requires the
> early_init_dt_scan() code to run first.
>

of_flat_dt_match_machine -> of_flat_dt_match which uses
initial_boot_params which isn't set until early_init_dt_scan. I had the
same thought about just rearranging but we still need something to be
set before doing the scan, hence the split.
 
> Once you've got the mdesc pointer, you've could set the limit before
> doing the full scan. Or, better yet because this is a fix for broken
> data, you could call a dt_fixup hook on the mdesc. Then exynos is the
> only platform that needs special treatment. The best thing for exynos to
> do is fix the buggy data by clearing the bogus entries. Then there's no
> need to reintroduce early_init_dt_add_memory_arch() for ARM.
> 

The fixup hook does sound better. The flow would become

setup_machine_fdt
	- early_init_dt_verify
	- of_flat_dt_match_machine
	- mdesc->dt_fixup
	- early_init_dt_scan_all

I notice that powerpc already has a DT fixup infrastructure but I don't see
any such thing for ARM. How much of that do you think could and should be
leveraged for ARM?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-06-30 18:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29 19:06 [PATCH 1/2] of: Split early_init_dt_scan into two parts Laura Abbott
2014-06-29 19:06 ` Laura Abbott
2014-06-29 19:06 ` [PATCH 2/2] arm: Add back maximum bank limit Laura Abbott
2014-06-29 19:06   ` Laura Abbott
2014-06-29 22:56   ` Andreas Färber
2014-06-29 22:56     ` Andreas Färber
2014-06-30 10:43   ` Grant Likely
2014-06-30 10:43     ` Grant Likely
2014-06-30 18:03     ` Laura Abbott [this message]
2014-06-30 18:03       ` Laura Abbott
2014-07-01 10:57       ` Grant Likely
2014-07-01 10:57         ` Grant Likely

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=53B1A65E.6050806@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --cc=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=khilman@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robherring2@gmail.com \
    --cc=trblinux@gmail.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.