* [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree
From: AKASHI Takahiro @ 2018-05-18 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518071133.GL2737@linaro.org>
On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote:
> James,
>
> On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote:
> > Hi Akashi,
> >
> > On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > load_other_segments() is expected to allocate and place all the necessary
> > > memory segments other than kernel, including initrd and device-tree
> > > blob (and elf core header for crash).
> > > While most of the code was borrowed from kexec-tools' counterpart,
> > > users may not be allowed to specify dtb explicitly, instead, the dtb
> > > presented by a boot loader is reused.
> >
> > (Nit: "a boot loader" -> "the original boot loader")
>
> OK
>
> > > arch_kimage_kernel_post_load_cleanup() is responsible for freeing arm64-
> > > specific data allocated in load_other_segments().
> >
> >
> > > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > > index f9ebf54ca247..b3b9b1725d8a 100644
> > > --- a/arch/arm64/kernel/machine_kexec_file.c
> > > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > > @@ -13,7 +13,26 @@
> > > #include <linux/ioport.h>
> > > #include <linux/kernel.h>
> > > #include <linux/kexec.h>
> > > +#include <linux/libfdt.h>
> > > #include <linux/memblock.h>
> > > +#include <linux/of_fdt.h>
> > > +#include <linux/types.h>
> > > +#include <asm/byteorder.h>
> > > +
> > > +static int __dt_root_addr_cells;
> > > +static int __dt_root_size_cells;
> >
> > > @@ -55,3 +74,144 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> > >
> > > return ret;
> > > }
> > > +
> > > +static int setup_dtb(struct kimage *image,
> > > + unsigned long initrd_load_addr, unsigned long initrd_len,
> > > + char *cmdline, unsigned long cmdline_len,
> > > + char **dtb_buf, size_t *dtb_buf_len)
> > > +{
> > > + char *buf = NULL;
> > > + size_t buf_size;
> > > + int nodeoffset;
> > > + u64 value;
> > > + int range_len;
> > > + int ret;
> > > +
> > > + /* duplicate dt blob */
> > > + buf_size = fdt_totalsize(initial_boot_params);
> > > + range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
> >
> > These two cells values are 0 here. Did you want
> > arch_kexec_file_init() in patch 7 in this patch?
> >
> > Ah, range_len isn't used, so, did you want the cells values and this range_len
> > thing in in patch 7!?
>
> Umm, this problem has long existed since my v1 :)
> I might better re-think about patch order.
>
> >
> > > +
> > > + if (initrd_load_addr)
> > > + buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64))
> > > + + fdt_prop_len("linux,initrd-end", sizeof(u64));
> > > +
> > > + if (cmdline)
> > > + buf_size += fdt_prop_len("bootargs", cmdline_len + 1);
> >
> > I can't find where fdt_prop_len() .... oh, patch 7. fdt_prop_len() doesn't look
> > like the sort of thing that should be created here, but I agree there isn't an
> > existing API to do this.
>
> Will take care of it.
>
>
> > (This must be why powerpc guesses that the fdt won't be more than double in size).
> >
> >
> > > + buf = vmalloc(buf_size);
> > > + if (!buf) {
> > > + ret = -ENOMEM;
> > > + goto out_err;
> > > + }
> > > +
> > > + ret = fdt_open_into(initial_boot_params, buf, buf_size);
> > > + if (ret)
> > > + goto out_err;
> > > +
> > > + nodeoffset = fdt_path_offset(buf, "/chosen");
> > > + if (nodeoffset < 0)
> > > + goto out_err;
> > > +
> > > + /* add bootargs */
> > > + if (cmdline) {
> > > + ret = fdt_setprop(buf, nodeoffset, "bootargs",
> > > + cmdline, cmdline_len + 1);
> >
> > fdt_setprop_string()?
>
> OK
cmdline_len is passed by system call, kexec_file_load(), and this means
that we can't believe that cmdline is always terminated with '\0'.
>
> >
> > > + if (ret)
> > > + goto out_err;
> > > + }
> > > +
> > > + /* add initrd-* */
> > > + if (initrd_load_addr) {
> > > + value = cpu_to_fdt64(initrd_load_addr);
> > > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-start",
> > > + &value, sizeof(value));
> >
> > sizeof(value) was assumed to be the same as sizeof(u64) earlier.
> > fdt_setprop_u64()?
>
> OK
>
> >
> > > + if (ret)
> > > + goto out_err;
> > > +
> > > + value = cpu_to_fdt64(initrd_load_addr + initrd_len);
> > > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-end",
> > > + &value, sizeof(value));
> > > + if (ret)
> > > + goto out_err;
> > > + }
> > > +
> > > + /* trim a buffer */
> > > + fdt_pack(buf);
> > > + *dtb_buf = buf;
> > > + *dtb_buf_len = fdt_totalsize(buf);
> > > +
> > > + return 0;
> > > +
> > > +out_err:
> > > + vfree(buf);
> > > + return ret;
> > > +}
> >
> > While powerpc has some similar code for updating the initrd and cmdline, it
> > makes different assumptions about the size of the dt, and has different behavior
> > for memreserve. (looks like we don't expect the initramfs to be memreserved).
> > Lets leave unifying that stuff where possible for the future.
>
> Sure
>
> > > +int load_other_segments(struct kimage *image,
> > > + char *initrd, unsigned long initrd_len,
> > > + char *cmdline, unsigned long cmdline_len)
> > > +{
> > > + struct kexec_segment *kern_seg;
> > > + struct kexec_buf kbuf;
> > > + unsigned long initrd_load_addr = 0;
> > > + char *dtb = NULL;
> > > + unsigned long dtb_len = 0;
> > > + int ret = 0;
> > > +
> > > + kern_seg = &image->segment[image->arch.kern_segment];
> > > + kbuf.image = image;
> > > + /* not allocate anything below the kernel */
> > > + kbuf.buf_min = kern_seg->mem + kern_seg->memsz;
> >
> > > + /* load initrd */
> > > + if (initrd) {
> > > + kbuf.buffer = initrd;
> > > + kbuf.bufsz = initrd_len;
> > > + kbuf.memsz = initrd_len;
> >
> > > + kbuf.buf_align = 0;
> >
> > I'm surprised there initrd has no alignment requirement,
>
> MeToo.
>
> > but kexec_add_buffer()
> > rounds this up to PAGE_SIZE.
>
> It seems that kimage_load_segment() requires this, but I'm not sure.
>
> >
> > > + /* within 1GB-aligned window of up to 32GB in size */
> > > + kbuf.buf_max = round_down(kern_seg->mem, SZ_1G)
> > > + + (unsigned long)SZ_1G * 32;
> > > + kbuf.top_down = false;
> > > +
> > > + ret = kexec_add_buffer(&kbuf);
> > > + if (ret)
> > > + goto out_err;
> > > + initrd_load_addr = kbuf.mem;
> > > +
> > > + pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > + initrd_load_addr, initrd_len, initrd_len);
> > > + }
> > > +
> > > + /* load dtb blob */
> > > + ret = setup_dtb(image, initrd_load_addr, initrd_len,
> > > + cmdline, cmdline_len, &dtb, &dtb_len);
> > > + if (ret) {
> > > + pr_err("Preparing for new dtb failed\n");
> > > + goto out_err;
> > > + }
> > > +
> > > + kbuf.buffer = dtb;
> > > + kbuf.bufsz = dtb_len;
> > > + kbuf.memsz = dtb_len;
> > > + /* not across 2MB boundary */
> > > + kbuf.buf_align = SZ_2M;
> > > + kbuf.buf_max = ULONG_MAX;
> > > + kbuf.top_down = true;
> > > +
> > > + ret = kexec_add_buffer(&kbuf);
> > > + if (ret)
> > > + goto out_err;
> > > + image->arch.dtb_mem = kbuf.mem;
> > > + image->arch.dtb_buf = dtb;
> > > +
> > > + pr_debug("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > > + kbuf.mem, dtb_len, dtb_len);
> > > +
> > > + return 0;
> > > +
> > > +out_err:
> > > + vfree(dtb);
> > > + image->arch.dtb_buf = NULL;
> >
> > Won't kimage_file_post_load_cleanup() always be called if we return an error
> > here? Why not leave the free()ing until then?
>
> Right.
> The reason why I left the code here was that we'd better locally clean up
> all the stuff that were locally allocated if we trivially need to (and can)
> do so.
>
> As it's redundant, I will remove it.
will remove only "image->arch.dtb_buf = NULL."
> Thanks,
> -Takahiro AKASHI
>
> >
> > > + return ret;
> > > +}
> >
> >
> >
> > Thanks,
> >
> > James
^ permalink raw reply
* [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Amelie DELAUNAY @ 2018-05-18 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517063640.GK5130@dell>
On 05/17/2018 08:36 AM, Lee Jones wrote:
> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
>
>>
>>
>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
>>>
>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
>>>> child drivers into a single PINCTRL/GPIO driver because of the following
>>>> reasons:
>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
>>>> not used on any of the boards using an stmfx and supported by Linux, so
>>>> no way to test these functions, and no need to maintain them while they
>>>> are not being used.
>>>> - But, in the case a new board will use more than GPIO function on
>>>> stmfx, the actual implementation allow to easily extract common init
>>>> part of stmfx and put it in an MFD driver.
>>>>
>>>> So I could remove gpio sub-node and put its contents in stmfx node and
>>>> keep single PINCTRL/GPIO driver for the time being.
>>>> Please advise,
>>>
>>> I would normally advice to use the right modeling from the start, create
>>> the MFD driver and spawn the devices from there. It is confusing
>>> if the layout of the driver(s) doesn't really match the layout of the
>>> hardware.
>>>
>>> I understand that it is a pain to write new MFD drivers to get your
>>> things going and it would be "nice to get this working really quick
>>> now" but in my experience it is better to do it right from the start.
>>>
>>
>> Hi Linus,
>>
>> Thanks for your advice. I understand the point.
>> So, the right modeling would be to:
>> - create an MFD driver with the common init part of stmfx
>> - remove all common init part of stmfx-pinctrl driver and keep only all
>> gpio/pinctrl functions.
>>
>> I will not develop the other stmfx functions (IDD measurement driver and
>> TouchScreen controller driver) because, as explained ealier, they are
>> not used on any of the boards using an stmfx and supported by Linux, so
>> no way to test these functions, and no need to maintain them while they
>> are not being used.
>>
>> Lee, are you OK with that ?
>
> I missed a lot of this conversation I think, but from what I've read,
> it sounds fine.
>
I summarize the situation:
- I still don't have an official datasheet for STMFX device which could
justify the use of an MFD driver;
- the MFD driver will contain the STMFX chip initialization stuff such
as regmap initialization (regmap structure will be shared with the
child), chip initialization, global interrupt management;
- there will be only one child (GPIO/PINCTRL node) for the time being.
So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
it still sound fine after this summary ? :)
Thanks,
Amelie
^ permalink raw reply
* [PATCH 4/4] omap4-droid4: Use software debounce for gpio-keys
From: Pavel Machek @ 2018-05-18 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517233542.30629-5-tony@atomide.com>
Hi!
> The default value of 5ms will use GPIO hardware based debounce clocks
> that will keep L4PER from idling consuming about extra 30mW.
>
> Use a value of 10ms that is above the hardware debounce maximum of
> 7.95ms forcing software based debouncing.
>
> This allows droid4 to enter PER retention during idle as long as UARTs
> are idled and USB modules unloaded or unbound.
>
> Note that there seems to be a pending issue with having droid 4 enter core
> retention during idle where GPIO bank 1 needs to be reset late after init
> for some reason to not block core retention. In addition to that, we are
> also missing GPIO related PM runtime calls for omap4 that will be posted
> separately.
Thanks, will take a look.
BTW, did you notice that debouncing is wrong on most of the keyboard?
If you double click a key (most will do, for example "J") it will fail
to recognize second release and instead of expected "jj", you get
autorepeat ("jjjjjjjjjjjjjjjjjjjjjj...").
Ok, I guess main keyboard is not on GPIO...
Best regards,
Pavel
> @@ -128,6 +128,7 @@
> gpios = <&gpio5 26 GPIO_ACTIVE_LOW>; /* gpio154 */
> linux,code = <KEY_VOLUMEDOWN>;
> linux,can-disable;
> + debounce-interval = <10>;
I'd say this subtlety is worth a comment.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180518/a68804eb/attachment.sig>
^ permalink raw reply
* [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
From: Maxime Ripard @ 2018-05-18 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0da5787f0ce2309a74db88820bc58b3b3501c451.camel@paulk.fr>
On Mon, May 14, 2018 at 10:36:08PM +0200, Paul Kocialkowski wrote:
> > > + backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> > > + brightness-levels = < 0 1 1 1 1 2 2 2
> > > + 2 3 3 3 3 4 4 4
> > > + 5 5 5 6 6 6 7 7
> > > + 8 8 8 9 9 9 10 10
> > > + 10 11 11 12 12 12 13 13
> > > + 14 14 14 15 15 16 16 17
> > > + 17 17 18 18 19 19 20 20
> > > + 21 21 21 22 22 23 23 24
> > > + 24 25 25 26 26 27 27 28
> > > + 28 29 30 30 31 31 32 32
> > > + 33 33 34 35 35 36 36 37
> > > + 38 38 39 39 40 41 41 42
> > > + 43 43 44 44 45 46 47 47
> > > + 48 49 49 50 51 51 52 53
> > > + 54 54 55 56 57 57 58 59
> > > + 60 61 61 62 63 64 65 65
> > > + 66 67 68 69 70 71 71 72
> > > + 73 74 75 76 77 78 79 80
> > > + 81 82 83 84 85 86 87 88
> > > + 89 90 91 92 93 94 95 96
> > > + 97 98 99 101 102 103 104 105
> > > + 106 108 109 110 111 112 114 115
> > > + 116 117 119 120 121 123 124 125
> > > + 127 128 129 131 132 133 135 136
> > > + 138 139 141 142 144 145 147 148
> > > + 150 151 153 154 156 157 159 161
> > > + 162 164 166 167 169 171 173 174
> > > + 176 178 180 181 183 185 187 189
> > > + 191 192 194 196 198 200 202 204
> > > + 206 208 210 212 214 216 219 221
> > > + 223 225 227 229 232 234 236 238
> > > + 241 242 244 246 248 250 253 255>;
> >
> > You kind of overdid it here :)
> >
> > What I meant to say before was that if you have 10 elements (and you
> > really should have something in that magnitude) each step should
> > increase the perceived brightness by 10%.
>
> Mhh I think 10 elements would fall too short to really depict the curve
> with appropriate precision. Given the usual size for brightness cursors
> in e.g. gnome-shell, it feels like a bigger number would be more
> appropriate. Let's make it to 100 with values from 0 to 255!
>
> > In this particular case, I really think having something close to <0 4
> > 8 16 32 64 128 255> would be enough.
> >
> > And in general, that kind of odd looking table without any more
> > context is just screaming for a comment :)
>
> Noted, I will explain the idea, but probably without the exact formula
> that's really a nasty hack written down on a piece of paper sitting in
> my garbage at this point.
So no one will ever be able to understand where this sequence comes
from (yourself-in-two-years included). That sounds like a pretty bad
idea.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180518/7fd364f8/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ghes_edac: enable HIP08 platform edac driver
From: Zhengqiang @ 2018-05-18 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8602b133-e0fa-57e2-5159-9d34a1ded85f@arm.com>
On 2018/5/18 2:02, James Morse wrote:
> Hi guys,
>
> Tyler, Zhengqiang, I assume all your shipped platforms with HEST->GHES entries
> also have DMI tables.
>
Sure, Our ARM64 platform have DMI tables. thanks.
>
> On 16/05/18 19:29, Borislav Petkov wrote:
>> On Wed, May 16, 2018 at 02:38:38PM +0100, James Morse wrote:
>>> XGene has its own edac driver, but it doesn't probe when booted via ACPI so
>>> won't conflict with ghes_edac.
>>
>> Actually it will. EDAC core can have only one EDAC driver loaded. Don't
>> ask me why - it has been that way since forever.
>
> By won't probe I mean it only works on DT systems:
>
> | static const struct of_device_id xgene_edac_of_match[] = {
> | { .compatible = "apm,xgene-edac" },
> | {},
> | };
>
> | .driver = {
> | .name = "xgene-edac",
> | .of_match_table = xgene_edac_of_match,
> | },
>
> To work on a system with GHES it would need an 'struct acpi_device_id' to
> describe the HID (?) and populate driver's acpi_match_table.
>
>
>> We can change it some
>> day but frankly, I don't see reasoning for it. One driver can easily
>> manage *all* error sources on a system, I'd say.
>
> I agree, there is no reason to support two at the same time, if this happens
> then there is probably something wrong with the platform (e.g. races with
> firmware reading the same hardware registers), so we should make some noise.
>
> Xgene's edac driver would be a good example of this, it looks like it reads data
> from some mmio region, if something else is doing the same we're going to make a
> mess.
>
>
>>> So I think we're good to make the whitelist x86 only.
>>> Your diff-hunk makes 'idx=-1', so we always get the 'Unfortunately' warning. I'd
>>> like to suppress this unless force_load has been used.
>>
>> Yeah, we should handle that differently for ARM. Toshi added the idx
>> thing in
>>
>> 5deed6b6a479 ("EDAC, ghes: Add platform check")
>>
>> to dump this when the platform is not whitelisted. So let's do that:
>>
>> ---
>> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
>> index 863fbf3db29f..473aeec4b1da 100644
>> --- a/drivers/edac/ghes_edac.c
>> +++ b/drivers/edac/ghes_edac.c
>> @@ -440,12 +440,16 @@ int ghes_edac_register(struct ghes *ghes, struct device *dev)
>> struct mem_ctl_info *mci;
>> struct edac_mc_layer layers[1];
>> struct ghes_edac_dimm_fill dimm_fill;
>> - int idx;
>> + int idx = -1;
>>
>> - /* Check if safe to enable on this system */
>> - idx = acpi_match_platform_list(plat_list);
>> - if (!force_load && idx < 0)
>> - return -ENODEV;
>
> v4.17-rc5 has 'return 0' here. Wouldn't this change means no ghes can be
> registered unless ghes_edac is also supported by the platform?
> Shouldn't this be '0' for a silent failure?
>
>
>> + if (IS_ENABLED(CONFIG_X86)) {
>> + /* Check if safe to enable on this system */
>> + idx = acpi_match_platform_list(plat_list);
>> + if (!force_load && idx < 0)
>> + return -ENODEV;
>> + } else {
>> + idx = 0;
>> + }
>>
>> /*
>> * We have only one logical memory controller to which all DIMMs belong.
>
> Tested on Seattle and some cranky homebrew-no-DMI firmware:
> Tested-by: James Morse <james.morse@arm.com>
>
> With the ENODEV/0 thing above:
> Reviewed-by: James Morse <james.morse@arm.com>
>
>
>>> It looks like even the oldest Arm64 ACPI systems have dmi tables, so we can
>>> probably require DMI or the 'force' flag.
>>
>> Well, with the hunk above it would still do ghes_edac_count_dimms() on
>> ARM and if it fails to find something, it will set fake, which is a good
>> sanity-check as it screams loudly. :)
>
>
> Thanks,
>
> James
>
> .
>
^ permalink raw reply
* [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree
From: AKASHI Takahiro @ 2018-05-18 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c10624c0-9962-af38-1dd5-656902180ace@arm.com>
James,
On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > load_other_segments() is expected to allocate and place all the necessary
> > memory segments other than kernel, including initrd and device-tree
> > blob (and elf core header for crash).
> > While most of the code was borrowed from kexec-tools' counterpart,
> > users may not be allowed to specify dtb explicitly, instead, the dtb
> > presented by a boot loader is reused.
>
> (Nit: "a boot loader" -> "the original boot loader")
OK
> > arch_kimage_kernel_post_load_cleanup() is responsible for freeing arm64-
> > specific data allocated in load_other_segments().
>
>
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> > index f9ebf54ca247..b3b9b1725d8a 100644
> > --- a/arch/arm64/kernel/machine_kexec_file.c
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -13,7 +13,26 @@
> > #include <linux/ioport.h>
> > #include <linux/kernel.h>
> > #include <linux/kexec.h>
> > +#include <linux/libfdt.h>
> > #include <linux/memblock.h>
> > +#include <linux/of_fdt.h>
> > +#include <linux/types.h>
> > +#include <asm/byteorder.h>
> > +
> > +static int __dt_root_addr_cells;
> > +static int __dt_root_size_cells;
>
> > @@ -55,3 +74,144 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> >
> > return ret;
> > }
> > +
> > +static int setup_dtb(struct kimage *image,
> > + unsigned long initrd_load_addr, unsigned long initrd_len,
> > + char *cmdline, unsigned long cmdline_len,
> > + char **dtb_buf, size_t *dtb_buf_len)
> > +{
> > + char *buf = NULL;
> > + size_t buf_size;
> > + int nodeoffset;
> > + u64 value;
> > + int range_len;
> > + int ret;
> > +
> > + /* duplicate dt blob */
> > + buf_size = fdt_totalsize(initial_boot_params);
> > + range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
>
> These two cells values are 0 here. Did you want
> arch_kexec_file_init() in patch 7 in this patch?
>
> Ah, range_len isn't used, so, did you want the cells values and this range_len
> thing in in patch 7!?
Umm, this problem has long existed since my v1 :)
I might better re-think about patch order.
>
> > +
> > + if (initrd_load_addr)
> > + buf_size += fdt_prop_len("linux,initrd-start", sizeof(u64))
> > + + fdt_prop_len("linux,initrd-end", sizeof(u64));
> > +
> > + if (cmdline)
> > + buf_size += fdt_prop_len("bootargs", cmdline_len + 1);
>
> I can't find where fdt_prop_len() .... oh, patch 7. fdt_prop_len() doesn't look
> like the sort of thing that should be created here, but I agree there isn't an
> existing API to do this.
Will take care of it.
> (This must be why powerpc guesses that the fdt won't be more than double in size).
>
>
> > + buf = vmalloc(buf_size);
> > + if (!buf) {
> > + ret = -ENOMEM;
> > + goto out_err;
> > + }
> > +
> > + ret = fdt_open_into(initial_boot_params, buf, buf_size);
> > + if (ret)
> > + goto out_err;
> > +
> > + nodeoffset = fdt_path_offset(buf, "/chosen");
> > + if (nodeoffset < 0)
> > + goto out_err;
> > +
> > + /* add bootargs */
> > + if (cmdline) {
> > + ret = fdt_setprop(buf, nodeoffset, "bootargs",
> > + cmdline, cmdline_len + 1);
>
> fdt_setprop_string()?
OK
>
> > + if (ret)
> > + goto out_err;
> > + }
> > +
> > + /* add initrd-* */
> > + if (initrd_load_addr) {
> > + value = cpu_to_fdt64(initrd_load_addr);
> > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-start",
> > + &value, sizeof(value));
>
> sizeof(value) was assumed to be the same as sizeof(u64) earlier.
> fdt_setprop_u64()?
OK
>
> > + if (ret)
> > + goto out_err;
> > +
> > + value = cpu_to_fdt64(initrd_load_addr + initrd_len);
> > + ret = fdt_setprop(buf, nodeoffset, "linux,initrd-end",
> > + &value, sizeof(value));
> > + if (ret)
> > + goto out_err;
> > + }
> > +
> > + /* trim a buffer */
> > + fdt_pack(buf);
> > + *dtb_buf = buf;
> > + *dtb_buf_len = fdt_totalsize(buf);
> > +
> > + return 0;
> > +
> > +out_err:
> > + vfree(buf);
> > + return ret;
> > +}
>
> While powerpc has some similar code for updating the initrd and cmdline, it
> makes different assumptions about the size of the dt, and has different behavior
> for memreserve. (looks like we don't expect the initramfs to be memreserved).
> Lets leave unifying that stuff where possible for the future.
Sure
> > +int load_other_segments(struct kimage *image,
> > + char *initrd, unsigned long initrd_len,
> > + char *cmdline, unsigned long cmdline_len)
> > +{
> > + struct kexec_segment *kern_seg;
> > + struct kexec_buf kbuf;
> > + unsigned long initrd_load_addr = 0;
> > + char *dtb = NULL;
> > + unsigned long dtb_len = 0;
> > + int ret = 0;
> > +
> > + kern_seg = &image->segment[image->arch.kern_segment];
> > + kbuf.image = image;
> > + /* not allocate anything below the kernel */
> > + kbuf.buf_min = kern_seg->mem + kern_seg->memsz;
>
> > + /* load initrd */
> > + if (initrd) {
> > + kbuf.buffer = initrd;
> > + kbuf.bufsz = initrd_len;
> > + kbuf.memsz = initrd_len;
>
> > + kbuf.buf_align = 0;
>
> I'm surprised there initrd has no alignment requirement,
MeToo.
> but kexec_add_buffer()
> rounds this up to PAGE_SIZE.
It seems that kimage_load_segment() requires this, but I'm not sure.
>
> > + /* within 1GB-aligned window of up to 32GB in size */
> > + kbuf.buf_max = round_down(kern_seg->mem, SZ_1G)
> > + + (unsigned long)SZ_1G * 32;
> > + kbuf.top_down = false;
> > +
> > + ret = kexec_add_buffer(&kbuf);
> > + if (ret)
> > + goto out_err;
> > + initrd_load_addr = kbuf.mem;
> > +
> > + pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > + initrd_load_addr, initrd_len, initrd_len);
> > + }
> > +
> > + /* load dtb blob */
> > + ret = setup_dtb(image, initrd_load_addr, initrd_len,
> > + cmdline, cmdline_len, &dtb, &dtb_len);
> > + if (ret) {
> > + pr_err("Preparing for new dtb failed\n");
> > + goto out_err;
> > + }
> > +
> > + kbuf.buffer = dtb;
> > + kbuf.bufsz = dtb_len;
> > + kbuf.memsz = dtb_len;
> > + /* not across 2MB boundary */
> > + kbuf.buf_align = SZ_2M;
> > + kbuf.buf_max = ULONG_MAX;
> > + kbuf.top_down = true;
> > +
> > + ret = kexec_add_buffer(&kbuf);
> > + if (ret)
> > + goto out_err;
> > + image->arch.dtb_mem = kbuf.mem;
> > + image->arch.dtb_buf = dtb;
> > +
> > + pr_debug("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> > + kbuf.mem, dtb_len, dtb_len);
> > +
> > + return 0;
> > +
> > +out_err:
> > + vfree(dtb);
> > + image->arch.dtb_buf = NULL;
>
> Won't kimage_file_post_load_cleanup() always be called if we return an error
> here? Why not leave the free()ing until then?
Right.
The reason why I left the code here was that we'd better locally clean up
all the stuff that were locally allocated if we trivially need to (and can)
do so.
As it's redundant, I will remove it.
Thanks,
-Takahiro AKASHI
>
> > + return ret;
> > +}
>
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 4/4] omap2: powerdomain: Inroduce cpu_pm notifiers for context save/restore
From: Tero Kristo @ 2018-05-18 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7df065c3-5154-5059-891c-2855e3cdbe00@ti.com>
On 18/05/18 07:32, Keerthy wrote:
>
>
> On Friday 18 May 2018 03:15 AM, Tony Lindgren wrote:
>> * Keerthy <j-keerthy@ti.com> [180516 15:21]:
>>> + /* Only AM43XX can lose pwrdm context during rtc-ddr suspend */
>>> + if (soc_is_am43xx()) {
>>> + nb.notifier_call = cpu_notifier;
>>> + cpu_pm_register_notifier(&nb);
>>> + }
>>> +
>>
>> Hmm in patch 3/4 you add omap4_pwrdm_save_context(), I think
>> that we'd want to run with the notifier for cpuidle on omap4?
>
> Okay i believe that is not needed for cpuidle on omap4. PRCM on wakeup
> domain so save/restore not needed for powerdomain on omap4.
>
> Tero can confirm the same.
Yea I don't believe this is needed. Only certain portions of the OMAP4
PRCM lose context during device off mode (which is currently not
supported by linux), and whatever portions do lose, they should use the
SAR_RAM approach for context save/restore, as that is supported by
HW/ROM code.
-Tero
>
> Should i rename omap4_pwrdm_save_context to am43xx_pwrdm_save_context to
> avoid confusion?
>
> Regards,
> Keerthy
>
>>
>> Regards,
>>
>> Tony
>>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH] clk: davinci: psc-da830: fix USB0 48MHz PHY clock registration
From: Sekhar Nori @ 2018-05-18 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f8a876b-6a66-687c-f83f-51b8d896c50a@ti.com>
Hi Stephen,
On Wednesday 16 May 2018 10:44 AM, Sekhar Nori wrote:
> Hi Stephen,
>
> On Wednesday 16 May 2018 04:04 AM, Stephen Boyd wrote:
>> Quoting Sekhar Nori (2018-05-07 04:34:57)
>>> USB0 48MHz PHY clock registration fails on DA830 because the
>>> da8xx-cfgchip clock driver cannot get a reference to USB0
>>> LPSC clock.
>>>
>>> The USB0 LPSC needs to be enabled during PHY clock enable. Setup
>>> the clock lookup correctly to fix this.
>>>
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>> ---
>>
>> Applied to clk-next
>>
>> Did this need a fixes tag? And should it go into 4.17 final? Or it's not
>> causing problems right now?
>
> We have not switched DaVinci to use common clock framework still. So no,
> this does not cause problems right now. All drivers/clk/davinci/*
> patches can be included for v4.18.
There are some more patches (fixes) to drivers/clk/davinci which have
been reviewed and both David and I think are ready for merge[1].
Do you have them in your queue? Else, I can send a pull request for you
to take a look and merge.
Thanks,
Sekhar
[1]
clk: davinci: psc-dm365: fix few clocks
clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups
clk: davinci: pll-dm355: fix SYSCLKn parent names
clk: davinci: pll-dm355: drop pll2_sysclk2
^ permalink raw reply
* [PATCH 1/2] dt-bindings: power: Add ZynqMP power domain bindings
From: Marek Szyprowski @ 2018-05-18 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN1PR02MB37588BFF357865F4C9628D99B8910@SN1PR02MB3758.namprd02.prod.outlook.com>
Hi Jolly,
On 2018-05-17 23:10, Jolly Shah wrote:
>>>>>> +Example:
>>>>>> + zynqmp-genpd {
>>>>>> + compatible = "xlnx,zynqmp-genpd";
>>>>> What's the control interface for controlling the domains?
>>>>>> +
>>>>>> + pd_usb0: pd-usb0 {
>>>>>> + pd-id = <22>;
>>>>>> + #power-domain-cells = <0>;
>>>>> There's no need for all these sub nodes. Make #power-domain-cells 1
>>>>> and put the id in the cell value.
>>>> That was my first reaction, too...
>>>>>> + };
>>>>>> +
>>>>>> + pd_sata: pd-sata {
>>>>>> + pd-id = <28>;
>>>>>> + #power-domain-cells = <0>;
>>>>>> + };
>>>>>> +
>>>>>> + pd_gpu: pd-gpu {
>>>>>> + pd-id = <58 20 21>;
>>>> ... until I saw the above.
>>>> Controlling the GPU power area requires controlling 3 physical areas?
>>>>
>>>> However, doing it this way may bite you in the future, if a need
>>>> arises to control a subset. And what about power up/down order?
>>> What about defining 3 separate domains and arranging them in
>>> parent-child relationship? generic power domains already supports that
>>> and this allows to nicely define the power on/off order.
>>>
>>>>>> + #power-domain-cells = <0x0>;
>>>>>> + };
>>>>>> + };
>> I agree it should be arranged in as parent child order to control subset or control
>> order. Will incorporate those changes in next version.
>
> As suggested, I tried out parent, child approach. However what I found is Genpd core takes care of parent child dependencies for power on off routines only. In our case, We need them in attach-detach routines too. In that case, we need to handle dependencies manually for those routines. Please suggest better approach, if any.
What do you mean to handle attach-detach?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: msm8996: Add ufs related nodes
From: Bjorn Andersson @ 2018-05-18 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518062638.31777-1-bjorn.andersson@linaro.org>
Add the UFS QMP phy node and the UFS host controller node, now that we
have working UFS and the necessary clocks in place.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 8 ++
arch/arm64/boot/dts/qcom/msm8996.dtsi | 85 ++++++++++++++++++++
2 files changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index 8be666ea92bd..00e3ecd1180a 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -122,6 +122,14 @@
status = "okay";
};
+ phy at 627000 {
+ status = "okay";
+ };
+
+ ufshc at 624000 {
+ status = "okay";
+ };
+
phy at 34000 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 37b7152cb064..221bb3d383c5 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -633,6 +633,91 @@
#interrupt-cells = <4>;
};
+ ufsphy: phy at 627000 {
+ compatible = "qcom,msm8996-ufs-phy-qmp-14nm";
+ reg = <0x627000 0xda8>;
+ reg-names = "phy_mem";
+ #phy-cells = <0>;
+
+ vdda-phy-supply = <&pm8994_l28>;
+ vdda-pll-supply = <&pm8994_l12>;
+
+ vdda-phy-max-microamp = <18380>;
+ vdda-pll-max-microamp = <9440>;
+
+ vddp-ref-clk-supply = <&pm8994_l25>;
+ vddp-ref-clk-max-microamp = <100>;
+ vddp-ref-clk-always-on;
+
+ clock-names = "ref_clk_src", "ref_clk";
+ clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
+ <&gcc GCC_UFS_CLKREF_CLK>;
+ status = "disabled";
+
+ power-domains = <&gcc UFS_GDSC>;
+ };
+
+ ufshc at 624000 {
+ compatible = "qcom,ufshc";
+ reg = <0x624000 0x2500>;
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+
+ phys = <&ufsphy>;
+ phy-names = "ufsphy";
+
+ vcc-supply = <&pm8994_l20>;
+ vccq-supply = <&pm8994_l25>;
+ vccq2-supply = <&pm8994_s4>;
+
+ vcc-max-microamp = <600000>;
+ vccq-max-microamp = <450000>;
+ vccq2-max-microamp = <450000>;
+
+ clock-names =
+ "core_clk_src",
+ "core_clk",
+ "bus_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro_src",
+ "core_clk_unipro",
+ "core_clk_ice",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk";
+ clocks =
+ <&gcc UFS_AXI_CLK_SRC>,
+ <&gcc GCC_UFS_AXI_CLK>,
+ <&gcc GCC_SYS_NOC_UFS_AXI_CLK>,
+ <&gcc GCC_AGGRE2_UFS_AXI_CLK>,
+ <&gcc GCC_UFS_AHB_CLK>,
+ <&gcc UFS_ICE_CORE_CLK_SRC>,
+ <&gcc GCC_UFS_UNIPRO_CORE_CLK>,
+ <&gcc GCC_UFS_ICE_CORE_CLK>,
+ <&rpmcc RPM_SMD_LN_BB_CLK>,
+ <&gcc GCC_UFS_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_RX_SYMBOL_0_CLK>;
+ freq-table-hz =
+ <100000000 200000000>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <150000000 300000000>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <0 0>;
+
+ lanes-per-direction = <1>;
+ status = "disabled";
+
+ ufs_variant {
+ compatible = "qcom,ufs_variant";
+ };
+ };
+
mmcc: clock-controller at 8c0000 {
compatible = "qcom,mmcc-msm8996";
#clock-cells = <1>;
--
2.17.0
^ permalink raw reply related
* [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory
From: AKASHI Takahiro @ 2018-05-18 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fbd2c6c6-be20-a9fa-0303-e4448225df18@arm.com>
James,
On Tue, May 15, 2018 at 05:15:52PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 15/05/18 05:45, AKASHI Takahiro wrote:
> > On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote:
> >> On 07/05/18 06:22, AKASHI Takahiro wrote:
> >>> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
> >>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
> >>>>> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> >>>>> index f76ea92dff91..f7dbba00be10 100644
> >>>>> --- a/arch/arm64/kernel/machine_kexec.c
> >>>>> +++ b/arch/arm64/kernel/machine_kexec.c
> >>>>> @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage)
> >>
> >>>>> cpu_soft_restart(kimage != kexec_crash_image,
> >>>>> - reboot_code_buffer_phys, kimage->head, kimage->start, 0);
> >>>>> + reboot_code_buffer_phys, kimage->head, kimage->start,
> >>>>> +#ifdef CONFIG_KEXEC_FILE
> >>>>> + kimage->purgatory_info.purgatory_buf ?
> >>>>> + 0 : kimage->arch.dtb_mem);
> >>>>> +#else
> >>>>> + 0);
> >>>>> +#endif
> >>
> >>
> >>>> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called from
> >>>> kexec_load_purgatory(), which we don't use. How does this get a value?
> >>>>
> >>>> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 for
> >>>> regular kexec (as we can't know where the dtb is)? (image_arg may then be a
> >>>> better name).
> >>>
> >>> The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE.
> >>
> >> I thought it was ARCH_HAS_KIMAGE_ARCH, which we can define all the time if
> >> that's what we want.
> >>
> >>
> >>> So I would like to
> >>> - merge this patch with patch#8
> >>> - change the condition
> >>> #ifdef CONFIG_KEXEC_FILE
> >>> kimage->file_mode ? kimage->arch.dtb_mem : 0);
We don't need "kimage->file_mode ?" since arch.dtb_mem is 0 if !file_mode.
> >>> #else
> >>> 0);
> >>> #endif
> >>
> >> If we can avoid even this #ifdef by always having kimage->arch, I'd prefer that.
> >> If we do that 'dtb_mem' would need some thing that indicates its for kexec_file,
> >> as kexec has a DTB too, we just don't know where it is...
> >
> > OK, but I want to have a minimum of kexec.arch always exist.
>
> I'm curious, why? Its 32bytes that is allocated a maximum of twice.
I believe that I'm a stingy minimalist :)
> (my questions on what needs to go in there were because it looked like a third
> user was missing...)
>
>
> > How about this?
> >
> > | struct kimage_arch {
> > | phys_addr_t dtb_mem;
> > | #ifdef CONFIG_KEXEC_FILE
>
> #ifdef in structs just breeds more #ifdefs, as the code that accesses those
> members has to be behind the same set of conditions.
>
> Given this, I prefer the #ifdefs around cpu_soft_restart() as it doesn't force
> us to add more #ifdefs later.
OK
> For either option without purgatory_info:
> Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH v10 25/27] ARM: davinci: add device tree support to timer
From: Sekhar Nori @ 2018-05-18 6:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1162de58-00bc-fdfa-eef1-48a094834ac3@lechnology.com>
On Thursday 17 May 2018 08:39 PM, David Lechner wrote:
> On 05/17/2018 09:35 AM, Sekhar Nori wrote:
>> Hi David,
>>
>> On Wednesday 09 May 2018 10:56 PM, David Lechner wrote:
>>> This adds device tree support to the davinci timer so that when clocks
>>> are moved to device tree, the timer will still work.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>
>>> +static int __init of_davinci_timer_init(struct device_node *np)
>>> +{
>>> +??? struct clk *clk;
>>> +
>>> +??? clk = of_clk_get(np, 0);
>>> +??? if (IS_ERR(clk)) {
>>> +??????? struct of_phandle_args clkspec;
>>> +
>>> +??????? /*
>>> +???????? * Fall back to using ref_clk if the actual clock is not
>>> +???????? * available. There will be problems later if the real clock
>>> +???????? * source is disabled.
>>> +???????? */
>>> +
>>> +??????? pr_warn("%s: falling back to ref_clk\n", __func__);
>>> +
>>> +??????? clkspec.np = of_find_node_by_name(NULL, "ref_clk");
>>> +??????? if (IS_ERR(clkspec.np)) {
>>> +??????????? pr_err("%s: No clock available for timer!\n", __func__);
>>> +??????????? return PTR_ERR(clkspec.np);
>>> +??????? }
>>> +??????? clk = of_clk_get_from_provider(&clkspec);
>>> +??????? of_node_put(clkspec.np);
>>> +??? }
>>
>> Do we need this error path now?
>>
>> Thanks,
>> Sekhar
>>
>
> No, not really.
Then lets just print an error and return the error number.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/4] omap2: clockdomain: Inroduce cpu_pm notifiers for context save/restore
From: Keerthy @ 2018-05-18 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517214347.GR98604@atomide.com>
On Friday 18 May 2018 03:13 AM, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [180516 15:21]:
>> Inroduce cpu_pm notifiers for context save/restore. This will be
>> needed for am43xx family in case of rtc only mode with ddr in
>> self-refresh.
> ...
>> +static int cpu_notifier(struct notifier_block *nb, unsigned long cmd, void *v)
>> +{
>> + switch (cmd) {
>> + case CPU_CLUSTER_PM_ENTER:
>> + if (enable_off_mode)
>> + clkdm_save_context();
>> + break;
>> + case CPU_CLUSTER_PM_EXIT:
>> + if (enable_off_mode)
>> + clkdm_restore_context();
>> + break;
>> + }
>> +
>> + return NOTIFY_OK;
>> +}
>
> Can you do this too only on suspend instead of the cpu notifier?
> If you need to call this eventually from cpuidle also then yeah
> the notifier makes sense.
Clockdomain under omap2 does not have suspend/resume calls as its still
not a driver. The initial version of this patch had save/restore calls
directly from pm33xx-core during suspend/resume platform ops are called.
Are you suggesting that?
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Bjorn Andersson @ 2018-05-18 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180412190138.12372-1-chunkeey@gmail.com>
On Thu 12 Apr 12:01 PDT 2018, Christian Lamparter wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 0a6f7952bbb1..18511e782cbd 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -530,6 +530,7 @@
> reg = <0x01010000 0x300000>;
> interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> + gpio-ranges = <&msmgpio 0 0 150>;
I'm still confused to why this information is in DT at all, it feels
like an implementation detail, not a system configuration thing.
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index e7abc8ba222b..ed889553f01c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -890,11 +890,24 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
> return ret;
> }
>
> - ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);
> - if (ret) {
> - dev_err(pctrl->dev, "Failed to add pin range\n");
> - gpiochip_remove(&pctrl->chip);
> - return ret;
> + /*
> + * For DeviceTree-supported systems, the gpio core checks the
> + * pinctrl's device node for the "gpio-ranges" property.
> + * If it is present, it takes care of adding the pin ranges
> + * for the driver. In this case the driver can skip ahead.
> + *
> + * In order to remain compatible with older, existing DeviceTree
> + * files which don't set the "gpio-ranges" property or systems that
> + * utilize ACPI the driver has to call gpiochip_add_pin_range().
> + */
> + if (!of_property_read_bool(pctrl->dev->of_node, "gpio-ranges")) {
> + ret = gpiochip_add_pin_range(&pctrl->chip,
> + dev_name(pctrl->dev), 0, 0, chip->ngpio);
> + if (ret) {
> + dev_err(pctrl->dev, "Failed to add pin range\n");
> + gpiochip_remove(&pctrl->chip);
> + return ret;
> + }
> }
The patch looks good, but I would like you to split it in DT and pinctrl
parts, to make it less likely to collide and to allow Andy to inject the
missing change of sdm845.dtsi (which is now in linux-next)
Please split it and add my
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
to both patches.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list
From: AKASHI Takahiro @ 2018-05-18 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518013735.GP24627@MiWiFi-R3L-srv>
Baoquan,
On Fri, May 18, 2018 at 09:37:35AM +0800, Baoquan He wrote:
> On 05/17/18 at 07:04pm, James Morse wrote:
> > Hi Baoquan,
> >
> > On 17/05/18 03:15, Baoquan He wrote:
> > > On 05/17/18 at 10:10am, Baoquan He wrote:
> > >> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > >>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> > >>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
> > >>>>> We need to prevent firmware-reserved memory regions, particularly EFI
> > >>>>> memory map as well as ACPI tables, from being corrupted by loading
> > >>>>> kernel/initrd (or other kexec buffers). We also want to support memory
> > >>>>> allocation in top-down manner in addition to default bottom-up.
> > >>>>> So let's have arm64 specific arch_kexec_walk_mem() which will search
> > >>>>> for available memory ranges in usable memblock list,
> > >>>>> i.e. !NOMAP & !reserved,
> > >>>>
> > >>>>> instead of system resource tree.
> > >>>>
> > >>>> Didn't we try to fix the system-resource-tree in order to fix regular-kexec to
> > >>>> be safe in the EFI-memory-map/ACPI-tables case?
> > >>>>
> > >>>> It would be good to avoid having two ways of doing this, and I would like to
> > >>>> avoid having extra arch code...
> > >>>
> > >>> I know what you mean.
> > >>> /proc/iomem or system resource is, in my opinion, not the best place to
> > >>> describe memory usage of kernel but rather to describe *physical* hardware
> > >>> layout. As we are still discussing about "reserved" memory, I don't want
> > >>> to depend on it.
> > >>> Along with memblock list, we will have more accurate control over memory
> > >>> usage.
> > >>
> > >> In kexec-tools, we see any usable memory as candidate which can be used
> > >
> > > Here I said 'any', it's not accurate. Those memory which need be passed
> > > to 2nd kernel for use need be excluded, just as we have done in
> > > kexec-tools.
> > >
> > >> to load kexec kernel image/initrd etc. However kexec loading is a
> > >> preparation work, it just books those position for later kexec kernel
> > >> jumping after "kexec -e", that is why we need kexec_buf to remember
> > >> them and do the real content copy of kernel/initrd.
> >
> > The problem we have on arm64 is /proc/iomem is being used for two things.
> > 1) Kexec's this is memory I can book for the new kernel.
> > 2) Kdump's this is memory I must describe for vmcore.
> >
> > We get the memory map from UEFI via the EFI stub, and leave it in
> > memblock_reserved() memory. A new kexec kernel needs this to boot: it mustn't
> > overwrite it. The same goes for the ACPI tables, they could be reclaimed and
> > used as memory, but the new kexec kernel needs them to boot, they are
> > memblock_reserved() too.
>
> Thanks for these details. Seems arm64 is different. In x86 64 memblock
Thanks to James from me, too.
> is used as bootmem allocator and will be released when buddy takes over.
> Mainly, using memblock may bring concern that kexec kernel
> will jump to a unfixed position. This creates an unexpected effect as
> KASLR is doing, namely kernel could be put at a random position. As we
I don't think that this would be a problem on arm64.
> know, kexec was invented for fast kernel dev testing by bypassing
> firmware reset, and has been taken to reboot those huge server with
> thousands of devices and large memory for business currently. This extra
> unpected KASLR effect may cause annoyance even though people have
> disabled KASLR explicitly for a specific testing purpose.
>
> Besides, discarding the /proc/iomem scanning but taking memblock instead
> in kernel space works for kexec loading for the time being, the flaw of
> /proc/iomem still exists and cause problem for user space kexec-tools,
> as pointed out. Do we have a plan for that?
This was the difference between my and James' standpoint (at leas initially).
James didn't want to require userspace changes to fix the issue, but
the reality is that, without modifying it, we can't support kexec and kdump
perfectly as James explained in his email.
> >
> > If we knock all memblock_reserved() regions out of /proc/iomem then kdump
> > doesn't work, because /proc/iomem is only generated once. Its a snapshot. The
> > initcode/data is an example of memory we release from memblock_reserve() after
> > this, then gets used for data we need in the vmcore.
>
> Hmm, I'm a little confused here. We have defined different iores type
> for different memory region. If acpi need be reused by kdump/kexec, we
> can change to not reclaim it, and add them into /proc/iomem in order to
> notify components which rely on them to process.
>
>
> enum {
> IORES_DESC_NONE = 0,
> IORES_DESC_CRASH_KERNEL = 1,
> IORES_DESC_ACPI_TABLES = 2,
> IORES_DESC_ACPI_NV_STORAGE = 3,
> IORES_DESC_PERSISTENT_MEMORY = 4,
> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
> IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
> };
I don't think that is the point.
Let me give you analogy: x86 has e820 and handles memory layout in kexec/
kdump with *x86-specific* code in kexec-tools, right? We want to do
something similar without introducing e820-like data.
In the current implementation on arm64, however, kexec-tools will only
recognize top-level entries in /proc/iomem leaving subsequent level of
entries ignored (except kernel text & data).
So adding extra hierarchy to /proc/iomem will break the compatibility
in any way.
The main reason that I insist on memblock in my kexec_file patch
is that we seem to be still far from reaching to agreement and
final solution in kexec (opposite to kexec_file) case.
Thanks,
-Takahiro AKASHI
>
> Just walk around and talk about it, limited by poor arm64 knowledge, I
> may not have a complete view. If it's not like what I think about, I
> will stop, and can come back when I get more background knowledge.
>
> Thanks
> Baoquan
>
> >
> > Ideally we would describe all this in /proc/iomem with:
> > | 8001e80000-83ff186fff : System RAM
> > | 8002080000-8002feffff : [Data you really need to boot]
> >
> > kexec-tools should not overwrite 'data you really need to boot' unless it knows
> > what it is, and that the system will never need it again. (examples: overwrite
> > the ACPI tables when booting a non-acpi kernel, overwrite the UEFI memory map if
> > the DT has been regenerated for a non-uefi kernel)
> >
> > But, kexec-tools doesn't parse those second level entries properly. We have a
> > bug in user-space, and a bug in the kernel.
> >
> > Because /proc/iomem is being used for two things, and kexec-tools only parses
> > one level, I don't think we can fix this in the kernel without breaking one of
> > the use-cases. I think Akashi's fix user-space too approach is the most
> > pragmatic approach.
> >
> >
> > >> Here you use
> > >> memblock to search available memory, isn't it deviating too far away
> > >> from the original design in kexec-tools. Assume kexec loading and
> > >> kexec_file loading should be consistent on loading even though they are
> > >> done in different space, kernel space and user space.
> >
> > Its much easier for us to parse memblock in the kernel as the helpers step over
> > the regions we know we don't want. For the resource list we would need to
> > strcmp(), and a bunch of handling for the second level entries.
> >
> >
> > Thanks,
> >
> > James
^ permalink raw reply
* [PATCH 4/4] omap2: powerdomain: Inroduce cpu_pm notifiers for context save/restore
From: Keerthy @ 2018-05-18 4:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517214507.GS98604@atomide.com>
On Friday 18 May 2018 03:15 AM, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [180516 15:21]:
>> + /* Only AM43XX can lose pwrdm context during rtc-ddr suspend */
>> + if (soc_is_am43xx()) {
>> + nb.notifier_call = cpu_notifier;
>> + cpu_pm_register_notifier(&nb);
>> + }
>> +
>
> Hmm in patch 3/4 you add omap4_pwrdm_save_context(), I think
> that we'd want to run with the notifier for cpuidle on omap4?
Okay i believe that is not needed for cpuidle on omap4. PRCM on wakeup
domain so save/restore not needed for powerdomain on omap4.
Tero can confirm the same.
Should i rename omap4_pwrdm_save_context to am43xx_pwrdm_save_context to
avoid confusion?
Regards,
Keerthy
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-18 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526615528-9707-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&gpio_mute 1>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..e3162bb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&gpio_mute 1 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
vccio1-supply = <&vcc_io>;
vccio2-supply = <&vcc18_emmc>;
- vccio3-supply = <&vcc_io>;
+ vccio3-supply = <&vcc_sdio>;
vccio4-supply = <&vcc_18>;
vccio5-supply = <&vcc_io>;
vccio6-supply = <&vcc_io>;
@@ -242,7 +255,12 @@
max-frequency = <150000000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-18 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526615528-9707-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v2: None
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_io>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: rockchip: Add gpio-mute to rk3328
From: djw at t-chip.com.cn @ 2018-05-18 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526615528-9707-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Adding a new gpio controller named "gpio-mute" to rk3328, providing
access to the GPIO_MUTE pin defined in the syscon GRF_SOC_CON10.
The GPIO_MUTE pin is referred to as <&gpio-mute 1>.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da1..5ba29d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -309,6 +309,13 @@
mode-loader = <BOOT_BL_DOWNLOAD>;
};
+ /* The GPIO_MUTE pin is referred to as <&gpio-mute 1>.*/
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
};
uart0: serial at ff110000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: djw at t-chip.com.cn @ 2018-05-18 3:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526615528-9707-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.
Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 0000000..b1b2a67
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = Active high,
+ 1 = Active low.
+- gpio,syscon-dev: Should contain <grf_phandle syscon_offset 0>.
+ If declared as child of the grf node, the grf_phandle can be 0.
+
+Example:
+
+1. As child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
+ };
+
+
+2. Not child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+ //...
+ };
+
+ gpio_mute: gpio-mute {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <&grf 0x0428 0>;
+ };
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..e24b408 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = {
.dat_bit_offset = 0x40 * 8 + 8,
};
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+ unsigned int offs;
+ u8 bit;
+ u32 data;
+ int ret;
+
+ offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+ bit = offs % SYSCON_REG_BITS;
+ data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+ ret = regmap_write(priv->syscon,
+ (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+ data);
+ if (ret < 0)
+ dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_gpio_syscon = {
+ /* Rockchip GRF_SOC_CON Bits 0-15 */
+ .flags = GPIO_SYSCON_FEAT_OUT,
+ .bit_count = 16,
+ .set = rockchip_gpio_set,
+};
+
#define KEYSTONE_LOCK_BIT BIT(0)
static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data = &keystone_dsp_gpio,
},
+ {
+ .compatible = "rockchip,gpio-syscon",
+ .data = &rockchip_gpio_syscon,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.
From: djw at t-chip.com.cn @ 2018-05-18 3:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Levin Du <djw@t-chip.com.cn>
Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.
This patch series adds a new compatible `rockchip,gpio-syscon` to
the gpio-syscon driver for general Rockchip SoC usage.
A new gpio controller named `gpio_mute` is defined in
rk3328.dtsi so that all rk3328 boards has access to it.
The ROC-RK3328-CC board use the new gpio <&gpio_mute 1> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.
Many thanks to Heiko's great advice!
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
- Split from V0 into small patches
- Sort dts properties in sdmmc node
Heiko Stuebner (1):
gpio: syscon: allow fetching syscon from parent node
Levin Du (4):
gpio: syscon: Add gpio-syscon for rockchip
arm64: dts: rockchip: Add gpio-mute to rk3328
arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 30 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 ++++
drivers/gpio/gpio-syscon.c | 32 +++++++++++++++++
4 files changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
--
2.7.4
^ permalink raw reply
* [RFC PATCH 04/10] devfreq: rk3399_dmc / rockchip: pm_domains: Register notify to DMC driver.
From: Chanwoo Choi @ 2018-05-18 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514211610.26618-5-enric.balletbo@collabora.com>
Hi,
As I already commented[1], I think that it is not proper in order to pass
the devfreq instance to power_domain driver by separate defined function
(rockchip_pm_register_dmcfreq_notifier()).
[1] https://patchwork.kernel.org/patch/10349571/
Maybe, you could check the 'OF graph[1]' or 'device connection[2]'
for the device connection. Unfortunately, I'm not sure what is
best solution for this issue.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/graph.txt
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f2d9b66d84f3ff5ea3aff111e6a403e04fa8bf37
On 2018? 05? 15? 06:16, Enric Balletbo i Serra wrote:
> From: Lin Huang <hl@rock-chips.com>
>
> The DMC (Dynamic Memory Interface) controller does a SiP call to the
> Trusted Firmware-A (TF-A) to change the DDR clock frequency. When this
> happens the TF-A writes to the PMU bus idle request register
> (PMU_BUS_IDLE_REQ) but at the same time it is possible that the Rockchip
> power domain driver writes to the same register. So, add a notification
> mechanism to ensure that the DMC and the PD driver does not access to this
> register at the same time.
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> [rewrite commit message]
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> As I explained in the cover letter I have doubts regarding this patch
> but I did not find another way to do it. So I will appreciate any
> feedback on this.
>
> drivers/devfreq/rk3399_dmc.c | 7 ++++++
> drivers/soc/rockchip/pm_domains.c | 36 +++++++++++++++++++++++++++++++
> include/soc/rockchip/rk3399_dmc.h | 14 ++++++++++++
> 3 files changed, 57 insertions(+)
> create mode 100644 include/soc/rockchip/rk3399_dmc.h
>
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index cc1bbca3fb15..2c4985a501cb 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -28,6 +28,7 @@
> #include <linux/rwsem.h>
> #include <linux/suspend.h>
>
> +#include <soc/rockchip/rk3399_dmc.h>
> #include <soc/rockchip/rk3399_grf.h>
> #include <soc/rockchip/rockchip_sip.h>
>
> @@ -443,6 +444,12 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
> data->dev = dev;
> platform_set_drvdata(pdev, data);
>
> + rockchip_pm_register_dmcfreq_notifier(data->devfreq);
> + if (ret < 0) {
> + dev_err(dev, "Failed to register dmcfreq notifier\n");
> + return ret;
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
> index 53efc386b1ad..b0e66f24b3e3 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/devfreq.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> #include <linux/err.h>
> @@ -76,9 +77,13 @@ struct rockchip_pmu {
> const struct rockchip_pmu_info *info;
> struct mutex mutex; /* mutex lock for pmu */
> struct genpd_onecell_data genpd_data;
> + struct devfreq *devfreq;
> + struct notifier_block dmc_nb;
> struct generic_pm_domain *domains[];
> };
>
> +static struct rockchip_pmu *dmc_pmu;
> +
> #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
>
> #define DOMAIN(pwr, status, req, idle, ack, wakeup) \
> @@ -601,6 +606,35 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
> return error;
> }
>
> +static int rk3399_dmcfreq_notify(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + if (event == DEVFREQ_PRECHANGE)
> + mutex_lock(&dmc_pmu->mutex);
> + else if (event == DEVFREQ_POSTCHANGE)
> + mutex_unlock(&dmc_pmu->mutex);
> +
> + return NOTIFY_OK;
> +}
> +
> +int rockchip_pm_register_dmcfreq_notifier(struct devfreq *devfreq)
> +{
> + int ret;
> +
> + if (!dmc_pmu)
> + return -EPROBE_DEFER;
> +
> + dmc_pmu->devfreq = devfreq;
> + dmc_pmu->dmc_nb.notifier_call = rk3399_dmcfreq_notify;
> + ret = devm_devfreq_register_notifier(devfreq->dev.parent,
> + dmc_pmu->devfreq,
> + &dmc_pmu->dmc_nb,
> + DEVFREQ_TRANSITION_NOTIFIER);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(rockchip_pm_register_dmcfreq_notifier);
> +
> static int rockchip_pm_domain_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -694,6 +728,8 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
> goto err_out;
> }
>
> + dmc_pmu = pmu;
> +
> return 0;
>
> err_out:
> diff --git a/include/soc/rockchip/rk3399_dmc.h b/include/soc/rockchip/rk3399_dmc.h
> new file mode 100644
> index 000000000000..031a62607f61
> --- /dev/null
> +++ b/include/soc/rockchip/rk3399_dmc.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Lin Huang <hl@rock-chips.com>
> + */
> +
> +#ifndef __SOC_RK3399_DMC_H
> +#define __SOC_RK3399_DMC_H
> +
> +#include <linux/devfreq.h>
> +
> +int rockchip_pm_register_dmcfreq_notifier(struct devfreq *devfreq);
> +
> +#endif
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries
From: Manivannan Sadhasivam @ 2018-05-18 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518023056.7869-1-manivannan.sadhasivam@linaro.org>
Add S900 pinctrl entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..9e1a17c9b4a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,10 +1125,12 @@ F: arch/arm/mach-actions/
F: arch/arm/boot/dts/owl-*
F: arch/arm64/boot/dts/actions/
F: drivers/clocksource/owl-*
+F: drivers/pinctrl/actions/*
F: drivers/soc/actions/
F: include/dt-bindings/power/owl-*
F: include/linux/soc/actions/
F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
--
2.14.1
^ permalink raw reply related
* [PATCH 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC
From: Manivannan Sadhasivam @ 2018-05-18 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518023056.7869-1-manivannan.sadhasivam@linaro.org>
Add gpio support to pinctrl driver for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pinctrl/actions/Kconfig | 1 +
drivers/pinctrl/actions/pinctrl-owl.c | 206 +++++++++++++++++++++++++++++++++
drivers/pinctrl/actions/pinctrl-owl.h | 20 ++++
drivers/pinctrl/actions/pinctrl-s900.c | 29 ++++-
4 files changed, 255 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index ede97cdbbc12..490927b4ea76 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -4,6 +4,7 @@ config PINCTRL_OWL
select PINMUX
select PINCONF
select GENERIC_PINCONF
+ select GPIOLIB
help
Say Y here to enable Actions Semi OWL pinctrl driver
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c b/drivers/pinctrl/actions/pinctrl-owl.c
index ee090697b1e9..4942e34c8b76 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -11,6 +11,7 @@
#include <linux/clk.h>
#include <linux/err.h>
+#include <linux/gpio/driver.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -31,6 +32,7 @@
* struct owl_pinctrl - pinctrl state of the device
* @dev: device handle
* @pctrldev: pinctrl handle
+ * @chip: gpio chip
* @lock: spinlock to protect registers
* @soc: reference to soc_data
* @base: pinctrl register base address
@@ -38,6 +40,7 @@
struct owl_pinctrl {
struct device *dev;
struct pinctrl_dev *pctrldev;
+ struct gpio_chip chip;
raw_spinlock_t lock;
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
@@ -536,6 +539,198 @@ static struct pinctrl_desc owl_pinctrl_desc = {
.owner = THIS_MODULE,
};
+static const struct owl_gpio_port *
+owl_gpio_get_port(struct owl_pinctrl *pctrl, unsigned int *pin)
+{
+ unsigned int start = 0, i;
+
+ for (i = 0; i < pctrl->soc->nports; i++) {
+ const struct owl_gpio_port *port = &pctrl->soc->ports[i];
+
+ if (*pin >= start && *pin < start + port->pins) {
+ *pin -= start;
+ return port;
+ }
+
+ start += port->pins;
+ }
+
+ return NULL;
+}
+
+static void owl_gpio_update_reg(void __iomem *base, unsigned int pin, int flag)
+{
+ u32 val;
+
+ val = readl_relaxed(base);
+
+ if (flag)
+ val |= BIT(pin);
+ else
+ val &= ~BIT(pin);
+
+ writel_relaxed(val, base);
+}
+
+static int owl_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ /*
+ * GPIOs have higher priority over other modules, so either setting
+ * them as OUT or IN is sufficient
+ */
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static void owl_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ /* disable gpio output */
+ owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+
+ /* disable gpio input */
+ owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+}
+
+static int owl_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+ u32 val;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ val = readl_relaxed(gpio_base + port->dat);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return !!(val & BIT(offset));
+}
+
+static void owl_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->dat, offset, value);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+}
+
+static int owl_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+ owl_gpio_update_reg(gpio_base + port->inen, offset, true);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static int owl_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct owl_gpio_port *port;
+ void __iomem *gpio_base;
+ unsigned long flags;
+
+ port = owl_gpio_get_port(pctrl, &offset);
+ if (WARN_ON(port == NULL))
+ return -ENODEV;
+
+ gpio_base = pctrl->base + port->offset;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+ owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+ owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+ owl_gpio_update_reg(gpio_base + port->dat, offset, value);
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+
+ return 0;
+}
+
+static int owl_gpio_init(struct owl_pinctrl *pctrl)
+{
+ struct gpio_chip *chip;
+ int ret;
+
+ chip = &pctrl->chip;
+ chip->base = -1;
+ chip->ngpio = pctrl->soc->ngpios;
+ chip->label = dev_name(pctrl->dev);
+ chip->parent = pctrl->dev;
+ chip->owner = THIS_MODULE;
+ chip->of_node = pctrl->dev->of_node;
+
+ ret = gpiochip_add_data(&pctrl->chip, pctrl);
+ if (ret) {
+ dev_err(pctrl->dev, "failed to register gpiochip\n");
+ return ret;
+ }
+
+ ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev),
+ 0, 0, chip->ngpio);
+ if (ret) {
+ dev_err(pctrl->dev, "failed to add pin range\n");
+ gpiochip_remove(&pctrl->chip);
+ return ret;
+ }
+
+ return 0;
+}
+
int owl_pinctrl_probe(struct platform_device *pdev,
struct owl_pinctrl_soc_data *soc_data)
{
@@ -571,6 +766,13 @@ int owl_pinctrl_probe(struct platform_device *pdev,
owl_pinctrl_desc.pins = soc_data->pins;
owl_pinctrl_desc.npins = soc_data->npins;
+ pctrl->chip.direction_input = owl_gpio_direction_input;
+ pctrl->chip.direction_output = owl_gpio_direction_output;
+ pctrl->chip.get = owl_gpio_get;
+ pctrl->chip.set = owl_gpio_set;
+ pctrl->chip.request = owl_gpio_request;
+ pctrl->chip.free = owl_gpio_free;
+
pctrl->soc = soc_data;
pctrl->dev = &pdev->dev;
@@ -581,6 +783,10 @@ int owl_pinctrl_probe(struct platform_device *pdev,
return PTR_ERR(pctrl->pctrldev);
}
+ ret = owl_gpio_init(pctrl);
+ if (ret)
+ return ret;
+
platform_set_drvdata(pdev, pctrl);
return 0;
diff --git a/drivers/pinctrl/actions/pinctrl-owl.h b/drivers/pinctrl/actions/pinctrl-owl.h
index 448f81a6db3b..74342378937c 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.h
+++ b/drivers/pinctrl/actions/pinctrl-owl.h
@@ -114,6 +114,22 @@ struct owl_pinmux_func {
unsigned int ngroups;
};
+/**
+ * struct owl_gpio_port - Actions GPIO port info
+ * @offset: offset of the GPIO port.
+ * @pins: number of pins belongs to the GPIO port.
+ * @outen: offset of the output enable register.
+ * @inen: offset of the input enable register.
+ * @dat: offset of the data register.
+ */
+struct owl_gpio_port {
+ unsigned int offset;
+ unsigned int pins;
+ unsigned int outen;
+ unsigned int inen;
+ unsigned int dat;
+};
+
/**
* struct owl_pinctrl_soc_data - Actions pin controller driver configuration
* @pins: array describing all pins of the pin controller.
@@ -124,6 +140,8 @@ struct owl_pinmux_func {
* @ngroups: number of entries in @groups.
* @padinfo: array describing the pad info of this SoC.
* @ngpios: number of pingroups the driver should expose as GPIOs.
+ * @port: array describing all GPIO ports of this SoC.
+ * @nports: number of GPIO ports in this SoC.
*/
struct owl_pinctrl_soc_data {
const struct pinctrl_pin_desc *pins;
@@ -134,6 +152,8 @@ struct owl_pinctrl_soc_data {
unsigned int ngroups;
const struct owl_padinfo *padinfo;
unsigned int ngpios;
+ const struct owl_gpio_port *ports;
+ unsigned int nports;
};
int owl_pinctrl_probe(struct platform_device *pdev,
diff --git a/drivers/pinctrl/actions/pinctrl-s900.c b/drivers/pinctrl/actions/pinctrl-s900.c
index 08d93f8fc086..5503c7945764 100644
--- a/drivers/pinctrl/actions/pinctrl-s900.c
+++ b/drivers/pinctrl/actions/pinctrl-s900.c
@@ -33,6 +33,13 @@
#define PAD_SR1 (0x0274)
#define PAD_SR2 (0x0278)
+#define OWL_GPIO_PORT_A 0
+#define OWL_GPIO_PORT_B 1
+#define OWL_GPIO_PORT_C 2
+#define OWL_GPIO_PORT_D 3
+#define OWL_GPIO_PORT_E 4
+#define OWL_GPIO_PORT_F 5
+
#define _GPIOA(offset) (offset)
#define _GPIOB(offset) (32 + (offset))
#define _GPIOC(offset) (64 + (offset))
@@ -1814,6 +1821,24 @@ static struct owl_padinfo s900_padinfo[NUM_PADS] = {
[SGPIO3] = PAD_INFO_PULLCTL_ST(SGPIO3)
};
+#define OWL_GPIO_PORT(port, base, count, _outen, _inen, _dat) \
+ [OWL_GPIO_PORT_##port] = { \
+ .offset = base, \
+ .pins = count, \
+ .outen = _outen, \
+ .inen = _inen, \
+ .dat = _dat, \
+ }
+
+static const struct owl_gpio_port s900_gpio_ports[] = {
+ OWL_GPIO_PORT(A, 0x0000, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(B, 0x000C, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(C, 0x0018, 12, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(D, 0x0024, 30, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(E, 0x0030, 32, 0x0, 0x4, 0x8),
+ OWL_GPIO_PORT(F, 0x00F0, 8, 0x0, 0x4, 0x8)
+};
+
static struct owl_pinctrl_soc_data s900_pinctrl_data = {
.padinfo = s900_padinfo,
.pins = (const struct pinctrl_pin_desc *)s900_pads,
@@ -1822,7 +1847,9 @@ static struct owl_pinctrl_soc_data s900_pinctrl_data = {
.nfunctions = ARRAY_SIZE(s900_functions),
.groups = s900_groups,
.ngroups = ARRAY_SIZE(s900_groups),
- .ngpios = NUM_GPIOS
+ .ngpios = NUM_GPIOS,
+ .ports = s900_gpio_ports,
+ .nports = ARRAY_SIZE(s900_gpio_ports)
};
static int s900_pinctrl_probe(struct platform_device *pdev)
--
2.14.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: actions: Add gpio line names to Bubblegum-96 board
From: Manivannan Sadhasivam @ 2018-05-18 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518023056.7869-1-manivannan.sadhasivam@linaro.org>
Add gpio line names to Actions Semi S900 based Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++++++++++++++++++++++
1 file changed, 175 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index ff043c961d75..d0ba35df9015 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -34,3 +34,178 @@
status = "okay";
clocks = <&cmu CLK_UART5>;
};
+
+/*
+ * GPIO name legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (pin out but not routed from the chip to
+ * anything the board)
+ * "[PER]" = pin is muxed for [peripheral] (not GPIO)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ *
+ * Line names are taken from the schematic "Schematics Bubblegum96"
+ * version v1.0
+ *
+ * For the lines routed to the external connectors the
+ * lines are named after the 96Boards CE Specification 1.0,
+ * Appendix "Expansion Connector Signal Description".
+ *
+ * When the 96Boards naming of a line and the schematic name of
+ * the same line are in conflict, the 96Boards specification
+ * takes precedence, which means that the external UART on the
+ * LSEC is named UART0 while the schematic and SoC names this
+ * UART2. Only exception is the I2C lines for which the schematic
+ * naming has been preferred. This is only for the informational
+ * lines i.e. "[FOO]", the GPIO named lines "GPIO-A" thru "GPIO-L"
+ * are the only ones actually used for GPIO.
+ */
+
+&pinctrl {
+ gpio-line-names =
+ "GPIO-A", /* GPIO_0, LSEC pin 23 */
+ "GPIO-B", /* GPIO_1, LSEC pin 24 */
+ "GPIO-C", /* GPIO_2, LSEC pin 25 */
+ "GPIO-D", /* GPIO_3, LSEC pin 26 */
+ "GPIO-E", /* GPIO_4, LSEC pin 27 */
+ "GPIO-F", /* GPIO_5, LSEC pin 28 */
+ "GPIO-G", /* GPIO_6, LSEC pin 29 */
+ "GPIO-H", /* GPIO_7, LSEC pin 30 */
+ "GPIO-I", /* GPIO_8, LSEC pin 31 */
+ "GPIO-J", /* GPIO_9, LSEC pin 32 */
+ "NC", /* GPIO_10 */
+ "NC", /* GPIO_11 */
+ "SIRQ2_1V8", /* GPIO_12 */
+ "PCM0_OUT", /* GPIO_13 */
+ "WIFI_LED", /* GPIO_14 */
+ "PCM0_SYNC", /* GPIO_15 */
+ "PCM0_CLK", /* GPIO_16 */
+ "PCM0_IN", /* GPIO_17 */
+ "BT_LED", /* GPIO_18 */
+ "LED0", /* GPIO_19 */
+ "LED1", /* GPIO_20 */
+ "JTAG_TCK", /* GPIO_21 */
+ "JTAG_TMS", /* GPIO_22 */
+ "JTAG_TDI", /* GPIO_23 */
+ "JTAG_TDO", /* GPIO_24 */
+ "[UART1_RxD]", /* GPIO_25, LSEC pin 13 */
+ "NC", /* GPIO_26 */
+ "[UART1_TxD]", /* GPIO_27, LSEC pin 11 */
+ "SD0_D0", /* GPIO_28 */
+ "SD0_D1", /* GPIO_29 */
+ "SD0_D2", /* GPIO_30 */
+ "SD0_D3", /* GPIO_31 */
+ "SD1_D0", /* GPIO_32 */
+ "SD1_D1", /* GPIO_33 */
+ "SD1_D2", /* GPIO_34 */
+ "SD1_D3", /* GPIO_35 */
+ "SD0_CMD", /* GPIO_36 */
+ "SD0_CLK", /* GPIO_37 */
+ "SD1_CMD", /* GPIO_38 */
+ "SD1_CLK", /* GPIO_39 */
+ "SPI0_SCLK", /* GPIO_40, LSEC pin 8 */
+ "SPI0_CS", /* GPIO_41, LSEC pin 12 */
+ "SPI0_DIN", /* GPIO_42, LSEC pin 10 */
+ "SPI0_DOUT", /* GPIO_43, LSEC pin 14 */
+ "I2C5_SDATA", /* GPIO_44, HSEC pin 36 */
+ "I2C5_SCLK", /* GPIO_45, HSEC pin 38 */
+ "UART0_RX", /* GPIO_46, LSEC pin 7 */
+ "UART0_TX", /* GPIO_47, LSEC pin 5 */
+ "UART0_RTSB", /* GPIO_48, LSEC pin 9 */
+ "UART0_CTSB", /* GPIO_49, LSEC pin 3 */
+ "I2C4_SCLK", /* GPIO_50, HSEC pin 32 */
+ "I2C4_SDATA", /* GPIO_51, HSEC pin 34 */
+ "I2C0_SCLK", /* GPIO_52 */
+ "I2C0_SDATA", /* GPIO_53 */
+ "I2C1_SCLK", /* GPIO_54, LSEC pin 15 */
+ "I2C1_SDATA", /* GPIO_55, LSEC pin 17 */
+ "I2C2_SCLK", /* GPIO_56, LSEC pin 19 */
+ "I2C2_SDATA", /* GPIO_57, LSEC pin 21 */
+ "CSI0_DN0", /* GPIO_58, HSEC pin 10 */
+ "CSI0_DP0", /* GPIO_59, HSEC pin 8 */
+ "CSI0_DN1", /* GPIO_60, HSEC pin 16 */
+ "CSI0_DP1", /* GPIO_61, HSEC pin 14 */
+ "CSI0_CN", /* GPIO_62, HSEC pin 4 */
+ "CSI0_CP", /* GPIO_63, HSEC pin 2 */
+ "CSI0_DN2", /* GPIO_64, HSEC pin 22 */
+ "CSI0_DP2", /* GPIO_65, HSEC pin 20 */
+ "CSI0_DN3", /* GPIO_66, HSEC pin 28 */
+ "CSI0_DP3", /* GPIO_67, HSEC pin 26 */
+ "[CLK0]", /* GPIO_68, HSEC pin 15 */
+ "CSI1_DN0", /* GPIO_69, HSEC pin 44 */
+ "CSI1_DP0", /* GPIO_70, HSEC pin 42 */
+ "CSI1_DN1", /* GPIO_71, HSEC pin 50 */
+ "CSI1_DP1", /* GPIO_72, HSEC pin 48 */
+ "CSI1_CN", /* GPIO_73, HSEC pin 56 */
+ "CSI1_CP", /* GPIO_74, HSEC pin 54 */
+ "[CLK1]", /* GPIO_75, HSEC pin 17 */
+ "[GPIOD0]", /* GPIO_76 */
+ "[GPIOD1]", /* GPIO_77 */
+ "BT_RST_N", /* GPIO_78 */
+ "EXT_DC_EN", /* GPIO_79 */
+ "[PCM_DI]", /* GPIO_80, LSEC pin 22 */
+ "[PCM_DO]", /* GPIO_81, LSEC pin 20 */
+ "[PCM_CLK]", /* GPIO_82, LSEC pin 18 */
+ "[PCM_FS]", /* GPIO_83, LSEC pin 16 */
+ "WAKE_BT", /* GPIO_84 */
+ "WL_REG_ON", /* GPIO_85 */
+ "NC", /* GPIO_86 */
+ "NC", /* GPIO_87 */
+ "NC", /* GPIO_88 */
+ "NC", /* GPIO_89 */
+ "NC", /* GPIO_90 */
+ "WIFI_WAKE", /* GPIO_91 */
+ "BT_WAKE", /* GPIO_92 */
+ "NC", /* GPIO_93 */
+ "OTG_EN2", /* GPIO_94 */
+ "OTG_EN", /* GPIO_95 */
+ "DSI_DP3", /* GPIO_96, HSEC pin 45 */
+ "DSI_DN3", /* GPIO_97, HSEC pin 47 */
+ "DSI_DP1", /* GPIO_98, HSEC pin 33 */
+ "DSI_DN1", /* GPIO_99, HSEC pin 35 */
+ "DSI_CP", /* GPIO_100, HSEC pin 21 */
+ "DSI_CN", /* GPIO_101, HSEC pin 23 */
+ "DSI_DP0", /* GPIO_102, HSEC pin 27 */
+ "DSI_DN0", /* GPIO_103, HSEC pin 29 */
+ "DSI_DP2", /* GPIO_104, HSEC pin 39 */
+ "DSI_DN2", /* GPIO_105, HSEC pin 41 */
+ "N0_D0", /* GPIO_106 */
+ "N0_D1", /* GPIO_107 */
+ "N0_D2", /* GPIO_108 */
+ "N0_D3", /* GPIO_109 */
+ "N0_D4", /* GPIO_110 */
+ "N0_D5", /* GPIO_111 */
+ "N0_D6", /* GPIO_112 */
+ "N0_D7", /* GPIO_113 */
+ "N0_DQS", /* GPIO_114 */
+ "N0_DQSN", /* GPIO_115 */
+ "NC", /* GPIO_116 */
+ "NC", /* GPIO_117 */
+ "NC", /* GPIO_118 */
+ "N0_CEB1", /* GPIO_119 */
+ "CARD_DT", /* GPIO_120 */
+ "N0_CEB3", /* GPIO_121 */
+ "SD_DAT0", /* GPIO_122, HSEC pin 1 */
+ "SD_DAT1", /* GPIO_123, HSEC pin 3 */
+ "SD_DAT2", /* GPIO_124, HSEC pin 5 */
+ "SD_DAT3", /* GPIO_125, HSEC pin 7 */
+ "NC", /* GPIO_126 */
+ "NC", /* GPIO_127 */
+ "[PWR_BTN_N]", /* GPIO_128, LSEC pin 4 */
+ "[RST_BTN_N]", /* GPIO_129, LSEC pin 6 */
+ "NC", /* GPIO_130 */
+ "SD_CMD", /* GPIO_131 */
+ "GPIO-L", /* GPIO_132, LSEC pin 34 */
+ "GPIO-K", /* GPIO_133, LSEC pin 33 */
+ "NC", /* GPIO_134 */
+ "SD_SCLK", /* GPIO_135 */
+ "NC", /* GPIO_136 */
+ "JTAG_TRST", /* GPIO_137 */
+ "I2C3_SCLK", /* GPIO_138 */
+ "LED2", /* GPIO_139 */
+ "LED3", /* GPIO_140 */
+ "I2C3_SDATA", /* GPIO_141 */
+ "UART3_RX", /* GPIO_142 */
+ "UART3_TX", /* GPIO_143 */
+ "UART3_RTSB", /* GPIO_144 */
+ "UART3_CTSB"; /* GPIO_145 */
+};
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox