Re: [PATCH] power: reset: hisi-reboot: use the correct HiSilicon copyright
On 3/30/21 2:38 PM, Hao Fang wrote: > s/Hisilicon/HiSilicon/g. > It should use capital S, according to > https://www.hisilicon.com/en/terms-of-use. > > Signed-off-by: Hao Fang > --- > drivers/power/reset/hisi-reboot.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/power/reset/hisi-reboot.c > b/drivers/power/reset/hisi-reboot.c > index 0ba5fdc..5abc5f6 100644 > --- a/drivers/power/reset/hisi-reboot.c > +++ b/drivers/power/reset/hisi-reboot.c > @@ -1,8 +1,8 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > - * Hisilicon SoC reset code > + * HiSilicon SoC reset code >* > - * Copyright (c) 2014 Hisilicon Ltd. > + * Copyright (c) 2014 HiSilicon Ltd. >* Copyright (c) 2014 Linaro Ltd. >* >* Author: Haojian Zhuang > Acked-by: Haojian Zhuang
Re: [PATCH] ARM: hisi: use the correct HiSilicon copyright
On 3/30/21 2:51 PM, Hao Fang wrote: > s/Hisilicon/HiSilicon/ > It should use capital S, according to > https://www.hisilicon.com/en/terms-of-use. > > Signed-off-by: Hao Fang > --- > arch/arm/mach-hisi/hisilicon.c | 4 ++-- > arch/arm/mach-hisi/hotplug.c | 2 +- > arch/arm/mach-hisi/platmcpm.c | 2 +- > arch/arm/mach-hisi/platsmp.c | 2 +- > 4 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c > index 07ea28b..b8d14b3 100644 > --- a/arch/arm/mach-hisi/hisilicon.c > +++ b/arch/arm/mach-hisi/hisilicon.c > @@ -1,8 +1,8 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* > - * (Hisilicon's SoC based) flattened device tree enabled machine > + * (HiSilicon's SoC based) flattened device tree enabled machine >* > - * Copyright (c) 2012-2013 Hisilicon Ltd. > + * Copyright (c) 2012-2013 HiSilicon Ltd. > * Copyright (c) 2012-2013 Linaro Ltd. >* >* Author: Haojian Zhuang > diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c > index 5c5f255..c517941 100644 > --- a/arch/arm/mach-hisi/hotplug.c > +++ b/arch/arm/mach-hisi/hotplug.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* >* Copyright (c) 2013 Linaro Ltd. > - * Copyright (c) 2013 Hisilicon Limited. > + * Copyright (c) 2013 HiSilicon Limited. >*/ > > #include > diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c > index f155e32..96a4840 100644 > --- a/arch/arm/mach-hisi/platmcpm.c > +++ b/arch/arm/mach-hisi/platmcpm.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* >* Copyright (c) 2013-2014 Linaro Ltd. > - * Copyright (c) 2013-2014 Hisilicon Limited. > + * Copyright (c) 2013-2014 HiSilicon Limited. >*/ > #include > #include > diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c > index da7a09c..a56cc64 100644 > --- a/arch/arm/mach-hisi/platsmp.c > +++ b/arch/arm/mach-hisi/platsmp.c > @@ -1,7 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0-only > /* >* Copyright (c) 2013 Linaro Ltd. > - * Copyright (c) 2013 Hisilicon Limited. > + * Copyright (c) 2013 HiSilicon Limited. >* Based on arch/arm/mach-vexpress/platsmp.c, Copyright (C) 2002 ARM Ltd. >*/ > #include > Acked-by: Haojian Zhuang
Re: [PATCH v4 0/2] pinctrl: single: support #pinctrl-cells = 2
On Wed, 1 Jul 2020 at 09:33, Drew Fustini wrote: > > Currently, pinctrl-single only allows #pinctrl-cells = 1. > > This series will allow pinctrl-single to also support #pinctrl-cells = 2 > > If "pinctrl-single,pins" has 3 arguments (offset, conf, mux) then > pcs_parse_one_pinctrl_entry() does an OR operation on conf and mux to > get the value to store in the register. > > To take advantage of #pinctrl-cells = 2, the AM33XX_PADCONF macro in > omap.h is modified to keep pin conf and pin mux values separate. > > change log: > - v4: squash patches 2 and 3 together so that git biesct will not result > in a boot failure > > - v3: change order of patches to make sure the pinctrl-single.c patch > does not break anything without the dts patches > > - v2: remove outer parentheses from AM33XX_PADCONF macro as it causes a > compile error in dtc. I had added it per suggestion from checkpatch > about having parentheses around complex values. > > Drew Fustini (2): > pinctrl: single: parse #pinctrl-cells = 2 > ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2 > > arch/arm/boot/dts/am33xx-l4.dtsi | 2 +- > drivers/pinctrl/pinctrl-single.c | 11 +-- > include/dt-bindings/pinctrl/omap.h | 2 +- > 3 files changed, 11 insertions(+), 4 deletions(-) > > -- > 2.25.1 > Acked-by: Haojian Zhuang
Re: [PATCH v2] pinctrl-single: fix pcs_parse_pinconf() return value
*np,
>
> /* If pinconf isn't supported, don't parse properties in below. */
> if (!PCS_HAS_PINCONF)
> - return 0;
> + return -ENOTSUPP;
>
> /* cacluate how much properties are supported in current node */
> for (i = 0; i < ARRAY_SIZE(prop2); i++) {
> @@ -928,7 +928,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
> struct device_node *np,
> nconfs++;
> }
> if (!nconfs)
> - return 0;
> + return -ENOTSUPP;
>
> func->conf = devm_kcalloc(pcs->dev,
> nconfs, sizeof(struct pcs_conf_vals),
> @@ -1056,9 +1056,12 @@ static int pcs_parse_one_pinctrl_entry(struct
> pcs_device *pcs,
>
> if (PCS_HAS_PINCONF && function) {
> res = pcs_parse_pinconf(pcs, np, function, map);
> - if (res)
> + if (res == 0)
> + *num_maps = 2;
> + else if (res == -ENOTSUPP)
> + *num_maps = 1;
> + else
> goto free_pingroups;
> - *num_maps = 2;
> } else {
> *num_maps = 1;
> }
> --
> 2.25.1
Tested-by: Haojian Zhuang
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 16:37 +0100, Leif Lindholm wrote: > On Tue, Aug 25, 2015 at 04:51:22PM +0200, Ard Biesheuvel wrote: > > >>Arm kernel should either fetch memory information from > > >>efi or DT. > > > > > > Absolutely. > > > > > >>Currently arm kernel fetch both efi memory information and > > >>reserved buffer from DTB at the same time. > > > > > > No, it does not. > > > > It should not, but it does. Due to an oversight, the stub removes > > /memreserve/ entries but ignores the reserved-memory node completely. > > Urgh. > > > This was reported here in fact > > > > http://thread.gmane.org/gmane.linux.kernel.efi/5736/focus=5742 > > > > but there has not been a followup to this series. > > Are all of those patches still relevant, or did some of them go in > already? > > Haojian: can you give that patch a spin and see if it does what you > need, combined with adding the reserved areas to the UEFI memory map? > > / > Leif It's so nice. This patch is what I need. Thanks Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
> On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
> > On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
> > > > > Are you then going to hack GRUB, release a special HiKey version of
> > > > > GRUB, not support any other versions, and still can your firmware
> > > > > UEFI?
> > > >
> > > > I don't need to hack GRUB at all.
> > >
> > > Then it is working for you by pure chance alone.
> > >
> > > Please listen to the advice you are being given here; we're trying to
> > > ensure that your platform functions (and continues to function) as best
> > > it can.
> >
> > Since we discussed a lot on this, let's make a conclusion on it.
> >
> > 1. UEFI could append the reserved buffer in it's memory mapping.
> > 2. These reserved buffer must be declared in DT, since we also need to
> >support non-UEFI (uboot) at the same time.
> > 3. Mailbox node should reference reserved buffer by phandle in DT. Then
> >map the buffer as non-cacheable in driver.
> > 4. These reserved buffer must use "no-map" property since it should be
> >non-cacheable in driver.
>
> For more specific discussion for DTS, i list two options at here;
>
> - Option 1: just simply reserve memory regions through memory node,
> and mailbox node will directly use the buffer through reg ranges;
>
> - Option 2: use reserved-memory and mailbox node will refer phandle
> of reserved-memory;
>
> These two options both can work well with UEFI and Uboot, but option 1
> is more simple and straightforward; so i personally prefer it. But
> look forwarding your guys' suggestion.
>
> Option 1:
>
> memory@0 {
> device_type = "memory";
> reg = <0x 0x 0x 0x05e0>,
> <0x 0x05f0 0x 0x00eff000>,
> <0x 0x06e0 0x 0x0060f000>,
> <0x 0x0741 0x 0x38bf>;
> };
>
> [...]
>
> mailbox: mailbox@f751 {
> #mbox-cells = <1>;
> compatible = "hisilicon,hi6220-mbox";
> reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
> <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
> interrupts = ;
> };
>
> Option 2:
>
> memory@0 {
> device_type = "memory";
> reg = <0x0 0x0 0x0 0x4000>;
> };
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> mcu_reserved: mcu_reserved@06dff000 {
> no-map;
> reg = <0x0 0x06dff000 0x0 0x1000>, /* MCU mailbox
> buffer */
> <0x0 0x05e0 0x0 0x0010>, /* MCU firmware
> buffer */
> <0x0 0x0740f000 0x0 0x1000>; /* MCU firmware
> section */
> };
> };
>
> [...]
>
> mailbox: mailbox@f751 {
> #mbox-cells = <1>;
> compatible = "hisilicon,hi6220-mbox";
> reg = <0x0 0xf751 0x0 0x1000>; /* IPC_S */
> memory-region = <_reserved>; /* Mailbox buffer */
> interrupts = ;
> };
I prefer the second one. From my view, memory node should only describe
the hardware information of memory.
Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote: > > > Are you then going to hack GRUB, release a special HiKey version of > > > GRUB, not support any other versions, and still can your firmware > > > UEFI? > > > > I don't need to hack GRUB at all. > > Then it is working for you by pure chance alone. > > Please listen to the advice you are being given here; we're trying to > ensure that your platform functions (and continues to function) as best > it can. Since we discussed a lot on this, let's make a conclusion on it. 1. UEFI could append the reserved buffer in it's memory mapping. 2. These reserved buffer must be declared in DT, since we also need to support non-UEFI (uboot) at the same time. 3. Mailbox node should reference reserved buffer by phandle in DT. Then map the buffer as non-cacheable in driver. 4. These reserved buffer must use "no-map" property since it should be non-cacheable in driver. 5. A patch is necessary in kernel. If efi stub feature is enabled, arm kernel should not parse memory node or reserved memory buffer in DT any more. Arm kernel should either fetch memory information from efi or DT. Currently arm kernel fetch both efi memory information and reserved buffer from DTB at the same time. Do you agree on these points? Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 10:46 +0100, Leif Lindholm wrote: > On Tue, Aug 25, 2015 at 04:13:47PM +0800, Haojian Zhuang wrote: > > On Mon, 2015-08-24 at 12:49 +0100, Leif Lindholm wrote: > > > On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote: > > > > > If your EFI memory map describes the memory as mappable, it is wrong. > > > > > > > > When kernel is working, kernel will create its own page table based on > > > > UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll > > > > be moved to reserved memblock. Why is it wrong? > > > > > > > > In the second, UEFI is firmware. When it's stable, nobody should change > > > > it without any reason. > > > > > > Much like the memory map. > > > > > > > These reserved memory are used in mailbox driver. > > > > Look. It's driver, so it could be changed at any time. > > > > > > No, it is a set of regions of memory set aside for use by a different > > > master in the system as well as communications with that master. > > > > > > The fact that there is a driver somewhere that is aware of this is > > > entirely beside the point. All agents in the system must adher to this > > > protocol. > > > > > > > Why do you want > > > > to UEFI knowing this memory range? Do you hope UEFI to change when > > > > mailbox driver is changed? > > > > > > Yes. > > > > > > UEFI is a runtime environment. Having random magic areas not to be > > > touched will cause random pieces of software running under it to break > > > horribly or break other things horribly. > > > Unless you mark them as reserved in the UEFI memory map. > > > At which point the Linux kernel will automatically ignore them, and > > > the proposed patch is redundant. > > > > > > So, yes, if you want a system that can boot reliably, run testsuites > > > (like SCT or FWTS), run applications (like fastboot ... or the EFI > > > stub kernel itself), then any memory regions that is reserved for > > > mailbox communication (or other masters in the system) _must_ be > > > marked in the EFI memory map. > > > > 1. We need support both UEFI and uboot. So the reserved buffer have to > > be declared in DTB since they are used by kernel driver, not UEFI. > > The buffer may need to be declared in DTB also, but it most certanily > needs to be declared in UEFI. > > And for the U-Boot case, since it is not memory available to Linux, it > should not be declared as "memory". Something are messed at here. We have these buffer are used in mailbox. They should be allocated as non-cacheable. If these buffers are contained in memory memblock in kernel, it means that they exist in kernel page table with cachable property. When it's used in mailbox driver with non-cachable property, it'll only cause cache maintenance issue. So Leo declared these buffers as reserved in DT with "no-map" property. It's the key. It could avoid the cache maintenance issue. > > > 2. UEFI just loads grub. It's no time to run any other custom EFI > > application. > > Apart from being completely irrelevant, how are you intending to > validate that GRUB never touches these memory regions? > GRUB is just a part of bootloader. When linux kernel is running, who cares GRUB? GRUB's lifetime is already finished. By the way, UEFI code region is at [0x3Dxx_, 0x3DFF_]. Those mailbox buffer is in [0x05e0_, 0x06f0_]. Then I can make sure UEFI won't touch the reserved buffer. Even if UEFI touched the reserved buffer, is it an issue? Definitely it's not. UEFI's lifetime is end when linux kernel is running at hikey. Even if UEFI runtime service is enabled, the runtime data area is at [0x38xx_, 0x38xx_]. > Build a version once, test it, and hope the results remain valid > forever? And then when you move the regions and the previously working > GRUB now tramples all over them? Or when something changes in upstream > GRUB and its memory allocations drifts into the secretly untouchable > regions? As I said above, UEFI won't touch it. And even UEFI touch it, kernel doesn't care since UEFI's lifetime is end. > > Are you then going to hack GRUB, release a special HiKey version of > GRUB, not support any other versions, and still can your firmware > UEFI? I don't need to hack GRUB at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 12:49 +0100, Leif Lindholm wrote: > On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote: > > > If your EFI memory map describes the memory as mappable, it is wrong. > > > > When kernel is working, kernel will create its own page table based on > > UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll > > be moved to reserved memblock. Why is it wrong? > > > > In the second, UEFI is firmware. When it's stable, nobody should change > > it without any reason. > > Much like the memory map. > > > These reserved memory are used in mailbox driver. > > Look. It's driver, so it could be changed at any time. > > No, it is a set of regions of memory set aside for use by a different > master in the system as well as communications with that master. > > The fact that there is a driver somewhere that is aware of this is > entirely beside the point. All agents in the system must adher to this > protocol. > > > Why do you want > > to UEFI knowing this memory range? Do you hope UEFI to change when > > mailbox driver is changed? > > Yes. > > UEFI is a runtime environment. Having random magic areas not to be > touched will cause random pieces of software running under it to break > horribly or break other things horribly. > Unless you mark them as reserved in the UEFI memory map. > At which point the Linux kernel will automatically ignore them, and > the proposed patch is redundant. > > So, yes, if you want a system that can boot reliably, run testsuites > (like SCT or FWTS), run applications (like fastboot ... or the EFI > stub kernel itself), then any memory regions that is reserved for > mailbox communication (or other masters in the system) _must_ be > marked in the EFI memory map. 1. We need support both UEFI and uboot. So the reserved buffer have to be declared in DTB since they are used by kernel driver, not UEFI. 2. UEFI just loads grub. It's no time to run any other custom EFI application. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 13:48 +0100, Mark Rutland wrote: > > > > > I don't see why you need reserved-memory here, given you're not > > > > > referring to > > > > > these regions by phandle anyway. > > > > > > > > - Now we have enabled EFI_STUB, so the memory node will be removed in > > > > kernel: > > > > efi_entry() > > > > \-> allocate_new_fdt_and_exit_boot() > > > > \-> update_fdt(); > > > > > > > > Finally in kernel it cannot use memory node to carve out reseved > > > > memory regions. > > > > > > > > - On the other hand, DTS's the memory node is to "describes the > > > > physical memory layout for the system"; so it's better to use it only > > > > to describe the hardware info for memory. We can use reserved-memory > > > > to help manage the memory regions which are reserved from software > > > > perspective. > > > > > > The fact that you have no-map means that the memory should not be > > > described to the kernel as mappable in the first place. It's wrong to > > > place such memory in the memory node, even if listed in reserved-memory. > > > > > > If your EFI memory map describes the memory as mappable, it is wrong. > > > > When kernel is working, kernel will create its own page table based on > > UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll > > be moved to reserved memblock. Why is it wrong? > > That is a _Linux_ detail, not a _UEFI_ detail. > > Anything which only handles UEFI and knows nothing of reserved-memory > (e.g. GRUB) will be broken and/or break the Linux use of the region, as > it will happily try to allocate memory in the region (and could even > decide to reserve it permanently for its own usage). > > If the memory is truly specific to the mailbox, then UEFI needs to know > that it is reserved as such. If it is not, then it need not be described > in the DT and can be allocated dynamically by the kernel. No. We support both UEFI and uboot on hikey. We must reserve these mailbox buffer in DT. Otherwise, it's a problem to support uboot. We should only deliver one kernel and one DTB to support both UEFI and uboot. And mailbox driver is already upgraded from beginning. Nobody can say that it won't be upgraded again in the future. By the way, UEFI is loaded in the upper memory region of hikey. It won't break anything in linux kernel. > > > In the second, UEFI is firmware. When it's stable, nobody should change > > it without any reason. These reserved memory are used in mailbox driver. > > Look. It's driver, so it could be changed at any time. Why do you want > > to UEFI knowing this memory range? Do you hope UEFI to change when > > mailbox driver is changed? > > It shouldn't need to change if that memory is truly reserved for the > sole use of the mailbox. If that's not the case then we have a different > issue. > > If the memory range to use can be allocated by the driver, then I don't > see why it should be described in reserved-memory. It certainly should > not require a no-map attribute. > > Additionally, the driver needs to ensure that the requisite cache > maintenance takes place prior to the use of the memory region given > prior agents may have ampped it as cacheable, leaving stale (perhaps > dirty) lines in the caches. > Since those mailbox buffer is declared as reserved with "no-map" property, it means that linux kernel won't create the page table of them. The meaning of "no-map" is removing it from memory memblock. setup_arch() | ---> efi_init() -- Get memory map information from UEFI | ---> arm64_memblock_init() | | | ---> early_init_fdt_scan_reserved_mem() | Get reserved memory buffer from DT. Split memory | memblock according to reserved buffer. ---> paging_init() |--> map_mem() _Only_ map the discrete memory memblock into kernel page table. >From this working flow, we could know that those mailbox buffers won't be mapped into kernel page table. So there's no concern on cache maintenance. > > > > According to upper info, we still need to use reserved-memory node to > > > > depict the reserved memory regions. i have no knowledge about EFI_STUB, > > > > so please confirm or correct as needed. > > > > > > If the memory shouldn't be mapped, it should neither be in the memory > > > node nor EFI memory map (with attributes allowing it to be mapped) to > > > begin with. > > > > As I said above, kernel will create its own page table. When kernel's > > page table is working, UEFI's page table is destroying. So the memory > > won't be mapped twice at the same time. What's wrong? > > > > > > As far as I can see you do not need to use reserved-memory. > > > > 1. Are we talking on the same thing? Leo already mentioned that all > > memory node in DTB will be destroyed by kernel when EFI_STUB is enabled > > on arm. Did you read the source code after his reply? > > And you suggested that Leo to use discrete
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 16:37 +0100, Leif Lindholm wrote: On Tue, Aug 25, 2015 at 04:51:22PM +0200, Ard Biesheuvel wrote: Arm kernel should either fetch memory information from efi or DT. Absolutely. Currently arm kernel fetch both efi memory information and reserved buffer from DTB at the same time. No, it does not. It should not, but it does. Due to an oversight, the stub removes /memreserve/ entries but ignores the reserved-memory node completely. Urgh. This was reported here in fact http://thread.gmane.org/gmane.linux.kernel.efi/5736/focus=5742 but there has not been a followup to this series. Are all of those patches still relevant, or did some of them go in already? Haojian: can you give that patch a spin and see if it does what you need, combined with adding the reserved areas to the UEFI memory map? / Leif It's so nice. This patch is what I need. Thanks Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 12:49 +0100, Leif Lindholm wrote: On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote: If your EFI memory map describes the memory as mappable, it is wrong. When kernel is working, kernel will create its own page table based on UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll be moved to reserved memblock. Why is it wrong? In the second, UEFI is firmware. When it's stable, nobody should change it without any reason. Much like the memory map. These reserved memory are used in mailbox driver. Look. It's driver, so it could be changed at any time. No, it is a set of regions of memory set aside for use by a different master in the system as well as communications with that master. The fact that there is a driver somewhere that is aware of this is entirely beside the point. All agents in the system must adher to this protocol. Why do you want to UEFI knowing this memory range? Do you hope UEFI to change when mailbox driver is changed? Yes. UEFI is a runtime environment. Having random magic areas not to be touched will cause random pieces of software running under it to break horribly or break other things horribly. Unless you mark them as reserved in the UEFI memory map. At which point the Linux kernel will automatically ignore them, and the proposed patch is redundant. So, yes, if you want a system that can boot reliably, run testsuites (like SCT or FWTS), run applications (like fastboot ... or the EFI stub kernel itself), then any memory regions that is reserved for mailbox communication (or other masters in the system) _must_ be marked in the EFI memory map. 1. We need support both UEFI and uboot. So the reserved buffer have to be declared in DTB since they are used by kernel driver, not UEFI. 2. UEFI just loads grub. It's no time to run any other custom EFI application. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 13:48 +0100, Mark Rutland wrote: I don't see why you need reserved-memory here, given you're not referring to these regions by phandle anyway. - Now we have enabled EFI_STUB, so the memory node will be removed in kernel: efi_entry() \- allocate_new_fdt_and_exit_boot() \- update_fdt(); Finally in kernel it cannot use memory node to carve out reseved memory regions. - On the other hand, DTS's the memory node is to describes the physical memory layout for the system; so it's better to use it only to describe the hardware info for memory. We can use reserved-memory to help manage the memory regions which are reserved from software perspective. The fact that you have no-map means that the memory should not be described to the kernel as mappable in the first place. It's wrong to place such memory in the memory node, even if listed in reserved-memory. If your EFI memory map describes the memory as mappable, it is wrong. When kernel is working, kernel will create its own page table based on UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll be moved to reserved memblock. Why is it wrong? That is a _Linux_ detail, not a _UEFI_ detail. Anything which only handles UEFI and knows nothing of reserved-memory (e.g. GRUB) will be broken and/or break the Linux use of the region, as it will happily try to allocate memory in the region (and could even decide to reserve it permanently for its own usage). If the memory is truly specific to the mailbox, then UEFI needs to know that it is reserved as such. If it is not, then it need not be described in the DT and can be allocated dynamically by the kernel. No. We support both UEFI and uboot on hikey. We must reserve these mailbox buffer in DT. Otherwise, it's a problem to support uboot. We should only deliver one kernel and one DTB to support both UEFI and uboot. And mailbox driver is already upgraded from beginning. Nobody can say that it won't be upgraded again in the future. By the way, UEFI is loaded in the upper memory region of hikey. It won't break anything in linux kernel. In the second, UEFI is firmware. When it's stable, nobody should change it without any reason. These reserved memory are used in mailbox driver. Look. It's driver, so it could be changed at any time. Why do you want to UEFI knowing this memory range? Do you hope UEFI to change when mailbox driver is changed? It shouldn't need to change if that memory is truly reserved for the sole use of the mailbox. If that's not the case then we have a different issue. If the memory range to use can be allocated by the driver, then I don't see why it should be described in reserved-memory. It certainly should not require a no-map attribute. Additionally, the driver needs to ensure that the requisite cache maintenance takes place prior to the use of the memory region given prior agents may have ampped it as cacheable, leaving stale (perhaps dirty) lines in the caches. Since those mailbox buffer is declared as reserved with no-map property, it means that linux kernel won't create the page table of them. The meaning of no-map is removing it from memory memblock. setup_arch() | --- efi_init() -- Get memory map information from UEFI | --- arm64_memblock_init() | | | --- early_init_fdt_scan_reserved_mem() | Get reserved memory buffer from DT. Split memory | memblock according to reserved buffer. --- paging_init() |-- map_mem() _Only_ map the discrete memory memblock into kernel page table. From this working flow, we could know that those mailbox buffers won't be mapped into kernel page table. So there's no concern on cache maintenance. According to upper info, we still need to use reserved-memory node to depict the reserved memory regions. i have no knowledge about EFI_STUB, so please confirm or correct as needed. If the memory shouldn't be mapped, it should neither be in the memory node nor EFI memory map (with attributes allowing it to be mapped) to begin with. As I said above, kernel will create its own page table. When kernel's page table is working, UEFI's page table is destroying. So the memory won't be mapped twice at the same time. What's wrong? As far as I can see you do not need to use reserved-memory. 1. Are we talking on the same thing? Leo already mentioned that all memory node in DTB will be destroyed by kernel when EFI_STUB is enabled on arm. Did you read the source code after his reply? And you suggested that Leo to use discrete memory region in DTB. It is really wrong. Kernel only gets memory map information from UEFI, not DTB. I did _not_ suggest that Leo use discrete memory. I suggested that reserved regions should
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 10:46 +0100, Leif Lindholm wrote: On Tue, Aug 25, 2015 at 04:13:47PM +0800, Haojian Zhuang wrote: On Mon, 2015-08-24 at 12:49 +0100, Leif Lindholm wrote: On Mon, Aug 24, 2015 at 06:19:56PM +0800, Haojian Zhuang wrote: If your EFI memory map describes the memory as mappable, it is wrong. When kernel is working, kernel will create its own page table based on UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll be moved to reserved memblock. Why is it wrong? In the second, UEFI is firmware. When it's stable, nobody should change it without any reason. Much like the memory map. These reserved memory are used in mailbox driver. Look. It's driver, so it could be changed at any time. No, it is a set of regions of memory set aside for use by a different master in the system as well as communications with that master. The fact that there is a driver somewhere that is aware of this is entirely beside the point. All agents in the system must adher to this protocol. Why do you want to UEFI knowing this memory range? Do you hope UEFI to change when mailbox driver is changed? Yes. UEFI is a runtime environment. Having random magic areas not to be touched will cause random pieces of software running under it to break horribly or break other things horribly. Unless you mark them as reserved in the UEFI memory map. At which point the Linux kernel will automatically ignore them, and the proposed patch is redundant. So, yes, if you want a system that can boot reliably, run testsuites (like SCT or FWTS), run applications (like fastboot ... or the EFI stub kernel itself), then any memory regions that is reserved for mailbox communication (or other masters in the system) _must_ be marked in the EFI memory map. 1. We need support both UEFI and uboot. So the reserved buffer have to be declared in DTB since they are used by kernel driver, not UEFI. The buffer may need to be declared in DTB also, but it most certanily needs to be declared in UEFI. And for the U-Boot case, since it is not memory available to Linux, it should not be declared as memory. Something are messed at here. We have these buffer are used in mailbox. They should be allocated as non-cacheable. If these buffers are contained in memory memblock in kernel, it means that they exist in kernel page table with cachable property. When it's used in mailbox driver with non-cachable property, it'll only cause cache maintenance issue. So Leo declared these buffers as reserved in DT with no-map property. It's the key. It could avoid the cache maintenance issue. 2. UEFI just loads grub. It's no time to run any other custom EFI application. Apart from being completely irrelevant, how are you intending to validate that GRUB never touches these memory regions? GRUB is just a part of bootloader. When linux kernel is running, who cares GRUB? GRUB's lifetime is already finished. By the way, UEFI code region is at [0x3Dxx_, 0x3DFF_]. Those mailbox buffer is in [0x05e0_, 0x06f0_]. Then I can make sure UEFI won't touch the reserved buffer. Even if UEFI touched the reserved buffer, is it an issue? Definitely it's not. UEFI's lifetime is end when linux kernel is running at hikey. Even if UEFI runtime service is enabled, the runtime data area is at [0x38xx_, 0x38xx_]. Build a version once, test it, and hope the results remain valid forever? And then when you move the regions and the previously working GRUB now tramples all over them? Or when something changes in upstream GRUB and its memory allocations drifts into the secretly untouchable regions? As I said above, UEFI won't touch it. And even UEFI touch it, kernel doesn't care since UEFI's lifetime is end. Are you then going to hack GRUB, release a special HiKey version of GRUB, not support any other versions, and still can your firmware UEFI? I don't need to hack GRUB at all. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote: Are you then going to hack GRUB, release a special HiKey version of GRUB, not support any other versions, and still can your firmware UEFI? I don't need to hack GRUB at all. Then it is working for you by pure chance alone. Please listen to the advice you are being given here; we're trying to ensure that your platform functions (and continues to function) as best it can. Since we discussed a lot on this, let's make a conclusion on it. 1. UEFI could append the reserved buffer in it's memory mapping. 2. These reserved buffer must be declared in DT, since we also need to support non-UEFI (uboot) at the same time. 3. Mailbox node should reference reserved buffer by phandle in DT. Then map the buffer as non-cacheable in driver. 4. These reserved buffer must use no-map property since it should be non-cacheable in driver. 5. A patch is necessary in kernel. If efi stub feature is enabled, arm kernel should not parse memory node or reserved memory buffer in DT any more. Arm kernel should either fetch memory information from efi or DT. Currently arm kernel fetch both efi memory information and reserved buffer from DTB at the same time. Do you agree on these points? Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Wed, 2015-08-26 at 00:00 +0800, Leo Yan wrote:
On Tue, Aug 25, 2015 at 09:43:14PM +0800, Haojian Zhuang wrote:
On Tue, 2015-08-25 at 11:42 +0100, Mark Rutland wrote:
Are you then going to hack GRUB, release a special HiKey version of
GRUB, not support any other versions, and still can your firmware
UEFI?
I don't need to hack GRUB at all.
Then it is working for you by pure chance alone.
Please listen to the advice you are being given here; we're trying to
ensure that your platform functions (and continues to function) as best
it can.
Since we discussed a lot on this, let's make a conclusion on it.
1. UEFI could append the reserved buffer in it's memory mapping.
2. These reserved buffer must be declared in DT, since we also need to
support non-UEFI (uboot) at the same time.
3. Mailbox node should reference reserved buffer by phandle in DT. Then
map the buffer as non-cacheable in driver.
4. These reserved buffer must use no-map property since it should be
non-cacheable in driver.
For more specific discussion for DTS, i list two options at here;
- Option 1: just simply reserve memory regions through memory node,
and mailbox node will directly use the buffer through reg ranges;
- Option 2: use reserved-memory and mailbox node will refer phandle
of reserved-memory;
These two options both can work well with UEFI and Uboot, but option 1
is more simple and straightforward; so i personally prefer it. But
look forwarding your guys' suggestion.
Option 1:
memory@0 {
device_type = memory;
reg = 0x 0x 0x 0x05e0,
0x 0x05f0 0x 0x00eff000,
0x 0x06e0 0x 0x0060f000,
0x 0x0741 0x 0x38bf;
};
[...]
mailbox: mailbox@f751 {
#mbox-cells = 1;
compatible = hisilicon,hi6220-mbox;
reg = 0x0 0xf751 0x0 0x1000, /* IPC_S */
0x0 0x06dff800 0x0 0x0800; /* Mailbox buffer */
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
};
Option 2:
memory@0 {
device_type = memory;
reg = 0x0 0x0 0x0 0x4000;
};
reserved-memory {
#address-cells = 2;
#size-cells = 2;
ranges;
mcu_reserved: mcu_reserved@06dff000 {
no-map;
reg = 0x0 0x06dff000 0x0 0x1000, /* MCU mailbox
buffer */
0x0 0x05e0 0x0 0x0010, /* MCU firmware
buffer */
0x0 0x0740f000 0x0 0x1000; /* MCU firmware
section */
};
};
[...]
mailbox: mailbox@f751 {
#mbox-cells = 1;
compatible = hisilicon,hi6220-mbox;
reg = 0x0 0xf751 0x0 0x1000; /* IPC_S */
memory-region = mcu_reserved; /* Mailbox buffer */
interrupts = GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH;
};
I prefer the second one. From my view, memory node should only describe
the hardware information of memory.
Regards
Haojian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 10:51 +0100, Mark Rutland wrote:
> On Mon, Aug 24, 2015 at 10:18:45AM +0100, Leo Yan wrote:
> > Hi Mark,
> >
> > On Fri, Aug 21, 2015 at 07:40:59PM +0100, Mark Rutland wrote:
> > > On Wed, Aug 19, 2015 at 10:37:35AM +0100, Leo Yan wrote:
> > > > On Hi6220, below memory regions in DDR have specific purpose:
> > > >
> > > > 0x05e0, - 0x05ef,: For MCU firmware using at runtime;
> > > > 0x0740,f000 - 0x0740,: For MCU firmware's section;
> > > > 0x06df,f000 - 0x06df,: For mailbox message data.
> > > >
> > > > This patch reserves these memory regions and add device node for
> > > > mailbox in dts.
> > > >
> > > > Signed-off-by: Leo Yan
> > > > ---
> > > > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20
> > > > +---
> > > > arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8
> > > > 2 files changed, 25 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > > > b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > > > index e36a539..d5470d3 100644
> > > > --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > > > +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> > > > @@ -7,9 +7,6 @@
> > > >
> > > > /dts-v1/;
> > > >
> > > > -/*Reserved 1MB memory for MCU*/
> > > > -/memreserve/ 0x05e0 0x0010;
> > > > -
> > > > #include "hi6220.dtsi"
> > > >
> > > > / {
> > > > @@ -28,4 +25,21 @@
> > > > device_type = "memory";
> > > > reg = <0x0 0x0 0x0 0x4000>;
> > > > };
> > > > +
> > > > + reserved-memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + ranges;
> > > > +
> > > > + mcu-buf@05e0 {
> > > > + no-map;
> > > > + reg = <0x0 0x05e0 0x0 0x0010>, /* MCU
> > > > firmware buffer */
> > > > + <0x0 0x0740f000 0x0 0x1000>; /* MCU
> > > > firmware section */
> > > > + };
> > > > +
> > > > + mbox-buf@06dff000 {
> > > > + no-map;
> > > > + reg = <0x0 0x06dff000 0x0 0x1000>; /*
> > > > Mailbox message buf */
> > > > + };
> > > > + };
> > >
> > > As far as I can see, it would be simpler to simply carve these out of the
> > > memory node.
> > >
> > > I don't see why you need reserved-memory here, given you're not referring
> > > to
> > > these regions by phandle anyway.
> >
> > - Now we have enabled EFI_STUB, so the memory node will be removed in
> > kernel:
> > efi_entry()
> > \-> allocate_new_fdt_and_exit_boot()
> > \-> update_fdt();
> >
> > Finally in kernel it cannot use memory node to carve out reseved
> > memory regions.
> >
> > - On the other hand, DTS's the memory node is to "describes the
> > physical memory layout for the system"; so it's better to use it only
> > to describe the hardware info for memory. We can use reserved-memory
> > to help manage the memory regions which are reserved from software
> > perspective.
>
> The fact that you have no-map means that the memory should not be
> described to the kernel as mappable in the first place. It's wrong to
> place such memory in the memory node, even if listed in reserved-memory.
>
> If your EFI memory map describes the memory as mappable, it is wrong.
When kernel is working, kernel will create its own page table based on
UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll
be moved to reserved memblock. Why is it wrong?
In the second, UEFI is firmware. When it's stable, nobody should change
it without any reason. These reserved memory are used in mailbox driver.
Look. It's driver, so it could be changed at any time. Why do you want
to UEFI knowing this memory range? Do you hope UEFI to change when
mailbox driver is changed?
>
> > According to upper info, we still need to use reserved-memory node to
> > depict the reserved memory regions. i have no knowledge about EFI_STUB,
> > so please confirm or correct as needed.
>
> If the memory shouldn't be mapped, it should neither be in the memory
> node nor EFI memory map (with attributes allowing it to be mapped) to
> begin with.
As I said above, kernel will create its own page table. When kernel's
page table is working, UEFI's page table is destroying. So the memory
won't be mapped twice at the same time. What's wrong?
>
> As far as I can see you do not need to use reserved-memory.
1. Are we talking on the same thing? Leo already mentioned that all
memory node in DTB will be destroyed by kernel when EFI_STUB is enabled
on arm. Did you read the source code after his reply?
And you suggested that Leo to use discrete memory region in DTB. It is
really wrong. Kernel only gets memory map information from UEFI, not
DTB.
2. The working flow is in below.
a. Kernel gets memory map
Re: [PATCH v1 3/3] arm64: dts: add Hi6220 mailbox node
On Mon, 2015-08-24 at 10:51 +0100, Mark Rutland wrote:
On Mon, Aug 24, 2015 at 10:18:45AM +0100, Leo Yan wrote:
Hi Mark,
On Fri, Aug 21, 2015 at 07:40:59PM +0100, Mark Rutland wrote:
On Wed, Aug 19, 2015 at 10:37:35AM +0100, Leo Yan wrote:
On Hi6220, below memory regions in DDR have specific purpose:
0x05e0, - 0x05ef,: For MCU firmware using at runtime;
0x0740,f000 - 0x0740,: For MCU firmware's section;
0x06df,f000 - 0x06df,: For mailbox message data.
This patch reserves these memory regions and add device node for
mailbox in dts.
Signed-off-by: Leo Yan leo@linaro.org
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20
+---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..d5470d3 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -7,9 +7,6 @@
/dts-v1/;
-/*Reserved 1MB memory for MCU*/
-/memreserve/ 0x05e0 0x0010;
-
#include hi6220.dtsi
/ {
@@ -28,4 +25,21 @@
device_type = memory;
reg = 0x0 0x0 0x0 0x4000;
};
+
+ reserved-memory {
+ #address-cells = 2;
+ #size-cells = 2;
+ ranges;
+
+ mcu-buf@05e0 {
+ no-map;
+ reg = 0x0 0x05e0 0x0 0x0010, /* MCU
firmware buffer */
+ 0x0 0x0740f000 0x0 0x1000; /* MCU
firmware section */
+ };
+
+ mbox-buf@06dff000 {
+ no-map;
+ reg = 0x0 0x06dff000 0x0 0x1000; /*
Mailbox message buf */
+ };
+ };
As far as I can see, it would be simpler to simply carve these out of the
memory node.
I don't see why you need reserved-memory here, given you're not referring
to
these regions by phandle anyway.
- Now we have enabled EFI_STUB, so the memory node will be removed in
kernel:
efi_entry()
\- allocate_new_fdt_and_exit_boot()
\- update_fdt();
Finally in kernel it cannot use memory node to carve out reseved
memory regions.
- On the other hand, DTS's the memory node is to describes the
physical memory layout for the system; so it's better to use it only
to describe the hardware info for memory. We can use reserved-memory
to help manage the memory regions which are reserved from software
perspective.
The fact that you have no-map means that the memory should not be
described to the kernel as mappable in the first place. It's wrong to
place such memory in the memory node, even if listed in reserved-memory.
If your EFI memory map describes the memory as mappable, it is wrong.
When kernel is working, kernel will create its own page table based on
UEFI memory map. Since it's reserved in DTS file as Leo's patch, it'll
be moved to reserved memblock. Why is it wrong?
In the second, UEFI is firmware. When it's stable, nobody should change
it without any reason. These reserved memory are used in mailbox driver.
Look. It's driver, so it could be changed at any time. Why do you want
to UEFI knowing this memory range? Do you hope UEFI to change when
mailbox driver is changed?
According to upper info, we still need to use reserved-memory node to
depict the reserved memory regions. i have no knowledge about EFI_STUB,
so please confirm or correct as needed.
If the memory shouldn't be mapped, it should neither be in the memory
node nor EFI memory map (with attributes allowing it to be mapped) to
begin with.
As I said above, kernel will create its own page table. When kernel's
page table is working, UEFI's page table is destroying. So the memory
won't be mapped twice at the same time. What's wrong?
As far as I can see you do not need to use reserved-memory.
1. Are we talking on the same thing? Leo already mentioned that all
memory node in DTB will be destroyed by kernel when EFI_STUB is enabled
on arm. Did you read the source code after his reply?
And you suggested that Leo to use discrete memory region in DTB. It is
really wrong. Kernel only gets memory map information from UEFI, not
DTB.
2. The working flow is in below.
a. Kernel gets memory map information from UEFI.
b. Kernel loads the memory reserved information from DTB.
3. Do you mean the reserved-memory is totally wrong? If it's wrong,
please submit patches to remove all reserved-memory in linux kernel
first.
4. Again and again. Memory node should be only used to describe the
RAM
Re: [PATCH v4 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC
On 5 May 2015 at 20:06, Bintian Wang wrote: > Hi6220 is one mobile solution of Hisilicon, this patchset contains > initial support for Hi6220 SoC and HiKey development board, which > supports octal ARM Cortex A53 cores. Initial support is minimal and > includes just the arch configuration, clock driver, device tree > configuration. > > PSCI is enabled in device tree and there is no problem to boot all the > octal cores, and the CPU hotplug is also working now, you can download > and compile the latest firmware based on the following link to run this > patch set: > https://github.com/96boards/documentation/wiki/UEFI > > Changes v4: > * Rebase to kernel 4.1-rc1 > * Delete "arm,cortex-a15-gic" from the gic node in dts > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC
On 5 May 2015 at 12:30, Bintian Wang wrote: > Hi6220 is one mobile solution of Hisilicon, this patchset contains > initial support for Hi6220 SoC and HiKey development board, which > supports octal ARM Cortex A53 cores. Initial support is minimal and > includes just the arch configuration, clock driver, device tree > configuration. > > PSCI is enabled in device tree and there is no problem to boot all the > octal cores, and the CPU hotplug is also working now, you can download > and compile the latest firmware based on the following link to run this > patch set: > https://github.com/96boards/documentation/wiki/UEFI > > Changes v3: > * Verified the CPU hotplug based on the new released firmware > * Redefined the compatible strings of four system controllers in dts > * Setting COMMON_CLK_HI6220 to a bool symbol > * Keep CONFGI_ARCH_HISI sorted alphabetically > > Changes v2: > * Split the DT bindings documents into earlier patches > * Change SMP enable method from spin-table to PSCI in device tree > * Remove "clock-frequency" from armv8-timer device node in device tree > * Add more description about Hisilicon designed system controllers > in DT bindings document > * Enable high speed clock on UART1 mux > * Other changes based on the discussion in the mailing list: > https://lkml.org/lkml/2015/2/5/147 > > Bintian Wang (5): > arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig > arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC > clk: hi6220: Document devicetree bindings for hi6220 clock > clk: hi6220: Clock driver support for Hisilicon hi6220 SoC > arm64: dts: Add dts files for Hisilicon Hi6220 SoC > > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC
On 5 May 2015 at 20:06, Bintian Wang bintian.w...@huawei.com wrote: Hi6220 is one mobile solution of Hisilicon, this patchset contains initial support for Hi6220 SoC and HiKey development board, which supports octal ARM Cortex A53 cores. Initial support is minimal and includes just the arch configuration, clock driver, device tree configuration. PSCI is enabled in device tree and there is no problem to boot all the octal cores, and the CPU hotplug is also working now, you can download and compile the latest firmware based on the following link to run this patch set: https://github.com/96boards/documentation/wiki/UEFI Changes v4: * Rebase to kernel 4.1-rc1 * Delete arm,cortex-a15-gic from the gic node in dts Acked-by: Haojian Zhuang haojian.zhu...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] arm64,hi6220: Enable Hisilicon Hi6220 SoC
On 5 May 2015 at 12:30, Bintian Wang bintian.w...@huawei.com wrote: Hi6220 is one mobile solution of Hisilicon, this patchset contains initial support for Hi6220 SoC and HiKey development board, which supports octal ARM Cortex A53 cores. Initial support is minimal and includes just the arch configuration, clock driver, device tree configuration. PSCI is enabled in device tree and there is no problem to boot all the octal cores, and the CPU hotplug is also working now, you can download and compile the latest firmware based on the following link to run this patch set: https://github.com/96boards/documentation/wiki/UEFI Changes v3: * Verified the CPU hotplug based on the new released firmware * Redefined the compatible strings of four system controllers in dts * Setting COMMON_CLK_HI6220 to a bool symbol * Keep CONFGI_ARCH_HISI sorted alphabetically Changes v2: * Split the DT bindings documents into earlier patches * Change SMP enable method from spin-table to PSCI in device tree * Remove clock-frequency from armv8-timer device node in device tree * Add more description about Hisilicon designed system controllers in DT bindings document * Enable high speed clock on UART1 mux * Other changes based on the discussion in the mailing list: https://lkml.org/lkml/2015/2/5/147 Bintian Wang (5): arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC clk: hi6220: Document devicetree bindings for hi6220 clock clk: hi6220: Clock driver support for Hisilicon hi6220 SoC arm64: dts: Add dts files for Hisilicon Hi6220 SoC Acked-by: Haojian Zhuang haojian.zhu...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: mmp: add GPIO driver for Marvell MMP series
On Tue, Feb 3, 2015 at 9:21 PM, Linus Walleij wrote: > On Wed, Jan 28, 2015 at 3:30 AM, Chao Xie wrote: > >> From: Chao Xie >> >> For some old PXA series, they used PXA GPIO driver. >> The IP of GPIO changes since PXA988 which is Marvell MMP >> series. >> It will use new way to control the GPIO level, direction >> and edge status. >> >> Signed-off-by: Chao Xie > > (...) > Just a silly question. What's the meaning of (...)? There're a lot of comments as (...). It's my first time to see this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: mmp: add GPIO driver for Marvell MMP series
On Tue, Feb 3, 2015 at 9:21 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jan 28, 2015 at 3:30 AM, Chao Xie chao@marvell.com wrote: From: Chao Xie chao@marvell.com For some old PXA series, they used PXA GPIO driver. The IP of GPIO changes since PXA988 which is Marvell MMP series. It will use new way to control the GPIO level, direction and edge status. Signed-off-by: Chao Xie chao@marvell.com (...) Just a silly question. What's the meaning of (...)? There're a lot of comments as (...). It's my first time to see this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irq: irq-hip04: initialize hip04_cpu_map to 0xffff
On 11 December 2014 at 19:03, Wang Long wrote: > HiP04 GIC extends to support 16 cores, so we should > initialize the hip04_cpu_map to 0x. > > Signed-off-by: Wang Long > --- > drivers/irqchip/irq-hip04.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c > index 9c8f8335..8eee46b 100644 > --- a/drivers/irqchip/irq-hip04.c > +++ b/drivers/irqchip/irq-hip04.c > @@ -382,7 +382,7 @@ hip04_of_init(struct device_node *node, struct > device_node *parent) > * It will be refined as each CPU probes its ID. > */ > for (i = 0; i < NR_HIP04_CPU_IF; i++) > - hip04_cpu_map[i] = 0xff; > + hip04_cpu_map[i] = 0x; > > /* > * Find out how many interrupts are supported. > -- > 1.8.3.4 > Acked-by: Haojian Zhuang Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irq: irq-hip04: initialize hip04_cpu_map to 0xffff
On 11 December 2014 at 19:03, Wang Long long.wangl...@huawei.com wrote: HiP04 GIC extends to support 16 cores, so we should initialize the hip04_cpu_map to 0x. Signed-off-by: Wang Long long.wangl...@huawei.com --- drivers/irqchip/irq-hip04.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c index 9c8f8335..8eee46b 100644 --- a/drivers/irqchip/irq-hip04.c +++ b/drivers/irqchip/irq-hip04.c @@ -382,7 +382,7 @@ hip04_of_init(struct device_node *node, struct device_node *parent) * It will be refined as each CPU probes its ID. */ for (i = 0; i NR_HIP04_CPU_IF; i++) - hip04_cpu_map[i] = 0xff; + hip04_cpu_map[i] = 0x; /* * Find out how many interrupts are supported. -- 1.8.3.4 Acked-by: Haojian Zhuang haojian.zhu...@linaro.org Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix lubbock interrupts handling
On Fri, Nov 28, 2014 at 9:30 PM, Robert Jarzmik wrote: > Thomas Gleixner writes: > >> So what is the relationship between installing that chained handler >> and that gpio-pxa probe stuff? > The relation is in gpio-pxa probe, look at the extract of pxa_gpio_probe() : > pxa_gpio_probe() > irq = gpio_to_irq(0); > irq_set_chip_and_handler(irq, _muxed_gpio_chip, > handle_edge_irq); > set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); > irq_set_chained_handler(IRQ_GPIO0, pxa_gpio_demux_handler); > > Now look at the extract from the former lubbock_init_irq() : > lubbock_init_irq() > irq = PXA_GPIO_TO_IRQ(0); > irq_set_chained_handler(irq, lubbock_irq_handler); > irq_set_irq_type(irq, IRQ_TYPE_EDGE_FALLING); > > Given that gpio_to_irq(0) = PXA_GPIO_TO_IRQ(0), see how these 2 are fighting > to > install the handler, and how the resulting installed handler depends on the > order of execution of pxa_gpio_to_irq() wrt lubbock_init_irq(). > >> And why is the GPIO0 interrupt handled from arch code rather than from >> a regular driver setup, which depends on the availablity of the GPIO >> driver? > Ah that's a good question. Maybe the answer is that there is no driver in this > case. > When I say "no driver", it's because this interrupt is a consequence of the > IO-Board (or motherboard) wiring topology. > > I think I need to add a bit of context, so pardon my crude ascii-art style, > and > see in the lubbock case, we have this wiring (list of IPs not exhaustive, and > gates to mask each XXX irq not added) : > > IPs on Motherboard Gates on motherboard SoC > > +-+ +---+ > | SMC Lan| --lan irq--- | Latch | - > +-+ | | \ > +--PXA-+ > | | \ | > | > +-+ | | |+--+ > | > | UDC Vbus | --vbus irq-- | Latch | -- NOR gate -- GPIO0 -- ||GPIO block| > | > +-+ | |line |+--+ > | > | | / | > | > +-+ | | / > +--+ > | SA| --sa11x irq--| Latch | - > +-+ +---+ > > The "gates on motherboard" is what lubbock.c is describing, ie. the > interconnection on the motherboard. I don't see the device/driver model > fitting > to describe these gates, do you ? > I think that it's a kind of irq muxing, just like lots of PMIC (power management IC). We should move the lubbock board irqs to a mfd driver, and register them as threaded irqs. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix lubbock interrupts handling
On Fri, Nov 28, 2014 at 9:30 PM, Robert Jarzmik robert.jarz...@free.fr wrote: Thomas Gleixner t...@linutronix.de writes: So what is the relationship between installing that chained handler and that gpio-pxa probe stuff? The relation is in gpio-pxa probe, look at the extract of pxa_gpio_probe() : pxa_gpio_probe() irq = gpio_to_irq(0); irq_set_chip_and_handler(irq, pxa_muxed_gpio_chip, handle_edge_irq); set_irq_flags(irq, IRQF_VALID | IRQF_PROBE); irq_set_chained_handler(IRQ_GPIO0, pxa_gpio_demux_handler); Now look at the extract from the former lubbock_init_irq() : lubbock_init_irq() irq = PXA_GPIO_TO_IRQ(0); irq_set_chained_handler(irq, lubbock_irq_handler); irq_set_irq_type(irq, IRQ_TYPE_EDGE_FALLING); Given that gpio_to_irq(0) = PXA_GPIO_TO_IRQ(0), see how these 2 are fighting to install the handler, and how the resulting installed handler depends on the order of execution of pxa_gpio_to_irq() wrt lubbock_init_irq(). And why is the GPIO0 interrupt handled from arch code rather than from a regular driver setup, which depends on the availablity of the GPIO driver? Ah that's a good question. Maybe the answer is that there is no driver in this case. When I say no driver, it's because this interrupt is a consequence of the IO-Board (or motherboard) wiring topology. I think I need to add a bit of context, so pardon my crude ascii-art style, and see in the lubbock case, we have this wiring (list of IPs not exhaustive, and gates to mask each XXX irq not added) : IPs on Motherboard Gates on motherboard SoC +-+ +---+ | SMC Lan| --lan irq--- | Latch | - +-+ | | \ +--PXA-+ | | \ | | +-+ | | |+--+ | | UDC Vbus | --vbus irq-- | Latch | -- NOR gate -- GPIO0 -- ||GPIO block| | +-+ | |line |+--+ | | | / | | +-+ | | / +--+ | SA| --sa11x irq--| Latch | - +-+ +---+ The gates on motherboard is what lubbock.c is describing, ie. the interconnection on the motherboard. I don't see the device/driver model fitting to describe these gates, do you ? I think that it's a kind of irq muxing, just like lots of PMIC (power management IC). We should move the lubbock board irqs to a mfd driver, and register them as threaded irqs. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
On Tue, Nov 4, 2014 at 8:46 PM, Zhou Wang wrote: > This patchset adds the support for NAND controller of hisilicon hip04 Soc. > The NAND controller IP was developed by hisilicon and needs a new driver to > support it. This patchset is based on v3.18-rc1. I have tested that NAND flash > controller works fine in Hip04 D01 board. > > Changes in v4: > - add mtd->dev.parent = >dev, thanks Frans Klaver. > Changes in v3: > - Modify code to eliminate some code style warnings. > - add ecc-bits input check. > - avoid using waterfall style in hisi_nfc_cmdfunc(). > Changes in v2: > - Remove the patch for device tree, now patchset only has the driver and its > device tree binding documentation. > - Change the file name: hisi_nand.c to hisi504_nand.c. > Changes in v1: > - Remove callback functions out of struct hinfc_host, and call them directly > in relative functions. > - Change hinfc_read and hinfc_write from macros to inline functions. > - Instead of putting pointers, embed struct nand_chip and struct mtd_info in > struct hinfc_host directly. > - rewrite some unclear lines in device tree binding document, correct some > code style error. > > Link on v3: > - https://lkml.org/lkml/2014/10/28/386 > Link on v2: > - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg750071.html > Link on v1: > - https://lkml.org/lkml/2014/7/15/198 > > Zhou Wang (2): > mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc > mtd: hisilicon: add device tree binding documentation > > .../devicetree/bindings/mtd/hisi504-nand.txt | 40 + > drivers/mtd/nand/Kconfig |5 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/hisi504_nand.c| 846 > > 4 files changed, 892 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/hisi504-nand.txt > create mode 100644 drivers/mtd/nand/hisi504_nand.c > > -- > 1.7.9.5 > Hi David & Brian, How do you think about this nand patch set? Could it be merged into v3.19? Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
On Tue, Nov 4, 2014 at 8:46 PM, Zhou Wang wangzhou@gmail.com wrote: This patchset adds the support for NAND controller of hisilicon hip04 Soc. The NAND controller IP was developed by hisilicon and needs a new driver to support it. This patchset is based on v3.18-rc1. I have tested that NAND flash controller works fine in Hip04 D01 board. Changes in v4: - add mtd-dev.parent = pdev-dev, thanks Frans Klaver. Changes in v3: - Modify code to eliminate some code style warnings. - add ecc-bits input check. - avoid using waterfall style in hisi_nfc_cmdfunc(). Changes in v2: - Remove the patch for device tree, now patchset only has the driver and its device tree binding documentation. - Change the file name: hisi_nand.c to hisi504_nand.c. Changes in v1: - Remove callback functions out of struct hinfc_host, and call them directly in relative functions. - Change hinfc_read and hinfc_write from macros to inline functions. - Instead of putting pointers, embed struct nand_chip and struct mtd_info in struct hinfc_host directly. - rewrite some unclear lines in device tree binding document, correct some code style error. Link on v3: - https://lkml.org/lkml/2014/10/28/386 Link on v2: - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg750071.html Link on v1: - https://lkml.org/lkml/2014/7/15/198 Zhou Wang (2): mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc mtd: hisilicon: add device tree binding documentation .../devicetree/bindings/mtd/hisi504-nand.txt | 40 + drivers/mtd/nand/Kconfig |5 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/hisi504_nand.c| 846 4 files changed, 892 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/hisi504-nand.txt create mode 100644 drivers/mtd/nand/hisi504_nand.c -- 1.7.9.5 Hi David Brian, How do you think about this nand patch set? Could it be merged into v3.19? Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/13] clk: mmp: clock device tree support
On 13 November 2014 08:35, Mike Turquette wrote: > Quoting Haojian Zhuang (2014-11-04 00:15:55) >> On Fri, Oct 31, 2014 at 10:13 AM, Chao Xie wrote: >> > From: Chao Xie >> > >> > The patch set focuses at support device tree for clock. >> > >> > The first part of the patches >> > clk: mmp: add prefix "mmp" for structures defined for clk-frac >> > clk: mmp: add spin lock for clk-frac >> > clk: mmp: add init callback for clk-frac >> > clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the >> > clk-frac. >> > >> > The second part of the patches >> > clk: mmp: add clock type mix >> > clk: mmp: add mmp private gate clock >> > >> > The third part of the patches >> > clk: mmp: add basic support functions for DT support >> > clk: mmp: add reset support >> > clk: mmp: add pxa168 DT support for clock driver >> > clk: mmp: add pxa910 DT support for clock driver >> > clk: mmp: add mmp2 DT support for clock driver >> > It add the device tree support for pxa168, pxa910 and mmp2. >> > >> > V1 -> V2: >> > Add reset support for the clocks that have reset bit. >> > >> > Chao Xie (13): >> > clk: mmp: add prefix "mmp" for structures defined for clk-frac >> > clk: mmp: add spin lock for clk-frac >> > clk: mmp: add init callback for clk-frac >> > clk: mmp: move definiton of mmp_clk_frac to clk.h >> > clk: mmp: add clock type mix >> > clk: mmp: add mmp private gate clock >> > clk: mmp: add basic support functions for DT support >> > clk: mmp: add reset support >> > clk: mmp: add pxa168 DT support for clock driver >> > clk: mmp: add pxa910 DT support for clock driver >> > clk: mmp: add mmp2 DT support for clock driver >> > arm: mmp: Make all the dts file to be compiled by Makefile >> > arm: mmp: Make use of the DT supported clock >> > >> > .../devicetree/bindings/clock/marvell,mmp2.txt | 21 + >> > .../devicetree/bindings/clock/marvell,pxa168.txt | 21 + >> > .../devicetree/bindings/clock/marvell,pxa910.txt | 21 + >> > arch/arm/boot/dts/Makefile | 3 + >> > arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- >> > arch/arm/boot/dts/mmp2.dtsi| 29 +- >> > arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- >> > arch/arm/boot/dts/pxa168.dtsi | 27 +- >> > arch/arm/boot/dts/pxa910-dkb.dts | 2 +- >> > arch/arm/boot/dts/pxa910.dtsi | 28 +- >> > arch/arm/mach-mmp/Kconfig | 12 +- >> > arch/arm/mach-mmp/mmp-dt.c | 57 +-- >> > arch/arm/mach-mmp/mmp2-dt.c| 26 +- >> > drivers/clk/mmp/Makefile | 7 +- >> > drivers/clk/mmp/clk-frac.c | 74 ++- >> > drivers/clk/mmp/clk-gate.c | 133 ++ >> > drivers/clk/mmp/clk-mix.c | 513 >> > + >> > drivers/clk/mmp/clk-mmp2.c | 6 +- >> > drivers/clk/mmp/clk-of-mmp2.c | 334 ++ >> > drivers/clk/mmp/clk-of-pxa168.c| 279 +++ >> > drivers/clk/mmp/clk-of-pxa910.c| 301 >> > drivers/clk/mmp/clk-pxa168.c | 6 +- >> > drivers/clk/mmp/clk-pxa910.c | 6 +- >> > drivers/clk/mmp/clk.c | 192 >> > drivers/clk/mmp/clk.h | 226 - >> > drivers/clk/mmp/reset.c| 99 >> > drivers/clk/mmp/reset.h| 31 ++ >> > include/dt-bindings/clock/marvell,mmp2.h | 74 +++ >> > include/dt-bindings/clock/marvell,pxa168.h | 57 +++ >> > include/dt-bindings/clock/marvell,pxa910.h | 54 +++ >> > 30 files changed, 2538 insertions(+), 105 deletions(-) >> > create mode 100644 >> > Documentation/devicetree/bindings/clock/marvell,mmp2.txt >> > create mode 100644 >> > Documentation/devicetree/bindings/clock/marvell,pxa168.txt >> > create mode 100644 >> > Documentation/devicetree/bindings/clock/marvell,pxa910.txt >> > create mode 100644 drivers/clk/mmp/clk-gate.c
Re: [PATCH V2 00/13] clk: mmp: clock device tree support
On 13 November 2014 08:35, Mike Turquette mturque...@linaro.org wrote: Quoting Haojian Zhuang (2014-11-04 00:15:55) On Fri, Oct 31, 2014 at 10:13 AM, Chao Xie chao@marvell.com wrote: From: Chao Xie chao@marvell.com The patch set focuses at support device tree for clock. The first part of the patches clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. The second part of the patches clk: mmp: add clock type mix clk: mmp: add mmp private gate clock The third part of the patches clk: mmp: add basic support functions for DT support clk: mmp: add reset support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver It add the device tree support for pxa168, pxa910 and mmp2. V1 - V2: Add reset support for the clocks that have reset bit. Chao Xie (13): clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add basic support functions for DT support clk: mmp: add reset support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver arm: mmp: Make all the dts file to be compiled by Makefile arm: mmp: Make use of the DT supported clock .../devicetree/bindings/clock/marvell,mmp2.txt | 21 + .../devicetree/bindings/clock/marvell,pxa168.txt | 21 + .../devicetree/bindings/clock/marvell,pxa910.txt | 21 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- arch/arm/boot/dts/mmp2.dtsi| 29 +- arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- arch/arm/boot/dts/pxa168.dtsi | 27 +- arch/arm/boot/dts/pxa910-dkb.dts | 2 +- arch/arm/boot/dts/pxa910.dtsi | 28 +- arch/arm/mach-mmp/Kconfig | 12 +- arch/arm/mach-mmp/mmp-dt.c | 57 +-- arch/arm/mach-mmp/mmp2-dt.c| 26 +- drivers/clk/mmp/Makefile | 7 +- drivers/clk/mmp/clk-frac.c | 74 ++- drivers/clk/mmp/clk-gate.c | 133 ++ drivers/clk/mmp/clk-mix.c | 513 + drivers/clk/mmp/clk-mmp2.c | 6 +- drivers/clk/mmp/clk-of-mmp2.c | 334 ++ drivers/clk/mmp/clk-of-pxa168.c| 279 +++ drivers/clk/mmp/clk-of-pxa910.c| 301 drivers/clk/mmp/clk-pxa168.c | 6 +- drivers/clk/mmp/clk-pxa910.c | 6 +- drivers/clk/mmp/clk.c | 192 drivers/clk/mmp/clk.h | 226 - drivers/clk/mmp/reset.c| 99 drivers/clk/mmp/reset.h| 31 ++ include/dt-bindings/clock/marvell,mmp2.h | 74 +++ include/dt-bindings/clock/marvell,pxa168.h | 57 +++ include/dt-bindings/clock/marvell,pxa910.h | 54 +++ 30 files changed, 2538 insertions(+), 105 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/marvell,mmp2.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa168.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa910.txt create mode 100644 drivers/clk/mmp/clk-gate.c create mode 100644 drivers/clk/mmp/clk-mix.c create mode 100644 drivers/clk/mmp/clk-of-mmp2.c create mode 100644 drivers/clk/mmp/clk-of-pxa168.c create mode 100644 drivers/clk/mmp/clk-of-pxa910.c create mode 100644 drivers/clk/mmp/clk.c create mode 100644 drivers/clk/mmp/reset.c create mode 100644 drivers/clk/mmp/reset.h create mode 100644 include/dt-bindings/clock/marvell,mmp2.h create mode 100644 include/dt-bindings/clock/marvell,pxa168.h create mode 100644 include/dt-bindings/clock/marvell,pxa910.h -- 1.8.3.2 Acked-by: Haojian Zhuang haojian.zhu...@gmail.com Mike, Please merge all mach-mmp patches with clock together. Otherwise, it may result in build issue. Can patches #12 #13 go through arm-soc? Hi Mike, I also hope so. But patch #12 makes those dtb files built automatically. And patch #13 references clocks that are defined in dt-binding files. If I merge patch #12 #13, I'll
Re: [PATCH] clk: hi3620: Move const initdata into correct code section
On 10 November 2014 20:58, Bintian Wang wrote:
> Use __initconst instead of __initdata for constant init data.
>
> Signed-off-by: Bintian Wang
> ---
> drivers/clk/hisilicon/clk-hi3620.c | 70
> +++---
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/clk/hisilicon/clk-hi3620.c
> b/drivers/clk/hisilicon/clk-hi3620.c
> index 339945d..640ea33 100644
> --- a/drivers/clk/hisilicon/clk-hi3620.c
> +++ b/drivers/clk/hisilicon/clk-hi3620.c
> @@ -38,44 +38,44 @@
> #include "clk.h"
>
> /* clock parent list */
> -static const char *timer0_mux_p[] __initdata = { "osc32k", "timerclk01", };
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: hi3620: Move const initdata into correct code section
On 10 November 2014 20:58, Bintian Wang bintian.w...@huawei.com wrote:
Use __initconst instead of __initdata for constant init data.
Signed-off-by: Bintian Wang bintian.w...@huawei.com
---
drivers/clk/hisilicon/clk-hi3620.c | 70
+++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hi3620.c
b/drivers/clk/hisilicon/clk-hi3620.c
index 339945d..640ea33 100644
--- a/drivers/clk/hisilicon/clk-hi3620.c
+++ b/drivers/clk/hisilicon/clk-hi3620.c
@@ -38,44 +38,44 @@
#include clk.h
/* clock parent list */
-static const char *timer0_mux_p[] __initdata = { osc32k, timerclk01, };
Acked-by: Haojian Zhuang haojian.zhu...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
On Tue, Nov 4, 2014 at 8:46 PM, Zhou Wang wrote: > This patchset adds the support for NAND controller of hisilicon hip04 Soc. > The NAND controller IP was developed by hisilicon and needs a new driver to > support it. This patchset is based on v3.18-rc1. I have tested that NAND flash > controller works fine in Hip04 D01 board. > > Changes in v4: > - add mtd->dev.parent = >dev, thanks Frans Klaver. > Changes in v3: > - Modify code to eliminate some code style warnings. > - add ecc-bits input check. > - avoid using waterfall style in hisi_nfc_cmdfunc(). > Changes in v2: > - Remove the patch for device tree, now patchset only has the driver and its > device tree binding documentation. > - Change the file name: hisi_nand.c to hisi504_nand.c. > Changes in v1: > - Remove callback functions out of struct hinfc_host, and call them directly > in relative functions. > - Change hinfc_read and hinfc_write from macros to inline functions. > - Instead of putting pointers, embed struct nand_chip and struct mtd_info in > struct hinfc_host directly. > - rewrite some unclear lines in device tree binding document, correct some > code style error. > > Link on v3: > - https://lkml.org/lkml/2014/10/28/386 > Link on v2: > - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg750071.html > Link on v1: > - https://lkml.org/lkml/2014/7/15/198 > > Zhou Wang (2): > mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc > mtd: hisilicon: add device tree binding documentation > > .../devicetree/bindings/mtd/hisi504-nand.txt | 40 + > drivers/mtd/nand/Kconfig |5 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/hisi504_nand.c| 846 > > 4 files changed, 892 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/hisi504-nand.txt > create mode 100644 drivers/mtd/nand/hisi504_nand.c > > -- > 1.7.9.5 > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
On Tue, Nov 4, 2014 at 8:46 PM, Zhou Wang wangzhou@gmail.com wrote: This patchset adds the support for NAND controller of hisilicon hip04 Soc. The NAND controller IP was developed by hisilicon and needs a new driver to support it. This patchset is based on v3.18-rc1. I have tested that NAND flash controller works fine in Hip04 D01 board. Changes in v4: - add mtd-dev.parent = pdev-dev, thanks Frans Klaver. Changes in v3: - Modify code to eliminate some code style warnings. - add ecc-bits input check. - avoid using waterfall style in hisi_nfc_cmdfunc(). Changes in v2: - Remove the patch for device tree, now patchset only has the driver and its device tree binding documentation. - Change the file name: hisi_nand.c to hisi504_nand.c. Changes in v1: - Remove callback functions out of struct hinfc_host, and call them directly in relative functions. - Change hinfc_read and hinfc_write from macros to inline functions. - Instead of putting pointers, embed struct nand_chip and struct mtd_info in struct hinfc_host directly. - rewrite some unclear lines in device tree binding document, correct some code style error. Link on v3: - https://lkml.org/lkml/2014/10/28/386 Link on v2: - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg750071.html Link on v1: - https://lkml.org/lkml/2014/7/15/198 Zhou Wang (2): mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc mtd: hisilicon: add device tree binding documentation .../devicetree/bindings/mtd/hisi504-nand.txt | 40 + drivers/mtd/nand/Kconfig |5 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/hisi504_nand.c| 846 4 files changed, 892 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/hisi504-nand.txt create mode 100644 drivers/mtd/nand/hisi504_nand.c -- 1.7.9.5 Acked-by: Haojian Zhuang haojian.zhu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/13] clk: mmp: clock device tree support
On Fri, Oct 31, 2014 at 10:13 AM, Chao Xie wrote: > From: Chao Xie > > The patch set focuses at support device tree for clock. > > The first part of the patches > clk: mmp: add prefix "mmp" for structures defined for clk-frac > clk: mmp: add spin lock for clk-frac > clk: mmp: add init callback for clk-frac > clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. > > The second part of the patches > clk: mmp: add clock type mix > clk: mmp: add mmp private gate clock > > The third part of the patches > clk: mmp: add basic support functions for DT support > clk: mmp: add reset support > clk: mmp: add pxa168 DT support for clock driver > clk: mmp: add pxa910 DT support for clock driver > clk: mmp: add mmp2 DT support for clock driver > It add the device tree support for pxa168, pxa910 and mmp2. > > V1 -> V2: > Add reset support for the clocks that have reset bit. > > Chao Xie (13): > clk: mmp: add prefix "mmp" for structures defined for clk-frac > clk: mmp: add spin lock for clk-frac > clk: mmp: add init callback for clk-frac > clk: mmp: move definiton of mmp_clk_frac to clk.h > clk: mmp: add clock type mix > clk: mmp: add mmp private gate clock > clk: mmp: add basic support functions for DT support > clk: mmp: add reset support > clk: mmp: add pxa168 DT support for clock driver > clk: mmp: add pxa910 DT support for clock driver > clk: mmp: add mmp2 DT support for clock driver > arm: mmp: Make all the dts file to be compiled by Makefile > arm: mmp: Make use of the DT supported clock > > .../devicetree/bindings/clock/marvell,mmp2.txt | 21 + > .../devicetree/bindings/clock/marvell,pxa168.txt | 21 + > .../devicetree/bindings/clock/marvell,pxa910.txt | 21 + > arch/arm/boot/dts/Makefile | 3 + > arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- > arch/arm/boot/dts/mmp2.dtsi| 29 +- > arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- > arch/arm/boot/dts/pxa168.dtsi | 27 +- > arch/arm/boot/dts/pxa910-dkb.dts | 2 +- > arch/arm/boot/dts/pxa910.dtsi | 28 +- > arch/arm/mach-mmp/Kconfig | 12 +- > arch/arm/mach-mmp/mmp-dt.c | 57 +-- > arch/arm/mach-mmp/mmp2-dt.c| 26 +- > drivers/clk/mmp/Makefile | 7 +- > drivers/clk/mmp/clk-frac.c | 74 ++- > drivers/clk/mmp/clk-gate.c | 133 ++ > drivers/clk/mmp/clk-mix.c | 513 > + > drivers/clk/mmp/clk-mmp2.c | 6 +- > drivers/clk/mmp/clk-of-mmp2.c | 334 ++ > drivers/clk/mmp/clk-of-pxa168.c| 279 +++ > drivers/clk/mmp/clk-of-pxa910.c| 301 > drivers/clk/mmp/clk-pxa168.c | 6 +- > drivers/clk/mmp/clk-pxa910.c | 6 +- > drivers/clk/mmp/clk.c | 192 > drivers/clk/mmp/clk.h | 226 - > drivers/clk/mmp/reset.c| 99 > drivers/clk/mmp/reset.h| 31 ++ > include/dt-bindings/clock/marvell,mmp2.h | 74 +++ > include/dt-bindings/clock/marvell,pxa168.h | 57 +++ > include/dt-bindings/clock/marvell,pxa910.h | 54 +++ > 30 files changed, 2538 insertions(+), 105 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/marvell,mmp2.txt > create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa168.txt > create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa910.txt > create mode 100644 drivers/clk/mmp/clk-gate.c > create mode 100644 drivers/clk/mmp/clk-mix.c > create mode 100644 drivers/clk/mmp/clk-of-mmp2.c > create mode 100644 drivers/clk/mmp/clk-of-pxa168.c > create mode 100644 drivers/clk/mmp/clk-of-pxa910.c > create mode 100644 drivers/clk/mmp/clk.c > create mode 100644 drivers/clk/mmp/reset.c > create mode 100644 drivers/clk/mmp/reset.h > create mode 100644 include/dt-bindings/clock/marvell,mmp2.h > create mode 100644 include/dt-bindings/clock/marvell,pxa168.h > create mode 100644 include/dt-bindings/clock/marvell,pxa910.h > > -- > 1.8.3.2 > Acked-by: Haojian Zhuang Mike, Please merge all mach-mmp patches with clock together. Otherwise, it may result in build issue. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/13] clk: mmp: clock device tree support
On Fri, Oct 31, 2014 at 10:13 AM, Chao Xie chao@marvell.com wrote: From: Chao Xie chao@marvell.com The patch set focuses at support device tree for clock. The first part of the patches clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. The second part of the patches clk: mmp: add clock type mix clk: mmp: add mmp private gate clock The third part of the patches clk: mmp: add basic support functions for DT support clk: mmp: add reset support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver It add the device tree support for pxa168, pxa910 and mmp2. V1 - V2: Add reset support for the clocks that have reset bit. Chao Xie (13): clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add basic support functions for DT support clk: mmp: add reset support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver arm: mmp: Make all the dts file to be compiled by Makefile arm: mmp: Make use of the DT supported clock .../devicetree/bindings/clock/marvell,mmp2.txt | 21 + .../devicetree/bindings/clock/marvell,pxa168.txt | 21 + .../devicetree/bindings/clock/marvell,pxa910.txt | 21 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- arch/arm/boot/dts/mmp2.dtsi| 29 +- arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- arch/arm/boot/dts/pxa168.dtsi | 27 +- arch/arm/boot/dts/pxa910-dkb.dts | 2 +- arch/arm/boot/dts/pxa910.dtsi | 28 +- arch/arm/mach-mmp/Kconfig | 12 +- arch/arm/mach-mmp/mmp-dt.c | 57 +-- arch/arm/mach-mmp/mmp2-dt.c| 26 +- drivers/clk/mmp/Makefile | 7 +- drivers/clk/mmp/clk-frac.c | 74 ++- drivers/clk/mmp/clk-gate.c | 133 ++ drivers/clk/mmp/clk-mix.c | 513 + drivers/clk/mmp/clk-mmp2.c | 6 +- drivers/clk/mmp/clk-of-mmp2.c | 334 ++ drivers/clk/mmp/clk-of-pxa168.c| 279 +++ drivers/clk/mmp/clk-of-pxa910.c| 301 drivers/clk/mmp/clk-pxa168.c | 6 +- drivers/clk/mmp/clk-pxa910.c | 6 +- drivers/clk/mmp/clk.c | 192 drivers/clk/mmp/clk.h | 226 - drivers/clk/mmp/reset.c| 99 drivers/clk/mmp/reset.h| 31 ++ include/dt-bindings/clock/marvell,mmp2.h | 74 +++ include/dt-bindings/clock/marvell,pxa168.h | 57 +++ include/dt-bindings/clock/marvell,pxa910.h | 54 +++ 30 files changed, 2538 insertions(+), 105 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/marvell,mmp2.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa168.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell,pxa910.txt create mode 100644 drivers/clk/mmp/clk-gate.c create mode 100644 drivers/clk/mmp/clk-mix.c create mode 100644 drivers/clk/mmp/clk-of-mmp2.c create mode 100644 drivers/clk/mmp/clk-of-pxa168.c create mode 100644 drivers/clk/mmp/clk-of-pxa910.c create mode 100644 drivers/clk/mmp/clk.c create mode 100644 drivers/clk/mmp/reset.c create mode 100644 drivers/clk/mmp/reset.h create mode 100644 include/dt-bindings/clock/marvell,mmp2.h create mode 100644 include/dt-bindings/clock/marvell,pxa168.h create mode 100644 include/dt-bindings/clock/marvell,pxa910.h -- 1.8.3.2 Acked-by: Haojian Zhuang haojian.zhu...@gmail.com Mike, Please merge all mach-mmp patches with clock together. Otherwise, it may result in build issue. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/2] ARM: hip04: add GPIO support
On Wed, Oct 22, 2014 at 7:55 PM, Zhou Wang wrote: > This series add the support for the GPIOs of Hisilicon Soc hip04. Hip04 uses > synopsis' GPIO IP, and we use the dwapb GPIO driver here. This series add the > corresponding dts. > > As the hip04 basic dts has been merged in 3.18 mainline kernel, I just resend > this patchset for review. > > Zhou Wang (2): > ARM: hip04: set ARCH_NR_GPIO to 128 > ARM: dts: hip04: add GPIO pieces > > arch/arm/Kconfig |1 + > arch/arm/boot/dts/hip04.dtsi | 75 > ++ > 2 files changed, 76 insertions(+) > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/2] ARM: hip04: add GPIO support
On Wed, Oct 22, 2014 at 7:55 PM, Zhou Wang wangzhou@gmail.com wrote: This series add the support for the GPIOs of Hisilicon Soc hip04. Hip04 uses synopsis' GPIO IP, and we use the dwapb GPIO driver here. This series add the corresponding dts. As the hip04 basic dts has been merged in 3.18 mainline kernel, I just resend this patchset for review. Zhou Wang (2): ARM: hip04: set ARCH_NR_GPIO to 128 ARM: dts: hip04: add GPIO pieces arch/arm/Kconfig |1 + arch/arm/boot/dts/hip04.dtsi | 75 ++ 2 files changed, 76 insertions(+) Acked-by: Haojian Zhuang haojian.zhu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
On Thu, Oct 23, 2014 at 10:04 PM, Zhou Wang wrote: > Signed-off-by: Zhou Wang > --- > drivers/mtd/nand/Kconfig|5 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/hisi504_nand.c | 836 > +++ > 3 files changed, 842 insertions(+) > create mode 100644 drivers/mtd/nand/hisi504_nand.c > I think that you need to run scripts/checkpatch.pl. There're some warnings reported on this patch. > + > + case NAND_CMD_SEQIN: > + host->offset = column; > + It's better not using waterfall style. Maybe you can write it clearly. case NAND_CMD_SEQIN: host->offset = column; set_addr(mtd, column, page_addr); break; > + chip->ecc.mode = of_get_nand_ecc_mode(np); > + /* read ecc-bits from dts */ > + of_property_read_u32(np, "hisi,nand-ecc-bits", >ecc_bits); Do you need to check the ecc_bits at here? Maybe user inputed the wrong ecc_bits in DTS. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
On Thu, Oct 23, 2014 at 10:04 PM, Zhou Wang wangzhou@gmail.com wrote: Signed-off-by: Zhou Wang wangzhou@gmail.com --- drivers/mtd/nand/Kconfig|5 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/hisi504_nand.c | 836 +++ 3 files changed, 842 insertions(+) create mode 100644 drivers/mtd/nand/hisi504_nand.c I think that you need to run scripts/checkpatch.pl. There're some warnings reported on this patch. + + case NAND_CMD_SEQIN: + host-offset = column; + It's better not using waterfall style. Maybe you can write it clearly. case NAND_CMD_SEQIN: host-offset = column; set_addr(mtd, column, page_addr); break; + chip-ecc.mode = of_get_nand_ecc_mode(np); + /* read ecc-bits from dts */ + of_property_read_u32(np, hisi,nand-ecc-bits, host-ecc_bits); Do you need to check the ecc_bits at here? Maybe user inputed the wrong ecc_bits in DTS. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk: hisilicon: ARCH_HIP04 and ARCH_HIX5HD2?
On 5 September 2014 07:07, Paul Bolle wrote:
> On Thu, 2014-06-19 at 17:00 +0800, Haojian Zhuang wrote:
>> On 19 June 2014 16:50, Paul Bolle wrote:
>> > 0) Commit d3e6573c48f4 ("clk: hip04: add clock driver") was included in
>> > v3.15. That clock driver is built only if CONFIG_ARCH_HIP04 is set.
>> >
>> > And commit 5efaf09021a5 ("clk: hisi: add clk-hix5hd2.c") was included in
>> > v3.16-rc1. And that driver is built only if CONFIG_ARCH_HIX5HD2 is set.
>> >
>> > 1) Neither the symbol ARCH_HIP04 nor the symbol ARCH_HIX5HD2 is part of
>> > v3.16-rc1. These symbols are also not part of next-20140619. I assume
>> > that both are pending somewhere. Is that correct?
>> >
>> > 2) It would probably be nice if these drivers got some (automatic) build
>> > coverage until those symbols enter the tree. I don't know how that could
>> > be achieved.
>>
>> Because clock driver is the first component should be merged into
>> kernel tree. Otherwise, SoC couldn't be compiled at all since SoC &
>> clock are in two different git tree.
>>
>> I also hope that SoC patches could be merged as soon as possible. But
>> we also need to follow up the comments on SoC patches from mailing
>> list. I can't not say when those SoC patches could be merged into
>> mainline since I'm not the gate keeper. I could only say that we're
>> making effort on this.
>
> ARCH_HIX5HD2 landed in v3.17-rc1, so it left my list of minor worries.
>
> I assume the code to add ARCH_HIP04 is still being worked on. Is that
> correct?
>
>
> Paul Bolle
>
Sorry for late response since I was in trip. Yes, you're right.
ARCH_HIP04 is still working on.
Best Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: clk: hisilicon: ARCH_HIP04 and ARCH_HIX5HD2?
On 5 September 2014 07:07, Paul Bolle pebo...@tiscali.nl wrote: On Thu, 2014-06-19 at 17:00 +0800, Haojian Zhuang wrote: On 19 June 2014 16:50, Paul Bolle pebo...@tiscali.nl wrote: 0) Commit d3e6573c48f4 (clk: hip04: add clock driver) was included in v3.15. That clock driver is built only if CONFIG_ARCH_HIP04 is set. And commit 5efaf09021a5 (clk: hisi: add clk-hix5hd2.c) was included in v3.16-rc1. And that driver is built only if CONFIG_ARCH_HIX5HD2 is set. 1) Neither the symbol ARCH_HIP04 nor the symbol ARCH_HIX5HD2 is part of v3.16-rc1. These symbols are also not part of next-20140619. I assume that both are pending somewhere. Is that correct? 2) It would probably be nice if these drivers got some (automatic) build coverage until those symbols enter the tree. I don't know how that could be achieved. Because clock driver is the first component should be merged into kernel tree. Otherwise, SoC couldn't be compiled at all since SoC clock are in two different git tree. I also hope that SoC patches could be merged as soon as possible. But we also need to follow up the comments on SoC patches from mailing list. I can't not say when those SoC patches could be merged into mainline since I'm not the gate keeper. I could only say that we're making effort on this. ARCH_HIX5HD2 landed in v3.17-rc1, so it left my list of minor worries. I assume the code to add ARCH_HIP04 is still being worked on. Is that correct? Paul Bolle Sorry for late response since I was in trip. Yes, you're right. ARCH_HIP04 is still working on. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] clk: mmp: clock device tree support
On 26 August 2014 12:38, Chao Xie wrote: > From: Chao Xie > > The patch set focuses at support device tree for clock. > > The first part of the patches > clk: mmp: add prefix "mmp" for structures defined for clk-frac > clk: mmp: add spin lock for clk-frac > clk: mmp: add init callback for clk-frac > clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. > > The second part of the patches > clk: mmp: add clock type mix > clk: mmp: add mmp private gate clock > > The third part of the patches > clk: mmp: add basic support functions for DT support > clk: mmp: add pxa168 DT support for clock driver > clk: mmp: add pxa910 DT support for clock driver > clk: mmp: add mmp2 DT support for clock driver > It add the device tree support for pxa168, pxa910 and mmp2. > > The final part of the patches > arm: mmp: Make all the dts file to be compiled by Makefile > arm: mmp: Make use of the DT supported clock > It changes the mmp platform to use device tree to parse the clocks. > > Chao Xie (12): > clk: mmp: add prefix "mmp" for structures defined for clk-frac > clk: mmp: add spin lock for clk-frac > clk: mmp: add init callback for clk-frac > clk: mmp: move definiton of mmp_clk_frac to clk.h > clk: mmp: add clock type mix > clk: mmp: add mmp private gate clock > clk: mmp: add basic support functions for DT support > clk: mmp: add pxa168 DT support for clock driver > clk: mmp: add pxa910 DT support for clock driver > clk: mmp: add mmp2 DT support for clock driver > arm: mmp: Make all the dts file to be compiled by Makefile > arm: mmp: Make use of the DT supported clock > > .../bindings/clock/marvell-mmp2-clock.txt | 20 + > .../bindings/clock/marvell-pxa168-clock.txt| 20 + > .../bindings/clock/marvell-pxa910-clock.txt| 20 + > arch/arm/boot/dts/Makefile | 3 + > arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- > arch/arm/boot/dts/mmp2.dtsi| 20 +- > arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- > arch/arm/boot/dts/pxa168.dtsi | 19 +- > arch/arm/boot/dts/pxa910-dkb.dts | 2 +- > arch/arm/boot/dts/pxa910.dtsi | 20 +- > arch/arm/mach-mmp/Kconfig | 10 +- > arch/arm/mach-mmp/mmp-dt.c | 57 +-- > arch/arm/mach-mmp/mmp2-dt.c| 26 +- > drivers/clk/mmp/Makefile | 5 +- > drivers/clk/mmp/clk-frac.c | 74 ++- > drivers/clk/mmp/clk-gate.c | 133 ++ > drivers/clk/mmp/clk-mix.c | 513 > + > drivers/clk/mmp/clk-mmp2.c | 6 +- > drivers/clk/mmp/clk-of-mmp2.c | 307 > drivers/clk/mmp/clk-of-pxa168.c| 251 ++ > drivers/clk/mmp/clk-of-pxa910.c| 260 +++ > drivers/clk/mmp/clk-pxa168.c | 6 +- > drivers/clk/mmp/clk-pxa910.c | 6 +- > drivers/clk/mmp/clk.c | 192 > drivers/clk/mmp/clk.h | 226 - > include/dt-bindings/clock/marvell-mmp2.h | 74 +++ > include/dt-bindings/clock/marvell-pxa168.h | 57 +++ > include/dt-bindings/clock/marvell-pxa910.h | 54 +++ > 28 files changed, 2280 insertions(+), 105 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt > create mode 100644 > Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt > create mode 100644 > Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt > create mode 100644 drivers/clk/mmp/clk-gate.c > create mode 100644 drivers/clk/mmp/clk-mix.c > create mode 100644 drivers/clk/mmp/clk-of-mmp2.c > create mode 100644 drivers/clk/mmp/clk-of-pxa168.c > create mode 100644 drivers/clk/mmp/clk-of-pxa910.c > create mode 100644 drivers/clk/mmp/clk.c > create mode 100644 include/dt-bindings/clock/marvell-mmp2.h > create mode 100644 include/dt-bindings/clock/marvell-pxa168.h > create mode 100644 include/dt-bindings/clock/marvell-pxa910.h > > -- > 1.8.3.2 > Hi Mike, I think that these clock patches are ready to merge. I want to go through arm-soc tree since chao will also move timer into clock source directory. Those patches will be depend on these clock patches. Could you help to give your Ack on these patches? Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] clk: mmp: clock device tree support
On 26 August 2014 12:38, Chao Xie chao@marvell.com wrote: From: Chao Xie chao@marvell.com The patch set focuses at support device tree for clock. The first part of the patches clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. The second part of the patches clk: mmp: add clock type mix clk: mmp: add mmp private gate clock The third part of the patches clk: mmp: add basic support functions for DT support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver It add the device tree support for pxa168, pxa910 and mmp2. The final part of the patches arm: mmp: Make all the dts file to be compiled by Makefile arm: mmp: Make use of the DT supported clock It changes the mmp platform to use device tree to parse the clocks. Chao Xie (12): clk: mmp: add prefix mmp for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add basic support functions for DT support clk: mmp: add pxa168 DT support for clock driver clk: mmp: add pxa910 DT support for clock driver clk: mmp: add mmp2 DT support for clock driver arm: mmp: Make all the dts file to be compiled by Makefile arm: mmp: Make use of the DT supported clock .../bindings/clock/marvell-mmp2-clock.txt | 20 + .../bindings/clock/marvell-pxa168-clock.txt| 20 + .../bindings/clock/marvell-pxa910-clock.txt| 20 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/mmp2-brownstone.dts | 2 +- arch/arm/boot/dts/mmp2.dtsi| 20 +- arch/arm/boot/dts/pxa168-aspenite.dts | 2 +- arch/arm/boot/dts/pxa168.dtsi | 19 +- arch/arm/boot/dts/pxa910-dkb.dts | 2 +- arch/arm/boot/dts/pxa910.dtsi | 20 +- arch/arm/mach-mmp/Kconfig | 10 +- arch/arm/mach-mmp/mmp-dt.c | 57 +-- arch/arm/mach-mmp/mmp2-dt.c| 26 +- drivers/clk/mmp/Makefile | 5 +- drivers/clk/mmp/clk-frac.c | 74 ++- drivers/clk/mmp/clk-gate.c | 133 ++ drivers/clk/mmp/clk-mix.c | 513 + drivers/clk/mmp/clk-mmp2.c | 6 +- drivers/clk/mmp/clk-of-mmp2.c | 307 drivers/clk/mmp/clk-of-pxa168.c| 251 ++ drivers/clk/mmp/clk-of-pxa910.c| 260 +++ drivers/clk/mmp/clk-pxa168.c | 6 +- drivers/clk/mmp/clk-pxa910.c | 6 +- drivers/clk/mmp/clk.c | 192 drivers/clk/mmp/clk.h | 226 - include/dt-bindings/clock/marvell-mmp2.h | 74 +++ include/dt-bindings/clock/marvell-pxa168.h | 57 +++ include/dt-bindings/clock/marvell-pxa910.h | 54 +++ 28 files changed, 2280 insertions(+), 105 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt create mode 100644 drivers/clk/mmp/clk-gate.c create mode 100644 drivers/clk/mmp/clk-mix.c create mode 100644 drivers/clk/mmp/clk-of-mmp2.c create mode 100644 drivers/clk/mmp/clk-of-pxa168.c create mode 100644 drivers/clk/mmp/clk-of-pxa910.c create mode 100644 drivers/clk/mmp/clk.c create mode 100644 include/dt-bindings/clock/marvell-mmp2.h create mode 100644 include/dt-bindings/clock/marvell-pxa168.h create mode 100644 include/dt-bindings/clock/marvell-pxa910.h -- 1.8.3.2 Hi Mike, I think that these clock patches are ready to merge. I want to go through arm-soc tree since chao will also move timer into clock source directory. Those patches will be depend on these clock patches. Could you help to give your Ack on these patches? Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: mm: fix the boundary checking on bitmaps
The issue of boundary checking on bitmaps is introduced by this commit
in below.
commit 4d852ef8c2544ce21ae41414099a7504c61164a0
Author: Andreas Herrmann
Date: Tue Feb 25 13:09:53 2014 +0100
arm: dma-mapping: Add support to extend DMA IOMMU mappings
Multiple bitmaps were introduced as extension. If it needs to extend
a bitmap, it still check whether the allocation exceeding the total
size, not current bitmap size. So change the condition from
mapping->bits to PAGE_SIZE.
Signed-off-by: Haojian Zhuang
---
arch/arm/mm/dma-mapping.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4c88935..d7da5c3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1089,9 +1089,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
spin_lock_irqsave(>lock, flags);
for (i = 0; i < mapping->nr_bitmaps; i++) {
start = bitmap_find_next_zero_area(mapping->bitmaps[i],
- mapping->bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start > mapping->bits)
+ if (start > PAGE_SIZE)
continue;
bitmap_set(mapping->bitmaps[i], start, count);
@@ -1110,9 +1110,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
}
start = bitmap_find_next_zero_area(mapping->bitmaps[i],
- mapping->bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start > mapping->bits) {
+ if (start > PAGE_SIZE) {
spin_unlock_irqrestore(>lock, flags);
return DMA_ERROR_CODE;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: mm: fix the boundary checking on bitmaps
The issue of boundary checking on bitmaps is introduced by this commit
in below.
commit 4d852ef8c2544ce21ae41414099a7504c61164a0
Author: Andreas Herrmann andreas.herrm...@calxeda.com
Date: Tue Feb 25 13:09:53 2014 +0100
arm: dma-mapping: Add support to extend DMA IOMMU mappings
Multiple bitmaps were introduced as extension. If it needs to extend
a bitmap, it still check whether the allocation exceeding the total
size, not current bitmap size. So change the condition from
mapping-bits to PAGE_SIZE.
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
arch/arm/mm/dma-mapping.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4c88935..d7da5c3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1089,9 +1089,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
spin_lock_irqsave(mapping-lock, flags);
for (i = 0; i mapping-nr_bitmaps; i++) {
start = bitmap_find_next_zero_area(mapping-bitmaps[i],
- mapping-bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start mapping-bits)
+ if (start PAGE_SIZE)
continue;
bitmap_set(mapping-bitmaps[i], start, count);
@@ -1110,9 +1110,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
}
start = bitmap_find_next_zero_area(mapping-bitmaps[i],
- mapping-bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start mapping-bits) {
+ if (start PAGE_SIZE) {
spin_unlock_irqrestore(mapping-lock, flags);
return DMA_ERROR_CODE;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix typo 'CONFIG_SPI_PXA2XX_MASTER'
On Fri, May 16, 2014 at 6:40 PM, Paul Bolle wrote:
> CONFIG_SPI_PXA2XX_MASTER was used were it was surely meant to use
> CONFIG_SPI_PXA2XX_MODULE. Use the IS_ENABLED() macro here, as it guards
> against typos like this one.
>
> Signed-off-by: Paul Bolle
> ---
> Untested, and (hardware) testing for the modular case might be needed.
> This typo was introduced in v2.6.28.
>
> arch/arm/mach-pxa/corgi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
> index 57d60542f982..ccff8d82cc27 100644
> --- a/arch/arm/mach-pxa/corgi.c
> +++ b/arch/arm/mach-pxa/corgi.c
> @@ -513,7 +513,7 @@ static struct pxa2xx_udc_mach_info udc_info __initdata = {
> .gpio_pullup= CORGI_GPIO_USB_PULLUP,
> };
>
> -#if defined(CONFIG_SPI_PXA2XX) || defined(CONFIG_SPI_PXA2XX_MASTER)
> +#if IS_ENABLED(CONFIG_SPI_PXA2XX)
> static struct pxa2xx_spi_master corgi_spi_info = {
> .num_chipselect = 3,
> };
> --
> 1.9.0
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: pxa: call debug_ll_io_init for earlyprintk
On Fri, Jun 6, 2014 at 3:10 AM, Andrew Ruder
wrote:
> This is already done automatically for many other ARM platforms by the
> ARM core code, but since pxa is using the .map_io callback, it needs to
> call it explicitely for earlyprintk support.
>
> Signed-off-by: Andrew Ruder
> ---
> arch/arm/mach-pxa/generic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
> index 4225417..94f49c2 100644
> --- a/arch/arm/mach-pxa/generic.c
> +++ b/arch/arm/mach-pxa/generic.c
> @@ -93,5 +93,6 @@ static struct map_desc common_io_desc[] __initdata = {
>
> void __init pxa_map_io(void)
> {
> + debug_ll_io_init();
> iotable_init(ARRAY_AND_SIZE(common_io_desc));
> }
> --
> 1.9.0.rc3.12.gbc97e2d
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: pxa: correct errata number for PXA270
On Fri, Jun 6, 2014 at 3:10 AM, Andrew Ruder wrote: > Comment incorrectly cites errata 39 > E39. SDIO: SDIO Devices Not Working at 19.5 Mbps > > Should be errata 38 > E38. MEMC: Memory Controller hangs when entering Self Refresh Mode. > > Signed-off-by: Andrew Ruder > --- > arch/arm/mach-pxa/sleep.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-pxa/sleep.S b/arch/arm/mach-pxa/sleep.S > index 1e544be..6c5b3ff 100644 > --- a/arch/arm/mach-pxa/sleep.S > +++ b/arch/arm/mach-pxa/sleep.S > @@ -157,7 +157,7 @@ pxa_cpu_do_suspend: > @ Do not reorder... > @ Intel PXA270 Specification Update notes problems performing > @ external accesses after SDRAM is put in self-refresh mode > - @ (see Errata 39 ...hangs when entering self-refresh mode) > + @ (see Errata 38 ...hangs when entering self-refresh mode) > > @ force address lines low by reading at physical address 0 > ldr r3, [r2] > -- > 1.9.0.rc3.12.gbc97e2d > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MAINTAINERS:ARM:hisi: add Hisilicon SoC family
On 4 July 2014 16:49, xuwei wrote: > Introduce a new mach-hisi that will support Hisilicon SoCs based on ARMv7 > and I am taking maintainership for it. > > Signed-off-by: Wei Xu > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 134483f..a4f700a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -972,6 +972,14 @@ F: arch/arm/mach-pxa/hx4700.c > F: arch/arm/mach-pxa/include/mach/hx4700.h > F: sound/soc/pxa/hx4700.c > > +ARM/Hisilicon SoC support > +M: Wei Xu > +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +W: www.hisilicon.com > +S: Supported > +T: git git://github.com/hisilicon/linux-hisi.git > +F: arch/arm/mach-hisi/ > + > ARM/HP JORNADA 7XX MACHINE SUPPORT > M: Kristoffer Ericson > W: www.jlime.com > -- > 1.8.1.2 > Acked-by: Haojian Zhuang Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MAINTAINERS:ARM:hisi: add Hisilicon SoC family
On 4 July 2014 16:49, xuwei xuw...@hisilicon.com wrote: Introduce a new mach-hisi that will support Hisilicon SoCs based on ARMv7 and I am taking maintainership for it. Signed-off-by: Wei Xu xuw...@hisilicon.com --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 134483f..a4f700a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -972,6 +972,14 @@ F: arch/arm/mach-pxa/hx4700.c F: arch/arm/mach-pxa/include/mach/hx4700.h F: sound/soc/pxa/hx4700.c +ARM/Hisilicon SoC support +M: Wei Xu xuw...@hisilicon.com +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +W: www.hisilicon.com +S: Supported +T: git git://github.com/hisilicon/linux-hisi.git +F: arch/arm/mach-hisi/ + ARM/HP JORNADA 7XX MACHINE SUPPORT M: Kristoffer Ericson kristoffer.eric...@gmail.com W: www.jlime.com -- 1.8.1.2 Acked-by: Haojian Zhuang haojian.zhu...@linaro.org Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: pxa: correct errata number for PXA270
On Fri, Jun 6, 2014 at 3:10 AM, Andrew Ruder andrew.ru...@elecsyscorp.com wrote: Comment incorrectly cites errata 39 E39. SDIO: SDIO Devices Not Working at 19.5 Mbps Should be errata 38 E38. MEMC: Memory Controller hangs when entering Self Refresh Mode. Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com --- arch/arm/mach-pxa/sleep.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/sleep.S b/arch/arm/mach-pxa/sleep.S index 1e544be..6c5b3ff 100644 --- a/arch/arm/mach-pxa/sleep.S +++ b/arch/arm/mach-pxa/sleep.S @@ -157,7 +157,7 @@ pxa_cpu_do_suspend: @ Do not reorder... @ Intel PXA270 Specification Update notes problems performing @ external accesses after SDRAM is put in self-refresh mode - @ (see Errata 39 ...hangs when entering self-refresh mode) + @ (see Errata 38 ...hangs when entering self-refresh mode) @ force address lines low by reading at physical address 0 ldr r3, [r2] -- 1.9.0.rc3.12.gbc97e2d Acked-by: Haojian Zhuang haojian.zhu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: pxa: call debug_ll_io_init for earlyprintk
On Fri, Jun 6, 2014 at 3:10 AM, Andrew Ruder
andrew.ru...@elecsyscorp.com wrote:
This is already done automatically for many other ARM platforms by the
ARM core code, but since pxa is using the .map_io callback, it needs to
call it explicitely for earlyprintk support.
Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com
---
arch/arm/mach-pxa/generic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 4225417..94f49c2 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -93,5 +93,6 @@ static struct map_desc common_io_desc[] __initdata = {
void __init pxa_map_io(void)
{
+ debug_ll_io_init();
iotable_init(ARRAY_AND_SIZE(common_io_desc));
}
--
1.9.0.rc3.12.gbc97e2d
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: fix typo 'CONFIG_SPI_PXA2XX_MASTER'
On Fri, May 16, 2014 at 6:40 PM, Paul Bolle pebo...@tiscali.nl wrote:
CONFIG_SPI_PXA2XX_MASTER was used were it was surely meant to use
CONFIG_SPI_PXA2XX_MODULE. Use the IS_ENABLED() macro here, as it guards
against typos like this one.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, and (hardware) testing for the modular case might be needed.
This typo was introduced in v2.6.28.
arch/arm/mach-pxa/corgi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 57d60542f982..ccff8d82cc27 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -513,7 +513,7 @@ static struct pxa2xx_udc_mach_info udc_info __initdata = {
.gpio_pullup= CORGI_GPIO_USB_PULLUP,
};
-#if defined(CONFIG_SPI_PXA2XX) || defined(CONFIG_SPI_PXA2XX_MASTER)
+#if IS_ENABLED(CONFIG_SPI_PXA2XX)
static struct pxa2xx_spi_master corgi_spi_info = {
.num_chipselect = 3,
};
--
1.9.0
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] clocksource: move PXA timer to clocksource framework
On Sun, Jun 22, 2014 at 6:09 AM, Robert Jarzmik wrote: > Move time.c from arch/arm/mach-pxa/time.c to > drivers/clocksource/pxa_timer.c. > > Signed-off-by: Robert Jarzmik > --- > arch/arm/mach-pxa/Makefile | 2 +- > drivers/clocksource/Makefile| 1 + > arch/arm/mach-pxa/time.c => drivers/clocksource/pxa_timer.c | 0 > 3 files changed, 2 insertions(+), 1 deletion(-) > rename arch/arm/mach-pxa/time.c => drivers/clocksource/pxa_timer.c (100%) > > diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile > index 648867a..2fe1824 100644 > --- a/arch/arm/mach-pxa/Makefile > +++ b/arch/arm/mach-pxa/Makefile > @@ -4,7 +4,7 @@ > > # Common support (must be linked before board specific support) > obj-y += clock.o devices.o generic.o irq.o \ > - time.o reset.o > + reset.o > obj-$(CONFIG_PM) += pm.o sleep.o standby.o > > # Generic drivers that other drivers may depend upon > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile > index 98cb6c5..e224125 100644 > --- a/drivers/clocksource/Makefile > +++ b/drivers/clocksource/Makefile > @@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= bcm2835_timer.o > obj-$(CONFIG_ARCH_MARCO) += timer-marco.o > obj-$(CONFIG_ARCH_MOXART) += moxart_timer.o > obj-$(CONFIG_ARCH_MXS) += mxs_timer.o > +obj-$(CONFIG_ARCH_PXA) += pxa_timer.o > obj-$(CONFIG_ARCH_PRIMA2) += timer-prima2.o > obj-$(CONFIG_ARCH_U300)+= timer-u300.o > obj-$(CONFIG_SUN4I_TIMER) += sun4i_timer.o > diff --git a/arch/arm/mach-pxa/time.c b/drivers/clocksource/pxa_timer.c > similarity index 100% > rename from arch/arm/mach-pxa/time.c > rename to drivers/clocksource/pxa_timer.c > -- > 2.0.0.rc2 > Acked-by: Haojian Zhuang Acked for all these three patches. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] clocksource: move PXA timer to clocksource framework
On Sun, Jun 22, 2014 at 6:09 AM, Robert Jarzmik robert.jarz...@free.fr wrote: Move time.c from arch/arm/mach-pxa/time.c to drivers/clocksource/pxa_timer.c. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr --- arch/arm/mach-pxa/Makefile | 2 +- drivers/clocksource/Makefile| 1 + arch/arm/mach-pxa/time.c = drivers/clocksource/pxa_timer.c | 0 3 files changed, 2 insertions(+), 1 deletion(-) rename arch/arm/mach-pxa/time.c = drivers/clocksource/pxa_timer.c (100%) diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile index 648867a..2fe1824 100644 --- a/arch/arm/mach-pxa/Makefile +++ b/arch/arm/mach-pxa/Makefile @@ -4,7 +4,7 @@ # Common support (must be linked before board specific support) obj-y += clock.o devices.o generic.o irq.o \ - time.o reset.o + reset.o obj-$(CONFIG_PM) += pm.o sleep.o standby.o # Generic drivers that other drivers may depend upon diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile index 98cb6c5..e224125 100644 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= bcm2835_timer.o obj-$(CONFIG_ARCH_MARCO) += timer-marco.o obj-$(CONFIG_ARCH_MOXART) += moxart_timer.o obj-$(CONFIG_ARCH_MXS) += mxs_timer.o +obj-$(CONFIG_ARCH_PXA) += pxa_timer.o obj-$(CONFIG_ARCH_PRIMA2) += timer-prima2.o obj-$(CONFIG_ARCH_U300)+= timer-u300.o obj-$(CONFIG_SUN4I_TIMER) += sun4i_timer.o diff --git a/arch/arm/mach-pxa/time.c b/drivers/clocksource/pxa_timer.c similarity index 100% rename from arch/arm/mach-pxa/time.c rename to drivers/clocksource/pxa_timer.c -- 2.0.0.rc2 Acked-by: Haojian Zhuang haojian.zhu...@gmail.com Acked for all these three patches. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk: hisilicon: ARCH_HIP04 and ARCH_HIX5HD2?
On 19 June 2014 16:50, Paul Bolle wrote:
> 0) Commit d3e6573c48f4 ("clk: hip04: add clock driver") was included in
> v3.15. That clock driver is built only if CONFIG_ARCH_HIP04 is set.
>
> And commit 5efaf09021a5 ("clk: hisi: add clk-hix5hd2.c") was included in
> v3.16-rc1. And that driver is built only if CONFIG_ARCH_HIX5HD2 is set.
>
> 1) Neither the symbol ARCH_HIP04 nor the symbol ARCH_HIX5HD2 is part of
> v3.16-rc1. These symbols are also not part of next-20140619. I assume
> that both are pending somewhere. Is that correct?
>
> 2) It would probably be nice if these drivers got some (automatic) build
> coverage until those symbols enter the tree. I don't know how that could
> be achieved.
>
>
> Paul Bolle
>
Because clock driver is the first component should be merged into
kernel tree. Otherwise, SoC couldn't be compiled at all since SoC &
clock are in two different git tree.
I also hope that SoC patches could be merged as soon as possible. But
we also need to follow up the comments on SoC patches from mailing
list. I can't not say when those SoC patches could be merged into
mainline since I'm not the gate keeper. I could only say that we're
making effort on this.
Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: clk: hisilicon: ARCH_HIP04 and ARCH_HIX5HD2?
On 19 June 2014 16:50, Paul Bolle pebo...@tiscali.nl wrote: 0) Commit d3e6573c48f4 (clk: hip04: add clock driver) was included in v3.15. That clock driver is built only if CONFIG_ARCH_HIP04 is set. And commit 5efaf09021a5 (clk: hisi: add clk-hix5hd2.c) was included in v3.16-rc1. And that driver is built only if CONFIG_ARCH_HIX5HD2 is set. 1) Neither the symbol ARCH_HIP04 nor the symbol ARCH_HIX5HD2 is part of v3.16-rc1. These symbols are also not part of next-20140619. I assume that both are pending somewhere. Is that correct? 2) It would probably be nice if these drivers got some (automatic) build coverage until those symbols enter the tree. I don't know how that could be achieved. Paul Bolle Because clock driver is the first component should be merged into kernel tree. Otherwise, SoC couldn't be compiled at all since SoC clock are in two different git tree. I also hope that SoC patches could be merged as soon as possible. But we also need to follow up the comments on SoC patches from mailing list. I can't not say when those SoC patches could be merged into mainline since I'm not the gate keeper. I could only say that we're making effort on this. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: Add hardware dependencies for sdhci-pxav3 and sdhci-pxav2
On Mon, Jun 16, 2014 at 8:18 PM, Jean Delvare wrote: > I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are > only needed on the MMP architecture. So add a hardware dependency on > ARCH_MMP, so that other users don't get to build useless drivers. > > Signed-off-by: Jean Delvare > Cc: Chris Ball > Cc: Ulf Hansson > Cc: Eric Miao > Cc: Haojian Zhuang > --- > Changes since v1: > * Rebased on kernel 3.16-rc1 > > drivers/mmc/host/Kconfig |2 ++ > 1 file changed, 2 insertions(+) > > --- linux-3.16-rc1.orig/drivers/mmc/host/Kconfig2014-06-16 > 14:03:26.195946537 +0200 > +++ linux-3.16-rc1/drivers/mmc/host/Kconfig 2014-06-16 14:04:02.128663037 > +0200 > @@ -217,6 +217,7 @@ config MMC_SDHCI_PXAV3 > tristate "Marvell MMP2 SD Host Controller support (PXAV3)" > depends on CLKDEV_LOOKUP > depends on MMC_SDHCI_PLTFM > + depends on ARCH_MMP || COMPILE_TEST > default CPU_MMP2 > help > This selects the Marvell(R) PXAV3 SD Host Controller. > @@ -229,6 +230,7 @@ config MMC_SDHCI_PXAV2 > tristate "Marvell PXA9XX SD Host Controller support (PXAV2)" > depends on CLKDEV_LOOKUP > depends on MMC_SDHCI_PLTFM > + depends on ARCH_MMP || COMPILE_TEST > default CPU_PXA910 > help > This selects the Marvell(R) PXAV2 SD Host Controller. > > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-pxa: gpio0 and gpio1 support on dt
On Thu, Jun 12, 2014 at 4:43 PM, Linus Walleij wrote: > On Thu, Jun 5, 2014 at 9:13 PM, Andrew Ruder > wrote: > >> pxa_gpio_probe() has some issues supporting the gpio0 and gpio1 >> interrupts under device-tree - it never actually sets up the chain >> handler to get interrupts on edge detect for GPIO0 and GPIO1. >> >> Signed-off-by: Andrew Ruder > > Makes perfect sense. Can I have an ACK from some PXA > maintainer on this? > > The PXA GPIO driver with it's messy irqchip registration looks > like a good candidate for switching to the gpiolib irqchip helpers > and rid some code. Just saying. > > Yours, > Linus Walleij Acked-by: Haojian Zhuang Yes, it's worth to rid some irqchip code. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-pxa: gpio0 and gpio1 support on dt
On Thu, Jun 12, 2014 at 4:43 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Jun 5, 2014 at 9:13 PM, Andrew Ruder andrew.ru...@elecsyscorp.com wrote: pxa_gpio_probe() has some issues supporting the gpio0 and gpio1 interrupts under device-tree - it never actually sets up the chain handler to get interrupts on edge detect for GPIO0 and GPIO1. Signed-off-by: Andrew Ruder andrew.ru...@elecsyscorp.com Makes perfect sense. Can I have an ACK from some PXA maintainer on this? The PXA GPIO driver with it's messy irqchip registration looks like a good candidate for switching to the gpiolib irqchip helpers and rid some code. Just saying. Yours, Linus Walleij Acked-by: Haojian Zhuang haojian.zhu...@gmail.com Yes, it's worth to rid some irqchip code. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc: Add hardware dependencies for sdhci-pxav3 and sdhci-pxav2
On Mon, Jun 16, 2014 at 8:18 PM, Jean Delvare jdelv...@suse.de wrote: I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are only needed on the MMP architecture. So add a hardware dependency on ARCH_MMP, so that other users don't get to build useless drivers. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Chris Ball ch...@printf.net Cc: Ulf Hansson ulf.hans...@linaro.org Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com --- Changes since v1: * Rebased on kernel 3.16-rc1 drivers/mmc/host/Kconfig |2 ++ 1 file changed, 2 insertions(+) --- linux-3.16-rc1.orig/drivers/mmc/host/Kconfig2014-06-16 14:03:26.195946537 +0200 +++ linux-3.16-rc1/drivers/mmc/host/Kconfig 2014-06-16 14:04:02.128663037 +0200 @@ -217,6 +217,7 @@ config MMC_SDHCI_PXAV3 tristate Marvell MMP2 SD Host Controller support (PXAV3) depends on CLKDEV_LOOKUP depends on MMC_SDHCI_PLTFM + depends on ARCH_MMP || COMPILE_TEST default CPU_MMP2 help This selects the Marvell(R) PXAV3 SD Host Controller. @@ -229,6 +230,7 @@ config MMC_SDHCI_PXAV2 tristate Marvell PXA9XX SD Host Controller support (PXAV2) depends on CLKDEV_LOOKUP depends on MMC_SDHCI_PLTFM + depends on ARCH_MMP || COMPILE_TEST default CPU_PXA910 help This selects the Marvell(R) PXAV2 SD Host Controller. Acked-by: Haojian Zhuang haojian.zhu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rtc: rtc-sa1100: Make of_device_id array const
On 3 June 2014 20:06, Jingoo Han wrote:
> Make of_device_id array const, because all OF functions handle
> it as const.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/rtc/rtc-sa1100.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
> index 0f7adeb..b6e1ca0 100644
> --- a/drivers/rtc/rtc-sa1100.c
> +++ b/drivers/rtc/rtc-sa1100.c
> @@ -338,7 +338,7 @@ static SIMPLE_DEV_PM_OPS(sa1100_rtc_pm_ops,
> sa1100_rtc_suspend,
> sa1100_rtc_resume);
>
> #ifdef CONFIG_OF
> -static struct of_device_id sa1100_rtc_dt_ids[] = {
> +static const struct of_device_id sa1100_rtc_dt_ids[] = {
> { .compatible = "mrvl,sa1100-rtc", },
> { .compatible = "mrvl,mmp-rtc", },
> {}
> --
> 1.7.10.4
>
>
Acked-by: Haojian Zhuang
Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rtc: rtc-sa1100: Make of_device_id array const
On 3 June 2014 20:06, Jingoo Han jg1@samsung.com wrote:
Make of_device_id array const, because all OF functions handle
it as const.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/rtc/rtc-sa1100.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 0f7adeb..b6e1ca0 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -338,7 +338,7 @@ static SIMPLE_DEV_PM_OPS(sa1100_rtc_pm_ops,
sa1100_rtc_suspend,
sa1100_rtc_resume);
#ifdef CONFIG_OF
-static struct of_device_id sa1100_rtc_dt_ids[] = {
+static const struct of_device_id sa1100_rtc_dt_ids[] = {
{ .compatible = mrvl,sa1100-rtc, },
{ .compatible = mrvl,mmp-rtc, },
{}
--
1.7.10.4
Acked-by: Haojian Zhuang haojian.zhu...@linaro.org
Regards
Haojian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: pl061: get gpio base from alias id
On 24 April 2014 02:52, Rob Herring wrote: > On Mon, Apr 21, 2014 at 8:35 PM, Haojian Zhuang > wrote: >> If gpio base number isn't specified, the gpio base will be find from >> the end of gpio number. In order to keep with schematics, use alias >> to get the ID of gpio chip. > > NAK. This is an abuse aliases. > >> Signed-off-by: Haojian Zhuang >> --- >> .../devicetree/bindings/gpio/gpio-pl061.txt| 31 >> ++ > > Is something wrong with the binding doc already in pl061-gpio.txt? > Oh. I just copy my old patch to here. I didn't notice there's a new pl061-gpio.txt. Thanks for reminder. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: pl061: get gpio base from alias id
On 23 April 2014 21:21, Linus Walleij wrote: > On Tue, Apr 22, 2014 at 3:35 AM, Haojian Zhuang > wrote: > >> If gpio base number isn't specified, the gpio base will be find from >> the end of gpio number. In order to keep with schematics, use alias >> to get the ID of gpio chip. >> >> Signed-off-by: Haojian Zhuang > > The idea with GPIO numbers is not that these shall correspond > to schematics or data sheets or anything like that. It's a completely > Linux-internal number and has nothing to do with anything else. > > The same is true for IRQ numbers. > > The long term goal is to get rid of both GPIO and IRQ numbers > and deal only with descriptors in the kernel. Go it. But the gpio sysfs interface is using the gpio name with an internal number. It'll make developer confusion since it's different from datasheet or schematics. Is there any plan to remove the confusion? Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: pl061: get gpio base from alias id
On 23 April 2014 21:21, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Apr 22, 2014 at 3:35 AM, Haojian Zhuang haojian.zhu...@linaro.org wrote: If gpio base number isn't specified, the gpio base will be find from the end of gpio number. In order to keep with schematics, use alias to get the ID of gpio chip. Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org The idea with GPIO numbers is not that these shall correspond to schematics or data sheets or anything like that. It's a completely Linux-internal number and has nothing to do with anything else. The same is true for IRQ numbers. The long term goal is to get rid of both GPIO and IRQ numbers and deal only with descriptors in the kernel. Go it. But the gpio sysfs interface is using the gpio name with an internal number. It'll make developer confusion since it's different from datasheet or schematics. Is there any plan to remove the confusion? Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio: pl061: get gpio base from alias id
On 24 April 2014 02:52, Rob Herring robherri...@gmail.com wrote: On Mon, Apr 21, 2014 at 8:35 PM, Haojian Zhuang haojian.zhu...@linaro.org wrote: If gpio base number isn't specified, the gpio base will be find from the end of gpio number. In order to keep with schematics, use alias to get the ID of gpio chip. NAK. This is an abuse aliases. Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org --- .../devicetree/bindings/gpio/gpio-pl061.txt| 31 ++ Is something wrong with the binding doc already in pl061-gpio.txt? Oh. I just copy my old patch to here. I didn't notice there's a new pl061-gpio.txt. Thanks for reminder. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: add gpio alias in hi3620 dts file
Use gpio alias to identify the index of gpio chip. Then we can keep the
same gpio number as schematics. Otherwise, gpio number is countered from
bottom to top.
Signed-off-by: Haojian Zhuang
---
arch/arm/boot/dts/hi3620.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index 6836795..2aaae09 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -21,6 +21,28 @@
serial2 =
serial3 =
serial4 =
+ gpio0 =
+ gpio1 =
+ gpio2 =
+ gpio3 =
+ gpio4 =
+ gpio5 =
+ gpio6 =
+ gpio7 =
+ gpio8 =
+ gpio9 =
+ gpio10 =
+ gpio11 =
+ gpio12 =
+ gpio13 =
+ gpio14 =
+ gpio15 =
+ gpio16 =
+ gpio17 =
+ gpio18 =
+ gpio19 =
+ gpio20 =
+ gpio21 =
};
pclk: clk {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] gpio: pl061: get gpio base from alias id
If gpio base number isn't specified, the gpio base will be find from
the end of gpio number. In order to keep with schematics, use alias
to get the ID of gpio chip.
Signed-off-by: Haojian Zhuang
---
.../devicetree/bindings/gpio/gpio-pl061.txt| 31 ++
drivers/gpio/gpio-pl061.c | 14 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pl061.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
new file mode 100644
index 000..164b5ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
@@ -0,0 +1,31 @@
+PL061 GPIO controller bindings
+
+Required properties:
+- compatible:
+ - "arm,pl061", "arm,primecell".
+- #gpio-cells : Should be two.
+ - first cell is the gpio pin number
+ - second cell is used to specify the gpio polarity:
+ 0 = active high
+ 1 = active low
+- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller : Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+ - first cell is the hw irq number
+ - second cell is used to specify the interrupt type:
+ 0 = default, unspecified type
+ 1 = rising edge triggered
+ 2 = falling edge triggered
+ 4 = high level triggered
+ 8 = low level triggered
+
+Example:
+ gpio0: gpio@fc806000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0xfc806000 0x1000>;
+ interrupts = <0 64 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index b0f4752..14f3ab5 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -236,6 +236,18 @@ static struct irq_chip pl061_irqchip = {
.irq_set_type = pl061_irq_type,
};
+/* Parse gpio base from DT */
+static int pl061_parse_gpio_base(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ int ret, id;
+
+ id = of_alias_get_id(np, "gpio");
+ if (id < 0)
+ return id;
+ return (id * PL061_GPIO_NR);
+}
+
static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = >dev;
@@ -255,7 +267,7 @@ static int pl061_probe(struct amba_device *adev, const
struct amba_id *id)
return -ENODEV;
}
} else {
- chip->gc.base = -1;
+ chip->gc.base = pl061_parse_gpio_base(dev);
irq_base = 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: add gpio alias in hi3620 dts file
Use gpio alias to identify the index of gpio chip. Then we can keep the
same gpio number as schematics. Otherwise, gpio number is countered from
bottom to top.
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
arch/arm/boot/dts/hi3620.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index 6836795..2aaae09 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -21,6 +21,28 @@
serial2 = uart2;
serial3 = uart3;
serial4 = uart4;
+ gpio0 = gpio0;
+ gpio1 = gpio1;
+ gpio2 = gpio2;
+ gpio3 = gpio3;
+ gpio4 = gpio4;
+ gpio5 = gpio5;
+ gpio6 = gpio6;
+ gpio7 = gpio7;
+ gpio8 = gpio8;
+ gpio9 = gpio9;
+ gpio10 = gpio10;
+ gpio11 = gpio11;
+ gpio12 = gpio12;
+ gpio13 = gpio13;
+ gpio14 = gpio14;
+ gpio15 = gpio15;
+ gpio16 = gpio16;
+ gpio17 = gpio17;
+ gpio18 = gpio18;
+ gpio19 = gpio19;
+ gpio20 = gpio20;
+ gpio21 = gpio21;
};
pclk: clk {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] gpio: pl061: get gpio base from alias id
If gpio base number isn't specified, the gpio base will be find from
the end of gpio number. In order to keep with schematics, use alias
to get the ID of gpio chip.
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
.../devicetree/bindings/gpio/gpio-pl061.txt| 31 ++
drivers/gpio/gpio-pl061.c | 14 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pl061.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
new file mode 100644
index 000..164b5ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
@@ -0,0 +1,31 @@
+PL061 GPIO controller bindings
+
+Required properties:
+- compatible:
+ - arm,pl061, arm,primecell.
+- #gpio-cells : Should be two.
+ - first cell is the gpio pin number
+ - second cell is used to specify the gpio polarity:
+ 0 = active high
+ 1 = active low
+- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller : Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+ - first cell is the hw irq number
+ - second cell is used to specify the interrupt type:
+ 0 = default, unspecified type
+ 1 = rising edge triggered
+ 2 = falling edge triggered
+ 4 = high level triggered
+ 8 = low level triggered
+
+Example:
+ gpio0: gpio@fc806000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xfc806000 0x1000;
+ interrupts = 0 64 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index b0f4752..14f3ab5 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -236,6 +236,18 @@ static struct irq_chip pl061_irqchip = {
.irq_set_type = pl061_irq_type,
};
+/* Parse gpio base from DT */
+static int pl061_parse_gpio_base(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ int ret, id;
+
+ id = of_alias_get_id(np, gpio);
+ if (id 0)
+ return id;
+ return (id * PL061_GPIO_NR);
+}
+
static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = adev-dev;
@@ -255,7 +267,7 @@ static int pl061_probe(struct amba_device *adev, const
struct amba_id *id)
return -ENODEV;
}
} else {
- chip-gc.base = -1;
+ chip-gc.base = pl061_parse_gpio_base(dev);
irq_base = 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] clk: changes for 3.15
On 6 April 2014 18:28, Paul Bolle wrote: > On Fri, 2014-04-04 at 10:47 -0700, Mike Turquette wrote: >> Haojian Zhuang (3): >> [...] >> clk: hip04: add clock driver > > This clock driver is only built if CONFIG_ARCH_HIP04 is set. But I > couldn't find a Kconfig symbol ARCH_HIP04. (I checked master of Linus' > tree and current linux-next.) > > Is the code to add this symbol queued somewhere? > > > Paul Bolle > Hi Paul, ARCH_HIP04 patches are still in review stage. Those patches could be found in arm-linux mailing list. Clock patches of ARCH_HIP04 is ready, so it could be merged first. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] clk: changes for 3.15
On 6 April 2014 18:28, Paul Bolle pebo...@tiscali.nl wrote: On Fri, 2014-04-04 at 10:47 -0700, Mike Turquette wrote: Haojian Zhuang (3): [...] clk: hip04: add clock driver This clock driver is only built if CONFIG_ARCH_HIP04 is set. But I couldn't find a Kconfig symbol ARCH_HIP04. (I checked master of Linus' tree and current linux-next.) Is the code to add this symbol queued somewhere? Paul Bolle Hi Paul, ARCH_HIP04 patches are still in review stage. Those patches could be found in arm-linux mailing list. Clock patches of ARCH_HIP04 is ready, so it could be merged first. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmp: allow platform devices with modular USB
a910_add_nand(_nand_info); > #endif > > @@ -285,22 +285,22 @@ static void __init ttc_dkb_init(void) > sizeof(struct pxa_gpio_platform_data)); > platform_add_devices(ARRAY_AND_SIZE(ttc_dkb_devices)); > > -#ifdef CONFIG_USB_MV_UDC > +#if IS_ENABLED(CONFIG_USB_MV_UDC) > pxa168_device_u2o.dev.platform_data = _usb_pdata; > platform_device_register(_device_u2o); > #endif > > -#ifdef CONFIG_USB_EHCI_MV_U2O > +#if IS_ENABLED(CONFIG_USB_EHCI_MV_U2O) > pxa168_device_u2oehci.dev.platform_data = _usb_pdata; > platform_device_register(_device_u2oehci); > #endif > > -#ifdef CONFIG_USB_MV_OTG > +#if IS_ENABLED(CONFIG_USB_MV_OTG) > pxa168_device_u2ootg.dev.platform_data = _usb_pdata; > platform_device_register(_device_u2ootg); > #endif > > -#ifdef CONFIG_MMP_DISP > +#if IS_ENABLED(CONFIG_MMP_DISP) > add_disp(); > #endif > } > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmp: allow platform devices with modular USB
) pxa168_device_u2oehci.dev.platform_data = ttc_usb_pdata; platform_device_register(pxa168_device_u2oehci); #endif -#ifdef CONFIG_USB_MV_OTG +#if IS_ENABLED(CONFIG_USB_MV_OTG) pxa168_device_u2ootg.dev.platform_data = ttc_usb_pdata; platform_device_register(pxa168_device_u2ootg); #endif -#ifdef CONFIG_MMP_DISP +#if IS_ENABLED(CONFIG_MMP_DISP) add_disp(); #endif } Acked-by: Haojian Zhuang haojian.zhu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Thu, Feb 27, 2014 at 9:37 AM, Chao Xie wrote: > On Mon, Feb 24, 2014 at 7:31 PM, Thomas Gleixner wrote: >> On Mon, 24 Feb 2014, Haojian Zhuang wrote: >> >>> On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie wrote: >>> > On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König >>> > wrote: >>> >> Hi Thomas, >>> >> >>> >> On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: >>> >>> The pm-mmp2 and pm-pxa910 power management related irq_set_wake >>> >>> callbacks fiddle pointlessly with the irq actions for no reason except >>> >>> for lack of understanding how the wakeup mechanism works. >>> >>> >>> >>> On supsend the core disables all interrupts lazily, i.e. it does not >>> >>> mask them at the irq controller level. So any interrupt which is >>> >>> firing during supsend will mark the corresponding interrupt line as >>> >> s/supsend/suspend/ twice >>> >>> pending. Just before the core powers down it checks whether there are >>> >>> interrupts pending from interrupt lines which are marked as wakeup >>> >>> sources and if so it aborts the resume and resends the interrupts. >>> >> It's the suspend that is aborted, not the resume. >>> >> >>> >> Other than that your change looks fine. >>> >> >>> > For pxa910 and MMP2, wake up source only wake up the AP subsystem. >>> > The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. >>> > Now the core is still powered down. APMU will check the interrupt >>> > lines, and find >>> > that there are interrupt pending, it will power on the cores. >>> > So if the irq is disabled, even wake up source can wake up AP subsystem, >>> > but the >>> > core is still powered down. It will not be powered up by APMU. >>> > >>> >>> Yes, suspend/resume can't work if the above code is removed. >>> >>> Interrupt source (logic AND with interrupt mask register) is connected >>> to MPMU as >>> wakeup source. If the interrupt is disabled, there's no wakeup source event. >>> >>> And APMU is waken up by MPMU. >>> >>> So please don't remove the above code. We must keep these interrupt lines >>> active >>> to wake up the whole system. >> >> They are kept active at the interrupt controller level. You just >> refuse to understand how the internals of the interrupt subsystem >> work. >> > If no irq_disable callback is hooked, when do irq_disable, it will not > actually disable > the interrupt, it will depend on next time when the irq happens, the > handler will first mask > the interrupt as this interrupt never happens. > So after system suspended, the interrupt happens, but the device > driver will not recieve this interrupt > because it is masked. > It results in that the device driver miss a important interrupt which > related to something need to be > handled. If user application for example android has power managment > daemon. It will find that nothing > to handle, it will make the system enter suspend again. > Let me list the logic to make it easier to understand. suspend_enter() --> dpm_suspend_end() --> dpm_suspend_noirq() --> suspend_device_irqs() --> __disable_irq() --> set IRQS_SUSPENDED && call irq_disable() if necessary --> syscore_suspend() --> check_wakeup_irqs() If there's no pending irq in suspend process && IRQS_SUSPENDED is set, then mask the irq. Yes, we didn't implement disable_irq(). But we must implement mask_irq(). So system suspends. Then system will never be waken up by this irq any more since it's masked. >> And even if you would need this flag, then fiddling with the irq desc >> internals is a big NONO. There is a proper way to hand that in. >> > > So can you suggest the proper way to handle it? Thanks. > >> Thanks, >> >> tglx >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Thu, Feb 27, 2014 at 9:37 AM, Chao Xie xiechao.m...@gmail.com wrote: On Mon, Feb 24, 2014 at 7:31 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 24 Feb 2014, Haojian Zhuang wrote: On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie xiechao.m...@gmail.com wrote: On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Hi Thomas, On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: The pm-mmp2 and pm-pxa910 power management related irq_set_wake callbacks fiddle pointlessly with the irq actions for no reason except for lack of understanding how the wakeup mechanism works. On supsend the core disables all interrupts lazily, i.e. it does not mask them at the irq controller level. So any interrupt which is firing during supsend will mark the corresponding interrupt line as s/supsend/suspend/ twice pending. Just before the core powers down it checks whether there are interrupts pending from interrupt lines which are marked as wakeup sources and if so it aborts the resume and resends the interrupts. It's the suspend that is aborted, not the resume. Other than that your change looks fine. For pxa910 and MMP2, wake up source only wake up the AP subsystem. The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. Now the core is still powered down. APMU will check the interrupt lines, and find that there are interrupt pending, it will power on the cores. So if the irq is disabled, even wake up source can wake up AP subsystem, but the core is still powered down. It will not be powered up by APMU. Yes, suspend/resume can't work if the above code is removed. Interrupt source (logic AND with interrupt mask register) is connected to MPMU as wakeup source. If the interrupt is disabled, there's no wakeup source event. And APMU is waken up by MPMU. So please don't remove the above code. We must keep these interrupt lines active to wake up the whole system. They are kept active at the interrupt controller level. You just refuse to understand how the internals of the interrupt subsystem work. If no irq_disable callback is hooked, when do irq_disable, it will not actually disable the interrupt, it will depend on next time when the irq happens, the handler will first mask the interrupt as this interrupt never happens. So after system suspended, the interrupt happens, but the device driver will not recieve this interrupt because it is masked. It results in that the device driver miss a important interrupt which related to something need to be handled. If user application for example android has power managment daemon. It will find that nothing to handle, it will make the system enter suspend again. Let me list the logic to make it easier to understand. suspend_enter() -- dpm_suspend_end() -- dpm_suspend_noirq() -- suspend_device_irqs() -- __disable_irq() -- set IRQS_SUSPENDED call irq_disable() if necessary -- syscore_suspend() -- check_wakeup_irqs() If there's no pending irq in suspend process IRQS_SUSPENDED is set, then mask the irq. Yes, we didn't implement disable_irq(). But we must implement mask_irq(). So system suspends. Then system will never be waken up by this irq any more since it's masked. And even if you would need this flag, then fiddling with the irq desc internals is a big NONO. There is a proper way to hand that in. So can you suggest the proper way to handle it? Thanks. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regulator: 88pm8607: fix indent code style
On Wed, Feb 26, 2014 at 9:22 AM, Jingoo Han wrote:
> Fix indent code style in order to fix the following checkpatch
> issues.
>
> ERROR: code indent should use tabs where possible
> WARNING: please, no space before tabs
> WARNING: please, no spaces at the start of a line
>
> Signed-off-by: Jingoo Han
> ---
> drivers/regulator/88pm8607.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
> index fa99bfc..337634a 100644
> --- a/drivers/regulator/88pm8607.c
> +++ b/drivers/regulator/88pm8607.c
> @@ -2,7 +2,7 @@
> * Regulators driver for Marvell 88PM8607
> *
> * Copyright (C) 2009 Marvell International Ltd.
> - * Haojian Zhuang
> + * Haojian Zhuang
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -78,7 +78,7 @@ static const unsigned int BUCK2_suspend_table[] = {
> };
>
> static const unsigned int BUCK3_table[] = {
> - 0, 25000, 5, 75000, 10, 125000, 15,
> 175000,
> + 0, 25000, 5, 75000, 10, 125000, 15,
> 175000,
> 20, 225000, 25, 275000, 30, 325000, 35,
> 375000,
> 40, 425000, 45, 475000, 50, 525000, 55,
> 575000,
> 60, 625000, 65, 675000, 70, 725000, 75,
> 775000,
> @@ -89,7 +89,7 @@ static const unsigned int BUCK3_table[] = {
> };
>
> static const unsigned int BUCK3_suspend_table[] = {
> - 0, 25000, 5, 75000, 10, 125000, 15,
> 175000,
> + 0, 25000, 5, 75000, 10, 125000, 15,
> 175000,
> 20, 225000, 25, 275000, 30, 325000, 35,
> 375000,
> 40, 425000, 45, 475000, 500000, 525000, 55,
> 575000,
> 60, 625000, 65, 675000, 70, 725000, 75,
> 775000,
> --
> 1.7.10.4
>
>
Acked-by: Haojian Zhuang
Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regulator: 88pm8607: fix indent code style
On Wed, Feb 26, 2014 at 9:22 AM, Jingoo Han jg1@samsung.com wrote:
Fix indent code style in order to fix the following checkpatch
issues.
ERROR: code indent should use tabs where possible
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/regulator/88pm8607.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index fa99bfc..337634a 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -2,7 +2,7 @@
* Regulators driver for Marvell 88PM8607
*
* Copyright (C) 2009 Marvell International Ltd.
- * Haojian Zhuang haojian.zhu...@marvell.com
+ * Haojian Zhuang haojian.zhu...@marvell.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -78,7 +78,7 @@ static const unsigned int BUCK2_suspend_table[] = {
};
static const unsigned int BUCK3_table[] = {
- 0, 25000, 5, 75000, 10, 125000, 15,
175000,
+ 0, 25000, 5, 75000, 10, 125000, 15,
175000,
20, 225000, 25, 275000, 30, 325000, 35,
375000,
40, 425000, 45, 475000, 50, 525000, 55,
575000,
60, 625000, 65, 675000, 70, 725000, 75,
775000,
@@ -89,7 +89,7 @@ static const unsigned int BUCK3_table[] = {
};
static const unsigned int BUCK3_suspend_table[] = {
- 0, 25000, 5, 75000, 10, 125000, 15,
175000,
+ 0, 25000, 5, 75000, 10, 125000, 15,
175000,
20, 225000, 25, 275000, 30, 325000, 35,
375000,
40, 425000, 45, 475000, 50, 525000, 55,
575000,
60, 625000, 65, 675000, 70, 725000, 75,
775000,
--
1.7.10.4
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
Regards
Haojian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie wrote: > On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König > wrote: >> Hi Thomas, >> >> On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: >>> The pm-mmp2 and pm-pxa910 power management related irq_set_wake >>> callbacks fiddle pointlessly with the irq actions for no reason except >>> for lack of understanding how the wakeup mechanism works. >>> >>> On supsend the core disables all interrupts lazily, i.e. it does not >>> mask them at the irq controller level. So any interrupt which is >>> firing during supsend will mark the corresponding interrupt line as >> s/supsend/suspend/ twice >>> pending. Just before the core powers down it checks whether there are >>> interrupts pending from interrupt lines which are marked as wakeup >>> sources and if so it aborts the resume and resends the interrupts. >> It's the suspend that is aborted, not the resume. >> >> Other than that your change looks fine. >> > For pxa910 and MMP2, wake up source only wake up the AP subsystem. > The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. > Now the core is still powered down. APMU will check the interrupt > lines, and find > that there are interrupt pending, it will power on the cores. > So if the irq is disabled, even wake up source can wake up AP subsystem, but > the > core is still powered down. It will not be powered up by APMU. > Yes, suspend/resume can't work if the above code is removed. Interrupt source (logic AND with interrupt mask register) is connected to MPMU as wakeup source. If the interrupt is disabled, there's no wakeup source event. And APMU is waken up by MPMU. So please don't remove the above code. We must keep these interrupt lines active to wake up the whole system. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie xiechao.m...@gmail.com wrote: On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Hi Thomas, On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: The pm-mmp2 and pm-pxa910 power management related irq_set_wake callbacks fiddle pointlessly with the irq actions for no reason except for lack of understanding how the wakeup mechanism works. On supsend the core disables all interrupts lazily, i.e. it does not mask them at the irq controller level. So any interrupt which is firing during supsend will mark the corresponding interrupt line as s/supsend/suspend/ twice pending. Just before the core powers down it checks whether there are interrupts pending from interrupt lines which are marked as wakeup sources and if so it aborts the resume and resends the interrupts. It's the suspend that is aborted, not the resume. Other than that your change looks fine. For pxa910 and MMP2, wake up source only wake up the AP subsystem. The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. Now the core is still powered down. APMU will check the interrupt lines, and find that there are interrupt pending, it will power on the cores. So if the irq is disabled, even wake up source can wake up AP subsystem, but the core is still powered down. It will not be powered up by APMU. Yes, suspend/resume can't work if the above code is removed. Interrupt source (logic AND with interrupt mask register) is connected to MPMU as wakeup source. If the interrupt is disabled, there's no wakeup source event. And APMU is waken up by MPMU. So please don't remove the above code. We must keep these interrupt lines active to wake up the whole system. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] irqchip: mmp: avoid use head file in a specific arch
On Fri, Dec 6, 2013 at 6:46 PM, Neil Zhang wrote: > For example, arm64 doesn't have mach/irq.h. > > Signed-off-by: Neil Zhang > Acked-by: Haojian Zhuang > --- > drivers/irqchip/irq-mmp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c > index 2cb7cd0..470c5de 100644 > --- a/drivers/irqchip/irq-mmp.c > +++ b/drivers/irqchip/irq-mmp.c > @@ -22,7 +22,7 @@ > #include > > #include > -#include > +#include > > #include "irqchip.h" > > -- > 1.7.9.5 > Hi Thomas, Since this patch is pending for a lot of time, could you help to give an Ack on this? Then I could push it into arm-soc tree. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] irqchip: mmp: avoid use head file in a specific arch
On Fri, Dec 6, 2013 at 6:46 PM, Neil Zhang zhan...@marvell.com wrote: For example, arm64 doesn't have mach/irq.h. Signed-off-by: Neil Zhang zhan...@marvell.com Acked-by: Haojian Zhuang haojian.zhu...@gmail.com --- drivers/irqchip/irq-mmp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c index 2cb7cd0..470c5de 100644 --- a/drivers/irqchip/irq-mmp.c +++ b/drivers/irqchip/irq-mmp.c @@ -22,7 +22,7 @@ #include linux/of_irq.h #include asm/exception.h -#include asm/mach/irq.h +#include asm/hardirq.h #include irqchip.h -- 1.7.9.5 Hi Thomas, Since this patch is pending for a lot of time, could you help to give an Ack on this? Then I could push it into arm-soc tree. Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] ARM: pxa: remove IRQF_DISABLED
On 12/10/2013 01:43 AM, Eric Miao wrote: Haojian, could you help take this via your tree to arm-soc? Applied. Thanks Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: prevent PXA270 occasional reboot freezes
On 12/11/2013 02:31 AM, Marek Vasut wrote: On Tuesday, December 10, 2013 at 11:48:59 AM, Daniel Mack wrote: On 12/10/2013 09:43 AM, Haojian Zhuang wrote: On 12/10/2013 12:39 PM, Sergei Ianovich wrote: Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by: Sergei Ianovich --- arch/arm/mach-pxa/reset.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c index 0d5dd64..263b152 100644 --- a/arch/arm/mach-pxa/reset.c +++ b/arch/arm/mach-pxa/reset.c @@ -13,6 +13,7 @@ #include #include +#include unsigned int reset_status; EXPORT_SYMBOL(reset_status); @@ -81,6 +82,12 @@ static void do_hw_reset(void) writel_relaxed(OSSR_M3, OSSR); /* ... in 100 ms */ writel_relaxed(readl_relaxed(OSCR) + 368640, OSMR3); + /* +* SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71) +* we put SDRAM into self-refresh to prevent that +*/ + while (1) + writel_relaxed(MDREFR_SLFRSH, MDREFR); } void pxa_restart(enum reboot_mode mode, const char *cmd) @@ -104,4 +111,3 @@ void pxa_restart(enum reboot_mode mode, const char *cmd) break; } } - Hi Daniel/Marek/Igor, Could you help to try this patch? I'm lack of PXA27x board. I don't have any either right now ... On VPAC270 Tested-by: Marek Vasut Best regards, Marek Vasut Applied. Thanks Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: prevent PXA270 occasional reboot freezes
On 12/10/2013 12:39 PM, Sergei Ianovich wrote: Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by: Sergei Ianovich --- arch/arm/mach-pxa/reset.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c index 0d5dd64..263b152 100644 --- a/arch/arm/mach-pxa/reset.c +++ b/arch/arm/mach-pxa/reset.c @@ -13,6 +13,7 @@ #include #include +#include unsigned int reset_status; EXPORT_SYMBOL(reset_status); @@ -81,6 +82,12 @@ static void do_hw_reset(void) writel_relaxed(OSSR_M3, OSSR); /* ... in 100 ms */ writel_relaxed(readl_relaxed(OSCR) + 368640, OSMR3); + /* +* SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71) +* we put SDRAM into self-refresh to prevent that +*/ + while (1) + writel_relaxed(MDREFR_SLFRSH, MDREFR); } void pxa_restart(enum reboot_mode mode, const char *cmd) @@ -104,4 +111,3 @@ void pxa_restart(enum reboot_mode mode, const char *cmd) break; } } - Hi Daniel/Marek/Igor, Could you help to try this patch? I'm lack of PXA27x board. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: prevent PXA270 occasional reboot freezes
On 12/11/2013 02:31 AM, Marek Vasut wrote: On Tuesday, December 10, 2013 at 11:48:59 AM, Daniel Mack wrote: On 12/10/2013 09:43 AM, Haojian Zhuang wrote: On 12/10/2013 12:39 PM, Sergei Ianovich wrote: Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by: Sergei Ianovich ynv...@gmail.com --- arch/arm/mach-pxa/reset.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c index 0d5dd64..263b152 100644 --- a/arch/arm/mach-pxa/reset.c +++ b/arch/arm/mach-pxa/reset.c @@ -13,6 +13,7 @@ #include mach/regs-ost.h #include mach/reset.h +#include mach/smemc.h unsigned int reset_status; EXPORT_SYMBOL(reset_status); @@ -81,6 +82,12 @@ static void do_hw_reset(void) writel_relaxed(OSSR_M3, OSSR); /* ... in 100 ms */ writel_relaxed(readl_relaxed(OSCR) + 368640, OSMR3); + /* +* SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71) +* we put SDRAM into self-refresh to prevent that +*/ + while (1) + writel_relaxed(MDREFR_SLFRSH, MDREFR); } void pxa_restart(enum reboot_mode mode, const char *cmd) @@ -104,4 +111,3 @@ void pxa_restart(enum reboot_mode mode, const char *cmd) break; } } - Hi Daniel/Marek/Igor, Could you help to try this patch? I'm lack of PXA27x board. I don't have any either right now ... On VPAC270 Tested-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut Applied. Thanks Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] ARM: pxa: remove IRQF_DISABLED
On 12/10/2013 01:43 AM, Eric Miao wrote: Haojian, could you help take this via your tree to arm-soc? Applied. Thanks Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: prevent PXA270 occasional reboot freezes
On 12/10/2013 12:39 PM, Sergei Ianovich wrote: Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by: Sergei Ianovich ynv...@gmail.com --- arch/arm/mach-pxa/reset.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c index 0d5dd64..263b152 100644 --- a/arch/arm/mach-pxa/reset.c +++ b/arch/arm/mach-pxa/reset.c @@ -13,6 +13,7 @@ #include mach/regs-ost.h #include mach/reset.h +#include mach/smemc.h unsigned int reset_status; EXPORT_SYMBOL(reset_status); @@ -81,6 +82,12 @@ static void do_hw_reset(void) writel_relaxed(OSSR_M3, OSSR); /* ... in 100 ms */ writel_relaxed(readl_relaxed(OSCR) + 368640, OSMR3); + /* +* SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71) +* we put SDRAM into self-refresh to prevent that +*/ + while (1) + writel_relaxed(MDREFR_SLFRSH, MDREFR); } void pxa_restart(enum reboot_mode mode, const char *cmd) @@ -104,4 +111,3 @@ void pxa_restart(enum reboot_mode mode, const char *cmd) break; } } - Hi Daniel/Marek/Igor, Could you help to try this patch? I'm lack of PXA27x board. Best Regards Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] arm: mmp: build sram driver alone
On Thu, Dec 5, 2013 at 10:00 AM, Dan Williams wrote: > On Wed, Dec 4, 2013 at 5:36 PM, Qiao Zhou wrote: >> sram driver can be used by many chips besides CPU_MMP2, and so build >> it alone. Also need to select MMP_SRAM for MMP_TDMA driver. >> >> Reported-by: Dan Williams >> Signed-off-by: Qiao Zhou >> --- > > Looks good, thanks for fixing it up. > > -- > Dan Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] arm: mmp: build sram driver alone
On Thu, Dec 5, 2013 at 10:00 AM, Dan Williams dan.j.willi...@intel.com wrote: On Wed, Dec 4, 2013 at 5:36 PM, Qiao Zhou zhouq...@marvell.com wrote: sram driver can be used by many chips besides CPU_MMP2, and so build it alone. Also need to select MMP_SRAM for MMP_TDMA driver. Reported-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Qiao Zhou zhouq...@marvell.com --- Looks good, thanks for fixing it up. -- Dan Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 V1] arm-mmp-build-sram-driver-alone
On Wed, Dec 4, 2013 at 4:21 PM, Qiao Zhou wrote: > V1 -> V0: > No need for help text for MMP_SRAM in Kconfig and move it into MMP_TDMA > text in Kconfig. > > Qiao Zhou (2): > arm: mmp: build sram driver alone > dma: mmp-tdma: select sram driver > > arch/arm/mach-mmp/Kconfig |3 +++ > arch/arm/mach-mmp/Makefile |3 ++- > drivers/dma/Kconfig|2 ++ > 3 files changed, 7 insertions(+), 1 deletions(-) > Dan indicated that you could pack these two patches into one. Whatever it's also OK to use two patches. Applied. Thanks Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: Remove unused variables
On Wed, Dec 4, 2013 at 6:26 PM, Daniel Mack wrote:
> On 12/04/2013 11:22 AM, Thierry Reding wrote:
>> The conf and of_id variables are assigned but never used, so they may as
>> well just be removed.
>>
>> Signed-off-by: Thierry Reding
>
> Acked-by: Daniel Mack
>
>> ---
>> arch/arm/mach-pxa/irq.c | 4
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
>> index b6cc1816463e..0eecd83c624e 100644
>> --- a/arch/arm/mach-pxa/irq.c
>> +++ b/arch/arm/mach-pxa/irq.c
>> @@ -235,8 +235,6 @@ static const struct of_device_id intc_ids[] __initconst
>> = {
>> void __init pxa_dt_irq_init(int (*fn)(struct irq_data *, unsigned int))
>> {
>> struct device_node *node;
>> - const struct of_device_id *of_id;
>> - struct pxa_intc_conf *conf;
>> struct resource res;
>> int n, ret;
>>
>> @@ -245,8 +243,6 @@ void __init pxa_dt_irq_init(int (*fn)(struct irq_data *,
>> unsigned int))
>> pr_err("Failed to find interrupt controller in arch-pxa\n");
>> return;
>> }
>> - of_id = of_match_node(intc_ids, node);
>> - conf = of_id->data;
>>
>> ret = of_property_read_u32(node, "marvell,intc-nr-irqs",
>> _internal_irq_nr);
>>
>
Applied.
Thanks
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: Remove unused variables
On Wed, Dec 4, 2013 at 6:26 PM, Daniel Mack zon...@gmail.com wrote:
On 12/04/2013 11:22 AM, Thierry Reding wrote:
The conf and of_id variables are assigned but never used, so they may as
well just be removed.
Signed-off-by: Thierry Reding thierry.red...@gmail.com
Acked-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-pxa/irq.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index b6cc1816463e..0eecd83c624e 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -235,8 +235,6 @@ static const struct of_device_id intc_ids[] __initconst
= {
void __init pxa_dt_irq_init(int (*fn)(struct irq_data *, unsigned int))
{
struct device_node *node;
- const struct of_device_id *of_id;
- struct pxa_intc_conf *conf;
struct resource res;
int n, ret;
@@ -245,8 +243,6 @@ void __init pxa_dt_irq_init(int (*fn)(struct irq_data *,
unsigned int))
pr_err(Failed to find interrupt controller in arch-pxa\n);
return;
}
- of_id = of_match_node(intc_ids, node);
- conf = of_id-data;
ret = of_property_read_u32(node, marvell,intc-nr-irqs,
pxa_internal_irq_nr);
Applied.
Thanks
Haojian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 V1] arm-mmp-build-sram-driver-alone
On Wed, Dec 4, 2013 at 4:21 PM, Qiao Zhou zhouq...@marvell.com wrote: V1 - V0: No need for help text for MMP_SRAM in Kconfig and move it into MMP_TDMA text in Kconfig. Qiao Zhou (2): arm: mmp: build sram driver alone dma: mmp-tdma: select sram driver arch/arm/mach-mmp/Kconfig |3 +++ arch/arm/mach-mmp/Makefile |3 ++- drivers/dma/Kconfig|2 ++ 3 files changed, 7 insertions(+), 1 deletions(-) Dan indicated that you could pack these two patches into one. Whatever it's also OK to use two patches. Applied. Thanks Haojian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v2] irqchip: mmp: avoid use head file in a specific arch
On Fri, Oct 11, 2013 at 4:23 PM, Neil Zhang wrote: > For example, arm64 doesn't have mach/irq.h. > > Signed-off-by: Neil Zhang > --- > drivers/irqchip/irq-mmp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c > index 2cb7cd0..470c5de 100644 > --- a/drivers/irqchip/irq-mmp.c > +++ b/drivers/irqchip/irq-mmp.c > @@ -22,7 +22,7 @@ > #include > > #include > -#include > +#include > > #include "irqchip.h" > > -- > 1.7.9.5 > Acked-by: Haojian Zhuang Thomas, Could you help to pick up this patch into your git tree? Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v2] irqchip: mmp: add dt support for wakeup
On Fri, Oct 11, 2013 at 4:23 PM, Neil Zhang wrote:
> Some of the Marvell SoCs use GIC as its interrupt controller,and ICU
> only used as wakeup logic. When AP subsystem is powered off, GIC will
> lose its context, the PMU will need ICU to wakeup the AP subsystem.
> So add wakeup entry for such kind of usage.
>
> Signed-off-by: Neil Zhang
> ---
> .../devicetree/bindings/arm/mrvl/intc.txt | 14 ++-
> drivers/irqchip/irq-mmp.c | 124
>
> include/linux/irqchip/mmp.h| 13 ++
> 3 files changed, 150 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 8b53273..4180928 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -2,7 +2,7 @@
>
> Required properties:
> - compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
> - "mrvl,mmp2-mux-intc"
> + "mrvl,mmp2-mux-intc", "mrvl,mmp-intc-wakeupgen"
> - reg : Address and length of the register set of the interrupt controller.
>If the interrupt controller is intc, address and length means the range
>of the whold interrupt controller. If the interrupt controller is mux-intc,
> @@ -15,6 +15,9 @@ Required properties:
> - interrupt-controller : Identifies the node as an interrupt controller.
> - #interrupt-cells : Specifies the number of cells needed to encode an
>interrupt source.
> +- mrvl,intc-gbl-mask : Specifies the address and value for global mask in the
> + interrupt controller.
As my understanding, we should avoid to write register settings in DTS file.
Loop devicetree guys.
> +- mrvl,intc-for-cp : Specifies the irqs that will be routed to cp
> - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
>controller.
> - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
> @@ -39,6 +42,15 @@ Example:
> mrvl,intc-nr-irqs = <2>;
> };
>
> + intc: wakeupgen@d4282000 {
> + compatible = "mrvl,mmp-intc-wakeupgen";
> + reg = <0xd4282000 0x1000>;
> + mrvl,intc-nr-irqs = <64>;
> + mrvl,intc-gbl-mask = <0x114 0x3
> + 0x144 0x3>;
> + mrvl,intc-for-cp = <0 31 32>;
> + };
> +
> * Marvell Orion Interrupt controller
>
> Required properties
> diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
> index 470c5de..445a00c 100644
> --- a/drivers/irqchip/irq-mmp.c
> +++ b/drivers/irqchip/irq-mmp.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -58,6 +60,8 @@ struct mmp_intc_conf {
> static void __iomem *mmp_icu_base;
> static struct icu_chip_data icu_data[MAX_ICU_NR];
> static int max_icu_nr;
> +static u32 irq_for_cp[64];
> +static u32 irq_for_cp_nr; /* How many irqs will be routed to cp */
>
> extern void mmp2_clear_pmic_int(void);
>
> @@ -123,6 +127,50 @@ static void icu_unmask_irq(struct irq_data *d)
> }
> }
>
> +static int irq_ignore_wakeup(struct icu_chip_data *data, int hwirq)
> +{
> + int i;
> +
> + if (hwirq < 0 || hwirq >= data->nr_irqs)
> + return 1;
> +
> + for (i = 0; i < irq_for_cp_nr; i++)
> + if (irq_for_cp[i] == hwirq)
> + return 1;
> +
> + return 0;
> +}
> +
> +static void icu_mask_irq_wakeup(struct irq_data *d)
> +{
> + struct icu_chip_data *data = _data[0];
> + int hwirq = d->hwirq - data->virq_base;
> + u32 r;
> +
> + if (irq_ignore_wakeup(data, hwirq))
> + return;
> +
> + r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> + r &= ~data->conf_mask;
> + r |= data->conf_disable;
> + writel_relaxed(r, mmp_icu_base + (hwirq << 2));
> +}
> +
> +static void icu_unmask_irq_wakeup(struct irq_data *d)
> +{
> + struct icu_chip_data *data = _data[0];
> + int hwirq = d->irq - data->virq_base;
> + u32 r;
> +
> + if (irq_ignore_wakeup(data, hwirq))
> + return;
> +
> + r = readl_relaxed(mmp_icu_base + (hwirq << 2));
> + r &= ~data->conf_mask;
> + r |= data->conf_enable;
> + writel_relaxed(r, mmp_icu_base + (hwirq << 2));
> +}
> +
> struct irq_chip icu_irq_chip = {
> .name = "icu_irq",
> .irq_mask = icu_mask_irq,
> @@ -491,5 +539,81 @@ err:
> irq_domain_remove(icu_data[i].domain);
> return -EINVAL;
> }
> +
> +void __init mmp_of_wakeup_init(void)
> +{
> + struct device_node *node;
> + const __be32 *wakeup_reg;
> + const __be32 *cp_irq_reg;
> + int ret, nr_irqs;
> + int size, i = 0;
> + int irq;
> +
> + node = of_find_compatible_node(NULL, NULL, "mrvl,mmp-intc-wakeupgen");
> + if (!node) {
> +
