* Re: [jeyu:modules-next 3/11] arc4.c:(___ksymtab+arc4_setkey+0x8): undefined reference to `no symbol'
From: Jessica Yu @ 2019-09-11 10:32 UTC (permalink / raw)
To: Matthias Maennich
Cc: Arnd Bergmann, Ard Biesheuvel, Greg Kroah-Hartman, Will Deacon,
Catalin Marinas, Martijn Coenen, linux-arm-kernel
In-Reply-To: <20190911052124.GA247847@google.com>
+++ Matthias Maennich [11/09/19 06:21 +0100]:
>On Wed, Sep 11, 2019 at 03:11:53AM +0800, kbuild test robot wrote:
>>tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/jeyu/linux.git modules-next
>>head: 32bca2df7da27be34371a37f9bb5e2b85fdd92bd
>>commit: 8651ec01daedad26290f76beeb4736f9d2da4b87 [3/11] module: add support for symbol namespaces.
>>config: arm64-defconfig (attached as .config)
>>compiler: aarch64-linux-gcc (GCC) 7.4.0
>>reproduce:
>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 8651ec01daedad26290f76beeb4736f9d2da4b87
>> # save the attached .config to linux build tree
>> GCC_VERSION=7.4.0 make.cross ARCH=arm64
>>
>>If you fix the issue, kindly add following tag
>>Reported-by: kbuild test robot <lkp@intel.com>
>>
>>All errors (new ones prefixed by >>):
>>
>> lib/crypto/arc4.o: In function `__ksymtab_arc4_setkey':
>>>>arc4.c:(___ksymtab+arc4_setkey+0x8): undefined reference to `no symbol'
>> lib/crypto/arc4.o: In function `__ksymtab_arc4_crypt':
>>>>arc4.c:(___ksymtab+arc4_crypt+0x8): undefined reference to `no symbol'
>
>Hmm, this is caused by the relative relocation of the 'namespace_offset'
>struct member to NULL in case there is no namespace defined:
>
>#define __KSYMTAB_ENTRY(sym, sec) \
> __ADDRESSABLE(sym) \
> asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
> " .balign 4 \n" \
> "__ksymtab_" #sym ": \n" \
> " .long " #sym "- . \n" \
> " .long __kstrtab_" #sym "- . \n" \
> " .long 0 - . \n" \
> ^^^^^^^
> " .previous \n")
>
>struct kernel_symbol {
> int value_offset;
> int name_offset;
> int namespace_offset;
>};
>
>That is apparently not an issue on x86, but on arm. Not sure how to
>express a relative relocation to NULL then.
>
>I will try to solve this somehow, just wanted to check if somebody knows the
>trick here.
(Adding more CC's..)
Do we have to have a place-relative relocation there? If we can't find
a workaround, having just .long 0 for a null namespace seemed to fix the
build issues on arm64 for me at least..
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [jeyu:modules-next 3/11] arc4.c:(___ksymtab+arc4_setkey+0x8): undefined reference to `no symbol'
From: Will Deacon @ 2019-09-11 10:36 UTC (permalink / raw)
To: Jessica Yu
Cc: Arnd Bergmann, Ard Biesheuvel, Catalin Marinas, Matthias Maennich,
graf, Greg Kroah-Hartman, Martijn Coenen, linux-arm-kernel
In-Reply-To: <20190911103217.GA27338@linux-8ccs.fritz.box>
Hi all,
On Wed, Sep 11, 2019 at 12:32:18PM +0200, Jessica Yu wrote:
> +++ Matthias Maennich [11/09/19 06:21 +0100]:
> > On Wed, Sep 11, 2019 at 03:11:53AM +0800, kbuild test robot wrote:
> > > tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/jeyu/linux.git modules-next
> > > head: 32bca2df7da27be34371a37f9bb5e2b85fdd92bd
> > > commit: 8651ec01daedad26290f76beeb4736f9d2da4b87 [3/11] module: add support for symbol namespaces.
> > > config: arm64-defconfig (attached as .config)
> > > compiler: aarch64-linux-gcc (GCC) 7.4.0
> > > reproduce:
> > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > git checkout 8651ec01daedad26290f76beeb4736f9d2da4b87
> > > # save the attached .config to linux build tree
> > > GCC_VERSION=7.4.0 make.cross ARCH=arm64
> > >
> > > If you fix the issue, kindly add following tag
> > > Reported-by: kbuild test robot <lkp@intel.com>
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > lib/crypto/arc4.o: In function `__ksymtab_arc4_setkey':
> > > > > arc4.c:(___ksymtab+arc4_setkey+0x8): undefined reference to `no symbol'
> > > lib/crypto/arc4.o: In function `__ksymtab_arc4_crypt':
> > > > > arc4.c:(___ksymtab+arc4_crypt+0x8): undefined reference to `no symbol'
> >
> > Hmm, this is caused by the relative relocation of the 'namespace_offset'
> > struct member to NULL in case there is no namespace defined:
> >
> > #define __KSYMTAB_ENTRY(sym, sec) \
> > __ADDRESSABLE(sym) \
> > asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
> > " .balign 4 \n" \
> > "__ksymtab_" #sym ": \n" \
> > " .long " #sym "- . \n" \
> > " .long __kstrtab_" #sym "- . \n" \
> > " .long 0 - . \n" \
> > ^^^^^^^
> > " .previous \n")
> >
> > struct kernel_symbol {
> > int value_offset;
> > int name_offset;
> > int namespace_offset;
> > };
> >
> > That is apparently not an issue on x86, but on arm. Not sure how to
> > express a relative relocation to NULL then.
> >
> > I will try to solve this somehow, just wanted to check if somebody knows the
> > trick here.
>
> (Adding more CC's..)
>
> Do we have to have a place-relative relocation there? If we can't find
> a workaround, having just .long 0 for a null namespace seemed to fix the
> build issues on arm64 for me at least..
Ard, Alex and I have hacked the following diff which seems to do the trick.
I'll post as a proper patch later today.
Will
--->8
diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
index e2b5d0f569d3..d0912c7ac2fc 100644
--- a/include/asm-generic/export.h
+++ b/include/asm-generic/export.h
@@ -17,7 +17,7 @@
.macro __put, val, name
#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
- .long \val - ., \name - ., 0 - .
+ .long \val - ., \name - ., 0
#elif defined(CONFIG_64BIT)
.quad \val, \name, 0
#else
diff --git a/include/linux/export.h b/include/linux/export.h
index 2c5468d8ea9a..ef5d015d754a 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -68,7 +68,7 @@ extern struct module __this_module;
"__ksymtab_" #sym ": \n" \
" .long " #sym "- . \n" \
" .long __kstrtab_" #sym "- . \n" \
- " .long 0 - . \n" \
+ " .long 0 \n" \
" .previous \n")
struct kernel_symbol {
diff --git a/kernel/module.c b/kernel/module.c
index f76efcf2043e..7ab244c4e1ba 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -547,6 +547,8 @@ static const char *kernel_symbol_name(const struct kernel_symbol *sym)
static const char *kernel_symbol_namespace(const struct kernel_symbol *sym)
{
#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
+ if (!sym->namespace_offset)
+ return NULL;
return offset_to_ptr(&sym->namespace_offset);
#else
return sym->namespace;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-11 10:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Ingo Molnar, linux-arm-kernel,
linux-mips, linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn,
linuxppc-dev, linux-m68k, Al Viro, Andy Lutomirski, Shuah Khan,
Namhyung Kim, David Drysdale, Christian Brauner, J. Bruce Fields,
linux-parisc, linux-api, Chanho Min, Jeff Layton, Oleg Nesterov,
patrick.bellasi, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190905105749.GW2386@hirez.programming.kicks-ass.net>
[-- Attachment #1.1: Type: text/plain, Size: 3879 bytes --]
On 2019-09-05, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Sep 05, 2019 at 11:43:05AM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote:
> > > On 2019-09-05, Peter Zijlstra <peterz@infradead.org> wrote:
> > > > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > > > > +/**
> > > > > + * copy_struct_to_user: copy a struct to user space
> > > > > + * @dst: Destination address, in user space.
> > > > > + * @usize: Size of @dst struct.
> > > > > + * @src: Source address, in kernel space.
> > > > > + * @ksize: Size of @src struct.
> > > > > + *
> > > > > + * Copies a struct from kernel space to user space, in a way that guarantees
> > > > > + * backwards-compatibility for struct syscall arguments (as long as future
> > > > > + * struct extensions are made such that all new fields are *appended* to the
> > > > > + * old struct, and zeroed-out new fields have the same meaning as the old
> > > > > + * struct).
> > > > > + *
> > > > > + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> > > > > + * The recommended usage is something like the following:
> > > > > + *
> > > > > + * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
> > > > > + * {
> > > > > + * int err;
> > > > > + * struct foo karg = {};
> > > > > + *
> > > > > + * // do something with karg
> > > > > + *
> > > > > + * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
> > > > > + * if (err)
> > > > > + * return err;
> > > > > + *
> > > > > + * // ...
> > > > > + * }
> > > > > + *
> > > > > + * There are three cases to consider:
> > > > > + * * If @usize == @ksize, then it's copied verbatim.
> > > > > + * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
> > > > > + * older user space. In order to avoid user space getting incomplete
> > > > > + * information (new fields might be important), all trailing bytes in @src
> > > > > + * (@ksize - @usize) must be zerored
> > > >
> > > > s/zerored/zero/, right?
> > >
> > > It should've been "zeroed".
> >
> > That reads wrong to me; that way it reads like this function must take
> > that action and zero out the 'rest'; which is just wrong.
> >
> > This function must verify those bytes are zero, not make them zero.
> >
> > > > > , otherwise -EFBIG is returned.
> > > >
> > > > 'Funny' that, copy_struct_from_user() below seems to use E2BIG.
> > >
> > > This is a copy of the semantics that sched_[sg]etattr(2) uses -- E2BIG for
> > > a "too big" struct passed to the kernel, and EFBIG for a "too big"
> > > struct passed to user-space. I would personally have preferred EMSGSIZE
> > > instead of EFBIG, but felt using the existing error codes would be less
> > > confusing.
> >
> > Sadly a recent commit:
> >
> > 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code")
> >
> > Made the situation even 'worse'.
>
> And thinking more about things; I'm not convinced the above patch is
> actually right.
>
> Do we really want to simply truncate all the attributes of the task?
>
> And should we not at least set sched_flags when there are non-default
> clamp values applied?
>
> See; that is I think the primary bug that had chrt failing; we tried to
> publish the default clamp values as !0.
I just saw this patch in -rc8 -- should I even attempt to port
sched_getattr(2) to copy_struct_to_user()? I agree that publishing a
default non-zero value is a mistake -- once you do that, old user space
will either get confused or lose information.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: swiotlb-xen cleanups v4
From: Christoph Hellwig @ 2019-09-11 10:45 UTC (permalink / raw)
To: Stefano Stabellini, Konrad Rzeszutek Wilk, gross, boris.ostrovsky
Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <20190905113408.3104-1-hch@lst.de>
Applied to the dma-mapping tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v1 1/3] scsi: core: allow auto suspend override by low-level driver
From: Avri Altman @ 2019-09-11 10:54 UTC (permalink / raw)
To: Stanley Chu, linux-scsi@vger.kernel.org,
martin.petersen@oracle.com, alim.akhtar@samsung.com,
pedrom.sousa@synopsys.com, sthumma@codeaurora.org,
jejb@linux.ibm.com, bvanassche@acm.org
Cc: marc.w.gonzalez@free.fr, andy.teng@mediatek.com,
chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
evgreen@chromium.org, subhashj@codeaurora.org,
linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
vivek.gautam@codeaurora.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
In-Reply-To: <1568194890-24439-2-git-send-email-stanley.chu@mediatek.com>
>
> Rework from previous work by:
> Sujit Reddy Thumma <sthumma@codeaurora.org>
>
> Until now the scsi mid-layer forbids runtime suspend till userspace enables it.
> This is mainly to quarantine some disks with broken runtime power
> management or have high latencies executing suspend resume callbacks. If
> the userspace doesn't enable the runtime suspend the underlying hardware
> will be always on even when it is not doing any useful work and thus wasting
> power.
>
> Some low-level drivers for the controllers can efficiently use runtime power
> management to reduce power consumption and improve battery life.
> Allow runtime suspend parameters override within the LLD itself instead of
> waiting for userspace to control the power management.
>
> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Stanley hi,
Your series looks fine.
I added some comments/questions - feel free to ignore it.
Thanks,
Avri
> ---
> drivers/scsi/scsi_sysfs.c | 3 ++-
> drivers/scsi/sd.c | 3 +++
> include/scsi/scsi_device.h | 2 +-
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index
> 64c96c7828ee..66a8a5c74352 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1300,7 +1300,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> device_enable_async_suspend(&sdev->sdev_gendev);
> scsi_autopm_get_target(starget);
> pm_runtime_set_active(&sdev->sdev_gendev);
> - pm_runtime_forbid(&sdev->sdev_gendev);
> + if (sdev->rpm_autosuspend_delay <= 0)
> + pm_runtime_forbid(&sdev->sdev_gendev);
> pm_runtime_enable(&sdev->sdev_gendev);
> scsi_autopm_put_target(starget);
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index
> 149d406aacc9..2218d57c4c0c 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -3371,6 +3371,9 @@ static int sd_probe(struct device *dev)
> }
>
> blk_pm_runtime_init(sdp->request_queue, dev);
> + if (sdp->rpm_autosuspend_delay > 0)
> + pm_runtime_set_autosuspend_delay(dev,
> +
Redundant line ?
> + sdp->rpm_autosuspend_delay);
Don't you need to call now pm_runtime_use_autosuspend() ?
> device_add_disk(dev, gd, NULL);
> if (sdkp->capacity)
> sd_dif_config_host(sdkp); diff --git a/include/scsi/scsi_device.h
> b/include/scsi/scsi_device.h index 202f4d6a4342..133b282fae5a 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -199,7 +199,7 @@ struct scsi_device {
> unsigned broken_fua:1; /* Don't set FUA bit */
> unsigned lun_in_cdb:1; /* Store LUN bits in CDB[1] */
> unsigned unmap_limit_for_ws:1; /* Use the UNMAP limit for WRITE
> SAME */
> -
> + int rpm_autosuspend_delay;
Can suspend be negative?
> atomic_t disk_events_disable_depth; /* disable depth for disk events */
>
> DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /*
> supported events */
> --
> 2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/4] arm64: use both ZONE_DMA and ZONE_DMA32
From: Nicolas Saenz Julienne @ 2019-09-11 10:54 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
linux-arm-kernel, linux-mm, linux-riscv, Will Deacon
Cc: f.fainelli, linux-kernel, mbrugger, linux-rpi-kernel, phill,
robin.murphy, m.szyprowski
In-Reply-To: <20190909095807.18709-4-nsaenzjulienne@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1180 bytes --]
On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> +
> /*
> - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> - * currently assumes that for memory starting above 4G, 32-bit devices will
> - * use a DMA offset.
> + * Return the maximum physical address for a zone with a given address size
> + * limit. It currently assumes that for memory starting above 4G, 32-bit
> + * devices will use a DMA offset.
> */
> -static phys_addr_t __init max_zone_dma32_phys(void)
> +static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> {
> phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
> - return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> + return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> }
Hi all,
while testing other code on top of this series on odd arm64 machines I found an
issue: when memblock_start_of_DRAM() != 0, max_zone_phys() isn't taking into
account the offset to the beginning of memory. This doesn't matter with
zone_bits == 32 but it does when zone_bits == 30.
I'll send a follow-up series.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v1 2/3] scsi: ufs: override auto suspend tunables for ufs
From: Avri Altman @ 2019-09-11 10:56 UTC (permalink / raw)
To: Stanley Chu, linux-scsi@vger.kernel.org,
martin.petersen@oracle.com, alim.akhtar@samsung.com,
pedrom.sousa@synopsys.com, sthumma@codeaurora.org,
jejb@linux.ibm.com, bvanassche@acm.org
Cc: marc.w.gonzalez@free.fr, andy.teng@mediatek.com,
chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
evgreen@chromium.org, subhashj@codeaurora.org,
linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
vivek.gautam@codeaurora.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
In-Reply-To: <1568194890-24439-3-git-send-email-stanley.chu@mediatek.com>
>
> Rework from previous work by:
> Sujit Reddy Thumma <sthumma@codeaurora.org>
>
> Override auto suspend tunables for UFS device LUNs during initialization so
> as to efficiently manage background operations and the power consumption.
>
> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 8 ++++++++ drivers/scsi/ufs/ufshcd.h | 10
> ++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> 30b752c61b97..d253a018a73b 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -88,6 +88,9 @@
> /* Interrupt aggregation default timeout, unit: 40us */
> #define INT_AGGR_DEF_TO 0x02
>
> +/* default delay of autosuspend: 2000 ms */ #define
Typo?
> +RPM_AUTOSUSPEND_DELAY_MS 2000
> +
> #define ufshcd_toggle_vreg(_dev, _vreg, _on) \
> ({ \
> int _ret; \
> @@ -4612,9 +4615,14 @@ static int ufshcd_change_queue_depth(struct
> scsi_device *sdev, int depth)
> */
> static int ufshcd_slave_configure(struct scsi_device *sdev) {
> + struct ufs_hba *hba = shost_priv(sdev->host);
> struct request_queue *q = sdev->request_queue;
>
> blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
> +
> + if (ufshcd_is_rpm_autosuspend_allowed(hba))
> + sdev->rpm_autosuspend_delay =
> RPM_AUTOSUSPEND_DELAY_MS;
> +
> return 0;
> }
>
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
> a43c7135f33d..99ea416519af 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -714,6 +714,12 @@ struct ufs_hba {
> * the performance of ongoing read/write operations.
> */
> #define UFSHCD_CAP_KEEP_AUTO_BKOPS_ENABLED_EXCEPT_SUSPEND (1
> << 5)
> + /*
> + * This capability allows host controller driver to automatically
> + * enable runtime power management by itself instead of waiting
> + * for userspace to control the power management.
> + */
> +#define UFSHCD_CAP_RPM_AUTOSUSPEND (1 << 6)
>
> struct devfreq *devfreq;
> struct ufs_clk_scaling clk_scaling; @@ -747,6 +753,10 @@ static inline
> bool ufshcd_can_autobkops_during_suspend(struct ufs_hba *hba) {
> return hba->caps & UFSHCD_CAP_AUTO_BKOPS_SUSPEND; }
> +static inline bool ufshcd_is_rpm_autosuspend_allowed(struct ufs_hba
> +*hba) {
> + return hba->caps & UFSHCD_CAP_RPM_AUTOSUSPEND; }
>
> static inline bool ufshcd_is_intr_aggr_allowed(struct ufs_hba *hba) {
> --
> 2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v1 3/3] scsi: ufs-mediatek: enable auto suspend capability
From: Avri Altman @ 2019-09-11 10:58 UTC (permalink / raw)
To: Stanley Chu, linux-scsi@vger.kernel.org,
martin.petersen@oracle.com, alim.akhtar@samsung.com,
pedrom.sousa@synopsys.com, sthumma@codeaurora.org,
jejb@linux.ibm.com, bvanassche@acm.org
Cc: marc.w.gonzalez@free.fr, andy.teng@mediatek.com,
chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
evgreen@chromium.org, subhashj@codeaurora.org,
linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
vivek.gautam@codeaurora.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
In-Reply-To: <1568194890-24439-4-git-send-email-stanley.chu@mediatek.com>
>
> Enable auto suspend capability in MediaTek UFS driver.
>
> Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
> ---
> drivers/scsi/ufs/ufs-mediatek.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
> index 0f6ff33ce52e..b7b177c6194c 100644
> --- a/drivers/scsi/ufs/ufs-mediatek.c
> +++ b/drivers/scsi/ufs/ufs-mediatek.c
> @@ -117,6 +117,11 @@ static int ufs_mtk_setup_clocks(struct ufs_hba
> *hba, bool on,
> return ret;
> }
>
> +static void ufs_mtk_set_caps(struct ufs_hba *hba) {
> + hba->caps |= UFSHCD_CAP_RPM_AUTOSUSPEND; }
Even a one-liner deserve new line for its closing brackets
> +
> /**
> * ufs_mtk_init - find other essential mmio bases
> * @hba: host controller instance
> @@ -147,6 +152,8 @@ static int ufs_mtk_init(struct ufs_hba *hba)
> if (err)
> goto out_variant_clear;
>
> + ufs_mtk_set_caps(hba);
> +
> /*
> * ufshcd_vops_init() is invoked after
> * ufshcd_setup_clock(true) in ufshcd_hba_init() thus
> --
> 2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/6] PCI: amlogic: Fix probed clock names
From: Andrew Murray @ 2019-09-11 10:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <1567950178-4466-3-git-send-email-narmstrong@baylibre.com>
On Sun, Sep 08, 2019 at 01:42:54PM +0000, Neil Armstrong wrote:
> Fix the clock names used in the probe function according
> to the bindings.
>
> Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> ---
> drivers/pci/controller/dwc/pci-meson.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
> index 541f37a6f6a5..ab79990798f8 100644
> --- a/drivers/pci/controller/dwc/pci-meson.c
> +++ b/drivers/pci/controller/dwc/pci-meson.c
> @@ -250,15 +250,15 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
> if (IS_ERR(res->port_clk))
> return PTR_ERR(res->port_clk);
>
> - res->mipi_gate = meson_pcie_probe_clock(dev, "pcie_mipi_en", 0);
> + res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> if (IS_ERR(res->mipi_gate))
> return PTR_ERR(res->mipi_gate);
>
> - res->general_clk = meson_pcie_probe_clock(dev, "pcie_general", 0);
> + res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
> if (IS_ERR(res->general_clk))
> return PTR_ERR(res->general_clk);
>
> - res->clk = meson_pcie_probe_clock(dev, "pcie", 0);
> + res->clk = meson_pcie_probe_clock(dev, "pclk", 0);
> if (IS_ERR(res->clk))
> return PTR_ERR(res->clk);
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 11:36 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal,
Konrad Rzeszutek Wilk, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <1d7de9f9f4074f67c567dbb4cc1497503d739e30.camel@linux.intel.com>
On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
[...]
> We don't put any limitations on the allocator other then that it needs to
> clean up the metadata on allocation, and that it cannot allocate a page
> that is in the process of being reported since we pulled it from the
> free_list. If the page is a "Reported" page then it decrements the
> reported_pages count for the free_area and makes sure the page doesn't
> exist in the "Boundary" array pointer value, if it does it moves the
> "Boundary" since it is pulling the page.
This is still a non-trivial limitation on the page allocation from an
external code IMHO. I cannot give any explicit reason why an ordering on
the free list might matter (well except for page shuffling which uses it
to make physical memory pattern allocation more random) but the
architecture seems hacky and dubious to be honest. It shoulds like the
whole interface has been developed around a very particular and single
purpose optimization.
I remember that there was an attempt to report free memory that provided
a callback mechanism [1], which was much less intrusive to the internals
of the allocator yet it should provide a similar functionality. Did you
see that approach? How does this compares to it? Or am I completely off
when comparing them?
[1] mostly likely not the latest version of the patchset
http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] PCI: amlogic: meson: Add support for G12A
From: Andrew Murray @ 2019-09-11 11:36 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <1567950178-4466-4-git-send-email-narmstrong@baylibre.com>
On Sun, Sep 08, 2019 at 01:42:55PM +0000, Neil Armstrong wrote:
> Add support for the Amlogic G12A SoC using a separate shared PHY.
>
> This adds support for fetching a PHY phandle and call the PHY init,
> reset and power on/off calls instead of writing in the PHY register or
> toggling the PHY reset line.
>
> The MIPI clock is also made optional since it is used for setting up
Is it worth indicating here that the MIPI clock is *only required* for
the G12A (or controllers with a shared phy)? It's still required for
AXG. It's not optional for G12A - it's ignored.
> the PHY reference clock chared with the DSI controller on AXG.
s/chared/shared/
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/pci/controller/dwc/pci-meson.c | 101 ++++++++++++++++++++-----
> 1 file changed, 84 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
> index ab79990798f8..3fadad381762 100644
> --- a/drivers/pci/controller/dwc/pci-meson.c
> +++ b/drivers/pci/controller/dwc/pci-meson.c
> @@ -16,6 +16,7 @@
> #include <linux/reset.h>
> #include <linux/resource.h>
> #include <linux/types.h>
> +#include <linux/phy/phy.h>
>
> #include "pcie-designware.h"
>
> @@ -96,12 +97,18 @@ struct meson_pcie_rc_reset {
> struct reset_control *apb;
> };
>
> +struct meson_pcie_param {
> + bool has_shared_phy;
> +};
> +
> struct meson_pcie {
> struct dw_pcie pci;
> struct meson_pcie_mem_res mem_res;
> struct meson_pcie_clk_res clk_res;
> struct meson_pcie_rc_reset mrst;
> struct gpio_desc *reset_gpio;
> + struct phy *phy;
> + const struct meson_pcie_param *param;
> };
>
> static struct reset_control *meson_pcie_get_reset(struct meson_pcie *mp,
> @@ -123,10 +130,12 @@ static int meson_pcie_get_resets(struct meson_pcie *mp)
> {
> struct meson_pcie_rc_reset *mrst = &mp->mrst;
>
> - mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> - if (IS_ERR(mrst->phy))
> - return PTR_ERR(mrst->phy);
> - reset_control_deassert(mrst->phy);
> + if (!mp->param->has_shared_phy) {
> + mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> + if (IS_ERR(mrst->phy))
> + return PTR_ERR(mrst->phy);
> + reset_control_deassert(mrst->phy);
> + }
>
> mrst->port = meson_pcie_get_reset(mp, "port", PCIE_NORMAL_RESET);
> if (IS_ERR(mrst->port))
> @@ -180,6 +189,9 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
> if (IS_ERR(mp->mem_res.cfg_base))
> return PTR_ERR(mp->mem_res.cfg_base);
>
> + if (mp->param->has_shared_phy)
> + return 0;
> +
It may be more consistent if, rather than returning here, you wrapped
the following 3 lines by the if statement.
> /* Meson SoC has two PCI controllers use same phy register*/
I guess this comment should now be updated to refer to AXG?
> mp->mem_res.phy_base = meson_pcie_get_mem_shared(pdev, mp, "phy");
> if (IS_ERR(mp->mem_res.phy_base))
> @@ -188,19 +200,33 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
> return 0;
> }
>
> -static void meson_pcie_power_on(struct meson_pcie *mp)
> +static int meson_pcie_power_on(struct meson_pcie *mp)
> {
> - writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> + int ret = 0;
> +
> + if (mp->param->has_shared_phy)
> + ret = phy_power_on(mp->phy);
I haven't seen any phy_[init/exit] calls, should there be any?
> + else
> + writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> +
> + return ret;
> }
>
> -static void meson_pcie_reset(struct meson_pcie *mp)
> +static int meson_pcie_reset(struct meson_pcie *mp)
> {
> struct meson_pcie_rc_reset *mrst = &mp->mrst;
> -
> - reset_control_assert(mrst->phy);
> - udelay(PCIE_RESET_DELAY);
> - reset_control_deassert(mrst->phy);
> - udelay(PCIE_RESET_DELAY);
> + int ret = 0;
> +
> + if (mp->param->has_shared_phy) {
> + ret = phy_reset(mp->phy);
> + if (ret)
> + return ret;
> + } else {
> + reset_control_assert(mrst->phy);
> + udelay(PCIE_RESET_DELAY);
> + reset_control_deassert(mrst->phy);
> + udelay(PCIE_RESET_DELAY);
> + }
>
> reset_control_assert(mrst->port);
> reset_control_assert(mrst->apb);
> @@ -208,6 +234,8 @@ static void meson_pcie_reset(struct meson_pcie *mp)
> reset_control_deassert(mrst->port);
> reset_control_deassert(mrst->apb);
> udelay(PCIE_RESET_DELAY);
> +
> + return 0;
> }
>
> static inline struct clk *meson_pcie_probe_clock(struct device *dev,
> @@ -250,9 +278,11 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
> if (IS_ERR(res->port_clk))
> return PTR_ERR(res->port_clk);
>
> - res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> - if (IS_ERR(res->mipi_gate))
> - return PTR_ERR(res->mipi_gate);
> + if (!mp->param->has_shared_phy) {
> + res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> + if (IS_ERR(res->mipi_gate))
> + return PTR_ERR(res->mipi_gate);
> + }
>
> res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
> if (IS_ERR(res->general_clk))
> @@ -524,6 +554,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
>
> static int meson_pcie_probe(struct platform_device *pdev)
> {
> + const struct meson_pcie_param *match_data;
> struct device *dev = &pdev->dev;
> struct dw_pcie *pci;
> struct meson_pcie *mp;
> @@ -537,6 +568,20 @@ static int meson_pcie_probe(struct platform_device *pdev)
> pci->dev = dev;
> pci->ops = &dw_pcie_ops;
>
> + match_data = of_device_get_match_data(dev);
> + if (!match_data) {
> + dev_err(dev, "failed to get match data\n");
> + return -ENODEV;
> + }
> + mp->param = match_data;
> +
> + if (mp->param->has_shared_phy) {
> + mp->phy = devm_phy_get(dev, "pcie");
> + if (IS_ERR(mp->phy)) {
> + return PTR_ERR(mp->phy);
> + }
> + }
> +
> mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(mp->reset_gpio)) {
> dev_err(dev, "get reset gpio failed\n");
> @@ -555,8 +600,17 @@ static int meson_pcie_probe(struct platform_device *pdev)
> return ret;
> }
>
> - meson_pcie_power_on(mp);
> - meson_pcie_reset(mp);
> + ret = meson_pcie_power_on(mp);
> + if (ret) {
> + dev_err(dev, "phy power on failed, %d\n", ret);
> + return ret;
> + }
> +
> + ret = meson_pcie_reset(mp);
> + if (ret) {
> + dev_err(dev, "reset failed, %d\n", ret);
> + return ret;
> + }
>
> ret = meson_pcie_probe_clocks(mp);
> if (ret) {
> @@ -575,9 +629,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static struct meson_pcie_param meson_pcie_axg_param = {
> + .has_shared_phy = false,
> +};
> +
> +static struct meson_pcie_param meson_pcie_g12a_param = {
> + .has_shared_phy = true,
> +};
> +
> static const struct of_device_id meson_pcie_of_match[] = {
> {
> .compatible = "amlogic,axg-pcie",
> + .data = &meson_pcie_axg_param,
> + },
> + {
> + .compatible = "amlogic,g12a-pcie",
> + .data = &meson_pcie_g12a_param,
Here, we hard-code knowledge about the SOCs regarding if they have shared phys
or not. I guess the alternative would have been to assume there is a shared
phy if the DT has a phandle for it. I.e. instead of mp->param->has_shared_phy
everywhere you could test for mp->phy. Though I guess at least with the
current approach you guard against bad DTs, this seems OK.
Thanks,
Andrew Murray
> },
> {},
> };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH] memory: atmel-ebi: move NUM_CS definition inside EBI driver
From: Alexandre Belloni @ 2019-09-11 11:37 UTC (permalink / raw)
To: Tudor.Ambarus
Cc: Ludovic.Desroches, lee.jones, linux-arm-kernel, linux-kernel
In-Reply-To: <20190906150632.19039-1-tudor.ambarus@microchip.com>
On 06/09/2019 15:06:41+0000, Tudor.Ambarus@microchip.com wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> The total number of EBI CS lines is described by the EBI controller
> and not by the Matrix. Move the definition for the number of CS
> inside EBI driver.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/memory/atmel-ebi.c | 6 ++++--
> include/linux/mfd/syscon/atmel-matrix.h | 1 -
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH] memory: atmel-ebi: switch to SPDX license identifiers
From: Alexandre Belloni @ 2019-09-11 11:37 UTC (permalink / raw)
To: Tudor.Ambarus; +Cc: Ludovic.Desroches, linux-arm-kernel, linux-kernel
In-Reply-To: <20190906151519.19442-1-tudor.ambarus@microchip.com>
On 06/09/2019 15:15:28+0000, Tudor.Ambarus@microchip.com wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> Adopt the SPDX license identifiers to ease license compliance
> management.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/memory/atmel-ebi.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: module: Drop 'rel->r_offset < 0' always false statement
From: Austin Kim @ 2019-09-11 11:42 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: matthias.schiffer, info, linux-arm-kernel, allison, linux-kernel
In-Reply-To: <20190911094031.GU13294@shell.armlinux.org.uk>
2019년 9월 11일 (수) 오후 6:40, Russell King - ARM Linux admin
<linux@armlinux.org.uk>님이 작성:
>
> On Wed, Sep 11, 2019 at 01:54:08PM +0900, Austin Kim wrote:
> > Since rel->r_offset is declared as Elf32_Addr,
> > this value is always non-negative.
> > typedef struct elf32_rel {
> > Elf32_Addr r_offset;
> > Elf32_Word r_info;
> > } Elf32_Rel;
> >
> > typedef __u32 Elf32_Addr;
> > typedef unsigned int __u32;
> >
> > Drop 'rel->r_offset < 0' statement which is always false.
> >
> > Signed-off-by: Austin Kim <austindh.kim@gmail.com>
> > ---
> > arch/arm/kernel/module.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> > index deef17f..0921ce7 100644
> > --- a/arch/arm/kernel/module.c
> > +++ b/arch/arm/kernel/module.c
> > @@ -92,7 +92,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
> > sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
> > symname = strtab + sym->st_name;
> >
> > - if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size - sizeof(u32)) {
> > + if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
> > pr_err("%s: section %u reloc %u sym '%s': out of bounds relocation, offset %d size %u\n",
>
> Also change %d to %u here.
Let me resend the patch with the change(%d to %u).
Thanks,
Austin Kim
>
> > module->name, relindex, i, symname,
> > rel->r_offset, dstsec->sh_size);
> > --
> > 2.6.2
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Andre Przywara @ 2019-09-11 11:42 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY3kfLbdSSdQtZUu9HU1YbXSpbQWW85m0sieR7bJJYBaFA@mail.gmail.com>
On Tue, 10 Sep 2019 21:36:35 -0500
Jassi Brar <jassisinghbrar@gmail.com> wrote:
Hi,
> On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Fri, 30 Aug 2019 03:12:29 -0500
> > Jassi Brar <jassisinghbrar@gmail.com> wrote:
> >
> > Hi,
> >
> > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > >
> > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> > > > > SMC/HVC mailbox
> > > > >
> > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > > > >
> > > > > > Hi Jassi,
> > > > > >
> > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc
> > > > > > > for the ARM SMC/HVC mailbox
> > > > > > >
> > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan <peng.fan@nxp.com> wrote:
> > > > > > >
> > > > > > > > > > +examples:
> > > > > > > > > > + - |
> > > > > > > > > > + sram@910000 {
> > > > > > > > > > + compatible = "mmio-sram";
> > > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>;
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > + #size-cells = <1>;
> > > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>;
> > > > > > > > > > +
> > > > > > > > > > + cpu_scp_lpri: scp-shmem@0 {
> > > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > > + reg = <0x0 0x200>;
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + cpu_scp_hpri: scp-shmem@200 {
> > > > > > > > > > + compatible = "arm,scmi-shmem";
> > > > > > > > > > + reg = <0x200 0x200>;
> > > > > > > > > > + };
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + firmware {
> > > > > > > > > > + smc_mbox: mailbox {
> > > > > > > > > > + #mbox-cells = <1>;
> > > > > > > > > > + compatible = "arm,smc-mbox";
> > > > > > > > > > + method = "smc";
> > > > > > > > > > + arm,num-chans = <0x2>;
> > > > > > > > > > + transports = "mem";
> > > > > > > > > > + /* Optional */
> > > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> > > > > > > > > >
> > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e,
> > > > > > > > > there can only be one instance running platform wide. Right?
> > > > > > > >
> > > > > > > > I think there could be channel for TEE, and channel for Linux.
> > > > > > > > For virtualization case, there could be dedicated channel for each VM.
> > > > > > > >
> > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > > > > > both be active at the same time, right?
> > > > > >
> > > > > > If I get your point correctly,
> > > > > > On UP, both could not be active. On SMP, tx/rx could be both active,
> > > > > > anyway this depends on secure firmware and Linux firmware design.
> > > > > >
> > > > > > Do you have any suggestions about arm,func-ids here?
> > > > > >
> > > > > I was thinking if this is just an instruction, why can't each channel be
> > > > > represented as a controller, i.e, have exactly one func-id per controller node.
> > > > > Define as many controllers as you need channels ?
> > > >
> > > > I am ok, this could make driver code simpler. Something as below?
> > > >
> > > > smc_tx_mbox: tx_mbox {
> > > > #mbox-cells = <0>;
> > > > compatible = "arm,smc-mbox";
> > > > method = "smc";
> > > > transports = "mem";
> > > > arm,func-id = <0xc20000fe>;
> > > > };
> > > >
> > > > smc_rx_mbox: rx_mbox {
> > > > #mbox-cells = <0>;
> > > > compatible = "arm,smc-mbox";
> > > > method = "smc";
> > > > transports = "mem";
> > > > arm,func-id = <0xc20000ff>;
> > > > };
> > > >
> > > > firmware {
> > > > scmi {
> > > > compatible = "arm,scmi";
> > > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>;
> > > > mbox-names = "tx", "rx";
> > > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
> > > > };
> > > > };
> > > >
> > > Yes, the channel part is good.
> > > But I am not convinced by the need to have SCMI specific "transport" mode.
> >
> > Why would this be SCMI specific and what is the problem with having this property?
> > By the very nature of the SMC/HVC call you would expect to also pass parameters in registers.
> > However this limits the amount of data you can push, so the option of reverting to a
> > memory based payload sounds very reasonable.
> >
> Of course, it is very legit to pass data via mem and many platforms do
> that. But as you note in your next post, the 'transport' doesn't seem
> necessary doing what it does in the driver.
Yes, indeed. I didn't realise that until looking more deeply into the driver later.
So I think we are on the same page regarding this: the *controller* driver and its binding does not need to know about the transport, that's something between the mailbox client and the firmware implementation.
Cheers,
Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 2/2] media: i2c: Add more sensor modes for ov8856 camera sensor
From: Sakari Ailus @ 2019-09-11 11:43 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Nicolas Boichat, andriy.shevchenko, srv_heupstream,
devicetree, shengnan.wang, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CAAFQd5Ar39TeFJbprQuMwCBVgjsuap1iQviz2dbf5Yw6OU1ZWA@mail.gmail.com>
Hi Tomasz,
On Wed, Sep 11, 2019 at 07:12:02PM +0900, Tomasz Figa wrote:
> Hi Sakari,
>
> On Tue, Sep 10, 2019 at 10:05 PM <dongchun.zhu@mediatek.com> wrote:
> >
> > From: Dongchun Zhu <dongchun.zhu@mediatek.com>
> >
> > This patch mainly adds two more sensor modes for OV8856 CMOS image sensor.
> > That is, the resolution of 1632*1224 and 3264*2448, corresponding to the bayer order of BGGR.
> > The sensor revision also differs in some OTP register.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > drivers/media/i2c/ov8856.c | 654 +++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 639 insertions(+), 15 deletions(-)
> >
>
> What do you think about the approach taken by this patch?
>
> My understanding is that the register arrays being added by it can be
> only used with 24MHz input clock, while the existing ones are for
> 19.2MHz. That means that this patch makes the driver expose completely
> different modes (resolutions, mbus formats) depending on the input
> clock. Are we okay with this?
These register list based drivers only support a tiny subset of
configurations a sensor can support, and the number of those configurations
may be amended over time.
I don't see a problem in choosing a different set of available
configurations based on the external clock frequency; that may, after all,
cause that some of the configurations, at a particular frame rate, are not
even achievable --- albeit this is perhaps unlikely in this case.
In practice, it's often the case that the sensor vendor provides these
configurations and the vendor may provide different configurations
(including output resolutions etc.) to different parties. So it may well be
the submitter of the patch would also not have access to similar
configurations (output size, cropping etc.) that now exist in the driver.
I'll review the patch itself soonish.
--
Regards,
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] crypto: sun4i-ss: Enable power management
From: Corentin Labbe @ 2019-09-11 11:46 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
Hello
This serie enables power management in the sun4i-ss driver.
Regards
Corentin Labbe (2):
crypto: sun4i-ss: simplify enable/disable of the device
crypto: sun4i-ss: enable pm_runtime
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 5 +
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 115 ++++++++++++++++------
2 files changed, 88 insertions(+), 32 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] crypto: sun4i-ss: enable pm_runtime
From: Corentin Labbe @ 2019-09-11 11:46 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190911114650.20567-1-clabbe.montjoie@gmail.com>
This patch enables power management on the Security System.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 5 +++
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 42 ++++++++++++++++++++++-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index fa4b1b47822e..1fedec9e83b0 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -10,6 +10,8 @@
*
* You could find the datasheet in Documentation/arm/sunxi.rst
*/
+
+#include <linux/pm_runtime.h>
#include "sun4i-ss.h"
static int noinline_for_stack sun4i_ss_opti_poll(struct skcipher_request *areq)
@@ -497,13 +499,16 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
return PTR_ERR(op->fallback_tfm);
}
+ pm_runtime_get_sync(op->ss->dev);
return 0;
}
void sun4i_ss_cipher_exit(struct crypto_tfm *tfm)
{
struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
+
crypto_free_sync_skcipher(op->fallback_tfm);
+ pm_runtime_put_sync(op->ss->dev);
}
/* check and set the AES key, prepare the mode to be used */
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 2c9ff01dddfc..5e6e1a308f60 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <crypto/scatterwalk.h>
#include <linux/scatterlist.h>
#include <linux/interrupt.h>
@@ -258,6 +259,37 @@ static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
return err;
}
+#ifdef CONFIG_PM
+static int sun4i_ss_pm_suspend(struct device *dev)
+{
+ struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
+
+ sun4i_ss_disable(ss);
+ return 0;
+}
+
+static int sun4i_ss_pm_resume(struct device *dev)
+{
+ struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
+
+ return sun4i_ss_enable(ss);
+}
+#endif
+
+const struct dev_pm_ops sun4i_ss_pm_ops = {
+ SET_RUNTIME_PM_OPS(sun4i_ss_pm_suspend, sun4i_ss_pm_resume, NULL)
+};
+
+static void sun4i_ss_pm_init(struct sun4i_ss_ctx *ss)
+{
+ pm_runtime_use_autosuspend(ss->dev);
+ pm_runtime_set_autosuspend_delay(ss->dev, 1000);
+
+ pm_runtime_get_noresume(ss->dev);
+ pm_runtime_set_active(ss->dev);
+ pm_runtime_enable(ss->dev);
+}
+
static int sun4i_ss_probe(struct platform_device *pdev)
{
u32 v;
@@ -357,9 +389,12 @@ static int sun4i_ss_probe(struct platform_device *pdev)
writel(0, ss->base + SS_CTL);
ss->dev = &pdev->dev;
+ platform_set_drvdata(pdev, ss);
spin_lock_init(&ss->slock);
+ sun4i_ss_pm_init(ss);
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
ss_algs[i].ss = ss;
switch (ss_algs[i].type) {
@@ -388,7 +423,8 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
- platform_set_drvdata(pdev, ss);
+
+ pm_runtime_put_sync(ss->dev);
return 0;
error_alg:
i--;
@@ -405,6 +441,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
+ pm_runtime_disable(ss->dev);
error_enable:
sun4i_ss_disable(ss);
return err;
@@ -429,6 +466,8 @@ static int sun4i_ss_remove(struct platform_device *pdev)
}
}
+ pm_runtime_disable(ss->dev);
+
writel(0, ss->base + SS_CTL);
sun4i_ss_disable(ss);
return 0;
@@ -445,6 +484,7 @@ static struct platform_driver sun4i_ss_driver = {
.remove = sun4i_ss_remove,
.driver = {
.name = "sun4i-ss",
+ .pm = &sun4i_ss_pm_ops,
.of_match_table = a20ss_crypto_of_match_table,
},
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] crypto: sun4i-ss: simplify enable/disable of the device
From: Corentin Labbe @ 2019-09-11 11:46 UTC (permalink / raw)
To: davem, herbert, mripard, wens
Cc: linux-sunxi, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190911114650.20567-1-clabbe.montjoie@gmail.com>
This patch regroups resource enabling/disabling in dedicated function.
This simplify error handling and will permit to support power
management.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 73 ++++++++++++++-----------
1 file changed, 42 insertions(+), 31 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 9aa6fe081a27..2c9ff01dddfc 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -223,6 +223,41 @@ static struct sun4i_ss_alg_template ss_algs[] = {
#endif
};
+static void sun4i_ss_disable(struct sun4i_ss_ctx *ss)
+{
+ if (ss->reset)
+ reset_control_assert(ss->reset);
+ clk_disable_unprepare(ss->ssclk);
+ clk_disable_unprepare(ss->busclk);
+}
+
+static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
+{
+ int err;
+
+ err = clk_prepare_enable(ss->busclk);
+ if (err) {
+ dev_err(ss->dev, "Cannot prepare_enable busclk\n");
+ goto err_enable;
+ }
+ err = clk_prepare_enable(ss->ssclk);
+ if (err) {
+ dev_err(ss->dev, "Cannot prepare_enable ssclk\n");
+ goto err_enable;
+ }
+ if (ss->reset) {
+ err = reset_control_deassert(ss->reset);
+ if (err) {
+ dev_err(ss->dev, "Cannot deassert reset control\n");
+ goto err_enable;
+ }
+ }
+ return err;
+err_enable:
+ sun4i_ss_disable(ss);
+ return err;
+}
+
static int sun4i_ss_probe(struct platform_device *pdev)
{
u32 v;
@@ -269,17 +304,9 @@ static int sun4i_ss_probe(struct platform_device *pdev)
ss->reset = NULL;
}
- /* Enable both clocks */
- err = clk_prepare_enable(ss->busclk);
- if (err) {
- dev_err(&pdev->dev, "Cannot prepare_enable busclk\n");
- return err;
- }
- err = clk_prepare_enable(ss->ssclk);
- if (err) {
- dev_err(&pdev->dev, "Cannot prepare_enable ssclk\n");
- goto error_ssclk;
- }
+ err = sun4i_ss_enable(ss);
+ if (err)
+ goto error_enable;
/*
* Check that clock have the correct rates given in the datasheet
@@ -288,16 +315,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
err = clk_set_rate(ss->ssclk, cr_mod);
if (err) {
dev_err(&pdev->dev, "Cannot set clock rate to ssclk\n");
- goto error_clk;
- }
-
- /* Deassert reset if we have a reset control */
- if (ss->reset) {
- err = reset_control_deassert(ss->reset);
- if (err) {
- dev_err(&pdev->dev, "Cannot deassert reset control\n");
- goto error_clk;
- }
+ goto error_enable;
}
/*
@@ -387,12 +405,8 @@ static int sun4i_ss_probe(struct platform_device *pdev)
break;
}
}
- if (ss->reset)
- reset_control_assert(ss->reset);
-error_clk:
- clk_disable_unprepare(ss->ssclk);
-error_ssclk:
- clk_disable_unprepare(ss->busclk);
+error_enable:
+ sun4i_ss_disable(ss);
return err;
}
@@ -416,10 +430,7 @@ static int sun4i_ss_remove(struct platform_device *pdev)
}
writel(0, ss->base + SS_CTL);
- if (ss->reset)
- reset_control_assert(ss->reset);
- clk_disable_unprepare(ss->busclk);
- clk_disable_unprepare(ss->ssclk);
+ sun4i_ss_disable(ss);
return 0;
}
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: David Hildenbrand @ 2019-09-11 11:47 UTC (permalink / raw)
To: Michal Hocko, Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm, will,
Andrea Arcangeli, virtio-dev, Rik van Riel, Matthew Wilcox,
Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190911113619.GP4023@dhcp22.suse.cz>
On 11.09.19 13:36, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
>> We don't put any limitations on the allocator other then that it needs to
>> clean up the metadata on allocation, and that it cannot allocate a page
>> that is in the process of being reported since we pulled it from the
>> free_list. If the page is a "Reported" page then it decrements the
>> reported_pages count for the free_area and makes sure the page doesn't
>> exist in the "Boundary" array pointer value, if it does it moves the
>> "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
>
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>
FWIW, Nitesh was looking into another approach [1], whereby the metadata
is stored outside of the buddy (unreported pages are tracked in a
bitmap). There are some limitations to this approach (esp., sparse zones
might waste memory (1bit per 2MB), memory hot(un)plug not supported yet
completely, scanning of the bitmap necessary). OTOH, the core buddy
modifications are minimized.
[1] https://lkml.org/lkml/2019/8/12/593
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] clk: imx8m: Define gates for pll1/2 dividers
From: Leonard Crestez @ 2019-09-11 12:05 UTC (permalink / raw)
To: Stephen Boyd, Shawn Guo, Jacky Bai, Abel Vesa
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
The fixed dividers for sys_pll1 and sys_pll2 on imx8m each have a gate
attached but they're currently unused so they default to "always on".
Add them to the clk tree for the sake of corectness. This could expose
bugs where parent clocks were not correctly enabled.
The new gates are added between the PLL and fixed dividers and new gates
are enumerated at the end in dt-bindings. This should ensure
compatibility, even though none of these fixed dividers are directly
referenced by peripherals anyway.
There are small differences on imx8mq because the PLL physical
implementation is also different.
Leonard Crestez (3):
clk: imx8mq: Define gates for pll1/2 fixed dividers
clk: imx8mm: Define gates for pll1/2 fixed dividers
clk: imx8mn: Define gates for pll1/2 fixed dividers
drivers/clk/imx/clk-imx8mm.c | 57 ++++++++++++++--------
drivers/clk/imx/clk-imx8mn.c | 57 ++++++++++++++--------
drivers/clk/imx/clk-imx8mq.c | 62 ++++++++++++++++--------
include/dt-bindings/clock/imx8mm-clock.h | 19 +++++++-
include/dt-bindings/clock/imx8mn-clock.h | 19 +++++++-
include/dt-bindings/clock/imx8mq-clock.h | 22 ++++++++-
6 files changed, 175 insertions(+), 61 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] clk: imx8mn: Define gates for pll1/2 fixed dividers
From: Leonard Crestez @ 2019-09-11 12:05 UTC (permalink / raw)
To: Stephen Boyd, Shawn Guo, Jacky Bai, Abel Vesa
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1568203237.git.leonard.crestez@nxp.com>
On imx8mn there are 9 fixed-factor dividers for SYS_PLL1 and SYS_PLL2
each with their own gate. Only one of these gates (the one "dividing" by
one) is currently defined and it's incorrectly set as the parent of all
the fixed-factor dividers.
Add the other 8 gates to the clock tree between sys_pll1/2_bypass and
the fixed dividers.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mn.c | 57 ++++++++++++++++--------
include/dt-bindings/clock/imx8mn-clock.h | 19 +++++++-
2 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index cc65c1369530..ca5f760a1108 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -450,33 +450,52 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
clks[IMX8MN_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out", "video_pll1_bypass", base + 0x28, 13);
clks[IMX8MN_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out", "dram_pll_bypass", base + 0x50, 13);
clks[IMX8MN_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 11);
clks[IMX8MN_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", "vpu_pll_bypass", base + 0x74, 11);
clks[IMX8MN_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 11);
- clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 11);
- clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 11);
clks[IMX8MN_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 11);
- /* SYS PLL fixed output */
- clks[IMX8MN_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", "sys_pll1_out", 1, 20);
- clks[IMX8MN_SYS_PLL1_80M] = imx_clk_fixed_factor("sys_pll1_80m", "sys_pll1_out", 1, 10);
- clks[IMX8MN_SYS_PLL1_100M] = imx_clk_fixed_factor("sys_pll1_100m", "sys_pll1_out", 1, 8);
- clks[IMX8MN_SYS_PLL1_133M] = imx_clk_fixed_factor("sys_pll1_133m", "sys_pll1_out", 1, 6);
- clks[IMX8MN_SYS_PLL1_160M] = imx_clk_fixed_factor("sys_pll1_160m", "sys_pll1_out", 1, 5);
- clks[IMX8MN_SYS_PLL1_200M] = imx_clk_fixed_factor("sys_pll1_200m", "sys_pll1_out", 1, 4);
- clks[IMX8MN_SYS_PLL1_266M] = imx_clk_fixed_factor("sys_pll1_266m", "sys_pll1_out", 1, 3);
- clks[IMX8MN_SYS_PLL1_400M] = imx_clk_fixed_factor("sys_pll1_400m", "sys_pll1_out", 1, 2);
+ /* SYS PLL1 fixed output */
+ clks[IMX8MN_SYS_PLL1_40M_CG] = imx_clk_gate("sys_pll1_40m_cg", "sys_pll1_bypass", base + 0x94, 27);
+ clks[IMX8MN_SYS_PLL1_80M_CG] = imx_clk_gate("sys_pll1_80m_cg", "sys_pll1_bypass", base + 0x94, 25);
+ clks[IMX8MN_SYS_PLL1_100M_CG] = imx_clk_gate("sys_pll1_100m_cg", "sys_pll1_bypass", base + 0x94, 23);
+ clks[IMX8MN_SYS_PLL1_133M_CG] = imx_clk_gate("sys_pll1_133m_cg", "sys_pll1_bypass", base + 0x94, 21);
+ clks[IMX8MN_SYS_PLL1_160M_CG] = imx_clk_gate("sys_pll1_160m_cg", "sys_pll1_bypass", base + 0x94, 19);
+ clks[IMX8MN_SYS_PLL1_200M_CG] = imx_clk_gate("sys_pll1_200m_cg", "sys_pll1_bypass", base + 0x94, 17);
+ clks[IMX8MN_SYS_PLL1_266M_CG] = imx_clk_gate("sys_pll1_266m_cg", "sys_pll1_bypass", base + 0x94, 15);
+ clks[IMX8MN_SYS_PLL1_400M_CG] = imx_clk_gate("sys_pll1_400m_cg", "sys_pll1_bypass", base + 0x94, 13);
+ clks[IMX8MN_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 11);
+
+ clks[IMX8MN_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", "sys_pll1_40m_cg", 1, 20);
+ clks[IMX8MN_SYS_PLL1_80M] = imx_clk_fixed_factor("sys_pll1_80m", "sys_pll1_80m_cg", 1, 10);
+ clks[IMX8MN_SYS_PLL1_100M] = imx_clk_fixed_factor("sys_pll1_100m", "sys_pll1_100m_cg", 1, 8);
+ clks[IMX8MN_SYS_PLL1_133M] = imx_clk_fixed_factor("sys_pll1_133m", "sys_pll1_133m_cg", 1, 6);
+ clks[IMX8MN_SYS_PLL1_160M] = imx_clk_fixed_factor("sys_pll1_160m", "sys_pll1_160m_cg", 1, 5);
+ clks[IMX8MN_SYS_PLL1_200M] = imx_clk_fixed_factor("sys_pll1_200m", "sys_pll1_200m_cg", 1, 4);
+ clks[IMX8MN_SYS_PLL1_266M] = imx_clk_fixed_factor("sys_pll1_266m", "sys_pll1_266m_cg", 1, 3);
+ clks[IMX8MN_SYS_PLL1_400M] = imx_clk_fixed_factor("sys_pll1_400m", "sys_pll1_400m_cg", 1, 2);
clks[IMX8MN_SYS_PLL1_800M] = imx_clk_fixed_factor("sys_pll1_800m", "sys_pll1_out", 1, 1);
- clks[IMX8MN_SYS_PLL2_50M] = imx_clk_fixed_factor("sys_pll2_50m", "sys_pll2_out", 1, 20);
- clks[IMX8MN_SYS_PLL2_100M] = imx_clk_fixed_factor("sys_pll2_100m", "sys_pll2_out", 1, 10);
- clks[IMX8MN_SYS_PLL2_125M] = imx_clk_fixed_factor("sys_pll2_125m", "sys_pll2_out", 1, 8);
- clks[IMX8MN_SYS_PLL2_166M] = imx_clk_fixed_factor("sys_pll2_166m", "sys_pll2_out", 1, 6);
- clks[IMX8MN_SYS_PLL2_200M] = imx_clk_fixed_factor("sys_pll2_200m", "sys_pll2_out", 1, 5);
- clks[IMX8MN_SYS_PLL2_250M] = imx_clk_fixed_factor("sys_pll2_250m", "sys_pll2_out", 1, 4);
- clks[IMX8MN_SYS_PLL2_333M] = imx_clk_fixed_factor("sys_pll2_333m", "sys_pll2_out", 1, 3);
- clks[IMX8MN_SYS_PLL2_500M] = imx_clk_fixed_factor("sys_pll2_500m", "sys_pll2_out", 1, 2);
+ /* SYS PLL2 fixed output */
+ clks[IMX8MN_SYS_PLL2_50M_CG] = imx_clk_gate("sys_pll2_50m_cg", "sys_pll2_bypass", base + 0x104, 27);
+ clks[IMX8MN_SYS_PLL2_100M_CG] = imx_clk_gate("sys_pll2_100m_cg", "sys_pll2_bypass", base + 0x104, 25);
+ clks[IMX8MN_SYS_PLL2_125M_CG] = imx_clk_gate("sys_pll2_125m_cg", "sys_pll2_bypass", base + 0x104, 23);
+ clks[IMX8MN_SYS_PLL2_166M_CG] = imx_clk_gate("sys_pll2_166m_cg", "sys_pll2_bypass", base + 0x104, 21);
+ clks[IMX8MN_SYS_PLL2_200M_CG] = imx_clk_gate("sys_pll2_200m_cg", "sys_pll2_bypass", base + 0x104, 19);
+ clks[IMX8MN_SYS_PLL2_250M_CG] = imx_clk_gate("sys_pll2_250m_cg", "sys_pll2_bypass", base + 0x104, 17);
+ clks[IMX8MN_SYS_PLL2_333M_CG] = imx_clk_gate("sys_pll2_333m_cg", "sys_pll2_bypass", base + 0x104, 15);
+ clks[IMX8MN_SYS_PLL2_500M_CG] = imx_clk_gate("sys_pll2_500m_cg", "sys_pll2_bypass", base + 0x104, 13);
+ clks[IMX8MN_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 11);
+
+ clks[IMX8MN_SYS_PLL2_50M] = imx_clk_fixed_factor("sys_pll2_50m", "sys_pll2_50m_cg", 1, 20);
+ clks[IMX8MN_SYS_PLL2_100M] = imx_clk_fixed_factor("sys_pll2_100m", "sys_pll2_100m_cg", 1, 10);
+ clks[IMX8MN_SYS_PLL2_125M] = imx_clk_fixed_factor("sys_pll2_125m", "sys_pll2_125m_cg", 1, 8);
+ clks[IMX8MN_SYS_PLL2_166M] = imx_clk_fixed_factor("sys_pll2_166m", "sys_pll2_166m_cg", 1, 6);
+ clks[IMX8MN_SYS_PLL2_200M] = imx_clk_fixed_factor("sys_pll2_200m", "sys_pll2_200m_cg", 1, 5);
+ clks[IMX8MN_SYS_PLL2_250M] = imx_clk_fixed_factor("sys_pll2_250m", "sys_pll2_250m_cg", 1, 4);
+ clks[IMX8MN_SYS_PLL2_333M] = imx_clk_fixed_factor("sys_pll2_333m", "sys_pll2_333m_cg", 1, 3);
+ clks[IMX8MN_SYS_PLL2_500M] = imx_clk_fixed_factor("sys_pll2_500m", "sys_pll2_500m_cg", 1, 2);
clks[IMX8MN_SYS_PLL2_1000M] = imx_clk_fixed_factor("sys_pll2_1000m", "sys_pll2_out", 1, 1);
np = dev->of_node;
base = devm_platform_ioremap_resource(pdev, 0);
if (WARN_ON(IS_ERR(base))) {
diff --git a/include/dt-bindings/clock/imx8mn-clock.h b/include/dt-bindings/clock/imx8mn-clock.h
index d7b201652f4c..0f2b8423ce1d 100644
--- a/include/dt-bindings/clock/imx8mn-clock.h
+++ b/include/dt-bindings/clock/imx8mn-clock.h
@@ -209,8 +209,25 @@
#define IMX8MN_CLK_ARM 191
#define IMX8MN_CLK_NAND_USDHC_BUS_RAWNAND_CLK 192
#define IMX8MN_CLK_GPU_CORE_ROOT 193
#define IMX8MN_CLK_GIC 194
-#define IMX8MN_CLK_END 195
+#define IMX8MN_SYS_PLL1_40M_CG 195
+#define IMX8MN_SYS_PLL1_80M_CG 196
+#define IMX8MN_SYS_PLL1_100M_CG 197
+#define IMX8MN_SYS_PLL1_133M_CG 198
+#define IMX8MN_SYS_PLL1_160M_CG 199
+#define IMX8MN_SYS_PLL1_200M_CG 200
+#define IMX8MN_SYS_PLL1_266M_CG 201
+#define IMX8MN_SYS_PLL1_400M_CG 202
+#define IMX8MN_SYS_PLL2_50M_CG 203
+#define IMX8MN_SYS_PLL2_100M_CG 204
+#define IMX8MN_SYS_PLL2_125M_CG 205
+#define IMX8MN_SYS_PLL2_166M_CG 206
+#define IMX8MN_SYS_PLL2_200M_CG 207
+#define IMX8MN_SYS_PLL2_250M_CG 208
+#define IMX8MN_SYS_PLL2_333M_CG 209
+#define IMX8MN_SYS_PLL2_500M_CG 210
+
+#define IMX8MN_CLK_END 211
#endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] clk: imx8mq: Define gates for pll1/2 fixed dividers
From: Leonard Crestez @ 2019-09-11 12:05 UTC (permalink / raw)
To: Stephen Boyd, Shawn Guo, Jacky Bai, Abel Vesa
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1568203237.git.leonard.crestez@nxp.com>
On imx8mq there are 9 fixed-factor dividers for SYS_PLL1 and SYS_PLL2
each with their own gate but these gates are not currently defined.
Add the other gates to the clock tree between sys1/2_pll_out and the
fixed dividers.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mq.c | 62 ++++++++++++++++--------
include/dt-bindings/clock/imx8mq-clock.h | 22 ++++++++-
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index 4c90eb06a591..154c8655f29d 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -344,30 +344,52 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_SYS1_PLL_OUT] = imx_clk_sccg_pll("sys1_pll_out", sys1_pll_out_sels, ARRAY_SIZE(sys1_pll_out_sels), 0, 0, 0, base + 0x30, CLK_IS_CRITICAL);
clks[IMX8MQ_SYS2_PLL_OUT] = imx_clk_sccg_pll("sys2_pll_out", sys2_pll_out_sels, ARRAY_SIZE(sys2_pll_out_sels), 0, 0, 1, base + 0x3c, CLK_IS_CRITICAL);
clks[IMX8MQ_SYS3_PLL_OUT] = imx_clk_sccg_pll("sys3_pll_out", sys3_pll_out_sels, ARRAY_SIZE(sys3_pll_out_sels), 0, 0, 1, base + 0x48, CLK_IS_CRITICAL);
clks[IMX8MQ_DRAM_PLL_OUT] = imx_clk_sccg_pll("dram_pll_out", dram_pll_out_sels, ARRAY_SIZE(dram_pll_out_sels), 0, 0, 0, base + 0x60, CLK_IS_CRITICAL);
- /* SYS PLL fixed output */
- clks[IMX8MQ_SYS1_PLL_40M] = imx_clk_fixed_factor("sys1_pll_40m", "sys1_pll_out", 1, 20);
- clks[IMX8MQ_SYS1_PLL_80M] = imx_clk_fixed_factor("sys1_pll_80m", "sys1_pll_out", 1, 10);
- clks[IMX8MQ_SYS1_PLL_100M] = imx_clk_fixed_factor("sys1_pll_100m", "sys1_pll_out", 1, 8);
- clks[IMX8MQ_SYS1_PLL_133M] = imx_clk_fixed_factor("sys1_pll_133m", "sys1_pll_out", 1, 6);
- clks[IMX8MQ_SYS1_PLL_160M] = imx_clk_fixed_factor("sys1_pll_160m", "sys1_pll_out", 1, 5);
- clks[IMX8MQ_SYS1_PLL_200M] = imx_clk_fixed_factor("sys1_pll_200m", "sys1_pll_out", 1, 4);
- clks[IMX8MQ_SYS1_PLL_266M] = imx_clk_fixed_factor("sys1_pll_266m", "sys1_pll_out", 1, 3);
- clks[IMX8MQ_SYS1_PLL_400M] = imx_clk_fixed_factor("sys1_pll_400m", "sys1_pll_out", 1, 2);
- clks[IMX8MQ_SYS1_PLL_800M] = imx_clk_fixed_factor("sys1_pll_800m", "sys1_pll_out", 1, 1);
-
- clks[IMX8MQ_SYS2_PLL_50M] = imx_clk_fixed_factor("sys2_pll_50m", "sys2_pll_out", 1, 20);
- clks[IMX8MQ_SYS2_PLL_100M] = imx_clk_fixed_factor("sys2_pll_100m", "sys2_pll_out", 1, 10);
- clks[IMX8MQ_SYS2_PLL_125M] = imx_clk_fixed_factor("sys2_pll_125m", "sys2_pll_out", 1, 8);
- clks[IMX8MQ_SYS2_PLL_166M] = imx_clk_fixed_factor("sys2_pll_166m", "sys2_pll_out", 1, 6);
- clks[IMX8MQ_SYS2_PLL_200M] = imx_clk_fixed_factor("sys2_pll_200m", "sys2_pll_out", 1, 5);
- clks[IMX8MQ_SYS2_PLL_250M] = imx_clk_fixed_factor("sys2_pll_250m", "sys2_pll_out", 1, 4);
- clks[IMX8MQ_SYS2_PLL_333M] = imx_clk_fixed_factor("sys2_pll_333m", "sys2_pll_out", 1, 3);
- clks[IMX8MQ_SYS2_PLL_500M] = imx_clk_fixed_factor("sys2_pll_500m", "sys2_pll_out", 1, 2);
- clks[IMX8MQ_SYS2_PLL_1000M] = imx_clk_fixed_factor("sys2_pll_1000m", "sys2_pll_out", 1, 1);
+
+ /* SYS PLL1 fixed output */
+ clks[IMX8MQ_SYS1_PLL_40M_CG] = imx_clk_gate("sys1_pll_40m_cg", "sys1_pll_out", base + 0x30, 9);
+ clks[IMX8MQ_SYS1_PLL_80M_CG] = imx_clk_gate("sys1_pll_80m_cg", "sys1_pll_out", base + 0x30, 11);
+ clks[IMX8MQ_SYS1_PLL_100M_CG] = imx_clk_gate("sys1_pll_100m_cg", "sys1_pll_out", base + 0x30, 13);
+ clks[IMX8MQ_SYS1_PLL_133M_CG] = imx_clk_gate("sys1_pll_133m_cg", "sys1_pll_out", base + 0x30, 15);
+ clks[IMX8MQ_SYS1_PLL_160M_CG] = imx_clk_gate("sys1_pll_160m_cg", "sys1_pll_out", base + 0x30, 17);
+ clks[IMX8MQ_SYS1_PLL_200M_CG] = imx_clk_gate("sys1_pll_200m_cg", "sys1_pll_out", base + 0x30, 19);
+ clks[IMX8MQ_SYS1_PLL_266M_CG] = imx_clk_gate("sys1_pll_266m_cg", "sys1_pll_out", base + 0x30, 21);
+ clks[IMX8MQ_SYS1_PLL_400M_CG] = imx_clk_gate("sys1_pll_400m_cg", "sys1_pll_out", base + 0x30, 23);
+ clks[IMX8MQ_SYS1_PLL_800M_CG] = imx_clk_gate("sys1_pll_800m_cg", "sys1_pll_out", base + 0x30, 25);
+
+ clks[IMX8MQ_SYS1_PLL_40M] = imx_clk_fixed_factor("sys1_pll_40m", "sys1_pll_40m_cg", 1, 20);
+ clks[IMX8MQ_SYS1_PLL_80M] = imx_clk_fixed_factor("sys1_pll_80m", "sys1_pll_80m_cg", 1, 10);
+ clks[IMX8MQ_SYS1_PLL_100M] = imx_clk_fixed_factor("sys1_pll_100m", "sys1_pll_100m_cg", 1, 8);
+ clks[IMX8MQ_SYS1_PLL_133M] = imx_clk_fixed_factor("sys1_pll_133m", "sys1_pll_133m_cg", 1, 6);
+ clks[IMX8MQ_SYS1_PLL_160M] = imx_clk_fixed_factor("sys1_pll_160m", "sys1_pll_160m_cg", 1, 5);
+ clks[IMX8MQ_SYS1_PLL_200M] = imx_clk_fixed_factor("sys1_pll_200m", "sys1_pll_200m_cg", 1, 4);
+ clks[IMX8MQ_SYS1_PLL_266M] = imx_clk_fixed_factor("sys1_pll_266m", "sys1_pll_266m_cg", 1, 3);
+ clks[IMX8MQ_SYS1_PLL_400M] = imx_clk_fixed_factor("sys1_pll_400m", "sys1_pll_400m_cg", 1, 2);
+ clks[IMX8MQ_SYS1_PLL_800M] = imx_clk_fixed_factor("sys1_pll_800m", "sys1_pll_800m_cg", 1, 1);
+
+ /* SYS PLL2 fixed output */
+ clks[IMX8MQ_SYS2_PLL_50M_CG] = imx_clk_gate("sys2_pll_50m_cg", "sys2_pll_out", base + 0x3c, 9);
+ clks[IMX8MQ_SYS2_PLL_100M_CG] = imx_clk_gate("sys2_pll_100m_cg", "sys2_pll_out", base + 0x3c, 11);
+ clks[IMX8MQ_SYS2_PLL_125M_CG] = imx_clk_gate("sys2_pll_125m_cg", "sys2_pll_out", base + 0x3c, 13);
+ clks[IMX8MQ_SYS2_PLL_166M_CG] = imx_clk_gate("sys2_pll_166m_cg", "sys2_pll_out", base + 0x3c, 15);
+ clks[IMX8MQ_SYS2_PLL_200M_CG] = imx_clk_gate("sys2_pll_200m_cg", "sys2_pll_out", base + 0x3c, 17);
+ clks[IMX8MQ_SYS2_PLL_250M_CG] = imx_clk_gate("sys2_pll_250m_cg", "sys2_pll_out", base + 0x3c, 19);
+ clks[IMX8MQ_SYS2_PLL_333M_CG] = imx_clk_gate("sys2_pll_333m_cg", "sys2_pll_out", base + 0x3c, 21);
+ clks[IMX8MQ_SYS2_PLL_500M_CG] = imx_clk_gate("sys2_pll_500m_cg", "sys2_pll_out", base + 0x3c, 23);
+ clks[IMX8MQ_SYS2_PLL_1000M_CG] = imx_clk_gate("sys2_pll_1000m_cg", "sys2_pll_out", base + 0x3c, 25);
+
+ clks[IMX8MQ_SYS2_PLL_50M] = imx_clk_fixed_factor("sys2_pll_50m", "sys2_pll_50m_cg", 1, 20);
+ clks[IMX8MQ_SYS2_PLL_100M] = imx_clk_fixed_factor("sys2_pll_100m", "sys2_pll_100m_cg", 1, 10);
+ clks[IMX8MQ_SYS2_PLL_125M] = imx_clk_fixed_factor("sys2_pll_125m", "sys2_pll_125m_cg", 1, 8);
+ clks[IMX8MQ_SYS2_PLL_166M] = imx_clk_fixed_factor("sys2_pll_166m", "sys2_pll_166m_cg", 1, 6);
+ clks[IMX8MQ_SYS2_PLL_200M] = imx_clk_fixed_factor("sys2_pll_200m", "sys2_pll_200m_cg", 1, 5);
+ clks[IMX8MQ_SYS2_PLL_250M] = imx_clk_fixed_factor("sys2_pll_250m", "sys2_pll_250m_cg", 1, 4);
+ clks[IMX8MQ_SYS2_PLL_333M] = imx_clk_fixed_factor("sys2_pll_333m", "sys2_pll_333m_cg", 1, 3);
+ clks[IMX8MQ_SYS2_PLL_500M] = imx_clk_fixed_factor("sys2_pll_500m", "sys2_pll_500m_cg", 1, 2);
+ clks[IMX8MQ_SYS2_PLL_1000M] = imx_clk_fixed_factor("sys2_pll_1000m", "sys2_pll_1000m_cg", 1, 1);
np = dev->of_node;
base = devm_platform_ioremap_resource(pdev, 0);
if (WARN_ON(IS_ERR(base)))
return PTR_ERR(base);
diff --git a/include/dt-bindings/clock/imx8mq-clock.h b/include/dt-bindings/clock/imx8mq-clock.h
index 65463673d25e..9b031f93b7d1 100644
--- a/include/dt-bindings/clock/imx8mq-clock.h
+++ b/include/dt-bindings/clock/imx8mq-clock.h
@@ -401,7 +401,27 @@
#define IMX8MQ_CLK_GPIO5_ROOT 263
#define IMX8MQ_CLK_SNVS_ROOT 264
#define IMX8MQ_CLK_GIC 265
-#define IMX8MQ_CLK_END 266
+#define IMX8MQ_SYS1_PLL_40M_CG 266
+#define IMX8MQ_SYS1_PLL_80M_CG 267
+#define IMX8MQ_SYS1_PLL_100M_CG 268
+#define IMX8MQ_SYS1_PLL_133M_CG 269
+#define IMX8MQ_SYS1_PLL_160M_CG 270
+#define IMX8MQ_SYS1_PLL_200M_CG 271
+#define IMX8MQ_SYS1_PLL_266M_CG 272
+#define IMX8MQ_SYS1_PLL_400M_CG 273
+#define IMX8MQ_SYS1_PLL_800M_CG 274
+#define IMX8MQ_SYS2_PLL_50M_CG 275
+#define IMX8MQ_SYS2_PLL_100M_CG 276
+#define IMX8MQ_SYS2_PLL_125M_CG 277
+#define IMX8MQ_SYS2_PLL_166M_CG 278
+#define IMX8MQ_SYS2_PLL_200M_CG 279
+#define IMX8MQ_SYS2_PLL_250M_CG 280
+#define IMX8MQ_SYS2_PLL_333M_CG 281
+#define IMX8MQ_SYS2_PLL_500M_CG 282
+#define IMX8MQ_SYS2_PLL_1000M_CG 283
+
+#define IMX8MQ_CLK_END 384
+
#endif /* __DT_BINDINGS_CLOCK_IMX8MQ_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] clk: imx8mm: Define gates for pll1/2 fixed dividers
From: Leonard Crestez @ 2019-09-11 12:05 UTC (permalink / raw)
To: Stephen Boyd, Shawn Guo, Jacky Bai, Abel Vesa
Cc: Dong Aisheng, Anson Huang, Michael Turquette, linux-imx, kernel,
Fabio Estevam, linux-clk, linux-arm-kernel
In-Reply-To: <cover.1568203237.git.leonard.crestez@nxp.com>
On imx8mm there are 9 fixed-factor dividers for SYS_PLL1 and SYS_PLL2
each with their own gate. Only one of these gates (the one "dividing" by
one) is currently defined and it's incorrectly set as the parent of all
the fixed-factor dividers.
Add the other 8 gates to the clock tree between sys_pll1/2_bypass and
the fixed dividers.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mm.c | 57 ++++++++++++++++--------
include/dt-bindings/clock/imx8mm-clock.h | 19 +++++++-
2 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 2758e3f0d15d..4ead3ea2713c 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -437,33 +437,52 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
clks[IMX8MM_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out", "video_pll1_bypass", base + 0x28, 13);
clks[IMX8MM_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out", "dram_pll_bypass", base + 0x50, 13);
clks[IMX8MM_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 11);
clks[IMX8MM_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", "vpu_pll_bypass", base + 0x74, 11);
clks[IMX8MM_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 11);
- clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 11);
- clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 11);
clks[IMX8MM_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 11);
- /* SYS PLL fixed output */
- clks[IMX8MM_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", "sys_pll1_out", 1, 20);
- clks[IMX8MM_SYS_PLL1_80M] = imx_clk_fixed_factor("sys_pll1_80m", "sys_pll1_out", 1, 10);
- clks[IMX8MM_SYS_PLL1_100M] = imx_clk_fixed_factor("sys_pll1_100m", "sys_pll1_out", 1, 8);
- clks[IMX8MM_SYS_PLL1_133M] = imx_clk_fixed_factor("sys_pll1_133m", "sys_pll1_out", 1, 6);
- clks[IMX8MM_SYS_PLL1_160M] = imx_clk_fixed_factor("sys_pll1_160m", "sys_pll1_out", 1, 5);
- clks[IMX8MM_SYS_PLL1_200M] = imx_clk_fixed_factor("sys_pll1_200m", "sys_pll1_out", 1, 4);
- clks[IMX8MM_SYS_PLL1_266M] = imx_clk_fixed_factor("sys_pll1_266m", "sys_pll1_out", 1, 3);
- clks[IMX8MM_SYS_PLL1_400M] = imx_clk_fixed_factor("sys_pll1_400m", "sys_pll1_out", 1, 2);
+ /* SYS PLL1 fixed output */
+ clks[IMX8MM_SYS_PLL1_40M_CG] = imx_clk_gate("sys_pll1_40m_cg", "sys_pll1_bypass", base + 0x94, 27);
+ clks[IMX8MM_SYS_PLL1_80M_CG] = imx_clk_gate("sys_pll1_80m_cg", "sys_pll1_bypass", base + 0x94, 25);
+ clks[IMX8MM_SYS_PLL1_100M_CG] = imx_clk_gate("sys_pll1_100m_cg", "sys_pll1_bypass", base + 0x94, 23);
+ clks[IMX8MM_SYS_PLL1_133M_CG] = imx_clk_gate("sys_pll1_133m_cg", "sys_pll1_bypass", base + 0x94, 21);
+ clks[IMX8MM_SYS_PLL1_160M_CG] = imx_clk_gate("sys_pll1_160m_cg", "sys_pll1_bypass", base + 0x94, 19);
+ clks[IMX8MM_SYS_PLL1_200M_CG] = imx_clk_gate("sys_pll1_200m_cg", "sys_pll1_bypass", base + 0x94, 17);
+ clks[IMX8MM_SYS_PLL1_266M_CG] = imx_clk_gate("sys_pll1_266m_cg", "sys_pll1_bypass", base + 0x94, 15);
+ clks[IMX8MM_SYS_PLL1_400M_CG] = imx_clk_gate("sys_pll1_400m_cg", "sys_pll1_bypass", base + 0x94, 13);
+ clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", "sys_pll1_bypass", base + 0x94, 11);
+
+ clks[IMX8MM_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", "sys_pll1_40m_cg", 1, 20);
+ clks[IMX8MM_SYS_PLL1_80M] = imx_clk_fixed_factor("sys_pll1_80m", "sys_pll1_80m_cg", 1, 10);
+ clks[IMX8MM_SYS_PLL1_100M] = imx_clk_fixed_factor("sys_pll1_100m", "sys_pll1_100m_cg", 1, 8);
+ clks[IMX8MM_SYS_PLL1_133M] = imx_clk_fixed_factor("sys_pll1_133m", "sys_pll1_133m_cg", 1, 6);
+ clks[IMX8MM_SYS_PLL1_160M] = imx_clk_fixed_factor("sys_pll1_160m", "sys_pll1_160m_cg", 1, 5);
+ clks[IMX8MM_SYS_PLL1_200M] = imx_clk_fixed_factor("sys_pll1_200m", "sys_pll1_200m_cg", 1, 4);
+ clks[IMX8MM_SYS_PLL1_266M] = imx_clk_fixed_factor("sys_pll1_266m", "sys_pll1_266m_cg", 1, 3);
+ clks[IMX8MM_SYS_PLL1_400M] = imx_clk_fixed_factor("sys_pll1_400m", "sys_pll1_400m_cg", 1, 2);
clks[IMX8MM_SYS_PLL1_800M] = imx_clk_fixed_factor("sys_pll1_800m", "sys_pll1_out", 1, 1);
- clks[IMX8MM_SYS_PLL2_50M] = imx_clk_fixed_factor("sys_pll2_50m", "sys_pll2_out", 1, 20);
- clks[IMX8MM_SYS_PLL2_100M] = imx_clk_fixed_factor("sys_pll2_100m", "sys_pll2_out", 1, 10);
- clks[IMX8MM_SYS_PLL2_125M] = imx_clk_fixed_factor("sys_pll2_125m", "sys_pll2_out", 1, 8);
- clks[IMX8MM_SYS_PLL2_166M] = imx_clk_fixed_factor("sys_pll2_166m", "sys_pll2_out", 1, 6);
- clks[IMX8MM_SYS_PLL2_200M] = imx_clk_fixed_factor("sys_pll2_200m", "sys_pll2_out", 1, 5);
- clks[IMX8MM_SYS_PLL2_250M] = imx_clk_fixed_factor("sys_pll2_250m", "sys_pll2_out", 1, 4);
- clks[IMX8MM_SYS_PLL2_333M] = imx_clk_fixed_factor("sys_pll2_333m", "sys_pll2_out", 1, 3);
- clks[IMX8MM_SYS_PLL2_500M] = imx_clk_fixed_factor("sys_pll2_500m", "sys_pll2_out", 1, 2);
+ /* SYS PLL2 fixed output */
+ clks[IMX8MM_SYS_PLL2_50M_CG] = imx_clk_gate("sys_pll2_50m_cg", "sys_pll2_bypass", base + 0x104, 27);
+ clks[IMX8MM_SYS_PLL2_100M_CG] = imx_clk_gate("sys_pll2_100m_cg", "sys_pll2_bypass", base + 0x104, 25);
+ clks[IMX8MM_SYS_PLL2_125M_CG] = imx_clk_gate("sys_pll2_125m_cg", "sys_pll2_bypass", base + 0x104, 23);
+ clks[IMX8MM_SYS_PLL2_166M_CG] = imx_clk_gate("sys_pll2_166m_cg", "sys_pll2_bypass", base + 0x104, 21);
+ clks[IMX8MM_SYS_PLL2_200M_CG] = imx_clk_gate("sys_pll2_200m_cg", "sys_pll2_bypass", base + 0x104, 19);
+ clks[IMX8MM_SYS_PLL2_250M_CG] = imx_clk_gate("sys_pll2_250m_cg", "sys_pll2_bypass", base + 0x104, 17);
+ clks[IMX8MM_SYS_PLL2_333M_CG] = imx_clk_gate("sys_pll2_333m_cg", "sys_pll2_bypass", base + 0x104, 15);
+ clks[IMX8MM_SYS_PLL2_500M_CG] = imx_clk_gate("sys_pll2_500m_cg", "sys_pll2_bypass", base + 0x104, 13);
+ clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", "sys_pll2_bypass", base + 0x104, 11);
+
+ clks[IMX8MM_SYS_PLL2_50M] = imx_clk_fixed_factor("sys_pll2_50m", "sys_pll2_50m_cg", 1, 20);
+ clks[IMX8MM_SYS_PLL2_100M] = imx_clk_fixed_factor("sys_pll2_100m", "sys_pll2_100m_cg", 1, 10);
+ clks[IMX8MM_SYS_PLL2_125M] = imx_clk_fixed_factor("sys_pll2_125m", "sys_pll2_125m_cg", 1, 8);
+ clks[IMX8MM_SYS_PLL2_166M] = imx_clk_fixed_factor("sys_pll2_166m", "sys_pll2_166m_cg", 1, 6);
+ clks[IMX8MM_SYS_PLL2_200M] = imx_clk_fixed_factor("sys_pll2_200m", "sys_pll2_200m_cg", 1, 5);
+ clks[IMX8MM_SYS_PLL2_250M] = imx_clk_fixed_factor("sys_pll2_250m", "sys_pll2_250m_cg", 1, 4);
+ clks[IMX8MM_SYS_PLL2_333M] = imx_clk_fixed_factor("sys_pll2_333m", "sys_pll2_333m_cg", 1, 3);
+ clks[IMX8MM_SYS_PLL2_500M] = imx_clk_fixed_factor("sys_pll2_500m", "sys_pll2_500m_cg", 1, 2);
clks[IMX8MM_SYS_PLL2_1000M] = imx_clk_fixed_factor("sys_pll2_1000m", "sys_pll2_out", 1, 1);
np = dev->of_node;
base = devm_platform_ioremap_resource(pdev, 0);
if (WARN_ON(IS_ERR(base)))
diff --git a/include/dt-bindings/clock/imx8mm-clock.h b/include/dt-bindings/clock/imx8mm-clock.h
index 07e6c686f3ef..8cf994043bcd 100644
--- a/include/dt-bindings/clock/imx8mm-clock.h
+++ b/include/dt-bindings/clock/imx8mm-clock.h
@@ -246,8 +246,25 @@
#define IMX8MM_CLK_GPIO5_ROOT 227
#define IMX8MM_CLK_SNVS_ROOT 228
#define IMX8MM_CLK_GIC 229
-#define IMX8MM_CLK_END 230
+#define IMX8MM_SYS_PLL1_40M_CG 230
+#define IMX8MM_SYS_PLL1_80M_CG 231
+#define IMX8MM_SYS_PLL1_100M_CG 232
+#define IMX8MM_SYS_PLL1_133M_CG 233
+#define IMX8MM_SYS_PLL1_160M_CG 234
+#define IMX8MM_SYS_PLL1_200M_CG 235
+#define IMX8MM_SYS_PLL1_266M_CG 236
+#define IMX8MM_SYS_PLL1_400M_CG 237
+#define IMX8MM_SYS_PLL2_50M_CG 239
+#define IMX8MM_SYS_PLL2_100M_CG 240
+#define IMX8MM_SYS_PLL2_125M_CG 241
+#define IMX8MM_SYS_PLL2_166M_CG 242
+#define IMX8MM_SYS_PLL2_200M_CG 243
+#define IMX8MM_SYS_PLL2_250M_CG 244
+#define IMX8MM_SYS_PLL2_333M_CG 245
+#define IMX8MM_SYS_PLL2_500M_CG 246
+
+#define IMX8MM_CLK_END 248
#endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michael S. Tsirkin @ 2019-09-11 12:08 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911113619.GP4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
>
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>
> --
> Michal Hocko
> SUSE Labs
Linus nacked that one. He thinks invoking callbacks with lots of
internal mm locks is too fragile.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox