Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
Hi Aren,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Aren-Moynihan/dt-bindings-iio-light-stk33xx-add-vdd-and-leda-regulators/20240424-064250
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link:
https://lore.kernel.org/r/20240423223309.1468198-4-aren%40peacevolution.org
patch subject: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and
power it off during suspend
config: i386-randconfig-141-20240424
(https://download.01.org/0day-ci/archive/20240425/202404251021.4oper3os-...@intel.com/config)
compiler: gcc-10 (Ubuntu 10.5.0-1ubuntu1) 10.5.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by: Dan Carpenter
| Closes: https://lore.kernel.org/r/202404251021.4oper3os-...@intel.com/
smatch warnings:
drivers/iio/light/stk3310.c:615 stk3310_probe() error: uninitialized symbol
'ret'.
vim +/ret +615 drivers/iio/light/stk3310.c
9046d80dce04c6 Uwe Kleine-König 2022-11-18 592 static int
stk3310_probe(struct i2c_client *client)
be9e6229d67696 Tiberiu Breana 2015-04-27 593 {
be9e6229d67696 Tiberiu Breana 2015-04-27 594 int ret;
be9e6229d67696 Tiberiu Breana 2015-04-27 595 struct iio_dev
*indio_dev;
be9e6229d67696 Tiberiu Breana 2015-04-27 596 struct stk3310_data
*data;
be9e6229d67696 Tiberiu Breana 2015-04-27 597
be9e6229d67696 Tiberiu Breana 2015-04-27 598 indio_dev =
devm_iio_device_alloc(&client->dev, sizeof(*data));
be9e6229d67696 Tiberiu Breana 2015-04-27 599 if (!indio_dev) {
be9e6229d67696 Tiberiu Breana 2015-04-27 600
dev_err(&client->dev, "iio allocation failed!\n");
be9e6229d67696 Tiberiu Breana 2015-04-27 601 return -ENOMEM;
be9e6229d67696 Tiberiu Breana 2015-04-27 602 }
be9e6229d67696 Tiberiu Breana 2015-04-27 603
be9e6229d67696 Tiberiu Breana 2015-04-27 604 data =
iio_priv(indio_dev);
be9e6229d67696 Tiberiu Breana 2015-04-27 605 data->client = client;
be9e6229d67696 Tiberiu Breana 2015-04-27 606
i2c_set_clientdata(client, indio_dev);
d6ecb01583d4e0 Arnaud Ferraris 2022-04-20 607
d6ecb01583d4e0 Arnaud Ferraris 2022-04-20 608
device_property_read_u32(&client->dev, "proximity-near-level",
d6ecb01583d4e0 Arnaud Ferraris 2022-04-20 609
&data->ps_near_level);
d6ecb01583d4e0 Arnaud Ferraris 2022-04-20 610
be9e6229d67696 Tiberiu Breana 2015-04-27 611 mutex_init(&data->lock);
be9e6229d67696 Tiberiu Breana 2015-04-27 612
dd231c1d219f6b Ondrej Jirman2024-04-23 613 data->vdd_reg =
devm_regulator_get(&client->dev, "vdd");
dd231c1d219f6b Ondrej Jirman2024-04-23 614 if
(IS_ERR(data->vdd_reg))
dd231c1d219f6b Ondrej Jirman2024-04-23 @615 return
dev_err_probe(&client->dev, ret, "get regulator vdd failed\n");
s/ret/PTR_ERR(data->vdd_reg)/
dd231c1d219f6b Ondrej Jirman2024-04-23 616
be9e6229d67696 Tiberiu Breana 2015-04-27 617 ret =
stk3310_regmap_init(data);
be9e6229d67696 Tiberiu Breana 2015-04-27 618 if (ret < 0)
be9e6229d67696 Tiberiu Breana 2015-04-27 619 return ret;
be9e6229d67696 Tiberiu Breana 2015-04-27 620
be9e6229d67696 Tiberiu Breana 2015-04-27 621 indio_dev->info =
&stk3310_info;
be9e6229d67696 Tiberiu Breana 2015-04-27 622 indio_dev->name =
STK3310_DRIVER_NAME;
be9e6229d67696 Tiberiu Breana 2015-04-27 623 indio_dev->modes =
INDIO_DIRECT_MODE;
be9e6229d67696 Tiberiu Breana 2015-04-27 624 indio_dev->channels =
stk3310_channels;
be9e6229d67696 Tiberiu Breana 2015-04-27 625 indio_dev->num_channels
= ARRAY_SIZE(stk3310_channels);
be9e6229d67696 Tiberiu Breana 2015-04-27 626
dd231c1d219f6b Ondrej Jirman2024-04-23 627 ret =
regulator_enable(data->vdd_reg);
dd231c1d219f6b Ondrej Jirman2024-04-23 628 if (ret)
dd231c1d219f6b Ondrej Jirman2024-04-23 629 return
dev_err_probe(&client->dev, ret,
dd231c1d219f6b Ondrej Jirman2024-04-23 630
"regulator vdd enable failed\n");
dd231c1d219f6b Ondrej Jirman2024-04-23 631
dd231c1d219f6b Ondrej Jirman2024-04-23 632 /* we need a short
delay to allow the chip time to power on */
dd231c1d219f6b Ondrej Jirman2024-04-23 633 fsleep(1000);
dd231c1d219f6b Ondrej Jirman2024-04-23 634
be9e6229d67696 Tiberiu Breana 2015-04-27 635 ret =
stk3310_init(indio_dev);
be9e6229d67696 Tiberiu Breana 2015-04
Re: [PATCH v12 14/14] selftests/sgx: Add scripts for EPC cgroup testing
On Wed Apr 24, 2024 at 10:42 PM EEST, Haitao Huang wrote: > Hi Jarkko > On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen > wrote: > > > On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote: > >> I did declare the configs in the config file but I missed it in my patch > >> as stated earlier. IIUC, that would not cause this error though. > >> > >> Maybe I should exit with the skip code if no CGROUP_MISC (no more > >> CGROUP_SGX_EPC) is configured? > > OK, so I wanted to do a distro kernel test here, and used the default > > OpenSUSE kernel config. I need to check if it has CGROUP_MISC set. > > I couldn't figure out why this failure you have encountered. I think > OpenSUSE kernel most likely config CGROUP_MISC. > > Also if CGROUP_MISC not set, then there should be error happen earlier on > echoing "+misc" to cgroup.subtree_control at line 20. But your log > indicates only error on echoing "sgx_epc ..." to > /sys/fs/cgroup/...//misc.max. > > I can only speculate that can could happen (if sgx epc cgroup was compiled > in) when the cgroup-fs subdirectories in question already have populated > config that is conflicting with the scripts. > > Could you double check or start from a clean environment? > Thanks > Haitao I can re-check next week once I'm back from Estonia. I'm travelling now to https://lu.ma/uncloud. BR, Jarkko
Re: [PATCH v5 3/5] vduse: Add function to get/free the pages for reconnection
On Wed, Apr 24, 2024 at 5:51 PM Michael S. Tsirkin wrote:
>
> On Wed, Apr 24, 2024 at 08:44:10AM +0800, Jason Wang wrote:
> > On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > > > On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin
> > > > wrote:
> > > > >
> > > > > On Thu, Apr 18, 2024 at 08:57:51AM +0800, Jason Wang wrote:
> > > > > > On Wed, Apr 17, 2024 at 5:29 PM Michael S. Tsirkin
> > > > > > wrote:
> > > > > > >
> > > > > > > On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu wrote:
> > > > > > > > Add the function vduse_alloc_reconnnect_info_mem
> > > > > > > > and vduse_alloc_reconnnect_info_mem
> > > > > > > > These functions allow vduse to allocate and free memory for
> > > > > > > > reconnection
> > > > > > > > information. The amount of memory allocated is vq_num pages.
> > > > > > > > Each VQS will map its own page where the reconnection
> > > > > > > > information will be saved
> > > > > > > >
> > > > > > > > Signed-off-by: Cindy Lu
> > > > > > > > ---
> > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 40
> > > > > > > > ++
> > > > > > > > 1 file changed, 40 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > index ef3c9681941e..2da659d5f4a8 100644
> > > > > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > > @@ -65,6 +65,7 @@ struct vduse_virtqueue {
> > > > > > > > int irq_effective_cpu;
> > > > > > > > struct cpumask irq_affinity;
> > > > > > > > struct kobject kobj;
> > > > > > > > + unsigned long vdpa_reconnect_vaddr;
> > > > > > > > };
> > > > > > > >
> > > > > > > > struct vduse_dev;
> > > > > > > > @@ -1105,6 +1106,38 @@ static void
> > > > > > > > vduse_vq_update_effective_cpu(struct vduse_virtqueue *vq)
> > > > > > > >
> > > > > > > > vq->irq_effective_cpu = curr_cpu;
> > > > > > > > }
> > > > > > > > +static int vduse_alloc_reconnnect_info_mem(struct vduse_dev
> > > > > > > > *dev)
> > > > > > > > +{
> > > > > > > > + unsigned long vaddr = 0;
> > > > > > > > + struct vduse_virtqueue *vq;
> > > > > > > > +
> > > > > > > > + for (int i = 0; i < dev->vq_num; i++) {
> > > > > > > > + /*page 0~ vq_num save the reconnect info for vq*/
> > > > > > > > + vq = dev->vqs[i];
> > > > > > > > + vaddr = get_zeroed_page(GFP_KERNEL);
> > > > > > >
> > > > > > >
> > > > > > > I don't get why you insist on stealing kernel memory for something
> > > > > > > that is just used by userspace to store data for its own use.
> > > > > > > Userspace does not lack ways to persist data, for example,
> > > > > > > create a regular file anywhere in the filesystem.
> > > > > >
> > > > > > Good point. So the motivation here is to:
> > > > > >
> > > > > > 1) be self contained, no dependency for high speed persist data
> > > > > > storage like tmpfs
> > > > >
> > > > > No idea what this means.
> > > >
> > > > I mean a regular file may slow down the datapath performance, so
> > > > usually the application will try to use tmpfs and other which is a
> > > > dependency for implementing the reconnection.
> > >
> > > Are we worried about systems without tmpfs now?
> >
> > Yes.
>
> Why? Who ships these?
Not sure, but it could be disabled or unmounted. I'm not sure make
VDUSE depends on TMPFS is a good idea.
Thanks
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 02:16:06AM +0300, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan wrote:
> >
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
>
> ...
>
> > ret = stk3310_init(indio_dev);
> > if (ret < 0)
> > - return ret;
> > + goto err_vdd_disable;
>
> This is wrong. You will have the regulator being disabled _before_
> IRQ. Note, that the original code likely has a bug which sets states
> before disabling IRQ and removing a handler.
Oh! now I see the issue you were talking about last time around. I
expect that means the irq shouldn't be managed with devres, so it can be
the first thing freed in the remove function (I haven't checked the docs
to see if there's an easier way yet).
I'll add a patch to fix the order of the handling of the irq (both this and
the issue Ondřej brought up).
> Side note, you may make the driver neater with help of
>
> struct device *dev = &client->dev;
>
> defined in this patch.
Good point, it's minor, but it should be a net improvement.
> ...
>
> > static int stk3310_suspend(struct device *dev)
> > {
> > struct stk3310_data *data;
>
> > data = iio_priv(i2c_get_clientdata(to_i2c_client(dev)));
>
> Side note: This may be updated (in a separate change) to use
> dev_get_drvdata() directly.
>
> Jonathan, do we have something like iio_priv_from_drvdata(struct
> device *dev)? Seems many drivers may utilise it.
>
At this rate I'm going to need to split off a separate style / code
cleanup series so I don't keep introducing dumb bugs while rebasing this
one.
Thank you for your time
- Aren
Re: [PATCH v2] ipvs: Fix checksumming on GSO of SCTP packets
On Sun, Apr 21, 2024 at 04:22:32PM +0200, Ismael Luceno wrote:
> It was observed in the wild that pairs of consecutive packets would leave
> the IPVS with the same wrong checksum, and the issue only went away when
> disabling GSO.
>
> IPVS needs to avoid computing the SCTP checksum when using GSO.
I am placing this into the nf.git tree for submission upstream in the
next pull request, unless stated otherwise.
Thanks.
> Fixes: 90017accff61 ("sctp: Add GSO support", 2016-06-02)
> Co-developed-by: Firo Yang
> Signed-off-by: Ismael Luceno
> Tested-by: Andreas Taschner
> CC: Michal Kubeček
> CC: Simon Horman
> CC: Julian Anastasov
> CC: lvs-de...@vger.kernel.org
> CC: netfilter-de...@vger.kernel.org
> CC: net...@vger.kernel.org
> CC: coret...@netfilter.org
> ---
>
> Notes:
> Changes since v1:
> * Added skb_is_gso before skb_is_gso_sctp.
> * Added "Fixes" tag.
>
> net/netfilter/ipvs/ip_vs_proto_sctp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> index a0921adc31a9..1e689c714127 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> @@ -126,7 +126,8 @@ sctp_snat_handler(struct sk_buff *skb, struct
> ip_vs_protocol *pp,
> if (sctph->source != cp->vport || payload_csum ||
> skb->ip_summed == CHECKSUM_PARTIAL) {
> sctph->source = cp->vport;
> - sctp_nat_csum(skb, sctph, sctphoff);
> + if (!skb_is_gso(skb) || !skb_is_gso_sctp(skb))
> + sctp_nat_csum(skb, sctph, sctphoff);
> } else {
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
> @@ -174,7 +175,8 @@ sctp_dnat_handler(struct sk_buff *skb, struct
> ip_vs_protocol *pp,
> (skb->ip_summed == CHECKSUM_PARTIAL &&
>!(skb_dst(skb)->dev->features & NETIF_F_SCTP_CRC))) {
> sctph->dest = cp->dport;
> - sctp_nat_csum(skb, sctph, sctphoff);
> + if (!skb_is_gso(skb) || !skb_is_gso_sctp(skb))
> + sctp_nat_csum(skb, sctph, sctphoff);
> } else if (skb->ip_summed != CHECKSUM_PARTIAL) {
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
> --
> 2.43.0
>
>
Re: [RFC][PATCH] uprobe: support for private hugetlb mappings
On 24.04.24 22:44, Guillaume Morin wrote: On 24 Apr 22:09, David Hildenbrand wrote: Let me try to see if we can get this done cleaner. One ugly part (in general here) is the custom page replacement in the registration part. We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing pages ourselves (which we likely shouldn't do ...) ... maybe we could use FAULT_FLAG_UNSHARE faults such that we will get an anonymous folio populated. (like KSM does nowadays) Punching FOLL_PIN|FOLL_LONGTERM into GUP would achieve the same thing, but using FOLL_WRITE would not work on many file systems. So maybe we have to trigger an unsharing fault ourselves. ^ realizing that we already use FOLL_FORCE, so we can just use FOLL_WRITE to break COW. It was never clear to me why uprobes was not doing FOLL_WRITE in the first place, I must say. It's quite dated code ... The use of FOLL_FORCE really is ugly here. When registering, we require VM_WRITE but ... when unregistering, we don't ... One issue here is that FOLL_FORCE|FOLL_WRITE is not implemented for hugetlb mappings. However this was also on my TODO and I have a draft patch that implements it. Yes, I documented it back then and added sanity checks in GUP code to fence it off. Shouldn't be too hard to implement (famous last words) and would be the cleaner thing to use here once I manage to switch over to FOLL_WRITE|FOLL_FORCE to break COW. -- Cheers, David / dhildenb
Re: [PATCH v21 2/5] ring-buffer: Introducing ring-buffer mapping functions
On 24.04.24 22:31, Vincent Donnefort wrote:
Hi David,
Thanks for your quick response.
On Wed, Apr 24, 2024 at 05:26:39PM +0200, David Hildenbrand wrote:
I gave it some more thought, and I think we are still missing something (I
wish PFNMAP/MIXEDMAP wouldn't be that hard).
+
+/*
+ * +--+ pgoff == 0
+ * | meta page |
+ * +--+ pgoff == 1
+ * | subbuffer 0 |
+ * | |
+ * +--+ pgoff == (1 + (1 << subbuf_order))
+ * | subbuffer 1 |
+ * | |
+ * ...
+ */
+#ifdef CONFIG_MMU
+static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
+ struct vm_area_struct *vma)
+{
+ unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
+ unsigned int subbuf_pages, subbuf_order;
+ struct page **pages;
+ int p = 0, s = 0;
+ int err;
+
I'd add some comments here like
/* Refuse any MAP_PRIVATE or writable mappings. */
+ if (vma->vm_flags & VM_WRITE || vma->vm_flags & VM_EXEC ||
+ !(vma->vm_flags & VM_MAYSHARE))
+ return -EPERM;
+
/*
* Make sure the mapping cannot become writable later. Also, tell the VM
* to not touch these pages pages (VM_DONTCOPY | VM_DONTDUMP) and tell
* GUP to leave them alone as well (VM_IO).
*/
+ vm_flags_mod(vma,
+VM_MIXEDMAP | VM_PFNMAP |
+VM_DONTCOPY | VM_DONTDUMP | VM_DONTEXPAND | VM_IO,
+VM_MAYWRITE);
I am still really unsure about VM_PFNMAP ... it's not a PFNMAP at all and,
as stated, vm_insert_pages() even complains quite a lot when it would have
to set VM_MIXEDMAP and VM_PFNMAP is already set, likely for a very good
reason.
Can't we limit ourselves to VM_IO?
But then, I wonder if it really helps much regarding GUP: yes, it blocks
ordinary GUP (see check_vma_flags()) but as insert_page_into_pte_locked()
does *not* set pte_special(), GUP-fast (gup_fast_pte_range()) will not
reject it.
Really, if you want GUP-fast to reject it, remap_pfn_range() and friends are
the way to go, that will set pte_special() such that also GUP-fast will
leave it alone, just like vm_normal_page() would.
So ... I know Linus recommended VM_PFNMAP/VM_IO to stop GUP, but it alone
won't stop all of GUP. We really have to mark the PTE as special, which
vm_insert_page() must not do (because it is refcounted!).
Hum, apologies, I am not sure to follow the connection here. Why do you think
the recommendation was to prevent GUP?
Ah, I'm hallucinating! :) "not let people play games with the mapping" to me
implied "make sure nobody touches it". If GUP is acceptable that makes stuff
a lot easier. VM_IO will block some GUP, but not all of it.
Which means: do we really have to stop GUP from grabbing that page?
Using vm_insert_page() only with VM_MIXEDMAP (and without VM_PFNMAP|VM_IO)
would be better.
Under the assumption we do not want to stop all GUP, why not using VM_IO over
VM_MIXEDMAP which is I believe more restrictive?
VM_MIXEDMAP will be implicitly set by vm_insert_page(). There is a lengthy
comment
for vm_normal_page() that explains all this madness. VM_MIXEDMAP is primarily
relevant for COW mappings, which you just forbid completely.
remap_pfn_range_notrack() documents the semantics of some of the other flags:
* VM_IO tells people not to look at these pages
* (accesses can have side effects).
* VM_PFNMAP tells the core MM that the base pages are just
* raw PFN mappings, and do not have a "struct page" associated
* with them.
* VM_DONTEXPAND
* Disable vma merging and expanding with mremap().
* VM_DONTDUMP
* Omit vma from core dump, even when VM_IO turned off.
VM_PFNMAP is very likely really not what we want, unless we really perform raw
PFN mappings ... VM_IO we can set without doing much harm.
So I would suggest dropping VM_PFNMAP when using vm_insert_pages(), using only
VM_IO
and likely just letting vm_insert_pages() set VM_MIXEDMAP for you.
[...]
vm_insert_pages() documents: "In case of error, we may have mapped a subset
of the provided pages. It is the caller's responsibility to account for this
case."
Which could for example happen, when allocating a page table fails.
Would we able to deal with that here?
As we are in the mmap path, on an error, I would expect the vma to be destroyed
and those pages whom insertion succeeded to be unmapped?
Ah, we simply fail ->mmap().
In mmap_region(), if call_mmap() failed, we "goto unmap_and_free_vma" where we
have
/* Undo any partial mapping done by a device driver. */
unmap_region(mm, &vmi.mas, vma, prev, next, vma->vm_start, vma->vm_end,
vma->vm_end, true);
But perhaps shall we proactively zap_page_range_single()?
No mmap_region() should indeed be handling it correctly already!
--
Cheers,
David / dhildenb
Re: [RFC][PATCH] uprobe: support for private hugetlb mappings
On 24 Apr 22:09, David Hildenbrand wrote: > > > Let me try to see if we can get this done cleaner. > > > > > > One ugly part (in general here) is the custom page replacement in the > > > registration part. > > > > > > We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing > > > pages > > > ourselves (which we likely shouldn't do ...) ... maybe we could use > > > FAULT_FLAG_UNSHARE faults such that we will get an anonymous folio > > > populated. (like KSM does nowadays) > > > > > > Punching FOLL_PIN|FOLL_LONGTERM into GUP would achieve the same thing, but > > > using FOLL_WRITE would not work on many file systems. So maybe we have to > > > trigger an unsharing fault ourselves. > > ^ realizing that we already use FOLL_FORCE, so we can just use FOLL_WRITE to > break COW. It was never clear to me why uprobes was not doing FOLL_WRITE in the first place, I must say. One issue here is that FOLL_FORCE|FOLL_WRITE is not implemented for hugetlb mappings. However this was also on my TODO and I have a draft patch that implements it. > > > > > > > That would do the page replacement for us and we "should" be able to > > > lookup > > > an anonymous folio that we can then just modify, like ptrace would. > > > > > > But then, there is also unregistration part, with weird conditional page > > > replacement. Zapping the anon page if the content matches the content of > > > the > > > original page is one thing. But why are we placing an existing anonymous > > > page by a new anonymous page when the content from the original page > > > differs > > > (but matches the one from the just copied page?)? > > > > > > I'll have to further think about that one. It's all a bit nasty. > > > > Sounds good to me. I am willing to help with the code when you have a > > plan or testing as you see fit. Let me know. > > I'm hacking on a redesign that removes the manual COW breaking logic and > *might* make it easier to integrate hugetlb. (very likely, but until I have > the redesign running I cannot promise anything :) ) > > I'll let you know once I have something ready so you could integrate the > hugetlb portion. Sounds good. -- Guillaume Morin
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote: > From: Hari Nagalla > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > Signed-off-by: Andrew Davis > --- > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++ > 1 file changed, 126 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): Warning: Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-...@ti.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v21 2/5] ring-buffer: Introducing ring-buffer mapping functions
Hi David,
Thanks for your quick response.
On Wed, Apr 24, 2024 at 05:26:39PM +0200, David Hildenbrand wrote:
>
> I gave it some more thought, and I think we are still missing something (I
> wish PFNMAP/MIXEDMAP wouldn't be that hard).
>
> > +
> > +/*
> > + * +--+ pgoff == 0
> > + * | meta page |
> > + * +--+ pgoff == 1
> > + * | subbuffer 0 |
> > + * | |
> > + * +--+ pgoff == (1 + (1 << subbuf_order))
> > + * | subbuffer 1 |
> > + * | |
> > + * ...
> > + */
> > +#ifdef CONFIG_MMU
> > +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> > + struct vm_area_struct *vma)
> > +{
> > + unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
> > + unsigned int subbuf_pages, subbuf_order;
> > + struct page **pages;
> > + int p = 0, s = 0;
> > + int err;
> > +
>
> I'd add some comments here like
>
> /* Refuse any MAP_PRIVATE or writable mappings. */
> > + if (vma->vm_flags & VM_WRITE || vma->vm_flags & VM_EXEC ||
> > + !(vma->vm_flags & VM_MAYSHARE))
> > + return -EPERM;
> > +
>
> /*
> * Make sure the mapping cannot become writable later. Also, tell the VM
> * to not touch these pages pages (VM_DONTCOPY | VM_DONTDUMP) and tell
> * GUP to leave them alone as well (VM_IO).
> */
> > + vm_flags_mod(vma,
> > +VM_MIXEDMAP | VM_PFNMAP |
> > +VM_DONTCOPY | VM_DONTDUMP | VM_DONTEXPAND | VM_IO,
> > +VM_MAYWRITE);
>
> I am still really unsure about VM_PFNMAP ... it's not a PFNMAP at all and,
> as stated, vm_insert_pages() even complains quite a lot when it would have
> to set VM_MIXEDMAP and VM_PFNMAP is already set, likely for a very good
> reason.
>
> Can't we limit ourselves to VM_IO?
>
> But then, I wonder if it really helps much regarding GUP: yes, it blocks
> ordinary GUP (see check_vma_flags()) but as insert_page_into_pte_locked()
> does *not* set pte_special(), GUP-fast (gup_fast_pte_range()) will not
> reject it.
>
> Really, if you want GUP-fast to reject it, remap_pfn_range() and friends are
> the way to go, that will set pte_special() such that also GUP-fast will
> leave it alone, just like vm_normal_page() would.
>
> So ... I know Linus recommended VM_PFNMAP/VM_IO to stop GUP, but it alone
> won't stop all of GUP. We really have to mark the PTE as special, which
> vm_insert_page() must not do (because it is refcounted!).
Hum, apologies, I am not sure to follow the connection here. Why do you think
the recommendation was to prevent GUP?
>
> Which means: do we really have to stop GUP from grabbing that page?
>
> Using vm_insert_page() only with VM_MIXEDMAP (and without VM_PFNMAP|VM_IO)
> would be better.
Under the assumption we do not want to stop all GUP, why not using VM_IO over
VM_MIXEDMAP which is I believe more restrictive?
>
> If we want to stop all of GUP, remap_pfn_range() currently seems unavoidable
> :(
>
>
> > +
> > + lockdep_assert_held(&cpu_buffer->mapping_lock);
> > +
> > + subbuf_order = cpu_buffer->buffer->subbuf_order;
> > + subbuf_pages = 1 << subbuf_order;
> > +
> > + nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
> > + nr_pages = ((nr_subbufs) << subbuf_order) - pgoff + 1; /* + meta-page */
> > +
> > + vma_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > + if (!vma_pages || vma_pages > nr_pages)
> > + return -EINVAL;
> > +
> > + nr_pages = vma_pages;
> > +
> > + pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
> > + if (!pages)
> > + return -ENOMEM;
> > +
> > + if (!pgoff) {
> > + pages[p++] = virt_to_page(cpu_buffer->meta_page);
> > +
> > + /*
> > +* TODO: Align sub-buffers on their size, once
> > +* vm_insert_pages() supports the zero-page.
> > +*/
> > + } else {
> > + /* Skip the meta-page */
> > + pgoff--;
> > +
> > + if (pgoff % subbuf_pages) {
> > + err = -EINVAL;
> > + goto out;
> > + }
> > +
> > + s += pgoff / subbuf_pages;
> > + }
> > +
> > + while (s < nr_subbufs && p < nr_pages) {
> > + struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]);
> > + int off = 0;
> > +
> > + for (; off < (1 << (subbuf_order)); off++, page++) {
> > + if (p >= nr_pages)
> > + break;
> > +
> > + pages[p++] = page;
> > + }
> > + s++;
> > + }
> > +
> > + err = vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);
>
> vm_insert_pages() documents: "In case of error, we may have mapped a subset
> of the provided pages. It is the caller's responsibility to account for this
> case."
>
> Which could for example happen, when allocating a page table fails.
>
> Would we able to deal with that here?
As we are in the mmap path, on an error, I wo
Re: [PATCH 6/7] arm64: dts: qcom: msm8976: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 7/7] arm64: dts: qcom: msm8994: Use mboxes properties for APCS
On 4/24/24 18:24, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 5/7] arm64: dts: qcom: msm8953: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 4/7] arm64: dts: qcom: msm8939: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/7] arm64: dts: qcom: msm8916: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/7] ARM: dts: qcom: msm8974: Use mboxes properties for APCS
On 4/24/24 18:23, Luca Weiss wrote: Instead of passing the syscon to the various nodes, use the mbox interface using the mboxes property. Signed-off-by: Luca Weiss --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH RFC 2/2] soc: qcom: smsm: Support using mailbox interface
On 4/24/24 19:21, Luca Weiss wrote: Add support for using the mbox interface instead of manually writing to the syscon. With this change the driver will attempt to get the mailbox first, and if that fails it will fall back to the existing way of using qcom,ipc-* properties and converting to syscon. Signed-off-by: Luca Weiss --- Looks good! Reviewed-by: Konrad Dybcio Konrad
Re: [RFC][PATCH] uprobe: support for private hugetlb mappings
On 22.04.24 22:53, Guillaume Morin wrote: On 22 Apr 20:59, David Hildenbrand wrote: The benefit - to me - is very clear. People do use hugetlb mappings to run code in production environments. The perf benefits are there for some workloads. Intel has published a whitepaper about it etc. Uprobes are a very good tool to do live tracing. If you can restart the process and reproduce, you should be able to disable hugetlb remapping but if you need to look at a live process, there are not many options. Not being able to use uprobes is crippling. Please add all that as motivation to the patch description or cover letter. Yes, libhugetlbfs exists. But why do we have to support uprobes with it? Nobody cared until now, why care now? I think you could ask the same question for every new feature patch :) I have to, because it usually indicates a lack of motivation in the cover-letter/patch description :P My cover letter was indeed lacking. I will make sure to add this kind of details next time. Since the removal a few releases ago of the __morecore() hook in glibc, the main feature of libhugetlbfs is ELF segments remapping. I think there are definitely a lot of users that simply deal with this unnecessary limitation. I am certainly not shoving this patch through anyone's throat if there is no interest. But we definitely find it a very useful feature ... Let me try to see if we can get this done cleaner. One ugly part (in general here) is the custom page replacement in the registration part. We are guaranteed to have a MAP_PRIVATE mapping. Instead of replacing pages ourselves (which we likely shouldn't do ...) ... maybe we could use FAULT_FLAG_UNSHARE faults such that we will get an anonymous folio populated. (like KSM does nowadays) Punching FOLL_PIN|FOLL_LONGTERM into GUP would achieve the same thing, but using FOLL_WRITE would not work on many file systems. So maybe we have to trigger an unsharing fault ourselves. ^ realizing that we already use FOLL_FORCE, so we can just use FOLL_WRITE to break COW. That would do the page replacement for us and we "should" be able to lookup an anonymous folio that we can then just modify, like ptrace would. But then, there is also unregistration part, with weird conditional page replacement. Zapping the anon page if the content matches the content of the original page is one thing. But why are we placing an existing anonymous page by a new anonymous page when the content from the original page differs (but matches the one from the just copied page?)? I'll have to further think about that one. It's all a bit nasty. Sounds good to me. I am willing to help with the code when you have a plan or testing as you see fit. Let me know. I'm hacking on a redesign that removes the manual COW breaking logic and *might* make it easier to integrate hugetlb. (very likely, but until I have the redesign running I cannot promise anything :) ) I'll let you know once I have something ready so you could integrate the hugetlb portion. -- Cheers, David / dhildenb
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 08:31:27PM GMT, Andy Shevchenko wrote: > On Wed, Apr 24, 2024 at 7:14 PM Ondřej Jirman wrote: > > On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote: > > > On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote: > > > > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote: > > > > > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan > > > > > wrote: > > ... > > > > > > > ret = stk3310_init(indio_dev); > > > > > > if (ret < 0) > > > > > > - return ret; > > > > > > + goto err_vdd_disable; > > > > > > > > > > This is wrong. You will have the regulator being disabled _before_ > > > > > IRQ. Note, that the original code likely has a bug which sets states > > > > > before disabling IRQ and removing a handler. > > > > > > > > How so? stk3310_init is called before enabling the interrupt. > > > > > > Exactly, IRQ is registered with devm and hence the error path and > > > remove stages will got it in a wrong order. > > > > Makes no sense. > > Huh?! > > > IRQ is not enabled here, yet. So in error path, the code will > > just disable the regulator and devm will unref it later on. IRQ doesn't > > enter > > the picture here at all in the error path. > > Error path _after_ IRQ handler has been _successfully_ installed. > And complete ->remove() stage. Allright. So fixing the other issue I mentioned will fix this one too, because there will be no error path after IRQ enable, then. kind regards, o. > > > > Original code has a bug that IRQ is enabled before registering the > > > > IIO device, > > > > > > Indeed, but this is another bug. > > > > > > > so if IRQ is triggered before registration, iio_push_event > > > > from IRQ handler may be called on a not yet registered IIO device. > > > > > > > > Never saw it happen, though. :) > > > > > > Because nobody cares enough to enable DEBUG_SHIRQ. > > > > Nice debug tool. I bet it makes quite a mess when enabled. :) > > FWIW, I have had it enabled for ages, but I have only a few devices, > so I fixed a few cases in the past WRT shared IRQ issues. > > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH v12 14/14] selftests/sgx: Add scripts for EPC cgroup testing
Hi Jarkko On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen wrote: On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote: I did declare the configs in the config file but I missed it in my patch as stated earlier. IIUC, that would not cause this error though. Maybe I should exit with the skip code if no CGROUP_MISC (no more CGROUP_SGX_EPC) is configured? OK, so I wanted to do a distro kernel test here, and used the default OpenSUSE kernel config. I need to check if it has CGROUP_MISC set. I couldn't figure out why this failure you have encountered. I think OpenSUSE kernel most likely config CGROUP_MISC. Also if CGROUP_MISC not set, then there should be error happen earlier on echoing "+misc" to cgroup.subtree_control at line 20. But your log indicates only error on echoing "sgx_epc ..." to /sys/fs/cgroup/...//misc.max. I can only speculate that can could happen (if sgx epc cgroup was compiled in) when the cgroup-fs subdirectories in question already have populated config that is conflicting with the scripts. Could you double check or start from a clean environment? Thanks Haitao
[PATCH v8 2/4] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+ bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handle
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memor
[PATCH v8 4/4] arm64: dts: ti: k3-am62: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor do not have an MMU, and as such
require the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi| 12
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 18 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..0c6ee801f35fc 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,16 @@ mcu_mcan1: can@4e18000 {
bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
status = "disabled";
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ resets = <&k3_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 3c45782ab2b78..bda9fb2e33eec 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -48,6 +48,18 @@ ramoops@9ca0 {
pmsg-size = <0x8000>;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb0 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc0 0x00 0xe0>;
+ no-map;
+ };
+
secure_tfa_ddr: tfa@9e78 {
reg = <0x00 0x9e78 0x00 0x8>;
alignment = <0x1000>;
@@ -457,6 +469,12 @@ mbox_m4_0: mbox-m4-0 {
};
};
+&mcu_m4fss {
+ mboxes = <&mailbox0_cluster0>, <&mbox_m4_0>;
+ memory-region = <&mcu_m4fss_dma_memory_region>,
+ <&mcu_m4fss_memory_region>;
+};
+
&usbss0 {
bootph-all;
status = "okay";
--
2.39.2
[PATCH v8 0/4] TI K3 M4F support on AM62 SoCs
Hello all, This is the continuation of the M4F RProc support series from here[0]. I'm helping out with the upstream task for Hari and so this version(v8) is a little different than the previous(v7) postings[0]. Most notable change I've introduced being the patches factoring out common support from the current K3 R5 and DSP drivers have been dropped. I'd like to do that re-factor *after* getting this driver in shape, that way we have 3 similar drivers to factor out from vs trying to make those changes in parallel with the series adding M4 support. Anyway, details on our M4F subsystem can be found the the AM62 TRM in the section on the same: AM62x Technical Reference Manual (SPRUIV7A – MAY 2022) https://www.ti.com/lit/pdf/SPRUIV7A Thanks, Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/ Hari Nagalla (3): dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs arm64: defconfig: Enable TI K3 M4 remoteproc driver arm64: dts: ti: k3-am62: Add M4F remoteproc node Martyn Welch (1): remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 +++ arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 12 + .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 18 + arch/arm64/configs/defconfig | 1 + drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 ++ 7 files changed, 956 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c -- 2.39.2
[PATCH v8 3/4] arm64: defconfig: Enable TI K3 M4 remoteproc driver
From: Hari Nagalla Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e1802..04e8e2ca4aa10 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1352,6 +1352,7 @@ CONFIG_QCOM_Q6V5_PAS=m CONFIG_QCOM_SYSMON=m CONFIG_QCOM_WCNSS_PIL=m CONFIG_TI_K3_DSP_REMOTEPROC=m +CONFIG_TI_K3_M4_REMOTEPROC=m CONFIG_TI_K3_R5_REMOTEPROC=m CONFIG_RPMSG_CHAR=m CONFIG_RPMSG_CTRL=m -- 2.39.2
[PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++
1 file changed, 126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0..3629ddd6efa8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla
+ - Mathieu Poirier
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - ti,am64-m4fss
+
+ power-domains:
+maxItems: 1
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+items:
+ - const: iram
+ - const: dram
+
+ resets:
+maxItems: 1
+
+ firmware-name:
+maxItems: 1
+description: Name of firmware to load for the M4F core
+
+ mboxes:
+description: |
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+maxItems: 1
+
+ memory-region:
+description: |
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. The reserved memory nodes should be carveout nodes,
+ and should be defined with a "no-map" property as per the bindings in
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
+ Optional memory regions available for firmware specific purposes.
+maxItems: 8
+items:
+ - description: regions used for DMA allocations like vrings, vring
buffers
+ and memory dedicated to firmware's specific purposes.
+additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cb0 0x00 0x10>;
+no-map;
+};
+
+mcu_m4fss_memory_region: m4f-memory@9cc0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cc0 0x00 0xe0>;
+no-map;
+};
+};
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mailbox0_cluster0: mailbox-0 {
+#mbox-cells = <1>;
+};
+
+remoteproc@500 {
+compatible = "ti,am64-m4fss";
+reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+reg-names = "iram", "dram";
+ti,sci = <&dmsc>;
+ti,sci-dev-id = <9>;
+ti,sci-proc-ids = <0x18 0xff>;
+resets = <&k3_reset 9 1>;
+firmware-name = "am62-mcu-m4f0_0-fw";
+mboxes = <&mailbox0_cluster0>, <&mbox_m4_0>;
+memory-region = <&mcu_m4fss_dma_memory_region>,
+<&mcu_m4fss_memory_region>;
+ };
+};
--
2.39.2
[PATCH v10 12/12] MAINTAINERS: add myself as Marvell PXA1908 maintainer
From: Duje Mihanović Add myself as the maintainer for Marvell PXA1908 SoC support. Signed-off-by: Duje Mihanović --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ebf03f5f0619..5d48ac9801df 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2370,6 +2370,15 @@ F: drivers/irqchip/irq-mvebu-* F: drivers/pinctrl/mvebu/ F: drivers/rtc/rtc-armada38x.c +ARM/Marvell PXA1908 SOC support +M: Duje Mihanović +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +T: git https://gitlab.com/LegoLivesMatter/linux +F: arch/arm64/boot/dts/marvell/pxa1908* +F: drivers/clk/mmp/clk-pxa1908*.c +F: include/dt-bindings/clock/marvell,pxa1908.h + ARM/Mediatek RTC DRIVER M: Eddie Huang M: Sean Wang -- 2.44.0
[PATCH v10 11/12] arm64: dts: Add DTS for Marvell PXA1908 and samsung,coreprimevelte
From: Duje Mihanović
Add DTS for Marvell PXA1908 SoC and Samsung Galaxy Core Prime Value
Edition LTE, a smartphone based on said SoC.
Signed-off-by: Duje Mihanović
---
arch/arm64/boot/dts/marvell/Makefile | 3 +
.../dts/marvell/pxa1908-samsung-coreprimevelte.dts | 328 +
arch/arm64/boot/dts/marvell/pxa1908.dtsi | 300 +++
3 files changed, 631 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/Makefile
b/arch/arm64/boot/dts/marvell/Makefile
index 99b8cb3c49e1..687c256d95fe 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -28,3 +28,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb
dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb
dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb
dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb
+
+# MMP SoC Family
+dtb-$(CONFIG_ARCH_MMP) += pxa1908-samsung-coreprimevelte.dtb
diff --git a/arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dts
b/arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dts
new file mode 100644
index ..2a1f309c8e54
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dts
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include "pxa1908.dtsi"
+#include
+#include
+
+/ {
+ model = "Samsung Galaxy Core Prime VE LTE";
+ compatible = "samsung,coreprimevelte", "marvell,pxa1908";
+
+ aliases {
+ mmc0 = &sdh2; /* eMMC */
+ mmc1 = &sdh0; /* SD card */
+ serial0 = &uart0;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ stdout-path = "serial0:115200n8";
+
+ /* S-Boot places the initramfs here */
+ linux,initrd-start = <0x4d7>;
+ linux,initrd-end = <0x500>;
+
+ fb0: framebuffer@17177000 {
+ compatible = "simple-framebuffer";
+ reg = <0 0x17177000 0 (480 * 800 * 4)>;
+ width = <480>;
+ height = <800>;
+ stride = <(480 * 4)>;
+ format = "a8r8g8b8";
+ };
+ };
+
+ /* Bootloader fills this in */
+ memory {
+ device_type = "memory";
+ reg = <0 0 0 0>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ framebuffer@1700 {
+ reg = <0 0x1700 0 0x180>;
+ no-map;
+ };
+
+ gpu@900 {
+ reg = <0 0x900 0 0x100>;
+ };
+
+ /* Communications processor, aka modem */
+ cp@500 {
+ reg = <0 0x500 0 0x300>;
+ };
+
+ cm3@a00 {
+ reg = <0 0xa00 0 0x8>;
+ };
+
+ seclog@800 {
+ reg = <0 0x800 0 0x10>;
+ };
+
+ ramoops@810 {
+ compatible = "ramoops";
+ reg = <0 0x810 0 0x4>;
+ record-size = <0x8000>;
+ console-size = <0x2>;
+ max-reason = <5>;
+ };
+ };
+
+
+ i2c-muic {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpio 30 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio 29 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <3>;
+ i2c-gpio,timeout-ms = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_muic_pins>;
+
+ muic: extcon@14 {
+ compatible = "siliconmitus,sm5504-muic";
+ reg = <0x14>;
+ interrupt-parent = <&gpio>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins>;
+ autorepeat;
+
+ key-home {
+ label = "Home";
+ linux,code = ;
+ gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
+ };
+
+ key-volup {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ };
+
+ key-voldown {
+ label = "Volume Down";
+ linux,code = ;
+ gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+
[PATCH v10 10/12] arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
From: Duje Mihanović Add ARCH_MMP configuration option for Marvell PXA1908 SoC. Signed-off-by: Duje Mihanović --- arch/arm64/Kconfig.platforms | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 24335565bad5..d71b0b6e75aa 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -168,6 +168,14 @@ config ARCH_MESON This enables support for the arm64 based Amlogic SoCs such as the s905, S905X/D, S912, A113X/D or S905X/D2 +config ARCH_MMP + bool "Marvell MMP SoC Family" + select PINCTRL + select PINCTRL_SINGLE + help + This enables support for Marvell MMP SoC family, currently + supporting PXA1908 aka IAP140. + config ARCH_MVEBU bool "Marvell EBU SoC Family" select ARMADA_AP806_SYSCON -- 2.44.0
[PATCH v10 07/12] clk: mmp: Add Marvell PXA1908 APMU driver
From: Duje Mihanović
Add driver for the APMU controller block found on Marvell's PXA1908 SoC.
This driver is incomplete, lacking support for (at least) GPU, VPU, DSI
and CCIC (camera related) clocks.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-pxa1908-apmu.c | 123 +
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 038bcd4d035e..a8b1a4b08824 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -11,4 +11,4 @@ obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
obj-$(CONFIG_COMMON_CLK_MMP2) += clk-of-mmp2.o clk-pll.o pwr-island.o
obj-$(CONFIG_COMMON_CLK_MMP2_AUDIO) += clk-audio.o
-obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
clk-pxa1908-apbcp.o
+obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
clk-pxa1908-apbcp.o clk-pxa1908-apmu.o
diff --git a/drivers/clk/mmp/clk-pxa1908-apmu.c
b/drivers/clk/mmp/clk-pxa1908-apmu.c
new file mode 100644
index ..693254539063
--- /dev/null
+++ b/drivers/clk/mmp/clk-pxa1908-apmu.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+
+#define APMU_CLK_GATE_CTRL 0x40
+#define APMU_CCIC1 0x24
+#define APMU_ISP 0x38
+#define APMU_DSI1 0x44
+#define APMU_DISP1 0x4c
+#define APMU_CCIC0 0x50
+#define APMU_SDH0 0x54
+#define APMU_SDH1 0x58
+#define APMU_USB 0x5c
+#define APMU_NF0x60
+#define APMU_VPU 0xa4
+#define APMU_GC0xcc
+#define APMU_SDH2 0xe0
+#define APMU_GC2D 0xf4
+#define APMU_TRACE 0x108
+#define APMU_DVC_DFC_DEBUG 0x140
+
+#define APMU_NR_CLKS 17
+
+struct pxa1908_clk_unit {
+ struct mmp_clk_unit unit;
+ void __iomem *base;
+};
+
+static DEFINE_SPINLOCK(pll1_lock);
+static struct mmp_param_general_gate_clk pll1_gate_clks[] = {
+ {PXA1908_CLK_PLL1_D2_GATE, "pll1_d2_gate", "pll1_d2", 0,
APMU_CLK_GATE_CTRL, 29, 0, &pll1_lock},
+ {PXA1908_CLK_PLL1_416_GATE, "pll1_416_gate", "pll1_416", 0,
APMU_CLK_GATE_CTRL, 27, 0, &pll1_lock},
+ {PXA1908_CLK_PLL1_624_GATE, "pll1_624_gate", "pll1_624", 0,
APMU_CLK_GATE_CTRL, 26, 0, &pll1_lock},
+ {PXA1908_CLK_PLL1_832_GATE, "pll1_832_gate", "pll1_832", 0,
APMU_CLK_GATE_CTRL, 30, 0, &pll1_lock},
+ {PXA1908_CLK_PLL1_1248_GATE, "pll1_1248_gate", "pll1_1248", 0,
APMU_CLK_GATE_CTRL, 28, 0, &pll1_lock},
+};
+
+static DEFINE_SPINLOCK(sdh0_lock);
+static DEFINE_SPINLOCK(sdh1_lock);
+static DEFINE_SPINLOCK(sdh2_lock);
+
+static const char * const sdh_parent_names[] = {"pll1_416", "pll1_624"};
+
+static struct mmp_clk_mix_config sdh_mix_config = {
+ .reg_info = DEFINE_MIX_REG_INFO(3, 8, 2, 6, 11),
+};
+
+static struct mmp_param_gate_clk apmu_gate_clks[] = {
+ {PXA1908_CLK_USB, "usb_clk", NULL, 0, APMU_USB, 0x9, 0x9, 0x1, 0, NULL},
+ {PXA1908_CLK_SDH0, "sdh0_clk", "sdh0_mix_clk", CLK_SET_RATE_PARENT |
CLK_SET_RATE_UNGATE, APMU_SDH0, 0x12, 0x12, 0x0, 0, &sdh0_lock},
+ {PXA1908_CLK_SDH1, "sdh1_clk", "sdh1_mix_clk", CLK_SET_RATE_PARENT |
CLK_SET_RATE_UNGATE, APMU_SDH1, 0x12, 0x12, 0x0, 0, &sdh1_lock},
+ {PXA1908_CLK_SDH2, "sdh2_clk", "sdh2_mix_clk", CLK_SET_RATE_PARENT |
CLK_SET_RATE_UNGATE, APMU_SDH2, 0x12, 0x12, 0x0, 0, &sdh2_lock}
+};
+
+static void pxa1908_axi_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_unit *unit = &pxa_unit->unit;
+
+ mmp_register_general_gate_clks(unit, pll1_gate_clks,
+ pxa_unit->base, ARRAY_SIZE(pll1_gate_clks));
+
+ sdh_mix_config.reg_info.reg_clk_ctrl = pxa_unit->base + APMU_SDH0;
+ mmp_clk_register_mix(NULL, "sdh0_mix_clk", sdh_parent_names,
+ ARRAY_SIZE(sdh_parent_names), CLK_SET_RATE_PARENT,
+ &sdh_mix_config, &sdh0_lock);
+ sdh_mix_config.reg_info.reg_clk_ctrl = pxa_unit->base + APMU_SDH1;
+ mmp_clk_register_mix(NULL, "sdh1_mix_clk", sdh_parent_names,
+ ARRAY_SIZE(sdh_parent_names), CLK_SET_RATE_PARENT,
+ &sdh_mix_config, &sdh1_lock);
+ sdh_mix_config.reg_info.reg_clk_ctrl = pxa_unit->base + APMU_SDH2;
+ mmp_clk_register_mix(NULL, "sdh2_mix_clk", sdh_parent_names,
+ ARRAY_SIZE(sdh_parent_names), CLK_SET_RATE_PARENT,
+ &sdh_mix_config, &sdh2_lock);
+
+ mmp_register_gate_clks(unit, apmu_gate_clks, pxa_unit->base,
+ ARRAY_SIZE(apmu_gate_clks));
+}
+
+static int pxa1908_apmu_probe(struct platform_device *pdev)
+{
+ struct pxa1908_clk_unit *pxa_unit;
+
+ pxa_unit = devm_kzalloc(&pdev->dev, sizeof(*pxa_unit), GFP_KERNEL);
+
[PATCH v10 08/12] clk: mmp: Add Marvell PXA1908 MPMU driver
From: Duje Mihanović
Add driver for the MPMU controller block on Marvell's PXA1908 SoC. The
driver is incomplete, currently only supporting the fixed PLL1; dynamic
PLLs 2-4 and CPU/DDR/AXI clock support is missing.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-pxa1908-mpmu.c | 112 +
2 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index a8b1a4b08824..062cd87fa8dd 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -11,4 +11,4 @@ obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
obj-$(CONFIG_COMMON_CLK_MMP2) += clk-of-mmp2.o clk-pll.o pwr-island.o
obj-$(CONFIG_COMMON_CLK_MMP2_AUDIO) += clk-audio.o
-obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
clk-pxa1908-apbcp.o clk-pxa1908-apmu.o
+obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
clk-pxa1908-apbcp.o clk-pxa1908-apmu.o clk-pxa1908-mpmu.o
diff --git a/drivers/clk/mmp/clk-pxa1908-mpmu.c
b/drivers/clk/mmp/clk-pxa1908-mpmu.c
new file mode 100644
index ..e3337bacaadd
--- /dev/null
+++ b/drivers/clk/mmp/clk-pxa1908-mpmu.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+
+#define MPMU_UART_PLL 0x14
+
+#define MPMU_NR_CLKS 39
+
+struct pxa1908_clk_unit {
+ struct mmp_clk_unit unit;
+ void __iomem *base;
+};
+
+static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
+ {PXA1908_CLK_CLK32, "clk32", NULL, 0, 32768},
+ {PXA1908_CLK_VCTCXO, "vctcxo", NULL, 0, 26 * HZ_PER_MHZ},
+ {PXA1908_CLK_PLL1_624, "pll1_624", NULL, 0, 624 * HZ_PER_MHZ},
+ {PXA1908_CLK_PLL1_416, "pll1_416", NULL, 0, 416 * HZ_PER_MHZ},
+ {PXA1908_CLK_PLL1_499, "pll1_499", NULL, 0, 499 * HZ_PER_MHZ},
+ {PXA1908_CLK_PLL1_832, "pll1_832", NULL, 0, 832 * HZ_PER_MHZ},
+ {PXA1908_CLK_PLL1_1248, "pll1_1248", NULL, 0, 1248 * HZ_PER_MHZ},
+};
+
+static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
+ {PXA1908_CLK_PLL1_D2, "pll1_d2", "pll1_624", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D4, "pll1_d4", "pll1_d2", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D6, "pll1_d6", "pll1_d2", 1, 3, 0},
+ {PXA1908_CLK_PLL1_D8, "pll1_d8", "pll1_d4", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D12, "pll1_d12", "pll1_d6", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D13, "pll1_d13", "pll1_624", 1, 13, 0},
+ {PXA1908_CLK_PLL1_D16, "pll1_d16", "pll1_d8", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D24, "pll1_d24", "pll1_d12", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D48, "pll1_d48", "pll1_d24", 1, 2, 0},
+ {PXA1908_CLK_PLL1_D96, "pll1_d96", "pll1_d48", 1, 2, 0},
+ {PXA1908_CLK_PLL1_32, "pll1_32", "pll1_d13", 2, 3, 0},
+ {PXA1908_CLK_PLL1_208, "pll1_208", "pll1_d2", 2, 3, 0},
+ {PXA1908_CLK_PLL1_117, "pll1_117", "pll1_624", 3, 16, 0},
+};
+
+static struct u32_fract uart_factor_tbl[] = {
+ {.numerator = 8125, .denominator = 1536}, /* 14.745MHz */
+};
+
+static struct mmp_clk_factor_masks uart_factor_masks = {
+ .factor = 2,
+ .num_mask = GENMASK(12, 0),
+ .den_mask = GENMASK(12, 0),
+ .num_shift = 16,
+ .den_shift = 0,
+};
+
+static void pxa1908_pll_init(struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_unit *unit = &pxa_unit->unit;
+
+ mmp_register_fixed_rate_clks(unit, fixed_rate_clks,
+ ARRAY_SIZE(fixed_rate_clks));
+
+ mmp_register_fixed_factor_clks(unit, fixed_factor_clks,
+ ARRAY_SIZE(fixed_factor_clks));
+
+ mmp_clk_register_factor("uart_pll", "pll1_d4",
+ CLK_SET_RATE_PARENT,
+ pxa_unit->base + MPMU_UART_PLL,
+ &uart_factor_masks, uart_factor_tbl,
+ ARRAY_SIZE(uart_factor_tbl), NULL);
+}
+
+static int pxa1908_mpmu_probe(struct platform_device *pdev)
+{
+ struct pxa1908_clk_unit *pxa_unit;
+
+ pxa_unit = devm_kzalloc(&pdev->dev, sizeof(*pxa_unit), GFP_KERNEL);
+ if (IS_ERR(pxa_unit))
+ return PTR_ERR(pxa_unit);
+
+ pxa_unit->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(pxa_unit->base))
+ return PTR_ERR(pxa_unit->base);
+
+ mmp_clk_init(pdev->dev.of_node, &pxa_unit->unit, MPMU_NR_CLKS);
+
+ pxa1908_pll_init(pxa_unit);
+
+ return 0;
+}
+
+static const struct of_device_id pxa1908_mpmu_match_table[] = {
+ { .compatible = "marvell,pxa1908-mpmu" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pxa1908_mpmu_match_table);
+
+static struct platform_driver pxa1908_mpmu_driver = {
+ .probe = pxa1908_mpmu_probe,
+ .driver = {
+ .name = "pxa1908-mpmu",
+ .of_match_table = pxa1908_mpmu_match_table
+ }
+};
+module_platform_driver(pxa1908_mpmu_driver);
[PATCH v10 05/12] clk: mmp: Add Marvell PXA1908 APBC driver
From: Duje Mihanović
Add driver for the APBC controller block found on Marvell's PXA1908 SoC.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-pxa1908-apbc.c | 131 +
2 files changed, 132 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 441bf83080a1..685bb80f8ae1 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -11,4 +11,4 @@ obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
obj-$(CONFIG_COMMON_CLK_MMP2) += clk-of-mmp2.o clk-pll.o pwr-island.o
obj-$(CONFIG_COMMON_CLK_MMP2_AUDIO) += clk-audio.o
-obj-y += clk-of-pxa1928.o
+obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
diff --git a/drivers/clk/mmp/clk-pxa1908-apbc.c
b/drivers/clk/mmp/clk-pxa1908-apbc.c
new file mode 100644
index ..a418b9f895c1
--- /dev/null
+++ b/drivers/clk/mmp/clk-pxa1908-apbc.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+
+#define APBC_UART0 0x0
+#define APBC_UART1 0x4
+#define APBC_GPIO 0x8
+#define APBC_PWM0 0xc
+#define APBC_PWM1 0x10
+#define APBC_PWM2 0x14
+#define APBC_PWM3 0x18
+#define APBC_SSP0 0x1c
+#define APBC_SSP1 0x20
+#define APBC_IPC_RST 0x24
+#define APBC_RTC 0x28
+#define APBC_TWSI0 0x2c
+#define APBC_KPC 0x30
+#define APBC_SWJTAG0x40
+#define APBC_SSP2 0x4c
+#define APBC_TWSI1 0x60
+#define APBC_THERMAL 0x6c
+#define APBC_TWSI3 0x70
+
+#define APBC_NR_CLKS 19
+
+struct pxa1908_clk_unit {
+ struct mmp_clk_unit unit;
+ void __iomem *base;
+};
+
+static DEFINE_SPINLOCK(pwm0_lock);
+static DEFINE_SPINLOCK(pwm2_lock);
+
+static DEFINE_SPINLOCK(uart0_lock);
+static DEFINE_SPINLOCK(uart1_lock);
+
+static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
+static const char * const ssp_parent_names[] = {"pll1_d16", "pll1_d48",
"pll1_d24", "pll1_d12"};
+
+static struct mmp_param_gate_clk apbc_gate_clks[] = {
+ {PXA1908_CLK_TWSI0, "twsi0_clk", "pll1_32", CLK_SET_RATE_PARENT,
APBC_TWSI0, 0x7, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI1, "twsi1_clk", "pll1_32", CLK_SET_RATE_PARENT,
APBC_TWSI1, 0x7, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI3, "twsi3_clk", "pll1_32", CLK_SET_RATE_PARENT,
APBC_TWSI3, 0x7, 3, 0, 0, NULL},
+ {PXA1908_CLK_GPIO, "gpio_clk", "vctcxo", CLK_SET_RATE_PARENT,
APBC_GPIO, 0x7, 3, 0, 0, NULL},
+ {PXA1908_CLK_KPC, "kpc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_KPC,
0x7, 3, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_RTC, "rtc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_RTC,
0x87, 0x83, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_PWM0, "pwm0_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT,
APBC_PWM0, 0x2, 2, 0, 0, &pwm0_lock},
+ {PXA1908_CLK_PWM1, "pwm1_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT,
APBC_PWM1, 0x6, 2, 0, 0, NULL},
+ {PXA1908_CLK_PWM2, "pwm2_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT,
APBC_PWM2, 0x2, 2, 0, 0, NULL},
+ {PXA1908_CLK_PWM3, "pwm3_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT,
APBC_PWM3, 0x6, 2, 0, 0, NULL},
+ {PXA1908_CLK_UART0, "uart0_clk", "uart0_mux", CLK_SET_RATE_PARENT,
APBC_UART0, 0x7, 3, 0, 0, &uart0_lock},
+ {PXA1908_CLK_UART1, "uart1_clk", "uart1_mux", CLK_SET_RATE_PARENT,
APBC_UART1, 0x7, 3, 0, 0, &uart1_lock},
+ {PXA1908_CLK_THERMAL, "thermal_clk", NULL, 0, APBC_THERMAL, 0x7, 3, 0,
0, NULL},
+ {PXA1908_CLK_IPC_RST, "ipc_clk", NULL, 0, APBC_IPC_RST, 0x7, 3, 0, 0,
NULL},
+ {PXA1908_CLK_SSP0, "ssp0_clk", "ssp0_mux", 0, APBC_SSP0, 0x7, 3, 0, 0,
NULL},
+ {PXA1908_CLK_SSP2, "ssp2_clk", "ssp2_mux", 0, APBC_SSP2, 0x7, 3, 0, 0,
NULL},
+};
+
+static struct mmp_param_mux_clk apbc_mux_clks[] = {
+ {0, "uart0_mux", uart_parent_names, ARRAY_SIZE(uart_parent_names),
CLK_SET_RATE_PARENT, APBC_UART0, 4, 3, 0, &uart0_lock},
+ {0, "uart1_mux", uart_parent_names, ARRAY_SIZE(uart_parent_names),
CLK_SET_RATE_PARENT, APBC_UART1, 4, 3, 0, &uart1_lock},
+ {0, "ssp0_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names), 0,
APBC_SSP0, 4, 3, 0, NULL},
+ {0, "ssp2_mux", ssp_parent_names, ARRAY_SIZE(ssp_parent_names), 0,
APBC_SSP2, 4, 3, 0, NULL},
+};
+
+static void pxa1908_apb_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_unit *unit = &pxa_unit->unit;
+ struct clk *clk;
+
+ mmp_clk_register_gate(NULL, "pwm01_apb_share", "pll1_d48",
+ CLK_SET_RATE_PARENT,
+ pxa_unit->base + APBC_PWM0,
+ 0x5, 1, 0, 0, &pwm0_lock);
+ mmp_clk_register_gate(NULL, "pwm23_apb_share", "pll1_d48",
+ C
[PATCH v10 06/12] clk: mmp: Add Marvell PXA1908 APBCP driver
From: Duje Mihanović
Add driver for the APBCP controller block found on Marvell's PXA1908
SoC.
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/Makefile| 2 +-
drivers/clk/mmp/clk-pxa1908-apbcp.c | 84 +
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 685bb80f8ae1..038bcd4d035e 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -11,4 +11,4 @@ obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
obj-$(CONFIG_COMMON_CLK_MMP2) += clk-of-mmp2.o clk-pll.o pwr-island.o
obj-$(CONFIG_COMMON_CLK_MMP2_AUDIO) += clk-audio.o
-obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
+obj-$(CONFIG_ARCH_MMP) += clk-of-pxa1928.o clk-pxa1908-apbc.o
clk-pxa1908-apbcp.o
diff --git a/drivers/clk/mmp/clk-pxa1908-apbcp.c
b/drivers/clk/mmp/clk-pxa1908-apbcp.c
new file mode 100644
index ..2a53cf276407
--- /dev/null
+++ b/drivers/clk/mmp/clk-pxa1908-apbcp.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk.h"
+
+#define APBCP_UART20x1c
+#define APBCP_TWSI20x28
+#define APBCP_AICER0x38
+
+#define APBCP_NR_CLKS 4
+
+struct pxa1908_clk_unit {
+ struct mmp_clk_unit unit;
+ void __iomem *base;
+};
+
+static DEFINE_SPINLOCK(uart2_lock);
+
+static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
+
+static struct mmp_param_gate_clk apbcp_gate_clks[] = {
+ {PXA1908_CLK_UART2, "uart2_clk", "uart2_mux", CLK_SET_RATE_PARENT,
APBCP_UART2, 0x7, 0x3, 0x0, 0, &uart2_lock},
+ {PXA1908_CLK_TWSI2, "twsi2_clk", "pll1_32", CLK_SET_RATE_PARENT,
APBCP_TWSI2, 0x7, 0x3, 0x0, 0, NULL},
+ {PXA1908_CLK_AICER, "ripc_clk", NULL, 0, APBCP_AICER, 0x7, 0x2, 0x0, 0,
NULL},
+};
+
+static struct mmp_param_mux_clk apbcp_mux_clks[] = {
+ {0, "uart2_mux", uart_parent_names, ARRAY_SIZE(uart_parent_names),
CLK_SET_RATE_PARENT, APBCP_UART2, 4, 3, 0, &uart2_lock},
+};
+
+static void pxa1908_apb_p_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_unit *unit = &pxa_unit->unit;
+
+ mmp_register_mux_clks(unit, apbcp_mux_clks, pxa_unit->base,
+ ARRAY_SIZE(apbcp_mux_clks));
+ mmp_register_gate_clks(unit, apbcp_gate_clks, pxa_unit->base,
+ ARRAY_SIZE(apbcp_gate_clks));
+}
+
+static int pxa1908_apbcp_probe(struct platform_device *pdev)
+{
+ struct pxa1908_clk_unit *pxa_unit;
+
+ pxa_unit = devm_kzalloc(&pdev->dev, sizeof(*pxa_unit), GFP_KERNEL);
+ if (IS_ERR(pxa_unit))
+ return PTR_ERR(pxa_unit);
+
+ pxa_unit->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(pxa_unit->base))
+ return PTR_ERR(pxa_unit->base);
+
+ mmp_clk_init(pdev->dev.of_node, &pxa_unit->unit, APBCP_NR_CLKS);
+
+ pxa1908_apb_p_periph_clk_init(pxa_unit);
+
+ return 0;
+}
+
+static const struct of_device_id pxa1908_apbcp_match_table[] = {
+ { .compatible = "marvell,pxa1908-apbcp" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pxa1908_apbcp_match_table);
+
+static struct platform_driver pxa1908_apbcp_driver = {
+ .probe = pxa1908_apbcp_probe,
+ .driver = {
+ .name = "pxa1908-apbcp",
+ .of_match_table = pxa1908_apbcp_match_table
+ }
+};
+module_platform_driver(pxa1908_apbcp_driver);
+
+MODULE_AUTHOR("Duje Mihanović ");
+MODULE_DESCRIPTION("Marvell PXA1908 APBCP Clock Driver");
+MODULE_LICENSE("GPL");
--
2.44.0
[PATCH v10 09/12] dt-bindings: marvell: Document PXA1908 SoC
From: Duje Mihanović Add dt binding for the Marvell PXA1908 SoC. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Duje Mihanović --- Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml index 4c43eaf3632e..f73bb8ec3a1a 100644 --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml @@ -35,6 +35,11 @@ properties: - enum: - dell,wyse-ariel - const: marvell,mmp3 + - description: PXA1908 based boards +items: + - enum: + - samsung,coreprimevelte + - const: marvell,pxa1908 additionalProperties: true -- 2.44.0
[PATCH v10 04/12] dt-bindings: clock: Add Marvell PXA1908 clock bindings
From: Duje Mihanović
Add dt bindings and documentation for the Marvell PXA1908 clock
controller.
Reviewed-by: Conor Dooley
Reviewed-by: Stephen Boyd
Signed-off-by: Duje Mihanović
---
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 48
include/dt-bindings/clock/marvell,pxa1908.h| 88 ++
2 files changed, 136 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
new file mode 100644
index ..4e78933232b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,pxa1908.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell PXA1908 Clock Controllers
+
+maintainers:
+ - Duje Mihanović
+
+description: |
+ The PXA1908 clock subsystem generates and supplies clock to various
+ controllers within the PXA1908 SoC. The PXA1908 contains numerous clock
+ controller blocks, with the ones currently supported being APBC, APBCP, MPMU
+ and APMU roughly corresponding to internal buses.
+
+ All these clock identifiers could be found in
.
+
+properties:
+ compatible:
+enum:
+ - marvell,pxa1908-apbc
+ - marvell,pxa1908-apbcp
+ - marvell,pxa1908-mpmu
+ - marvell,pxa1908-apmu
+
+ reg:
+maxItems: 1
+
+ '#clock-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ # APMU block:
+ - |
+clock-controller@d4282800 {
+ compatible = "marvell,pxa1908-apmu";
+ reg = <0xd4282800 0x400>;
+ #clock-cells = <1>;
+};
diff --git a/include/dt-bindings/clock/marvell,pxa1908.h
b/include/dt-bindings/clock/marvell,pxa1908.h
new file mode 100644
index ..fb15b0d0cd4c
--- /dev/null
+++ b/include/dt-bindings/clock/marvell,pxa1908.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+#ifndef __DTS_MARVELL_PXA1908_CLOCK_H
+#define __DTS_MARVELL_PXA1908_CLOCK_H
+
+/* plls */
+#define PXA1908_CLK_CLK32 1
+#define PXA1908_CLK_VCTCXO 2
+#define PXA1908_CLK_PLL1_624 3
+#define PXA1908_CLK_PLL1_416 4
+#define PXA1908_CLK_PLL1_499 5
+#define PXA1908_CLK_PLL1_832 6
+#define PXA1908_CLK_PLL1_1248 7
+#define PXA1908_CLK_PLL1_D28
+#define PXA1908_CLK_PLL1_D49
+#define PXA1908_CLK_PLL1_D810
+#define PXA1908_CLK_PLL1_D16 11
+#define PXA1908_CLK_PLL1_D612
+#define PXA1908_CLK_PLL1_D12 13
+#define PXA1908_CLK_PLL1_D24 14
+#define PXA1908_CLK_PLL1_D48 15
+#define PXA1908_CLK_PLL1_D96 16
+#define PXA1908_CLK_PLL1_D13 17
+#define PXA1908_CLK_PLL1_3218
+#define PXA1908_CLK_PLL1_208 19
+#define PXA1908_CLK_PLL1_117 20
+#define PXA1908_CLK_PLL1_416_GATE 21
+#define PXA1908_CLK_PLL1_624_GATE 22
+#define PXA1908_CLK_PLL1_832_GATE 23
+#define PXA1908_CLK_PLL1_1248_GATE 24
+#define PXA1908_CLK_PLL1_D2_GATE 25
+#define PXA1908_CLK_PLL1_499_EN26
+#define PXA1908_CLK_PLL2VCO27
+#define PXA1908_CLK_PLL2 28
+#define PXA1908_CLK_PLL2P 29
+#define PXA1908_CLK_PLL2VCODIV330
+#define PXA1908_CLK_PLL3VCO31
+#define PXA1908_CLK_PLL3 32
+#define PXA1908_CLK_PLL3P 33
+#define PXA1908_CLK_PLL3VCODIV334
+#define PXA1908_CLK_PLL4VCO35
+#define PXA1908_CLK_PLL4 36
+#define PXA1908_CLK_PLL4P 37
+#define PXA1908_CLK_PLL4VCODIV338
+
+/* apb (apbc) peripherals */
+#define PXA1908_CLK_UART0 1
+#define PXA1908_CLK_UART1 2
+#define PXA1908_CLK_GPIO 3
+#define PXA1908_CLK_PWM0 4
+#define PXA1908_CLK_PWM1 5
+#define PXA1908_CLK_PWM2 6
+#define PXA1908_CLK_PWM3 7
+#define PXA1908_CLK_SSP0 8
+#define PXA1908_CLK_SSP1 9
+#define PXA1908_CLK_IPC_RST10
+#define PXA1908_CLK_RTC11
+#define PXA1908_CLK_TWSI0 12
+#define PXA1908_CLK_KPC13
+#define PXA1908_CLK_SWJTAG 14
+#define PXA1908_CLK_SSP2 15
+#define PXA1908_CLK_TWSI1 16
+#define PXA1908_CLK_THERMAL17
+#define PXA1908_CLK_TWSI3 18
+
+/* apb (apbcp) peripherals */
+#define PXA1908_CLK_UART2 1
+#define PXA1908_CLK_TWSI2 2
+#define PXA1908_CLK_AICER 3
+
+/* axi (apmu) peripherals */
+#define PXA1908_CLK_CCIC1 1
+#define PXA1908_CLK_ISP2
+#define PXA1908_CLK_DSI1 3
+#define PXA1908_CLK_DISP1
[PATCH v10 03/12] pinctrl: single: add marvell,pxa1908-padconf compatible
From: Duje Mihanović
Add the "marvell,pxa1908-padconf" compatible to allow migrating to a
separate pinctrl driver later.
Acked-by: Linus Walleij
Signed-off-by: Duje Mihanović
---
drivers/pinctrl/pinctrl-single.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 19cc0db771a5..c15bf3cbabd7 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1967,6 +1967,7 @@ static const struct pcs_soc_data pinconf_single = {
};
static const struct of_device_id pcs_of_match[] = {
+ { .compatible = "marvell,pxa1908-padconf", .data = &pinconf_single },
{ .compatible = "ti,am437-padconf", .data = &pinctrl_single_am437x },
{ .compatible = "ti,am654-padconf", .data = &pinctrl_single_am654 },
{ .compatible = "ti,dra7-padconf", .data = &pinctrl_single_dra7 },
--
2.44.0
[PATCH v10 01/12] clk: mmp: Switch to use struct u32_fract instead of custom one
From: Andy Shevchenko
The struct mmp_clk_factor_tbl repeats the generic struct u32_fract.
Kill the custom one and use the generic one instead.
Signed-off-by: Andy Shevchenko
Tested-by: Duje Mihanović
Reviewed-by: Linus Walleij
Reviewed-by: Stephen Boyd
Signed-off-by: Duje Mihanović
---
drivers/clk/mmp/clk-frac.c | 57
drivers/clk/mmp/clk-of-mmp2.c| 26 +-
drivers/clk/mmp/clk-of-pxa168.c | 4 +--
drivers/clk/mmp/clk-of-pxa1928.c | 6 ++---
drivers/clk/mmp/clk-of-pxa910.c | 4 +--
drivers/clk/mmp/clk.h| 10 +++
6 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 1b90867b60c4..6556f6ada2e8 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -26,14 +26,15 @@ static long clk_factor_round_rate(struct clk_hw *hw,
unsigned long drate,
{
struct mmp_clk_factor *factor = to_clk_factor(hw);
u64 rate = 0, prev_rate;
+ struct u32_fract *d;
int i;
for (i = 0; i < factor->ftbl_cnt; i++) {
- prev_rate = rate;
- rate = *prate;
- rate *= factor->ftbl[i].den;
- do_div(rate, factor->ftbl[i].num * factor->masks->factor);
+ d = &factor->ftbl[i];
+ prev_rate = rate;
+ rate = (u64)(*prate) * d->denominator;
+ do_div(rate, d->numerator * factor->masks->factor);
if (rate > drate)
break;
}
@@ -52,23 +53,22 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw
*hw,
{
struct mmp_clk_factor *factor = to_clk_factor(hw);
struct mmp_clk_factor_masks *masks = factor->masks;
- unsigned int val, num, den;
+ struct u32_fract d;
+ unsigned int val;
u64 rate;
val = readl_relaxed(factor->base);
/* calculate numerator */
- num = (val >> masks->num_shift) & masks->num_mask;
+ d.numerator = (val >> masks->num_shift) & masks->num_mask;
/* calculate denominator */
- den = (val >> masks->den_shift) & masks->den_mask;
-
- if (!den)
+ d.denominator = (val >> masks->den_shift) & masks->den_mask;
+ if (!d.denominator)
return 0;
- rate = parent_rate;
- rate *= den;
- do_div(rate, num * factor->masks->factor);
+ rate = (u64)parent_rate * d.denominator;
+ do_div(rate, d.numerator * factor->masks->factor);
return rate;
}
@@ -82,18 +82,18 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned
long drate,
int i;
unsigned long val;
unsigned long flags = 0;
+ struct u32_fract *d;
u64 rate = 0;
for (i = 0; i < factor->ftbl_cnt; i++) {
- rate = prate;
- rate *= factor->ftbl[i].den;
- do_div(rate, factor->ftbl[i].num * factor->masks->factor);
+ d = &factor->ftbl[i];
+ rate = (u64)prate * d->denominator;
+ do_div(rate, d->numerator * factor->masks->factor);
if (rate > drate)
break;
}
- if (i > 0)
- i--;
+ d = i ? &factor->ftbl[i - 1] : &factor->ftbl[0];
if (factor->lock)
spin_lock_irqsave(factor->lock, flags);
@@ -101,10 +101,10 @@ static int clk_factor_set_rate(struct clk_hw *hw,
unsigned long drate,
val = readl_relaxed(factor->base);
val &= ~(masks->num_mask << masks->num_shift);
- val |= (factor->ftbl[i].num & masks->num_mask) << masks->num_shift;
+ val |= (d->numerator & masks->num_mask) << masks->num_shift;
val &= ~(masks->den_mask << masks->den_shift);
- val |= (factor->ftbl[i].den & masks->den_mask) << masks->den_shift;
+ val |= (d->denominator & masks->den_mask) << masks->den_shift;
writel_relaxed(val, factor->base);
@@ -118,7 +118,8 @@ static int clk_factor_init(struct clk_hw *hw)
{
struct mmp_clk_factor *factor = to_clk_factor(hw);
struct mmp_clk_factor_masks *masks = factor->masks;
- u32 val, num, den;
+ struct u32_fract d;
+ u32 val;
int i;
unsigned long flags = 0;
@@ -128,23 +129,22 @@ static int clk_factor_init(struct clk_hw *hw)
val = readl(factor->base);
/* calculate numerator */
- num = (val >> masks->num_shift) & masks->num_mask;
+ d.numerator = (val >> masks->num_shift) & masks->num_mask;
/* calculate denominator */
- den = (val >> masks->den_shift) & masks->den_mask;
+ d.denominator = (val >> masks->den_shift) & masks->den_mask;
for (i = 0; i < factor->ftbl_cnt; i++)
- if (den == factor->ftbl[i].den && num == factor->ftbl[i].num)
+ if (d.denominator == factor->ftbl[i].denominator &&
+ d.numerator == factor->ftbl[i].numerator
[PATCH v10 02/12] dt-bindings: pinctrl: pinctrl-single: add marvell,pxa1908-padconf compatible
From: Duje Mihanović Add the "marvell,pxa1908-padconf" compatible to allow migrating to a separate pinctrl driver later. Reviewed-by: Rob Herring Acked-by: Linus Walleij Signed-off-by: Duje Mihanović --- Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml index c11495524dd2..1ce24ad8bc73 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml @@ -33,6 +33,10 @@ properties: - ti,omap5-padconf - ti,j7200-padconf - const: pinctrl-single + - items: + - enum: + - marvell,pxa1908-padconf + - const: pinconf-single reg: maxItems: 1 -- 2.44.0
[PATCH v10 00/12] Initial Marvell PXA1908 support
Hello, This series adds initial support for the Marvell PXA1908 SoC and "samsung,coreprimevelte", a smartphone using the SoC. USB works and the phone can boot a rootfs from an SD card, but there are some warnings in the dmesg: During SMP initialization: [0.006519] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00 [0.006542] CPU features: Unsupported CPU feature variation detected. [0.006589] CPU1: Booted secondary processor 0x01 [0x410fd032] [0.010710] Detected VIPT I-cache on CPU2 [0.010716] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00 [0.010758] CPU2: Booted secondary processor 0x02 [0x410fd032] [0.014849] Detected VIPT I-cache on CPU3 [0.014855] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00 [0.014895] CPU3: Booted secondary processor 0x03 [0x410fd032] SMMU probing fails: [0.101798] arm-smmu c001.iommu: probing hardware configuration... [0.101809] arm-smmu c001.iommu: SMMUv1 with: [0.101816] arm-smmu c001.iommu: no translation support! A 3.14 based Marvell tree is available on GitHub acorn-marvell/brillo_pxa_kernel, and a Samsung one on GitHub CoderCharmander/g361f-kernel. Andreas Färber attempted to upstream support for this SoC in 2017: https://lore.kernel.org/lkml/20170222022929.10540-1-afaer...@suse.de/ Signed-off-by: Duje Mihanović Changes in v10: - Update trailers - Rebase on v6.9-rc5 - Clock driver changes: - Add a couple of forgotten clocks in APBC - The clocks are thermal_clk, ipc_clk, ssp0_clk, ssp2_clk and swjtag - The IDs and register offsets were already present, but I forgot to actually register them - Split each controller block into own file - Drop unneeded -of in clock driver filenames - Simplify struct pxa1908_clk_unit - Convert to platform driver - Add module metadata - DTS changes: - Properly name pinctrl nodes - Drop pinctrl #size-cells, #address-cells, ranges and #gpio-size-cells - Fix pinctrl input-schmitt configuration - Link to v9: https://lore.kernel.org/20240402-pxa1908-lkml-v9-0-25a003e83...@skole.hr Changes in v9: - Update trailers and rebase on v6.9-rc2, no changes - Link to v8: https://lore.kernel.org/20240110-pxa1908-lkml-v8-0-fea768a59...@skole.hr Changes in v8: - Drop SSPA patch - Drop broken-cd from eMMC node - Specify S-Boot hardcoded initramfs location in device tree - Add ARM PMU node - Correct inverted modem memory base and size - Update trailers - Rebase on next-20240110 - Link to v7: https://lore.kernel.org/20231102-pxa1908-lkml-v7-0-cabb1a0cb...@skole.hr and https://lore.kernel.org/20231102152033.5511-1-duje.mihano...@skole.hr Changes in v7: - Suppress SND_MMP_SOC_SSPA on ARM64 - Update trailers - Rebase on v6.6-rc7 - Link to v6: https://lore.kernel.org/r/20231010-pxa1908-lkml-v6-0-b2fe09240...@skole.hr Changes in v6: - Address maintainer comments: - Add "marvell,pxa1908-padconf" binding to pinctrl-single driver - Drop GPIO patch as it's been pulled - Update trailers - Rebase on v6.6-rc5 - Link to v5: https://lore.kernel.org/r/20230812-pxa1908-lkml-v5-0-a5d51937e...@skole.hr Changes in v5: - Address maintainer comments: - Move *_NR_CLKS to clock driver from dt binding file - Allocate correct number of clocks for each block instead of blindly allocating 50 for each - Link to v4: https://lore.kernel.org/r/20230807-pxa1908-lkml-v4-0-cb387d73b...@skole.hr Changes in v4: - Address maintainer comments: - Relicense clock binding file to BSD-2 - Add pinctrl-names to SD card node - Add vgic registers to GIC node - Rebase on v6.5-rc5 - Link to v3: https://lore.kernel.org/r/20230804-pxa1908-lkml-v3-0-8e48fca37...@skole.hr Changes in v3: - Address maintainer comments: - Drop GPIO dynamic allocation patch - Move clock register offsets into driver (instead of bindings file) - Add missing Tested-by trailer to u32_fract patch - Move SoC binding to arm/mrvl/mrvl.yaml - Add serial0 alias and stdout-path to board dts to enable UART debugging - Rebase on v6.5-rc4 - Link to v2: https://lore.kernel.org/r/20230727162909.6031-1-duje.mihano...@skole.hr Changes in v2: - Remove earlycon patch as it's been merged into tty-next - Address maintainer comments: - Clarify GPIO regressions on older PXA platforms - Add Fixes tag to commit disabling GPIO pinctrl calls for this SoC - Add missing includes to clock driver - Clock driver uses HZ_PER_MHZ, u32_fract and GENMASK - Dual license clock bindings - Change clock IDs to decimal - Fix underscores in dt node names - Move chosen node to top of board dts - Clean up documentation - Reorder commits - Drop pxa,rev-id - Rename muic-i2c to i2c-muic - Reword some commits - Move framebuffer node to chosen - Add aliases for mmc nodes - Rebase on v6.5-rc3
Re: [RFC PATCH 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup
On Wed Apr 24, 2024 at 8:44 PM EEST, Jarkko Sakkinen wrote: > On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote: > > I still have some questions: > > > > It seems that the variable "ret" is set to 0 if there is **some** EPC pages > > have been > > added when interrupted by signal(Supposed that sgx_encl_add_page() > > always returns successfully). > > Ah, ok. > > Returning zero is right thing to do because it also returns count of > pages successfully added. I.e. the function does not guarantee that > all pages are processsed but it does guarantee that the system is in > predictable state. > > It could be that e.g. sgx_alloc_epc_page() calls fails. > > So, it is a bit like how read system call works. Good that you asked that had rethink for a while. What I would suggest that you just put out 2nd verson out and then we see where it is going. For sgx_ioc_encl_add_pages() it is important to maintain exact semantics as we need to maintain backwards compatibility. BR, Jarkko
Re: [RFC PATCH 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup
On Wed Apr 24, 2024 at 2:50 PM EEST, Bojun Zhu wrote: > I still have some questions: > > It seems that the variable "ret" is set to 0 if there is **some** EPC pages > have been > added when interrupted by signal(Supposed that sgx_encl_add_page() > always returns successfully). Ah, ok. Returning zero is right thing to do because it also returns count of pages successfully added. I.e. the function does not guarantee that all pages are processsed but it does guarantee that the system is in predictable state. It could be that e.g. sgx_alloc_epc_page() calls fails. So, it is a bit like how read system call works. BR, Jarkko
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 7:14 PM Ondřej Jirman wrote: > On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote: > > On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote: > > > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote: > > > > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan > > > > wrote: ... > > > > > ret = stk3310_init(indio_dev); > > > > > if (ret < 0) > > > > > - return ret; > > > > > + goto err_vdd_disable; > > > > > > > > This is wrong. You will have the regulator being disabled _before_ > > > > IRQ. Note, that the original code likely has a bug which sets states > > > > before disabling IRQ and removing a handler. > > > > > > How so? stk3310_init is called before enabling the interrupt. > > > > Exactly, IRQ is registered with devm and hence the error path and > > remove stages will got it in a wrong order. > > Makes no sense. Huh?! > IRQ is not enabled here, yet. So in error path, the code will > just disable the regulator and devm will unref it later on. IRQ doesn't enter > the picture here at all in the error path. Error path _after_ IRQ handler has been _successfully_ installed. And complete ->remove() stage. > > > Original code has a bug that IRQ is enabled before registering the > > > IIO device, > > > > Indeed, but this is another bug. > > > > > so if IRQ is triggered before registration, iio_push_event > > > from IRQ handler may be called on a not yet registered IIO device. > > > > > > Never saw it happen, though. :) > > > > Because nobody cares enough to enable DEBUG_SHIRQ. > > Nice debug tool. I bet it makes quite a mess when enabled. :) FWIW, I have had it enabled for ages, but I have only a few devices, so I fixed a few cases in the past WRT shared IRQ issues. -- With Best Regards, Andy Shevchenko
[PATCH RFC 2/2] soc: qcom: smsm: Support using mailbox interface
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to syscon.
Signed-off-by: Luca Weiss
---
drivers/soc/qcom/smsm.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/smsm.c b/drivers/soc/qcom/smsm.c
index e7c7e9a640a6..ffe78ae34386 100644
--- a/drivers/soc/qcom/smsm.c
+++ b/drivers/soc/qcom/smsm.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -71,6 +72,7 @@ struct smsm_host;
* @lock: spinlock for read-modify-write of the outgoing state
* @entries: context for each of the entries
* @hosts: context for each of the hosts
+ * @mbox_client: mailbox client handle
*/
struct qcom_smsm {
struct device *dev;
@@ -88,6 +90,8 @@ struct qcom_smsm {
struct smsm_entry *entries;
struct smsm_host *hosts;
+
+ struct mbox_client mbox_client;
};
/**
@@ -120,11 +124,14 @@ struct smsm_entry {
* @ipc_regmap:regmap for outgoing interrupt
* @ipc_offset:offset in @ipc_regmap for outgoing interrupt
* @ipc_bit: bit in @ipc_regmap + @ipc_offset for outgoing interrupt
+ * @mbox_chan: apcs ipc mailbox channel handle
*/
struct smsm_host {
struct regmap *ipc_regmap;
int ipc_offset;
int ipc_bit;
+
+ struct mbox_chan *mbox_chan;
};
/**
@@ -172,7 +179,13 @@ static int smsm_update_bits(void *data, u32 mask, u32
value)
hostp = &smsm->hosts[host];
val = readl(smsm->subscription + host);
- if (val & changes && hostp->ipc_regmap) {
+ if (!(val & changes))
+ continue;
+
+ if (hostp->mbox_chan) {
+ mbox_send_message(hostp->mbox_chan, NULL);
+ mbox_client_txdone(hostp->mbox_chan, 0);
+ } else if (hostp->ipc_regmap) {
regmap_write(hostp->ipc_regmap,
hostp->ipc_offset,
BIT(hostp->ipc_bit));
@@ -352,6 +365,28 @@ static const struct irq_domain_ops smsm_irq_ops = {
.xlate = irq_domain_xlate_twocell,
};
+/**
+ * smsm_parse_mbox() - requests an mbox channel
+ * @smsm: smsm driver context
+ * @host_id: index of the remote host to be resolved
+ *
+ * Requests the desired channel using the mbox interface which is needed for
+ * sending the outgoing interrupts to a remove hosts - identified by @host_id.
+ */
+static int smsm_parse_mbox(struct qcom_smsm *smsm, unsigned int host_id)
+{
+ struct smsm_host *host = &smsm->hosts[host_id];
+ int ret = 0;
+
+ host->mbox_chan = mbox_request_channel(&smsm->mbox_client, host_id);
+ if (IS_ERR(host->mbox_chan)) {
+ ret = PTR_ERR(host->mbox_chan);
+ host->mbox_chan = NULL;
+ }
+
+ return ret;
+}
+
/**
* smsm_parse_ipc() - parses a qcom,ipc-%d device tree property
* @smsm: smsm driver context
@@ -521,8 +556,16 @@ static int qcom_smsm_probe(struct platform_device *pdev)
"qcom,local-host",
&smsm->local_host);
+ smsm->mbox_client.dev = &pdev->dev;
+ smsm->mbox_client.knows_txdone = true;
+
/* Parse the host properties */
for (id = 0; id < smsm->num_hosts; id++) {
+ /* Try using mbox interface first, otherwise fall back to
syscon */
+ ret = smsm_parse_mbox(smsm, id);
+ if (!ret)
+ continue;
+
ret = smsm_parse_ipc(smsm, id);
if (ret < 0)
goto out_put;
@@ -609,6 +652,9 @@ static int qcom_smsm_probe(struct platform_device *pdev)
qcom_smem_state_unregister(smsm->state);
out_put:
+ for (id = 0; id < smsm->num_hosts; id++)
+ mbox_free_channel(smsm->hosts[id].mbox_chan);
+
of_node_put(local_node);
return ret;
}
@@ -622,6 +668,9 @@ static void qcom_smsm_remove(struct platform_device *pdev)
if (smsm->entries[id].domain)
irq_domain_remove(smsm->entries[id].domain);
+ for (id = 0; id < smsm->num_hosts; id++)
+ mbox_free_channel(smsm->hosts[id].mbox_chan);
+
qcom_smem_state_unregister(smsm->state);
}
--
2.44.0
[PATCH RFC 0/2] Support mailbox interface in qcom,smsm driver
Take a shot at converting the last driver that requires direct "qcom,ipc*" syscon references in devicetree by allowing the smsm driver to use the mailbox interface to achieve the same effect. I'm not very happy about how the devicetree change looks in the end. Perhaps it's better to use mbox-names to not have <0> elements in dt, and reference the items by name from the driver? e.g. this change for msm8226 could be represented differently. - qcom,ipc-1 = <&apcs 8 13>; - qcom,ipc-2 = <&apcs 8 9>; - qcom,ipc-3 = <&apcs 8 19>; + mboxes = <0>, <&apcs 13>, <&apcs 9>, <&apcs 19>; vs. for example: - qcom,ipc-1 = <&apcs 8 13>; - qcom,ipc-2 = <&apcs 8 9>; - qcom,ipc-3 = <&apcs 8 19>; + mboxes = <&apcs 13>, <&apcs 9>, <&apcs 19>; + mbox-names = "ipc-1", "ipc-2", "ipc-3"; But also here the name with 'ipc-N' is probably not particularly fitting? Please let me know your thoughts and any suggestions. Signed-off-by: Luca Weiss --- Luca Weiss (2): dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc soc: qcom: smsm: Support using mailbox interface .../devicetree/bindings/soc/qcom/qcom,smsm.yaml| 48 drivers/soc/qcom/smsm.c| 51 +- 2 files changed, 90 insertions(+), 9 deletions(-) --- base-commit: ed30a4a51bb196781c8058073ea720133a65596f change-id: 20240424-smsm-mbox-0666f35eae44 Best regards, -- Luca Weiss
[PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
the mboxes property by index, starting at 0 since that's a valid SMSM
host also.
The new example shows how an smsm node with just qcom,ipc-3 should be
specified with the mboxes property.
Signed-off-by: Luca Weiss
---
.../devicetree/bindings/soc/qcom/qcom,smsm.yaml| 48 ++
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
index db67cf043256..b12589171169 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
@@ -33,6 +33,13 @@ properties:
specifier of the column in the subscription matrix representing the local
processor.
+ mboxes:
+minItems: 1
+maxItems: 5
+description:
+ Reference to the mailbox representing the outgoing doorbell in APCS for
+ this client.
+
'#size-cells':
const: 0
@@ -98,15 +105,18 @@ required:
- '#address-cells'
- '#size-cells'
-anyOf:
+oneOf:
- required:
- - qcom,ipc-1
- - required:
- - qcom,ipc-2
- - required:
- - qcom,ipc-3
- - required:
- - qcom,ipc-4
+ - mboxes
+ - anyOf:
+ - required:
+ - qcom,ipc-1
+ - required:
+ - qcom,ipc-2
+ - required:
+ - qcom,ipc-3
+ - required:
+ - qcom,ipc-4
additionalProperties: false
@@ -136,3 +146,25 @@ examples:
#interrupt-cells = <2>;
};
};
+ # Example using mboxes property
+ - |
+#include
+
+shared-memory {
+compatible = "qcom,smsm";
+#address-cells = <1>;
+#size-cells = <0>;
+mboxes = <0>, <0>, <0>, <&apcs 19>;
+
+apps@0 {
+reg = <0>;
+#qcom,smem-state-cells = <1>;
+};
+
+wcnss@7 {
+reg = <7>;
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <2>;
+};
+};
--
2.44.0
Re: [PATCH 0/7] Use mboxes instead of syscon for APCS (arm32 & arm64)
On Wed, Apr 24, 2024 at 06:23:53PM +0200, Luca Weiss wrote: > The first patch is for removing a bogus error warning I've noticed while > developing this on msm8226 - there the patches are also coming later for > this SoC since apcs is getting hooked up to cpufreq there also. > > Apart from usages from the qcom,smsm driver (patches coming!) all other > usages of the apcs mailbox now go via the mailbox driver - where one is > used, so some arm32 boards will continue using "qcom,ipc*" properties in > the short or long term. > Very nice, thank you for cleaning this up. Regards, Bjorn > Only compile-tested apart from msm8953 (tested on sdm632-fairphone-fp3) > and msm8974 (tested on msm8974pro-fairphone-fp2), but I don't expect any > complications with this. > > Signed-off-by: Luca Weiss > --- > Luca Weiss (7): > rpmsg: qcom_smd: Don't print error during probe deferral > ARM: dts: qcom: msm8974: Use mboxes properties for APCS > arm64: dts: qcom: msm8916: Use mboxes properties for APCS > arm64: dts: qcom: msm8939: Use mboxes properties for APCS > arm64: dts: qcom: msm8953: Use mboxes properties for APCS > arm64: dts: qcom: msm8976: Use mboxes properties for APCS > arm64: dts: qcom: msm8994: Use mboxes properties for APCS > > arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++--- > arch/arm64/boot/dts/qcom/msm8916.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8939.dtsi| 4 ++-- > arch/arm64/boot/dts/qcom/msm8953.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8976.dtsi| 8 > arch/arm64/boot/dts/qcom/msm8994.dtsi| 6 +++--- > drivers/rpmsg/qcom_smd.c | 3 ++- > 7 files changed, 28 insertions(+), 27 deletions(-) > --- > base-commit: 43173e6dbaa227f3107310d4df4a3bacd5e0df33 > change-id: 20240423-apcs-mboxes-12ee6c01a5b3 > > Best regards, > -- > Luca Weiss >
Re: [PATCH 1/7] rpmsg: qcom_smd: Don't print error during probe deferral
On Wed, Apr 24, 2024 at 06:23:54PM +0200, Luca Weiss wrote:
> When the mailbox driver has not probed yet, skip printing the error
> message since it's just going to confuse users.
>
> Signed-off-by: Luca Weiss
> ---
> drivers/rpmsg/qcom_smd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index 43f601c84b4f..6fc299657adf 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -1502,7 +1502,8 @@ struct qcom_smd_edge *qcom_smd_register_edge(struct
> device *parent,
>
> ret = qcom_smd_parse_edge(&edge->dev, node, edge);
> if (ret) {
> - dev_err(&edge->dev, "failed to parse smd edge\n");
> + if (ret != -EPROBE_DEFER)
> + dev_err(&edge->dev, "failed to parse smd edge\n");
In the described case, this error message would not be entirely
accurate, and the cause is not accurately captured in devices_deferred.
Unless I'm mistaken, it seems like qcom_smd_parse_edge() will also print
a more useful error in every other case, except after the mbox_chan !=
-ENODEV check..
How about making that:
if (PTR_ERR(edge->mbox_chan) != -ENODEV) {
ret = dev_err_probe(dev, PTR_ERR(edge->mbox_chan),
"failed to acquire IPC mailbox\n");
goto put_node;
}
And then drop the error print here in qcom_smd_register_edge().
It would bring us the devices_deferred tracking, and it would avoid the
double print in all other cases.
Regards,
Bjorn
> goto unregister_dev;
> }
>
>
> --
> 2.44.0
>
Re: [PATCH 0/7] Use mboxes instead of syscon for APCS (arm32 & arm64)
On Mittwoch, 24. April 2024 18:23:53 MESZ Luca Weiss wrote: > The first patch is for removing a bogus error warning I've noticed while > developing this on msm8226 - there the patches are also coming later for > this SoC since apcs is getting hooked up to cpufreq there also. > > Apart from usages from the qcom,smsm driver (patches coming!) all other > usages of the apcs mailbox now go via the mailbox driver - where one is > used, so some arm32 boards will continue using "qcom,ipc*" properties in > the short or long term. > > Only compile-tested apart from msm8953 (tested on sdm632-fairphone-fp3) > and msm8974 (tested on msm8974pro-fairphone-fp2), but I don't expect any > complications with this. I think I forgot to mention this, but the msm8974 patch depends on this series: https://lore.kernel.org/linux-arm-msm/20240408-msm8974-apcs-v1-0-90cb73688...@z3ntu.xyz/ > > Signed-off-by: Luca Weiss > --- > Luca Weiss (7): > rpmsg: qcom_smd: Don't print error during probe deferral > ARM: dts: qcom: msm8974: Use mboxes properties for APCS > arm64: dts: qcom: msm8916: Use mboxes properties for APCS > arm64: dts: qcom: msm8939: Use mboxes properties for APCS > arm64: dts: qcom: msm8953: Use mboxes properties for APCS > arm64: dts: qcom: msm8976: Use mboxes properties for APCS > arm64: dts: qcom: msm8994: Use mboxes properties for APCS > > arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++--- > arch/arm64/boot/dts/qcom/msm8916.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8939.dtsi| 4 ++-- > arch/arm64/boot/dts/qcom/msm8953.dtsi| 10 +- > arch/arm64/boot/dts/qcom/msm8976.dtsi| 8 > arch/arm64/boot/dts/qcom/msm8994.dtsi| 6 +++--- > drivers/rpmsg/qcom_smd.c | 3 ++- > 7 files changed, 28 insertions(+), 27 deletions(-) > --- > base-commit: 43173e6dbaa227f3107310d4df4a3bacd5e0df33 > change-id: 20240423-apcs-mboxes-12ee6c01a5b3 > > Best regards, >
[PATCH] drivers: remoteproc: xlnx: fix uninitialized tcm mode
Add "else" case for default tcm mode to silent following static check:
zynqmp_r5_cluster_init()
error: uninitialized symbol 'tcm_mode'.
Fixes: a6b974b40f94 ("drivers: remoteproc: xlnx: Add Versal and Versal-NET
support")
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
b/drivers/remoteproc/xlnx_r5_remoteproc.c
index d98940d7ef8f..84243d1dff9f 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -1006,6 +1006,8 @@ static int zynqmp_r5_cluster_init(struct
zynqmp_r5_cluster *cluster)
tcm_mode = PM_RPU_TCM_COMB;
else
tcm_mode = PM_RPU_TCM_SPLIT;
+ } else {
+ tcm_mode = PM_RPU_TCM_COMB;
}
/*
base-commit: a49a6c600193e32123e8885515051b34a5d711ff
--
2.25.1
[PATCH 2/7] ARM: dts: qcom: msm8974: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 20958c47ff3a..0f1dc4355c7a 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -130,7 +130,7 @@ master-stats {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 0>;
+ mboxes = <&apcs 0>;
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
@@ -217,7 +217,7 @@ smp2p-adsp {
interrupt-parent = <&intc>;
interrupts = ;
- qcom,ipc = <&apcs 8 10>;
+ mboxes = <&apcs 10>;
qcom,local-pid = <0>;
qcom,remote-pid = <2>;
@@ -242,7 +242,7 @@ smp2p-modem {
interrupt-parent = <&intc>;
interrupts = ;
- qcom,ipc = <&apcs 8 14>;
+ mboxes = <&apcs 14>;
qcom,local-pid = <0>;
qcom,remote-pid = <1>;
@@ -267,7 +267,7 @@ smp2p-wcnss {
interrupt-parent = <&intc>;
interrupts = ;
- qcom,ipc = <&apcs 8 18>;
+ mboxes = <&apcs 18>;
qcom,local-pid = <0>;
qcom,remote-pid = <4>;
@@ -757,7 +757,7 @@ iris {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 17>;
+ mboxes = <&apcs 17>;
qcom,smd-edge = <6>;
wcnss {
@@ -1576,7 +1576,7 @@ bam_dmux: bam-dmux {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 12>;
+ mboxes = <&apcs 12>;
qcom,smd-edge = <0>;
label = "modem";
@@ -2213,7 +2213,7 @@ remoteproc_adsp: remoteproc@fe20 {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 8>;
+ mboxes = <&apcs 8>;
qcom,smd-edge = <1>;
label = "lpass";
};
--
2.44.0
[PATCH 0/7] Use mboxes instead of syscon for APCS (arm32 & arm64)
The first patch is for removing a bogus error warning I've noticed while developing this on msm8226 - there the patches are also coming later for this SoC since apcs is getting hooked up to cpufreq there also. Apart from usages from the qcom,smsm driver (patches coming!) all other usages of the apcs mailbox now go via the mailbox driver - where one is used, so some arm32 boards will continue using "qcom,ipc*" properties in the short or long term. Only compile-tested apart from msm8953 (tested on sdm632-fairphone-fp3) and msm8974 (tested on msm8974pro-fairphone-fp2), but I don't expect any complications with this. Signed-off-by: Luca Weiss --- Luca Weiss (7): rpmsg: qcom_smd: Don't print error during probe deferral ARM: dts: qcom: msm8974: Use mboxes properties for APCS arm64: dts: qcom: msm8916: Use mboxes properties for APCS arm64: dts: qcom: msm8939: Use mboxes properties for APCS arm64: dts: qcom: msm8953: Use mboxes properties for APCS arm64: dts: qcom: msm8976: Use mboxes properties for APCS arm64: dts: qcom: msm8994: Use mboxes properties for APCS arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 14 +++--- arch/arm64/boot/dts/qcom/msm8916.dtsi| 10 +- arch/arm64/boot/dts/qcom/msm8939.dtsi| 4 ++-- arch/arm64/boot/dts/qcom/msm8953.dtsi| 10 +- arch/arm64/boot/dts/qcom/msm8976.dtsi| 8 arch/arm64/boot/dts/qcom/msm8994.dtsi| 6 +++--- drivers/rpmsg/qcom_smd.c | 3 ++- 7 files changed, 28 insertions(+), 27 deletions(-) --- base-commit: 43173e6dbaa227f3107310d4df4a3bacd5e0df33 change-id: 20240423-apcs-mboxes-12ee6c01a5b3 Best regards, -- Luca Weiss
[PATCH 1/7] rpmsg: qcom_smd: Don't print error during probe deferral
When the mailbox driver has not probed yet, skip printing the error
message since it's just going to confuse users.
Signed-off-by: Luca Weiss
---
drivers/rpmsg/qcom_smd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 43f601c84b4f..6fc299657adf 100644
--- a/drivers/rpmsg/qcom_smd.c
+++ b/drivers/rpmsg/qcom_smd.c
@@ -1502,7 +1502,8 @@ struct qcom_smd_edge *qcom_smd_register_edge(struct
device *parent,
ret = qcom_smd_parse_edge(&edge->dev, node, edge);
if (ret) {
- dev_err(&edge->dev, "failed to parse smd edge\n");
+ if (ret != -EPROBE_DEFER)
+ dev_err(&edge->dev, "failed to parse smd edge\n");
goto unregister_dev;
}
--
2.44.0
[PATCH 4/7] arm64: dts: qcom: msm8939: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index dd45975682b2..95487de2ca6a 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -248,7 +248,7 @@ rpm: remoteproc {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs1_mbox 8 0>;
+ mboxes = <&apcs1_mbox 0>;
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
@@ -2067,7 +2067,7 @@ wcnss_iris: iris {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs1_mbox 8 17>;
+ mboxes = <&apcs1_mbox 17>;
qcom,smd-edge = <6>;
qcom,remote-pid = <4>;
--
2.44.0
[PATCH 3/7] arm64: dts: qcom: msm8916: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index cedff4166bfb..46bb322ae133 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -308,7 +308,7 @@ rpm: remoteproc {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 0>;
+ mboxes = <&apcs 0>;
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
@@ -360,7 +360,7 @@ smp2p-hexagon {
interrupts = ;
- qcom,ipc = <&apcs 8 14>;
+ mboxes = <&apcs 14>;
qcom,local-pid = <0>;
qcom,remote-pid = <1>;
@@ -385,7 +385,7 @@ smp2p-wcnss {
interrupts = ;
- qcom,ipc = <&apcs 8 18>;
+ mboxes = <&apcs 18>;
qcom,local-pid = <0>;
qcom,remote-pid = <4>;
@@ -1978,7 +1978,7 @@ smd-edge {
interrupts = ;
qcom,smd-edge = <0>;
- qcom,ipc = <&apcs 8 12>;
+ mboxes = <&apcs 12>;
qcom,remote-pid = <1>;
label = "hexagon";
@@ -2459,7 +2459,7 @@ wcnss_iris: iris {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 17>;
+ mboxes = <&apcs 17>;
qcom,smd-edge = <6>;
qcom,remote-pid = <4>;
--
2.44.0
[PATCH 5/7] arm64: dts: qcom: msm8953: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index f1011bb641c6..650ad75923f8 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -195,7 +195,7 @@ rpm: remoteproc {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 0>;
+ mboxes = <&apcs 0>;
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
@@ -361,7 +361,7 @@ smp2p-modem {
interrupts = ;
- qcom,ipc = <&apcs 8 14>;
+ mboxes = <&apcs 14>;
qcom,local-pid = <0>;
qcom,remote-pid = <1>;
@@ -386,7 +386,7 @@ smp2p-wcnss {
interrupts = ;
- qcom,ipc = <&apcs 8 18>;
+ mboxes = <&apcs 18>;
qcom,local-pid = <0>;
qcom,remote-pid = <4>;
@@ -1267,7 +1267,7 @@ smd-edge {
interrupts = ;
qcom,smd-edge = <0>;
- qcom,ipc = <&apcs 8 12>;
+ mboxes = <&apcs 12>;
qcom,remote-pid = <1>;
label = "modem";
@@ -1734,7 +1734,7 @@ wcnss_iris: iris {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 17>;
+ mboxes = <&apcs 17>;
qcom,smd-edge = <6>;
qcom,remote-pid = <4>;
--
2.44.0
[PATCH 7/7] arm64: dts: qcom: msm8994: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index 695e541832ad..9949d2cd23d8 100644
--- a/arch/arm64/boot/dts/qcom/msm8994.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8994.dtsi
@@ -183,7 +183,7 @@ rpm: remoteproc {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 0>;
+ mboxes = <&apcs 0>;
qcom,smd-edge = <15>;
qcom,remote-pid = <6>;
@@ -300,7 +300,7 @@ smp2p-lpass {
interrupts = ;
- qcom,ipc = <&apcs 8 10>;
+ mboxes = <&apcs 10>;
qcom,local-pid = <0>;
qcom,remote-pid = <2>;
@@ -325,7 +325,7 @@ smp2p-modem {
interrupt-parent = <&intc>;
interrupts = ;
- qcom,ipc = <&apcs 8 14>;
+ mboxes = <&apcs 14>;
qcom,local-pid = <0>;
qcom,remote-pid = <1>;
--
2.44.0
[PATCH 6/7] arm64: dts: qcom: msm8976: Use mboxes properties for APCS
Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..9ca0867e45ba 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -237,7 +237,7 @@ rpm: remoteproc {
smd-edge {
interrupts = ;
- qcom,ipc = <&apcs 8 0>;
+ mboxes = <&apcs 0>;
qcom,smd-edge = <15>;
rpm_requests: rpm-requests {
@@ -361,7 +361,7 @@ tz-apps@8dd0 {
smp2p-hexagon {
compatible = "qcom,smp2p";
interrupts = ;
- qcom,ipc = <&apcs 8 10>;
+ mboxes = <&apcs 10>;
qcom,local-pid = <0>;
qcom,remote-pid = <2>;
@@ -384,7 +384,7 @@ adsp_smp2p_in: slave-kernel {
smp2p-modem {
compatible = "qcom,smp2p";
interrupts = ;
- qcom,ipc = <&apcs 8 14>;
+ mboxes = <&apcs 14>;
qcom,local-pid = <0>;
qcom,remote-pid = <1>;
@@ -407,7 +407,7 @@ modem_smp2p_in: slave-kernel {
smp2p-wcnss {
compatible = "qcom,smp2p";
interrupts = ;
- qcom,ipc = <&apcs 8 18>;
+ mboxes = <&apcs 18>;
qcom,local-pid = <0>;
qcom,remote-pid = <4>;
--
2.44.0
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 06:20:41PM GMT, Andy Shevchenko wrote: > On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote: > > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote: > > > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan > > > wrote: > > ... > > > > > ret = stk3310_init(indio_dev); > > > > if (ret < 0) > > > > - return ret; > > > > + goto err_vdd_disable; > > > > > > This is wrong. You will have the regulator being disabled _before_ > > > IRQ. Note, that the original code likely has a bug which sets states > > > before disabling IRQ and removing a handler. > > > > How so? stk3310_init is called before enabling the interrupt. > > Exactly, IRQ is registered with devm and hence the error path and > remove stages will got it in a wrong order. Makes no sense. IRQ is not enabled here, yet. So in error path, the code will just disable the regulator and devm will unref it later on. IRQ doesn't enter the picture here at all in the error path. > > Original code has a bug that IRQ is enabled before registering the > > IIO device, > > Indeed, but this is another bug. > > > so if IRQ is triggered before registration, iio_push_event > > from IRQ handler may be called on a not yet registered IIO device. > > > > Never saw it happen, though. :) > > Because nobody cares enough to enable DEBUG_SHIRQ. Nice debug tool. I bet it makes quite a mess when enabled. :) Kind regards, o. > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH v3 4/4] media: mediatek: imgsys: Support image processing
On Wed, Apr 24, 2024 at 12:04:54PM +0200, AngeloGioacchino Del Regno wrote:
> Il 24/04/24 12:02, AngeloGioacchino Del Regno ha scritto:
> > Il 24/04/24 05:03, Olivia Wen ha scritto:
> > > Integrate the imgsys core architecture driver for image processing on
> > > the MT8188 platform.
> > >
> > > Signed-off-by: Olivia Wen
> >
> > This should be reordered before introducing the 8188 scp core 1 support
> > commit,
> > but let's check with Mathieu before sending a v4.
> >
I don't have a strong preference.
> > With that reordered,
> >
> > Reviewed-by: AngeloGioacchino Del Regno
> >
>
> Wait, no. Sorry. I just noticed that the commit message is totally wrong.
>
> This is not a media commit, but remoteproc, and you're not adding support for
> image processing with this commit - not in media at least.
> Also, you're not adding any imgsys core architecture driver.
>
> Please fix both commit description and title.
>
I agree.
> Regards,
> Angelo
>
> >
> > > ---
> > > include/linux/remoteproc/mtk_scp.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/linux/remoteproc/mtk_scp.h
> > > b/include/linux/remoteproc/mtk_scp.h
> > > index 7c2b7cc9..344ff41 100644
> > > --- a/include/linux/remoteproc/mtk_scp.h
> > > +++ b/include/linux/remoteproc/mtk_scp.h
> > > @@ -43,6 +43,7 @@ enum scp_ipi_id {
> > > SCP_IPI_CROS_HOST_CMD,
> > > SCP_IPI_VDEC_LAT,
> > > SCP_IPI_VDEC_CORE,
> > > + SCP_IPI_IMGSYS_CMD,
> > > SCP_IPI_NS_SERVICE = 0xFF,
> > > SCP_IPI_MAX = 0x100,
> > > };
> >
>
Re: [PATCH v21 2/5] ring-buffer: Introducing ring-buffer mapping functions
I gave it some more thought, and I think we are still missing something
(I wish PFNMAP/MIXEDMAP wouldn't be that hard).
+
+/*
+ * +--+ pgoff == 0
+ * | meta page |
+ * +--+ pgoff == 1
+ * | subbuffer 0 |
+ * | |
+ * +--+ pgoff == (1 + (1 << subbuf_order))
+ * | subbuffer 1 |
+ * | |
+ * ...
+ */
+#ifdef CONFIG_MMU
+static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
+ struct vm_area_struct *vma)
+{
+ unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
+ unsigned int subbuf_pages, subbuf_order;
+ struct page **pages;
+ int p = 0, s = 0;
+ int err;
+
I'd add some comments here like
/* Refuse any MAP_PRIVATE or writable mappings. */
+ if (vma->vm_flags & VM_WRITE || vma->vm_flags & VM_EXEC ||
+ !(vma->vm_flags & VM_MAYSHARE))
+ return -EPERM;
+
/*
* Make sure the mapping cannot become writable later. Also, tell the VM
* to not touch these pages pages (VM_DONTCOPY | VM_DONTDUMP) and tell
* GUP to leave them alone as well (VM_IO).
*/
+ vm_flags_mod(vma,
+VM_MIXEDMAP | VM_PFNMAP |
+VM_DONTCOPY | VM_DONTDUMP | VM_DONTEXPAND | VM_IO,
+VM_MAYWRITE);
I am still really unsure about VM_PFNMAP ... it's not a PFNMAP at all
and, as stated, vm_insert_pages() even complains quite a lot when it
would have to set VM_MIXEDMAP and VM_PFNMAP is already set, likely for a
very good reason.
Can't we limit ourselves to VM_IO?
But then, I wonder if it really helps much regarding GUP: yes, it blocks
ordinary GUP (see check_vma_flags()) but as
insert_page_into_pte_locked() does *not* set pte_special(), GUP-fast
(gup_fast_pte_range()) will not reject it.
Really, if you want GUP-fast to reject it, remap_pfn_range() and friends
are the way to go, that will set pte_special() such that also GUP-fast
will leave it alone, just like vm_normal_page() would.
So ... I know Linus recommended VM_PFNMAP/VM_IO to stop GUP, but it
alone won't stop all of GUP. We really have to mark the PTE as special,
which vm_insert_page() must not do (because it is refcounted!).
Which means: do we really have to stop GUP from grabbing that page?
Using vm_insert_page() only with VM_MIXEDMAP (and without
VM_PFNMAP|VM_IO) would be better.
If we want to stop all of GUP, remap_pfn_range() currently seems
unavoidable :(
+
+ lockdep_assert_held(&cpu_buffer->mapping_lock);
+
+ subbuf_order = cpu_buffer->buffer->subbuf_order;
+ subbuf_pages = 1 << subbuf_order;
+
+ nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
+ nr_pages = ((nr_subbufs) << subbuf_order) - pgoff + 1; /* + meta-page */
+
+ vma_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ if (!vma_pages || vma_pages > nr_pages)
+ return -EINVAL;
+
+ nr_pages = vma_pages;
+
+ pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return -ENOMEM;
+
+ if (!pgoff) {
+ pages[p++] = virt_to_page(cpu_buffer->meta_page);
+
+ /*
+* TODO: Align sub-buffers on their size, once
+* vm_insert_pages() supports the zero-page.
+*/
+ } else {
+ /* Skip the meta-page */
+ pgoff--;
+
+ if (pgoff % subbuf_pages) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ s += pgoff / subbuf_pages;
+ }
+
+ while (s < nr_subbufs && p < nr_pages) {
+ struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]);
+ int off = 0;
+
+ for (; off < (1 << (subbuf_order)); off++, page++) {
+ if (p >= nr_pages)
+ break;
+
+ pages[p++] = page;
+ }
+ s++;
+ }
+
+ err = vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);
vm_insert_pages() documents: "In case of error, we may have mapped a
subset of the provided pages. It is the caller's responsibility to
account for this case."
Which could for example happen, when allocating a page table fails.
Would we able to deal with that here?
Again, I wish it would all be easier ...
--
Cheers,
David / dhildenb
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 3:59 PM Ondřej Jirman wrote: > On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote: > > On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan > > wrote: ... > > > ret = stk3310_init(indio_dev); > > > if (ret < 0) > > > - return ret; > > > + goto err_vdd_disable; > > > > This is wrong. You will have the regulator being disabled _before_ > > IRQ. Note, that the original code likely has a bug which sets states > > before disabling IRQ and removing a handler. > > How so? stk3310_init is called before enabling the interrupt. Exactly, IRQ is registered with devm and hence the error path and remove stages will got it in a wrong order. > Original code has a bug that IRQ is enabled before registering the > IIO device, Indeed, but this is another bug. > so if IRQ is triggered before registration, iio_push_event > from IRQ handler may be called on a not yet registered IIO device. > > Never saw it happen, though. :) Because nobody cares enough to enable DEBUG_SHIRQ. -- With Best Regards, Andy Shevchenko
Re: [PATCH v9 01/36] tracing: Add a comment about ftrace_regs definition
On Wed, 24 Apr 2024 15:19:24 +0200 Florent Revest wrote: > On Wed, Apr 24, 2024 at 2:23 PM Florent Revest wrote: > > > > On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google) > > wrote: > > > > > > From: Masami Hiramatsu (Google) > > > > > > To clarify what will be expected on ftrace_regs, add a comment to the > > > architecture independent definition of the ftrace_regs. > > > > > > Signed-off-by: Masami Hiramatsu (Google) > > > Acked-by: Mark Rutland > > > --- > > > Changes in v8: > > > - Update that the saved registers depends on the context. > > > Changes in v3: > > > - Add instruction pointer > > > Changes in v2: > > > - newly added. > > > --- > > > include/linux/ftrace.h | 26 ++ > > > 1 file changed, 26 insertions(+) > > > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > > > index 54d53f345d14..b81f1afa82a1 100644 > > > --- a/include/linux/ftrace.h > > > +++ b/include/linux/ftrace.h > > > @@ -118,6 +118,32 @@ extern int ftrace_enabled; > > > > > > #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS > > > > > > +/** > > > + * ftrace_regs - ftrace partial/optimal register set > > > + * > > > + * ftrace_regs represents a group of registers which is used at the > > > + * function entry and exit. There are three types of registers. > > > + * > > > + * - Registers for passing the parameters to callee, including the stack > > > + * pointer. (e.g. rcx, rdx, rdi, rsi, r8, r9 and rsp on x86_64) > > > + * - Registers for passing the return values to caller. > > > + * (e.g. rax and rdx on x86_64) > > > > Ooc, have we ever considered skipping argument registers that are not > > return value registers in the exit code paths ? For example, why would > > we want to save rdi in a return handler ? > > > > But if we want to avoid the situation of having "sparse ftrace_regs" > > all over again, we'd have to split ftrace_regs into a ftrace_args_regs > > and a ftrace_ret_regs which would make this refactoring even more > > painful, just to skip a few instructions. :| > > > > I don't necessarily think it's worth it, I just wanted to make sure > > this was considered. > > Ah, well, I just reached patch 22 and noticed that there you add add: > > + * Basically, ftrace_regs stores the registers related to the context. > + * On function entry, registers for function parameters and hooking the > + * function call are stored, and on function exit, registers for function > + * return value and frame pointers are stored. > > So ftrace_regs can be a a sparse structure then. That's fair enough with me! > ;) Yes, and in this patch, I explained that too :) > + * On the function entry, those registers will be restored except for > + * the stack pointer, so that user can change the function parameters > + * and instruction pointer (e.g. live patching.) > + * On the function exit, only registers which is used for return values > > + * are restored. So the function exit, ftrace_regs will be sparse. Thank you, -- Masami Hiramatsu (Google)
Re: [PATCH v9 00/36] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph
Neat! :) I had a look at mostly the "high level" part (fprobe and arm64 specific bits) and this seems to be in a good state to me. Thanks for all that work, that is quite a refactoring :) On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google) wrote: > > Hi, > > Here is the 9th version of the series to re-implement the fprobe on > function-graph tracer. The previous version is; > > https://lore.kernel.org/all/170887410337.564249.6360118840946697039.stgit@devnote2/ > > This version is ported on the latest kernel (v6.9-rc3 + probes/for-next) > and fixed some bugs + performance optimization patch[36/36]. > - [12/36] Fix to clear fgraph_array entry in registration failure, also >return -ENOSPC when fgraph_array is full. > - [28/36] Add new store_fprobe_entry_data() for fprobe. > - [31/36] Remove DIV_ROUND_UP() and fix entry data address calculation. > - [36/36] Add new flag to skip timestamp recording. > > Overview > > This series does major 2 changes, enable multiple function-graphs on > the ftrace (e.g. allow function-graph on sub instances) and rewrite the > fprobe on this function-graph. > > The former changes had been sent from Steven Rostedt 4 years ago (*), > which allows users to set different setting function-graph tracer (and > other tracers based on function-graph) in each trace-instances at the > same time. > > (*) https://lore.kernel.org/all/20190525031633.811342...@goodmis.org/ > > The purpose of latter change are; > > 1) Remove dependency of the rethook from fprobe so that we can reduce >the return hook code and shadow stack. > > 2) Make 'ftrace_regs' the common trace interface for the function >boundary. > > 1) Currently we have 2(or 3) different function return hook codes, > the function-graph tracer and rethook (and legacy kretprobe). > But since this is redundant and needs double maintenance cost, > I would like to unify those. From the user's viewpoint, function- > graph tracer is very useful to grasp the execution path. For this > purpose, it is hard to use the rethook in the function-graph > tracer, but the opposite is possible. (Strictly speaking, kretprobe > can not use it because it requires 'pt_regs' for historical reasons.) > > 2) Now the fprobe provides the 'pt_regs' for its handler, but that is > wrong for the function entry and exit. Moreover, depending on the > architecture, there is no way to accurately reproduce 'pt_regs' > outside of interrupt or exception handlers. This means fprobe should > not use 'pt_regs' because it does not use such exceptions. > (Conversely, kprobe should use 'pt_regs' because it is an abstract > interface of the software breakpoint exception.) > > This series changes fprobe to use function-graph tracer for tracing > function entry and exit, instead of mixture of ftrace and rethook. > Unlike the rethook which is a per-task list of system-wide allocated > nodes, the function graph's ret_stack is a per-task shadow stack. > Thus it does not need to set 'nr_maxactive' (which is the number of > pre-allocated nodes). > Also the handlers will get the 'ftrace_regs' instead of 'pt_regs'. > Since eBPF mulit_kprobe/multi_kretprobe events still use 'pt_regs' as > their register interface, this changes it to convert 'ftrace_regs' to > 'pt_regs'. Of course this conversion makes an incomplete 'pt_regs', > so users must access only registers for function parameters or > return value. > > Design > -- > Instead of using ftrace's function entry hook directly, the new fprobe > is built on top of the function-graph's entry and return callbacks > with 'ftrace_regs'. > > Since the fprobe requires access to 'ftrace_regs', the architecture > must support CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS and > CONFIG_HAVE_FTRACE_GRAPH_FUNC, which enables to call function-graph > entry callback with 'ftrace_regs', and also > CONFIG_HAVE_FUNCTION_GRAPH_FREGS, which passes the ftrace_regs to > return_to_handler. > > All fprobes share a single function-graph ops (means shares a common > ftrace filter) similar to the kprobe-on-ftrace. This needs another > layer to find corresponding fprobe in the common function-graph > callbacks, but has much better scalability, since the number of > registered function-graph ops is limited. > > In the entry callback, the fprobe runs its entry_handler and saves the > address of 'fprobe' on the function-graph's shadow stack as data. The > return callback decodes the data to get the 'fprobe' address, and runs > the exit_handler. > > The fprobe introduces two hash-tables, one is for entry callback which > searches fprobes related to the given function address passed by entry > callback. The other is for a return callback which checks if the given > 'fprobe' data structure pointer is still valid. Note that it is > possible to unregister fprobe before the return callback runs. Thus > the address validation must be done before using it in the return > callback. > > This series can be applied against the probes
Re: [PATCH v9 01/36] tracing: Add a comment about ftrace_regs definition
On Wed, Apr 24, 2024 at 2:23 PM Florent Revest wrote: > > On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google) > wrote: > > > > From: Masami Hiramatsu (Google) > > > > To clarify what will be expected on ftrace_regs, add a comment to the > > architecture independent definition of the ftrace_regs. > > > > Signed-off-by: Masami Hiramatsu (Google) > > Acked-by: Mark Rutland > > --- > > Changes in v8: > > - Update that the saved registers depends on the context. > > Changes in v3: > > - Add instruction pointer > > Changes in v2: > > - newly added. > > --- > > include/linux/ftrace.h | 26 ++ > > 1 file changed, 26 insertions(+) > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > > index 54d53f345d14..b81f1afa82a1 100644 > > --- a/include/linux/ftrace.h > > +++ b/include/linux/ftrace.h > > @@ -118,6 +118,32 @@ extern int ftrace_enabled; > > > > #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS > > > > +/** > > + * ftrace_regs - ftrace partial/optimal register set > > + * > > + * ftrace_regs represents a group of registers which is used at the > > + * function entry and exit. There are three types of registers. > > + * > > + * - Registers for passing the parameters to callee, including the stack > > + * pointer. (e.g. rcx, rdx, rdi, rsi, r8, r9 and rsp on x86_64) > > + * - Registers for passing the return values to caller. > > + * (e.g. rax and rdx on x86_64) > > Ooc, have we ever considered skipping argument registers that are not > return value registers in the exit code paths ? For example, why would > we want to save rdi in a return handler ? > > But if we want to avoid the situation of having "sparse ftrace_regs" > all over again, we'd have to split ftrace_regs into a ftrace_args_regs > and a ftrace_ret_regs which would make this refactoring even more > painful, just to skip a few instructions. :| > > I don't necessarily think it's worth it, I just wanted to make sure > this was considered. Ah, well, I just reached patch 22 and noticed that there you add add: + * Basically, ftrace_regs stores the registers related to the context. + * On function entry, registers for function parameters and hooking the + * function call are stored, and on function exit, registers for function + * return value and frame pointers are stored. So ftrace_regs can be a a sparse structure then. That's fair enough with me! ;)
[PATCH v2 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs
PSC controller has a limitation that it can only power-up the second
core when the first core is in ON state. Power-state for core0 should be
equal to or higher than core1.
Therefore, prevent core1 from powering up before core0 during the start
process from sysfs. Similarly, prevent core0 from shutting down before
core1 has been shut down from sysfs.
Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F
subsystem")
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 5a9bd5d4a2ea..b9d2a16af563 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -548,7 +548,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
struct device *dev = kproc->dev;
- struct k3_r5_core *core;
+ struct k3_r5_core *core0, *core;
u32 boot_addr;
int ret;
@@ -574,6 +574,15 @@ static int k3_r5_rproc_start(struct rproc *rproc)
goto unroll_core_run;
}
} else {
+ /* do not allow core 1 to start before core 0 */
+ core0 = list_first_entry(&cluster->cores, struct k3_r5_core,
+elem);
+ if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
+ dev_err(dev, "%s: can not start core 1 before core 0\n",
+ __func__);
+ return -EPERM;
+ }
+
ret = k3_r5_core_run(core);
if (ret)
goto put_mbox;
@@ -619,7 +628,8 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
{
struct k3_r5_rproc *kproc = rproc->priv;
struct k3_r5_cluster *cluster = kproc->cluster;
- struct k3_r5_core *core = kproc->core;
+ struct device *dev = kproc->dev;
+ struct k3_r5_core *core1, *core = kproc->core;
int ret;
/* halt all applicable cores */
@@ -632,6 +642,15 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
}
}
} else {
+ /* do not allow core 0 to stop before core 1 */
+ core1 = list_last_entry(&cluster->cores, struct k3_r5_core,
+ elem);
+ if (core != core1 && core1->rproc->state != RPROC_OFFLINE) {
+ dev_err(dev, "%s: can not stop core 0 before core 1\n",
+ __func__);
+ return -EPERM;
+ }
+
ret = k3_r5_core_halt(core);
if (ret)
goto out;
--
2.34.1
[PATCH v2 1/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1
From: Apurva Nandan
PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.
Make the powering up of cores sequential, by waiting for the current core
to power-up before proceeding to the next core, with a timeout of 2sec.
Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait
for the current core to be released from reset before proceeding with the
next core.
Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F
subsystem")
Signed-off-by: Apurva Nandan
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index ad3415a3851b..5a9bd5d4a2ea 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -103,12 +103,14 @@ struct k3_r5_soc_data {
* @dev: cached device pointer
* @mode: Mode to configure the Cluster - Split or LockStep
* @cores: list of R5 cores within the cluster
+ * @core_transition: wait queue to sync core state changes
* @soc_data: SoC-specific feature data for a R5FSS
*/
struct k3_r5_cluster {
struct device *dev;
enum cluster_mode mode;
struct list_head cores;
+ wait_queue_head_t core_transition;
const struct k3_r5_soc_data *soc_data;
};
@@ -128,6 +130,7 @@ struct k3_r5_cluster {
* @atcm_enable: flag to control ATCM enablement
* @btcm_enable: flag to control BTCM enablement
* @loczrama: flag to dictate which TCM is at device address 0x0
+ * @released_from_reset: flag to signal when core is out of reset
*/
struct k3_r5_core {
struct list_head elem;
@@ -144,6 +147,7 @@ struct k3_r5_core {
u32 atcm_enable;
u32 btcm_enable;
u32 loczrama;
+ bool released_from_reset;
};
/**
@@ -460,6 +464,8 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
ret);
return ret;
}
+ core->released_from_reset = true;
+ wake_up_interruptible(&cluster->core_transition);
/*
* Newer IP revisions like on J7200 SoCs support h/w auto-initialization
@@ -1140,6 +1146,7 @@ static int k3_r5_rproc_configure_mode(struct k3_r5_rproc
*kproc)
return ret;
}
+ core->released_from_reset = c_state;
ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl,
&stat);
if (ret < 0) {
@@ -1280,6 +1287,26 @@ static int k3_r5_cluster_rproc_init(struct
platform_device *pdev)
cluster->mode == CLUSTER_MODE_SINGLECPU ||
cluster->mode == CLUSTER_MODE_SINGLECORE)
break;
+
+ /*
+* R5 cores require to be powered on sequentially, core0
+* should be in higher power state than core1 in a cluster
+* So, wait for current core to power up before proceeding
+* to next core and put timeout of 2sec for each core.
+*
+* This waiting mechanism is necessary because
+* rproc_auto_boot_callback() for core1 can be called before
+* core0 due to thread execution order.
+*/
+ ret = wait_event_interruptible_timeout(cluster->core_transition,
+
core->released_from_reset,
+ msecs_to_jiffies(2000));
+ if (ret <= 0) {
+ dev_err(dev,
+ "Timed out waiting for %s core to power up!\n",
+ rproc->name);
+ return ret;
+ }
}
return 0;
@@ -1709,6 +1736,7 @@ static int k3_r5_probe(struct platform_device *pdev)
cluster->dev = dev;
cluster->soc_data = data;
INIT_LIST_HEAD(&cluster->cores);
+ init_waitqueue_head(&cluster->core_transition);
ret = of_property_read_u32(np, "ti,cluster-mode", &cluster->mode);
if (ret < 0 && ret != -EINVAL) {
--
2.34.1
[PATCH v2 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1
PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1, else the kernel is seen hanging during rproc loading. Make the powering up of cores sequential, by waiting for the current core to power-up before proceeding to the next core, with a timeout of 2sec. Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait for the current core to be released from reset before proceeding with the next core. Also, ensure that core1 can not be powered on before core0 when starting cores from sysfs. Similarly, ensure that core0 can not be shutdown before core1 from sysfs. v2: Changelog: 1) Fixed multi-line comment format 2) Included root cause of bug in comments 3) Added a patch to ensure power-up/shutdown is sequential via sysfs Link to v1: https://lore.kernel.org/all/20230906124756.3480579-1-a-nan...@ti.com/ Apurva Nandan (1): remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi (1): remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs drivers/remoteproc/ti_k3_r5_remoteproc.c | 51 +++- 1 file changed, 49 insertions(+), 2 deletions(-) -- 2.34.1
Re: [PATCH] drm/qxl: fix comment typo
On Wed, Apr 24, 2024 at 6:06 AM Xinghui Li wrote: > > There is one typo in drivers/gpu/drm/qxl/qxl_gem.c's comment, which > 'acess' should be 'access'. So fix it. > > Signed-off-by: Xinghui Li > --- > drivers/gpu/drm/qxl/qxl_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c > index fc5e3763c359..2cfe29d72d81 100644 > --- a/drivers/gpu/drm/qxl/qxl_gem.c > +++ b/drivers/gpu/drm/qxl/qxl_gem.c > @@ -74,7 +74,7 @@ int qxl_gem_object_create(struct qxl_device *qdev, int size, > > /* > * If the caller passed a valid gobj pointer, it is responsible to call > - * drm_gem_object_put() when it no longer needs to acess the object. > + * drm_gem_object_put() when it no longer needs to access the object. > * > * If gobj is NULL, it is handled internally. > */ > -- > 2.39.3 > Reviewed-by: Wander Lairson Costa
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Wed, Apr 24, 2024 at 02:16:06AM GMT, Andy Shevchenko wrote:
> On Wed, Apr 24, 2024 at 1:41 AM Aren Moynihan wrote:
> >
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
>
> ...
>
> > ret = stk3310_init(indio_dev);
> > if (ret < 0)
> > - return ret;
> > + goto err_vdd_disable;
>
> This is wrong. You will have the regulator being disabled _before_
> IRQ. Note, that the original code likely has a bug which sets states
> before disabling IRQ and removing a handler.
How so? stk3310_init is called before enabling the interrupt.
Original code has a bug that IRQ is enabled before registering the
IIO device, so if IRQ is triggered before registration, iio_push_event
from IRQ handler may be called on a not yet registered IIO device.
Never saw it happen, though. :)
kind regards,
o.
> Side note, you may make the driver neater with help of
>
> struct device *dev = &client->dev;
>
> defined in this patch.
>
> ...
>
> > static int stk3310_suspend(struct device *dev)
> > {
> > struct stk3310_data *data;
>
> > data = iio_priv(i2c_get_clientdata(to_i2c_client(dev)));
>
> Side note: This may be updated (in a separate change) to use
> dev_get_drvdata() directly.
>
> Jonathan, do we have something like iio_priv_from_drvdata(struct
> device *dev)? Seems many drivers may utilise it.
>
> > }
>
> ...
>
> > static int stk3310_resume(struct device *dev)
>
> Ditto.
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and power it off during suspend
Hi Aren,
kernel test robot noticed the following build warnings:
[auto build test WARNING on jic23-iio/togreg]
[also build test WARNING on sunxi/sunxi/for-next robh/for-next linus/master
v6.9-rc5 next-20240423]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Aren-Moynihan/dt-bindings-iio-light-stk33xx-add-vdd-and-leda-regulators/20240424-064250
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link:
https://lore.kernel.org/r/20240423223309.1468198-4-aren%40peacevolution.org
patch subject: [PATCH v2 2/6] iio: light: stk3310: Implement vdd supply and
power it off during suspend
config: arm64-randconfig-001-20240424
(https://download.01.org/0day-ci/archive/20240424/202404242057.pudy5rb1-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
5ef5eb66fb428aaf61fb51b709f065c069c11242)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240424/202404242057.pudy5rb1-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202404242057.pudy5rb1-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/iio/light/stk3310.c:10:
In file included from include/linux/i2c.h:19:
In file included from include/linux/regulator/consumer.h:35:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:21:
In file included from include/linux/mm.h:2208:
include/linux/vmstat.h:522:36: warning: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Wenum-enum-conversion]
522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
>> drivers/iio/light/stk3310.c:615:38: warning: variable 'ret' is uninitialized
>> when used here [-Wuninitialized]
615 | return dev_err_probe(&client->dev, ret, "get
regulator vdd failed\n");
|^~~
drivers/iio/light/stk3310.c:594:9: note: initialize the variable 'ret' to
silence this warning
594 | int ret;
|^
| = 0
2 warnings generated.
vim +/ret +615 drivers/iio/light/stk3310.c
591
592 static int stk3310_probe(struct i2c_client *client)
593 {
594 int ret;
595 struct iio_dev *indio_dev;
596 struct stk3310_data *data;
597
598 indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
599 if (!indio_dev) {
600 dev_err(&client->dev, "iio allocation failed!\n");
601 return -ENOMEM;
602 }
603
604 data = iio_priv(indio_dev);
605 data->client = client;
606 i2c_set_clientdata(client, indio_dev);
607
608 device_property_read_u32(&client->dev, "proximity-near-level",
609 &data->ps_near_level);
610
611 mutex_init(&data->lock);
612
613 data->vdd_reg = devm_regulator_get(&client->dev, "vdd");
614 if (IS_ERR(data->vdd_reg))
> 615 return dev_err_probe(&client->dev, ret, "get regulator
> vdd failed\n");
616
617 ret = stk3310_regmap_init(data);
618 if (ret < 0)
619 return ret;
620
621 indio_dev->info = &stk3310_info;
622 indio_dev->name = STK3310_DRIVER_NAME;
623 indio_dev->modes = INDIO_DIRECT_MODE;
624 indio_dev->channels = stk3310_channels;
625 indio_dev->num_channels = ARRAY_SIZE(stk3310_channels);
626
627 ret = regulator_enable(data->vdd_reg);
628 if (ret)
629 return dev_err_probe(&client->dev, ret,
630 "regulator vdd enable failed\n");
631
632 /* we need a short delay to allow the chip time to power on */
633 fsleep(1000);
634
635 ret = stk3310_init(indio_dev);
636 if (ret < 0)
637 goto err_vdd_disable;
638
639 if (client->irq > 0) {
Re: [PATCH v9 01/36] tracing: Add a comment about ftrace_regs definition
On Mon, Apr 15, 2024 at 2:49 PM Masami Hiramatsu (Google)
wrote:
>
> From: Masami Hiramatsu (Google)
>
> To clarify what will be expected on ftrace_regs, add a comment to the
> architecture independent definition of the ftrace_regs.
>
> Signed-off-by: Masami Hiramatsu (Google)
> Acked-by: Mark Rutland
> ---
> Changes in v8:
> - Update that the saved registers depends on the context.
> Changes in v3:
> - Add instruction pointer
> Changes in v2:
> - newly added.
> ---
> include/linux/ftrace.h | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 54d53f345d14..b81f1afa82a1 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -118,6 +118,32 @@ extern int ftrace_enabled;
>
> #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
>
> +/**
> + * ftrace_regs - ftrace partial/optimal register set
> + *
> + * ftrace_regs represents a group of registers which is used at the
> + * function entry and exit. There are three types of registers.
> + *
> + * - Registers for passing the parameters to callee, including the stack
> + * pointer. (e.g. rcx, rdx, rdi, rsi, r8, r9 and rsp on x86_64)
> + * - Registers for passing the return values to caller.
> + * (e.g. rax and rdx on x86_64)
Ooc, have we ever considered skipping argument registers that are not
return value registers in the exit code paths ? For example, why would
we want to save rdi in a return handler ?
But if we want to avoid the situation of having "sparse ftrace_regs"
all over again, we'd have to split ftrace_regs into a ftrace_args_regs
and a ftrace_ret_regs which would make this refactoring even more
painful, just to skip a few instructions. :|
I don't necessarily think it's worth it, I just wanted to make sure
this was considered.
> + * - Registers for hooking the function call and return including the
> + * frame pointer (the frame pointer is architecture/config dependent)
> + * (e.g. rip, rbp and rsp for x86_64)
> + *
> + * Also, architecture dependent fields can be used for internal process.
> + * (e.g. orig_ax on x86_64)
> + *
> + * On the function entry, those registers will be restored except for
> + * the stack pointer, so that user can change the function parameters
> + * and instruction pointer (e.g. live patching.)
> + * On the function exit, only registers which is used for return values
> + * are restored.
> + *
> + * NOTE: user *must not* access regs directly, only do it via APIs, because
> + * the member can be changed according to the architecture.
> + */
> struct ftrace_regs {
> struct pt_regs regs;
> };
>
Re: [RFC PATCH 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup
Hi Jarkko,
> On Apr 24, 2024, at 18:42, Jarkko Sakkinen wrote:
>
> On Wed Apr 24, 2024 at 10:02 AM EEST, Jarkko Sakkinen wrote:
>> On Wed Apr 24, 2024 at 9:46 AM EEST, Bojun Zhu wrote:
>>> Based on the the discussion among you, Jarkko and Reinette,
>>> I will keep the need_resched() and wrap the logic in using sgx_resched(),
>>> as suggested by Jarkko.
>>
>> Sounds like a plan :-)
>
> In sgx_ioc_enclave_add_pages() "if (!c)" check might cause possibly
> some confusion.
>
> Reason for it is that in "transaction sense" the operation can
> be only meaningfully restarted when no pages have not been added
> as MRENCLAVE checksum cannot be reset.
>
> BR, Jarkko
>
Thanks for your reminder.
According to the SGX hardware specification, similar to "ADD PAGES”,
the operations in "MODT PAGEs” and "REMOVE PAGEs(at runtime)”
can be only meaningfully restarted when no page has been handled.
For the following code in sgx_ioc_enclave_add_pages():
```c
if (signal_pending(current)) {
if (!c)
ret = -ERESTARTSYS;
break;
}
```
I still have some questions:
It seems that the variable "ret" is set to 0 if there is **some** EPC pages
have been
added when interrupted by signal(Supposed that sgx_encl_add_page()
always returns successfully).
Shall we set the return value as "-EINTR" if the context is interrupted by
signal when some EPC pages have been added?
(BTW, return values contain -EINTR as shown in
https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/cpu/sgx/ioctl.c#L402)
Please correct me if misunderstood it.
Regards,
Bojun
Re: [RFC PATCH 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup
On Wed Apr 24, 2024 at 10:02 AM EEST, Jarkko Sakkinen wrote: > On Wed Apr 24, 2024 at 9:46 AM EEST, Bojun Zhu wrote: > > Based on the the discussion among you, Jarkko and Reinette, > > I will keep the need_resched() and wrap the logic in using sgx_resched(), > > as suggested by Jarkko. > > Sounds like a plan :-) In sgx_ioc_enclave_add_pages() "if (!c)" check might cause possibly some confusion. Reason for it is that in "transaction sense" the operation can be only meaningfully restarted when no pages have not been added as MRENCLAVE checksum cannot be reset. BR, Jarkko
Re: [PATCH v3 4/4] media: mediatek: imgsys: Support image processing
Il 24/04/24 12:02, AngeloGioacchino Del Regno ha scritto:
Il 24/04/24 05:03, Olivia Wen ha scritto:
Integrate the imgsys core architecture driver for image processing on
the MT8188 platform.
Signed-off-by: Olivia Wen
This should be reordered before introducing the 8188 scp core 1 support commit,
but let's check with Mathieu before sending a v4.
With that reordered,
Reviewed-by: AngeloGioacchino Del Regno
Wait, no. Sorry. I just noticed that the commit message is totally wrong.
This is not a media commit, but remoteproc, and you're not adding support for
image processing with this commit - not in media at least.
Also, you're not adding any imgsys core architecture driver.
Please fix both commit description and title.
Regards,
Angelo
---
include/linux/remoteproc/mtk_scp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/remoteproc/mtk_scp.h
b/include/linux/remoteproc/mtk_scp.h
index 7c2b7cc9..344ff41 100644
--- a/include/linux/remoteproc/mtk_scp.h
+++ b/include/linux/remoteproc/mtk_scp.h
@@ -43,6 +43,7 @@ enum scp_ipi_id {
SCP_IPI_CROS_HOST_CMD,
SCP_IPI_VDEC_LAT,
SCP_IPI_VDEC_CORE,
+ SCP_IPI_IMGSYS_CMD,
SCP_IPI_NS_SERVICE = 0xFF,
SCP_IPI_MAX = 0x100,
};
Re: [PATCH v3 4/4] media: mediatek: imgsys: Support image processing
Il 24/04/24 05:03, Olivia Wen ha scritto:
Integrate the imgsys core architecture driver for image processing on
the MT8188 platform.
Signed-off-by: Olivia Wen
This should be reordered before introducing the 8188 scp core 1 support commit,
but let's check with Mathieu before sending a v4.
With that reordered,
Reviewed-by: AngeloGioacchino Del Regno
---
include/linux/remoteproc/mtk_scp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/remoteproc/mtk_scp.h
b/include/linux/remoteproc/mtk_scp.h
index 7c2b7cc9..344ff41 100644
--- a/include/linux/remoteproc/mtk_scp.h
+++ b/include/linux/remoteproc/mtk_scp.h
@@ -43,6 +43,7 @@ enum scp_ipi_id {
SCP_IPI_CROS_HOST_CMD,
SCP_IPI_VDEC_LAT,
SCP_IPI_VDEC_CORE,
+ SCP_IPI_IMGSYS_CMD,
SCP_IPI_NS_SERVICE = 0xFF,
SCP_IPI_MAX = 0x100,
};
Re: [PATCH v3 3/4] remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizes
Il 24/04/24 05:03, Olivia Wen ha scritto: The SCP on different chips will require different DRAM sizes and IPI shared buffer sizes based on varying requirements. Signed-off-by: Olivia Wen Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v3 2/4] remoteproc: mediatek: Support MT8188 SCP core 1
Il 24/04/24 05:03, Olivia Wen ha scritto: MT8188 SCP has two RISC-V cores which is similar to MT8195 but without L1TCM. We've added MT8188-specific functions to configure L1TCM in multicore setups. Signed-off-by: Olivia Wen Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v5 3/5] vduse: Add function to get/free the pages for reconnection
On Wed, Apr 24, 2024 at 08:44:10AM +0800, Jason Wang wrote:
> On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > > On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, Apr 18, 2024 at 08:57:51AM +0800, Jason Wang wrote:
> > > > > On Wed, Apr 17, 2024 at 5:29 PM Michael S. Tsirkin
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu wrote:
> > > > > > > Add the function vduse_alloc_reconnnect_info_mem
> > > > > > > and vduse_alloc_reconnnect_info_mem
> > > > > > > These functions allow vduse to allocate and free memory for
> > > > > > > reconnection
> > > > > > > information. The amount of memory allocated is vq_num pages.
> > > > > > > Each VQS will map its own page where the reconnection information
> > > > > > > will be saved
> > > > > > >
> > > > > > > Signed-off-by: Cindy Lu
> > > > > > > ---
> > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 40
> > > > > > > ++
> > > > > > > 1 file changed, 40 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > index ef3c9681941e..2da659d5f4a8 100644
> > > > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > > > @@ -65,6 +65,7 @@ struct vduse_virtqueue {
> > > > > > > int irq_effective_cpu;
> > > > > > > struct cpumask irq_affinity;
> > > > > > > struct kobject kobj;
> > > > > > > + unsigned long vdpa_reconnect_vaddr;
> > > > > > > };
> > > > > > >
> > > > > > > struct vduse_dev;
> > > > > > > @@ -1105,6 +1106,38 @@ static void
> > > > > > > vduse_vq_update_effective_cpu(struct vduse_virtqueue *vq)
> > > > > > >
> > > > > > > vq->irq_effective_cpu = curr_cpu;
> > > > > > > }
> > > > > > > +static int vduse_alloc_reconnnect_info_mem(struct vduse_dev *dev)
> > > > > > > +{
> > > > > > > + unsigned long vaddr = 0;
> > > > > > > + struct vduse_virtqueue *vq;
> > > > > > > +
> > > > > > > + for (int i = 0; i < dev->vq_num; i++) {
> > > > > > > + /*page 0~ vq_num save the reconnect info for vq*/
> > > > > > > + vq = dev->vqs[i];
> > > > > > > + vaddr = get_zeroed_page(GFP_KERNEL);
> > > > > >
> > > > > >
> > > > > > I don't get why you insist on stealing kernel memory for something
> > > > > > that is just used by userspace to store data for its own use.
> > > > > > Userspace does not lack ways to persist data, for example,
> > > > > > create a regular file anywhere in the filesystem.
> > > > >
> > > > > Good point. So the motivation here is to:
> > > > >
> > > > > 1) be self contained, no dependency for high speed persist data
> > > > > storage like tmpfs
> > > >
> > > > No idea what this means.
> > >
> > > I mean a regular file may slow down the datapath performance, so
> > > usually the application will try to use tmpfs and other which is a
> > > dependency for implementing the reconnection.
> >
> > Are we worried about systems without tmpfs now?
>
> Yes.
Why? Who ships these?
> >
> >
> > > >
> > > > > 2) standardize the format in uAPI which allows reconnection from
> > > > > arbitrary userspace, unfortunately, such effort was removed in new
> > > > > versions
> > > >
> > > > And I don't see why that has to live in the kernel tree either.
> > >
> > > I can't find a better place, any idea?
> > >
> > > Thanks
> >
> >
> > Well anywhere on github really. with libvhost-user maybe?
> > It's harmless enough in Documentation
> > if you like but ties you to the kernel release cycle in a way that
> > is completely unnecessary.
>
> Ok.
>
> Thanks
>
> >
> > > >
> > > > > If the above doesn't make sense, we don't need to offer those pages
> > > > > by VDUSE.
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > + if (vaddr == 0)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + vq->vdpa_reconnect_vaddr = vaddr;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int vduse_free_reconnnect_info_mem(struct vduse_dev *dev)
> > > > > > > +{
> > > > > > > + struct vduse_virtqueue *vq;
> > > > > > > +
> > > > > > > + for (int i = 0; i < dev->vq_num; i++) {
> > > > > > > + vq = dev->vqs[i];
> > > > > > > +
> > > > > > > + if (vq->vdpa_reconnect_vaddr)
> > > > > > > + free_page(vq->vdpa_reconnect_vaddr);
> > > > > > > + vq->vdpa_reconnect_vaddr = 0;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > >
> > > > > > > static long vduse_dev_ioctl(struct file *file, unsigned int cmd,
> > > > > > > unsigned long arg)
> > > > > > > @@ -1672,6 +1705,8 @@ static
[PATCH v7 5/6] soc: qcom: add pd-mapper implementation
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.
Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.
This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 10 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h| 14 +
drivers/soc/qcom/qcom_pd_mapper.c | 656 +
drivers/soc/qcom/qcom_pdr_msg.c| 34 ++
include/linux/soc/qcom/pd_mapper.h | 28 ++
6 files changed, 743 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 95973c6b828f..f666366841b8 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -72,6 +72,16 @@ config QCOM_OCMEM
requirements. This is typically used by the GPU, camera/video, and
audio components on some Snapdragon SoCs.
+config QCOM_PD_MAPPER
+ tristate "Qualcomm Protection Domain Mapper"
+ select QCOM_QMI_HELPERS
+ depends on NET && QRTR
+ help
+ The Protection Domain Mapper maps registered services to the domains
+ and instances handled by the remote DSPs. This is a kernel-space
+ implementation of the service. It is a simpler alternative to the
+ userspace daemon.
+
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 3110ac3288bc..d3560f861085 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
+obj-$(CONFIG_QCOM_PD_MAPPER) += qcom_pd_mapper.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 7e5bb5a95275..8d17f7fb79e7 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -13,6 +13,8 @@
#define SERVREG_SET_ACK_REQ0x23
#define SERVREG_RESTART_PD_REQ 0x24
+#define SERVREG_LOC_PFR_REQ0x24
+
#define SERVREG_DOMAIN_LIST_LENGTH 32
#define SERVREG_RESTART_PD_REQ_MAX_LEN 67
#define SERVREG_REGISTER_LISTENER_REQ_LEN 71
@@ -20,6 +22,7 @@
#define SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN74
#define SERVREG_STATE_UPDATED_IND_MAX_LEN 79
#define SERVREG_GET_DOMAIN_LIST_RESP_MAX_LEN 2389
+#define SERVREG_LOC_PFR_RESP_MAX_LEN 10
struct servreg_location_entry {
char name[SERVREG_NAME_LENGTH + 1];
@@ -79,6 +82,15 @@ struct servreg_set_ack_resp {
struct qmi_response_type_v01 resp;
};
+struct servreg_loc_pfr_req {
+ char service[SERVREG_NAME_LENGTH + 1];
+ char reason[257];
+};
+
+struct servreg_loc_pfr_resp {
+ struct qmi_response_type_v01 rsp;
+};
+
extern const struct qmi_elem_info servreg_location_entry_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_req_ei[];
extern const struct qmi_elem_info servreg_get_domain_list_resp_ei[];
@@ -89,5 +101,7 @@ extern const struct qmi_elem_info
servreg_restart_pd_resp_ei[];
extern const struct qmi_elem_info servreg_state_updated_ind_ei[];
extern const struct qmi_elem_info servreg_set_ack_req_ei[];
extern const struct qmi_elem_info servreg_set_ack_resp_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_req_ei[];
+extern const struct qmi_elem_info servreg_loc_pfr_resp_ei[];
#endif
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c
b/drivers/soc/qcom/qcom_pd_mapper.c
new file mode 100644
index ..ba5440506c95
--- /dev/null
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -0,0 +1,656 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm Protection Domain mapper
+ *
+ * Copyright (c) 2023 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pdr_internal.h"
+
+#define SERVREG_QMI_VERSION 0x101
+#define SERVREG_QMI_INSTANCE 0
+
+#define TMS_SERVREG_SERVICE "tms/servreg"
+
+struct qcom_pdm_domain_data {
+ const char *domain;
+ u32 instance_id;
+ /* NULL-terminated array */
+ const char * s
[PATCH v7 6/6] remoteproc: qcom: enable in-kernel PD mapper
Request in-kernel protection domain mapper to be started before starting
Qualcomm DSP and release it once DSP is stopped. Once all DSPs are
stopped, the PD mapper will be stopped too.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 4
drivers/remoteproc/qcom_q6v5_adsp.c | 11 ++-
drivers/remoteproc/qcom_q6v5_mss.c | 10 +-
drivers/remoteproc/qcom_q6v5_pas.c | 12 +++-
drivers/remoteproc/qcom_q6v5_wcss.c | 12 +++-
5 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa85..a0ce552f89a1 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -181,6 +181,7 @@ config QCOM_Q6V5_ADSP
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
+ depends on QCOM_PD_MAPPER || QCOM_PD_MAPPER=n
select MFD_SYSCON
select QCOM_PIL_INFO
select QCOM_MDT_LOADER
@@ -201,6 +202,7 @@ config QCOM_Q6V5_MSS
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
+ depends on QCOM_PD_MAPPER || QCOM_PD_MAPPER=n
select MFD_SYSCON
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
@@ -221,6 +223,7 @@ config QCOM_Q6V5_PAS
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
+ depends on QCOM_PD_MAPPER || QCOM_PD_MAPPER=n
select MFD_SYSCON
select QCOM_PIL_INFO
select QCOM_MDT_LOADER
@@ -243,6 +246,7 @@ config QCOM_Q6V5_WCSS
depends on QCOM_SYSMON || QCOM_SYSMON=n
depends on RPMSG_QCOM_GLINK || RPMSG_QCOM_GLINK=n
depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
+ depends on QCOM_PD_MAPPER || QCOM_PD_MAPPER=n
select MFD_SYSCON
select QCOM_MDT_LOADER
select QCOM_PIL_INFO
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 1d24c9b656a8..02d0c626b03b 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -375,10 +376,14 @@ static int adsp_start(struct rproc *rproc)
int ret;
unsigned int val;
- ret = qcom_q6v5_prepare(&adsp->q6v5);
+ ret = qcom_pdm_get();
if (ret)
return ret;
+ ret = qcom_q6v5_prepare(&adsp->q6v5);
+ if (ret)
+ goto put_pdm;
+
ret = adsp_map_carveout(rproc);
if (ret) {
dev_err(adsp->dev, "ADSP smmu mapping failed\n");
@@ -446,6 +451,8 @@ static int adsp_start(struct rproc *rproc)
adsp_unmap_carveout(rproc);
disable_irqs:
qcom_q6v5_unprepare(&adsp->q6v5);
+put_pdm:
+ qcom_pdm_release();
return ret;
}
@@ -478,6 +485,8 @@ static int adsp_stop(struct rproc *rproc)
if (handover)
qcom_adsp_pil_handover(&adsp->q6v5);
+ qcom_pdm_release();
+
return ret;
}
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 1779fc890e10..791f11e7adbf 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1581,10 +1582,14 @@ static int q6v5_start(struct rproc *rproc)
int xfermemop_ret;
int ret;
- ret = q6v5_mba_load(qproc);
+ ret = qcom_pdm_get();
if (ret)
return ret;
+ ret = q6v5_mba_load(qproc);
+ if (ret)
+ goto put_pdm;
+
dev_info(qproc->dev, "MBA booted with%s debug policy, loading mpss\n",
qproc->dp_size ? "" : "out");
@@ -1613,6 +1618,8 @@ static int q6v5_start(struct rproc *rproc)
reclaim_mpss:
q6v5_mba_reclaim(qproc);
q6v5_dump_mba_logs(qproc);
+put_pdm:
+ qcom_pdm_release();
return ret;
}
@@ -1627,6 +1634,7 @@ static int q6v5_stop(struct rproc *rproc)
dev_err(qproc->dev, "timed out on wait\n");
q6v5_mba_reclaim(qproc);
+ qcom_pdm_release();
return 0;
}
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 54d8005d40a3..653e54f975fc 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -261,10 +262,14 @@ static int adsp_start(struct rproc *rproc)
struct qcom_adsp *adsp = rproc->priv;
int ret;
- ret = qcom_q6v5_prepare(&adsp->q6v5);
+ ret = qcom_pdm_get();
if (ret)
return ret;
+ ret = qcom_q6v5_prepare(&adsp->q6v5);
+ if (ret)
[PATCH v7 4/6] soc: qcom: qmi: add a way to remove running service
Add qmi_del_server(), a pair to qmi_add_server(), a way to remove
running server from the QMI socket. This is e.g. necessary for
pd-mapper, which needs to readd a server each time the DSP is started or
stopped.
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/qmi_interface.c | 67
include/linux/soc/qcom/qmi.h | 2 ++
2 files changed, 69 insertions(+)
diff --git a/drivers/soc/qcom/qmi_interface.c b/drivers/soc/qcom/qmi_interface.c
index bb98b06e87f8..18ff2015c682 100644
--- a/drivers/soc/qcom/qmi_interface.c
+++ b/drivers/soc/qcom/qmi_interface.c
@@ -289,6 +289,73 @@ int qmi_add_server(struct qmi_handle *qmi, unsigned int
service,
}
EXPORT_SYMBOL_GPL(qmi_add_server);
+static void qmi_send_del_server(struct qmi_handle *qmi, struct qmi_service
*svc)
+{
+ struct qrtr_ctrl_pkt pkt;
+ struct sockaddr_qrtr sq;
+ struct msghdr msg = { };
+ struct kvec iv = { &pkt, sizeof(pkt) };
+ int ret;
+
+ memset(&pkt, 0, sizeof(pkt));
+ pkt.cmd = cpu_to_le32(QRTR_TYPE_DEL_SERVER);
+ pkt.server.service = cpu_to_le32(svc->service);
+ pkt.server.instance = cpu_to_le32(svc->version | svc->instance << 8);
+ pkt.server.node = cpu_to_le32(qmi->sq.sq_node);
+ pkt.server.port = cpu_to_le32(qmi->sq.sq_port);
+
+ sq.sq_family = qmi->sq.sq_family;
+ sq.sq_node = qmi->sq.sq_node;
+ sq.sq_port = QRTR_PORT_CTRL;
+
+ msg.msg_name = &sq;
+ msg.msg_namelen = sizeof(sq);
+
+ mutex_lock(&qmi->sock_lock);
+ if (qmi->sock) {
+ ret = kernel_sendmsg(qmi->sock, &msg, &iv, 1, sizeof(pkt));
+ if (ret < 0)
+ pr_err("send service deregistration failed: %d\n", ret);
+ }
+ mutex_unlock(&qmi->sock_lock);
+}
+
+/**
+ * qmi_del_server() - register a service with the name service
+ * @qmi: qmi handle
+ * @service: type of the service
+ * @instance: instance of the service
+ * @version: version of the service
+ *
+ * Remove registration of the service with the name service. This notifies
+ * clients that they should no longer send messages to the client associated
+ * with @qmi.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+int qmi_del_server(struct qmi_handle *qmi, unsigned int service,
+ unsigned int version, unsigned int instance)
+{
+ struct qmi_service *svc;
+ struct qmi_service *tmp;
+
+ list_for_each_entry_safe(svc, tmp, &qmi->services, list_node) {
+ if (svc->service != service ||
+ svc->version != version ||
+ svc->instance != instance)
+ continue;
+
+ qmi_send_del_server(qmi, svc);
+ list_del(&svc->list_node);
+ kfree(svc);
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(qmi_del_server);
+
/**
* qmi_txn_init() - allocate transaction id within the given QMI handle
* @qmi: QMI handle
diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
index 469e02d2aa0d..5039c30e4bdc 100644
--- a/include/linux/soc/qcom/qmi.h
+++ b/include/linux/soc/qcom/qmi.h
@@ -241,6 +241,8 @@ int qmi_add_lookup(struct qmi_handle *qmi, unsigned int
service,
unsigned int version, unsigned int instance);
int qmi_add_server(struct qmi_handle *qmi, unsigned int service,
unsigned int version, unsigned int instance);
+int qmi_del_server(struct qmi_handle *qmi, unsigned int service,
+ unsigned int version, unsigned int instance);
int qmi_handle_init(struct qmi_handle *qmi, size_t max_msg_len,
const struct qmi_ops *ops,
--
2.39.2
[PATCH v7 3/6] soc: qcom: pdr: extract PDR message marshalling data
The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
module that can be used by both PDR helpers and by PD mapper.
Reviewed-by: Bryan O'Donoghue
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig| 4 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/pdr_internal.h | 306 ++
drivers/soc/qcom/qcom_pdr_msg.c | 319
4 files changed, 334 insertions(+), 296 deletions(-)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5af33b0e3470..95973c6b828f 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,8 +75,12 @@ config QCOM_OCMEM
config QCOM_PDR_HELPERS
tristate
select QCOM_QMI_HELPERS
+ select QCOM_PDR_MSG
depends on NET
+config QCOM_PDR_MSG
+ tristate
+
config QCOM_PMIC_PDCHARGER_ULOG
tristate "Qualcomm PMIC PDCharger ULOG driver"
depends on RPMSG
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ca0bece0dfff..3110ac3288bc 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
+obj-$(CONFIG_QCOM_PDR_MSG) += qcom_pdr_msg.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink_altmode.o
obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG) += pmic_pdcharger_ulog.o
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 03c282b7f17e..7e5bb5a95275 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -28,83 +28,12 @@ struct servreg_location_entry {
u32 instance;
};
-static const struct qmi_elem_info servreg_location_entry_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- name),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- instance),
- },
- {
- .data_type = QMI_UNSIGNED_1_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0,
- .offset = offsetof(struct servreg_location_entry,
- service_data),
- },
- {}
-};
-
struct servreg_get_domain_list_req {
char service_name[SERVREG_NAME_LENGTH + 1];
u8 domain_offset_valid;
u32 domain_offset;
};
-static const struct qmi_elem_info servreg_get_domain_list_req_ei[] = {
- {
- .data_type = QMI_STRING,
- .elem_len = SERVREG_NAME_LENGTH + 1,
- .elem_size = sizeof(char),
- .array_type = NO_ARRAY,
- .tlv_type = 0x01,
- .offset = offsetof(struct servreg_get_domain_list_req,
- service_name),
- },
- {
- .data_type = QMI_OPT_FLAG,
- .elem_len = 1,
- .elem_size = sizeof(u8),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
- domain_offset_valid),
- },
- {
- .data_type = QMI_UNSIGNED_4_BYTE,
- .elem_len = 1,
- .elem_size = sizeof(u32),
- .array_type = NO_ARRAY,
- .tlv_type = 0x10,
- .offset = offsetof(struct servreg_get_domain_list_req,
- domain_offset),
- },
- {}
-};
-
struct servreg_get_domain_list_resp {
struct qmi_response_type_v01 resp;
u8 tota
[PATCH v7 2/6] soc: qcom: pdr: fix parsing of domains lists
While parsing the domains list, start offsets from 0 rather than from
domains_read. The domains_read is equal to the total count of the
domains we have seen, while the domains list in the message starts from
offset 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index 19cfe4b41235..3c6f2d21e5e4 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -415,7 +415,7 @@ static int pdr_locate_service(struct pdr_handle *pdr,
struct pdr_service *pds)
if (ret < 0)
goto out;
- for (i = domains_read; i < resp->domain_list_len; i++) {
+ for (i = 0; i < resp->domain_list_len; i++) {
entry = &resp->domain_list[i];
if (strnlen(entry->name, sizeof(entry->name)) ==
sizeof(entry->name))
--
2.39.2
[PATCH v7 0/6] soc: qcom: add in-kernel pd-mapper implementation
Protection domain mapper is a QMI service providing mapping between 'protection domains' and services supported / allowed in these domains. For example such mapping is required for loading of the WiFi firmware or for properly starting up the UCSI / altmode / battery manager support. The existing userspace implementation has several issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't reread the JSON files if the firmware location is changed (or if the firmware was not available at the time pd-mapper was started but the corresponding directory is mounted later), etc. However this configuration is largely static and common between different platforms. Provide in-kernel service implementing static per-platform data. Unlike previous revisions of the patchset, this iteration uses static configuration per platform, rather than building it dynamically from the list of DSPs being started. To: Bjorn Andersson To: Konrad Dybcio To: Sibi Sankar To: Mathieu Poirier Cc: linux-arm-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: Johan Hovold Cc: Xilin Wu Cc: "Bryan O'Donoghue" -- Changes in v7: - Fixed modular build (Steev) - Link to v6: https://lore.kernel.org/r/20240422-qcom-pd-mapper-v6-0-f96957d01...@linaro.org Changes in v6: - Reworked mutex to fix lockdep issue on deregistration - Fixed dependencies between PD-mapper and remoteproc to fix modular builds (Krzysztof) - Added EXPORT_SYMBOL_GPL to fix modular builds (Krzysztof) - Fixed kerneldocs (Krzysztof) - Removed extra pr_debug messages (Krzysztof) - Fixed wcss build (Krzysztof) - Added platforms which do not require protection domain mapping to silence the notice on those platforms - Link to v5: https://lore.kernel.org/r/20240419-qcom-pd-mapper-v5-0-e35b6f847...@linaro.org Changes in v5: - pdr: drop lock in pdr_register_listener, list_lock is already held (Chris Lew) - pd_mapper: reworked to provide static configuration per platform (Bjorn) - Link to v4: https://lore.kernel.org/r/20240311-qcom-pd-mapper-v4-0-24679cca5...@linaro.org Changes in v4: - Fixed missing chunk, reenabled kfree in qmi_del_server (Konrad) - Added configuration for sm6350 (Thanks to Luca) - Removed RFC tag (Konrad) - Link to v3: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-0-6858fa1ac...@linaro.org Changes in RFC v3: - Send start / stop notifications when PD-mapper domain list is changed - Reworked the way PD-mapper treats protection domains, register all of them in a single batch - Added SC7180 domains configuration based on TCL Book 14 GO - Link to v2: https://lore.kernel.org/r/20240301-qcom-pd-mapper-v2-0-5d12a081d...@linaro.org Changes in RFC v2: - Swapped num_domains / domains (Konrad) - Fixed an issue with battery not working on sc8280xp - Added missing configuration for QCS404 --- Dmitry Baryshkov (6): soc: qcom: pdr: protect locator_addr with the main mutex soc: qcom: pdr: fix parsing of domains lists soc: qcom: pdr: extract PDR message marshalling data soc: qcom: qmi: add a way to remove running service soc: qcom: add pd-mapper implementation remoteproc: qcom: enable in-kernel PD mapper drivers/remoteproc/Kconfig | 4 + drivers/remoteproc/qcom_q6v5_adsp.c | 11 +- drivers/remoteproc/qcom_q6v5_mss.c | 10 +- drivers/remoteproc/qcom_q6v5_pas.c | 12 +- drivers/remoteproc/qcom_q6v5_wcss.c | 12 +- drivers/soc/qcom/Kconfig| 14 + drivers/soc/qcom/Makefile | 2 + drivers/soc/qcom/pdr_interface.c| 6 +- drivers/soc/qcom/pdr_internal.h | 318 ++--- drivers/soc/qcom/qcom_pd_mapper.c | 656 drivers/soc/qcom/qcom_pdr_msg.c | 353 +++ drivers/soc/qcom/qmi_interface.c| 67 include/linux/soc/qcom/pd_mapper.h | 28 ++ include/linux/soc/qcom/qmi.h| 2 + 14 files changed, 1193 insertions(+), 302 deletions(-) --- base-commit: a59668a9397e7245b26e9be85d23f242ff757ae8 change-id: 20240301-qcom-pd-mapper-e12d622d4ad0 Best regards, -- Dmitry Baryshkov
[PATCH v7 1/6] soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Tested-by: Neil Armstrong # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/pdr_interface.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index a1b6a4081dea..19cfe4b41235 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle *qmi,
locator_hdl);
struct pdr_service *pds;
+ mutex_lock(&pdr->lock);
/* Create a local client port for QMI communication */
pdr->locator_addr.sq_family = AF_QIPCRTR;
pdr->locator_addr.sq_node = svc->node;
pdr->locator_addr.sq_port = svc->port;
- mutex_lock(&pdr->lock);
pdr->locator_init_complete = true;
mutex_unlock(&pdr->lock);
@@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle *qmi,
mutex_lock(&pdr->lock);
pdr->locator_init_complete = false;
- mutex_unlock(&pdr->lock);
pdr->locator_addr.sq_node = 0;
pdr->locator_addr.sq_port = 0;
+ mutex_unlock(&pdr->lock);
}
static const struct qmi_ops pdr_locator_ops = {
--
2.39.2
Re: [PATCH] ftrace: riscv: move from REGS to ARGS
Puranjay Mohan writes: > This commit replaces riscv's support for FTRACE_WITH_REGS with support > for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop > relying on stop_machine() for RISCV's implementation of ftrace. > > The main relevant benefit that this change will bring for the above > use-case is that now we don't have separate ftrace_caller and > ftrace_regs_caller trampolines. This will allow the callsite to call > ftrace_caller by modifying a single instruction. Now the callsite can > do something similar to: > > When not tracing:| When tracing: > > func: func: > auipc t0, ftrace_caller_topauipc t0, ftrace_caller_top > nop <==> jalr t0, ftrace_caller_bottom > [...] [...] > > The above assumes that we are dropping the support of calling a direct > trampoline from the callsite. We need to drop this as the callsite can't > change the target address to call, it can only enable/disable a call to > a preset target (ftrace_caller in the above diagram). We can later optimize > this by calling an intermediate dispatcher trampoline before ftrace_caller. > > Currently, ftrace_regs_caller saves all CPU registers in the format of > struct pt_regs and allows the tracer to modify them. We don't need to > save all of the CPU registers because at function entry only a subset of > pt_regs is live: > > |--+--+-| > | Register | ABI Name | Description | > |--+--+-| > | x1 | ra | Return address for traced function | > | x2 | sp | Stack pointer | > | x5 | t0 | Return address for ftrace_caller trampoline | > | x8 | s0/fp| Frame pointer | > | x10-11 | a0-1 | Function arguments/return values| > | x12-17 | a2-7 | Function arguments | > |--+--+-| > > See RISCV calling convention[1] for the above table. > > Saving just the live registers decreases the amount of stack space > required from 288 Bytes to 112 Bytes. > > Basic testing was done with this on the VisionFive 2 development board. > > Note: > - Moving from REGS to ARGS will mean that RISCV will stop supporting > KPROBES_ON_FTRACE as it requires full pt_regs to be saved. > - KPROBES_ON_FTRACE will be supplanted by FPROBES see [2]. Puranjay, Apologies for the slow response. Restating from the RFC; This change is a prerequisite for moving towards a "FTRACE_WITH_CALL_OPS" model on riscv, and finally getting rid of the stop_machine() text patching. I've tested this on QEMU, and on the VisionFive2. No regressions (FTRACE_STARTUP_*, and kselftest), other than that KPROBES_ON_FTRACE no longer works. (Which will be addressed by [2]). Palmer, my preference is that this should go on for-next, rather than being part of the upcoming text patching support (worked on by Andy), but really up to you. Tested-by: Björn Töpel Reviewed-by: Björn Töpel
[PATCH] drm/qxl: fix comment typo
There is one typo in drivers/gpu/drm/qxl/qxl_gem.c's comment, which 'acess' should be 'access'. So fix it. Signed-off-by: Xinghui Li --- drivers/gpu/drm/qxl/qxl_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c index fc5e3763c359..2cfe29d72d81 100644 --- a/drivers/gpu/drm/qxl/qxl_gem.c +++ b/drivers/gpu/drm/qxl/qxl_gem.c @@ -74,7 +74,7 @@ int qxl_gem_object_create(struct qxl_device *qdev, int size, /* * If the caller passed a valid gobj pointer, it is responsible to call - * drm_gem_object_put() when it no longer needs to acess the object. + * drm_gem_object_put() when it no longer needs to access the object. * * If gobj is NULL, it is handled internally. */ -- 2.39.3
Re: [RFC PATCH 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup
On Wed Apr 24, 2024 at 9:46 AM EEST, Bojun Zhu wrote: > Based on the the discussion among you, Jarkko and Reinette, > I will keep the need_resched() and wrap the logic in using sgx_resched(), > as suggested by Jarkko. Sounds like a plan :-) > Regards, > > Bojun BR, Jarkko
