* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 10:10 UTC (permalink / raw)
To: Yu-chang Lee (李禹璋),
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <f25b4d913a584d753888e7a3c32502eae1f7fbf0.camel@mediatek.com>
On 27/03/2024 11:01, Yu-chang Lee (李禹璋) wrote:
> On Wed, 2024-03-27 at 09:39 +0100, Krzysztof Kozlowski wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> On 27/03/2024 06:57, yu-chang.lee wrote:
>>> Add Smart Multimedia Interface Local Arbiter to mediatek
>>> power domain.
>>>
>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
>>> ---
>>> .../devicetree/bindings/power/mediatek,power-controller.yaml | 4
>> ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git
>> a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>> b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> index 8985e2df8a56..228c0dec5253 100644
>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> @@ -125,6 +125,10 @@ $defs:
>>> $ref: /schemas/types.yaml#/definitions/phandle
>>> description: phandle to the device containing the SMI
>> register range.
>>>
>>> + mediatek,larb:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: phandle to the device containing the LARB
>> register range.
>>
>> Why do you need it?
>>
>> Plus I also see mediatek,larbs and mediatek,larb-id... so now we have
>> third one similar.
>>
> MM driver used "mediatek,larbs" for it larb node.
> Power domain driver used "mediatek,larb".
> "mediatek,larb-id" is for larb in dts.
>
> The naming is no related to each other.
Then it is just confusing.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 0/3] Speed up boot with faster linear map creation
From: Ard Biesheuvel @ 2024-03-27 10:09 UTC (permalink / raw)
To: Ryan Roberts
Cc: Catalin Marinas, Will Deacon, Mark Rutland, David Hildenbrand,
Donald Dutile, Eric Chanudet, linux-arm-kernel, linux-kernel
In-Reply-To: <20240326101448.3453626-1-ryan.roberts@arm.com>
Hi Ryan,
On Tue, 26 Mar 2024 at 12:15, Ryan Roberts <ryan.roberts@arm.com> wrote:
>
> Hi All,
>
> It turns out that creating the linear map can take a significant proportion of
> the total boot time, especially when rodata=full. And a large portion of the
> time it takes to create the linear map is issuing TLBIs. This series reworks the
> kernel pgtable generation code to significantly reduce the number of TLBIs. See
> each patch for details.
>
> The below shows the execution time of map_mem() across a couple of different
> systems with different RAM configurations. We measure after applying each patch
> and show the improvement relative to base (v6.9-rc1):
>
> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G
> ---------------|-------------|-------------|-------------|-------------
> | ms (%) | ms (%) | ms (%) | ms (%)
> ---------------|-------------|-------------|-------------|-------------
> base | 151 (0%) | 2191 (0%) | 8990 (0%) | 17443 (0%)
> no-cont-remap | 77 (-49%) | 429 (-80%) | 1753 (-80%) | 3796 (-78%)
> no-alloc-remap | 77 (-49%) | 375 (-83%) | 1532 (-83%) | 3366 (-81%)
> lazy-unmap | 63 (-58%) | 330 (-85%) | 1312 (-85%) | 2929 (-83%)
>
> This series applies on top of v6.9-rc1. All mm selftests pass. I haven't yet
> tested all VA size configs (although I don't anticipate any issues); I'll do
> this as part of followup.
>
These are very nice results!
Before digging into the details: do we still have a strong case for
supporting contiguous PTEs and PMDs in these routines?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 10:01 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <6dd9959e-f741-47af-b10a-1894f72ae78f@linaro.org>
On Wed, 2024-03-27 at 09:39 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 06:57, yu-chang.lee wrote:
> > Add Smart Multimedia Interface Local Arbiter to mediatek
> > power domain.
> >
> > Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
> > ---
> > .../devicetree/bindings/power/mediatek,power-controller.yaml | 4
> ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git
> a/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> b/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> > index 8985e2df8a56..228c0dec5253 100644
> > --- a/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> > +++ b/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> > @@ -125,6 +125,10 @@ $defs:
> > $ref: /schemas/types.yaml#/definitions/phandle
> > description: phandle to the device containing the SMI
> register range.
> >
> > + mediatek,larb:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: phandle to the device containing the LARB
> register range.
>
> Why do you need it?
>
> Plus I also see mediatek,larbs and mediatek,larb-id... so now we have
> third one similar.
>
MM driver used "mediatek,larbs" for it larb node.
Power domain driver used "mediatek,larb".
"mediatek,larb-id" is for larb in dts.
The naming is no related to each other.
Best Regards,
Yu-chang.
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 9:59 UTC (permalink / raw)
To: Yu-chang Lee (李禹璋),
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <f3eedfb3495bb9c28b5cbf466387c24822c5b6f6.camel@mediatek.com>
On 27/03/2024 10:34, Yu-chang Lee (李禹璋) wrote:
> On Wed, 2024-03-27 at 10:23 +0100, Krzysztof Kozlowski wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> On 27/03/2024 09:39, Krzysztof Kozlowski wrote:
>>> On 27/03/2024 06:57, yu-chang.lee wrote:
>>>> Add Smart Multimedia Interface Local Arbiter to mediatek
>>>> power domain.
>>>>
>>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
>>>> ---
>>>> .../devicetree/bindings/power/mediatek,power-controller.yaml | 4
>> ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git
>> a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>> b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>>> index 8985e2df8a56..228c0dec5253 100644
>>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>>> @@ -125,6 +125,10 @@ $defs:
>>>> $ref: /schemas/types.yaml#/definitions/phandle
>>>> description: phandle to the device containing the SMI
>> register range.
>>>>
>>>> + mediatek,larb:
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> + description: phandle to the device containing the LARB
>> register range.
>>>
>>> Why do you need it?
>>>
>>> Plus I also see mediatek,larbs and mediatek,larb-id... so now we
>> have
>>> third one similar.
>>
>> ... and not even tested!
>>
>> Best regards,
>> Krzysztof
>>
> Hi,
>
> I will double check the format of yaml for the next version, sorry for
> inconvenience. But I did test it on mt8188 chromebook, the reason why
How do you test a binding on chromebook?
> power domain need larb node is that when mtcmos power on, signal glitch
> may produce. Power domain driver must reset larb when this happen to
> prevent dummy transaction on bus. That why I need larb node in dts.
No one talks here about larb node...
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64
From: Ryan Roberts @ 2024-03-27 10:01 UTC (permalink / raw)
To: David Hildenbrand, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <35236bbf-3d9a-40e9-84b5-e10e10295c0c@redhat.com>
On 27/03/2024 09:34, David Hildenbrand wrote:
> On 26.03.24 18:51, Ryan Roberts wrote:
>> On 26/03/2024 17:39, David Hildenbrand wrote:
>>> On 26.03.24 18:32, Ryan Roberts wrote:
>>>> On 26/03/2024 17:04, David Hildenbrand wrote:
>>>>>>>>>
>>>>>>>>> Likely, we just want to read "the real deal" on both sides of the
>>>>>>>>> pte_same()
>>>>>>>>> handling.
>>>>>>>>
>>>>>>>> Sorry I'm not sure I understand? You mean read the full pte including
>>>>>>>> access/dirty? That's the same as dropping the patch, right? Of course if
>>>>>>>> we do
>>>>>>>> that, we still have to keep pte_get_lockless() around for this case. In an
>>>>>>>> ideal
>>>>>>>> world we would convert everything over to ptep_get_lockless_norecency() and
>>>>>>>> delete ptep_get_lockless() to remove the ugliness from arm64.
>>>>>>>
>>>>>>> Yes, agreed. Patch #3 does not look too crazy and it wouldn't really affect
>>>>>>> any
>>>>>>> architecture.
>>>>>>>
>>>>>>> I do wonder if pte_same_norecency() should be defined per architecture
>>>>>>> and the
>>>>>>> default would be pte_same(). So we could avoid the mkold etc on all other
>>>>>>> architectures.
>>>>>>
>>>>>> Wouldn't that break it's semantics? The "norecency" of
>>>>>> ptep_get_lockless_norecency() means "recency information in the returned pte
>>>>>> may
>>>>>> be incorrect". But the "norecency" of pte_same_norecency() means "ignore the
>>>>>> access and dirty bits when you do the comparison".
>>>>>
>>>>> My idea was that ptep_get_lockless_norecency() would return the actual
>>>>> result on
>>>>> these architectures. So e.g., on x86, there would be no actual change in
>>>>> generated code.
>>>>
>>>> I think this is a bad plan... You'll end up with subtle differences between
>>>> architectures.
>>>>
>>>>>
>>>>> But yes, the documentation of these functions would have to be improved.
>>>>>
>>>>> Now I wonder if ptep_get_lockless_norecency() should actively clear
>>>>> dirty/accessed bits to more easily find any actual issues where the bits still
>>>>> matter ...
>>>>
>>>> I did a version that took that approach. Decided it was not as good as this way
>>>> though. Now for the life of me, I can't remember my reasoning.
>>>
>>> Maybe because there are some code paths that check accessed/dirty without
>>> "correctness" implications? For example, if the PTE is already dirty, no need to
>>> set it dirty etc?
>>
>> I think I decided I was penalizing the architectures that don't care because all
>> their ptep_get_norecency() and ptep_get_lockless_norecency() need to explicitly
>> clear access/dirty. And I would have needed ptep_get_norecency() from day 1 so
>> that I could feed its result into pte_same().
>
> True. With ptep_get_norecency() you're also penalizing other architectures.
> Therefore my original thought about making the behavior arch-specific, but the
> arch has to make sure to get the combination of
> ptep_get_lockless_norecency()+ptep_same_norecency() is right.
>
> So if an arch decide to ignore bits in ptep_get_lockless_norecency(), it must
> make sure to also ignore them in ptep_same_norecency(), and must be able to
> handle access/dirty bit changes differently.
>
> Maybe one could have one variant for "hw-managed access/dirty" vs. "sw managed
> accessed or dirty". Only the former would end up ignoring stuff here, the latter
> would not.
>
> But again, just some random thoughts how this affects other architectures and
> how we could avoid it. The issue I describe in patch #3 would be gone if
> ptep_same_norecency() would just do a ptep_same() check on other architectures
> -- and would make it easier to sell :)
Perhaps - let me chew on that for a bit. It doesn't feel as easy as you suggest
to me. But I can't put my finger on why...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] dmaengine: xilinx: xdma: Fix synchronization issue
From: Louis Chauvet @ 2024-03-27 9:58 UTC (permalink / raw)
To: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Vinod Koul, Michal Simek,
Jan Kuliga, Miquel Raynal
Cc: dmaengine, linux-arm-kernel, linux-kernel, stable, Louis Chauvet
In-Reply-To: <20240327-digigram-xdma-fixes-v1-0-45f4a52c0283@bootlin.com>
The current xdma_synchronize method does not properly wait for the last
transfer to be done. Due to limitations of the XMDA engine, it is not
possible to stop a transfer in the middle of a descriptor. Said
otherwise, if a stop is requested at the end of descriptor "N" and the OS
is fast enough, the DMA controller will effectively stop immediately.
However, if the OS is slightly too slow to request the stop and the DMA
engine starts descriptor "N+1", the N+1 transfer will be performed until
its end. This means that after a terminate_all, the last descriptor must
remain valid and the synchronization must wait for this last descriptor to
be terminated.
Fixes: 855c2e1d1842 ("dmaengine: xilinx: xdma: Rework xdma_terminate_all()")
Fixes: f5c392d106e7 ("dmaengine: xilinx: xdma: Add terminate_all/synchronize callbacks")
Cc: stable@vger.kernel.org
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
drivers/dma/xilinx/xdma-regs.h | 3 +++
drivers/dma/xilinx/xdma.c | 26 ++++++++++++++++++--------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/xilinx/xdma-regs.h b/drivers/dma/xilinx/xdma-regs.h
index 98f5f6fb9ff9..6ad08878e938 100644
--- a/drivers/dma/xilinx/xdma-regs.h
+++ b/drivers/dma/xilinx/xdma-regs.h
@@ -117,6 +117,9 @@ struct xdma_hw_desc {
CHAN_CTRL_IE_WRITE_ERROR | \
CHAN_CTRL_IE_DESC_ERROR)
+/* bits of the channel status register */
+#define XDMA_CHAN_STATUS_BUSY BIT(0)
+
#define XDMA_CHAN_STATUS_MASK CHAN_CTRL_START
#define XDMA_CHAN_ERROR_MASK (CHAN_CTRL_IE_DESC_ALIGN_MISMATCH | \
diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c
index b9788aa8f6b7..5a3a3293b21b 100644
--- a/drivers/dma/xilinx/xdma.c
+++ b/drivers/dma/xilinx/xdma.c
@@ -71,6 +71,8 @@ struct xdma_chan {
enum dma_transfer_direction dir;
struct dma_slave_config cfg;
u32 irq;
+ struct completion last_interrupt;
+ bool stop_requested;
};
/**
@@ -376,6 +378,8 @@ static int xdma_xfer_start(struct xdma_chan *xchan)
return ret;
xchan->busy = true;
+ xchan->stop_requested = false;
+ reinit_completion(&xchan->last_interrupt);
return 0;
}
@@ -387,7 +391,6 @@ static int xdma_xfer_start(struct xdma_chan *xchan)
static int xdma_xfer_stop(struct xdma_chan *xchan)
{
int ret;
- u32 val;
struct xdma_device *xdev = xchan->xdev_hdl;
/* clear run stop bit to prevent any further auto-triggering */
@@ -395,13 +398,7 @@ static int xdma_xfer_stop(struct xdma_chan *xchan)
CHAN_CTRL_RUN_STOP);
if (ret)
return ret;
-
- /* Clear the channel status register */
- ret = regmap_read(xdev->rmap, xchan->base + XDMA_CHAN_STATUS_RC, &val);
- if (ret)
- return ret;
-
- return 0;
+ return ret;
}
/**
@@ -474,6 +471,8 @@ static int xdma_alloc_channels(struct xdma_device *xdev,
xchan->xdev_hdl = xdev;
xchan->base = base + i * XDMA_CHAN_STRIDE;
xchan->dir = dir;
+ xchan->stop_requested = false;
+ init_completion(&xchan->last_interrupt);
ret = xdma_channel_init(xchan);
if (ret)
@@ -521,6 +520,7 @@ static int xdma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(&xdma_chan->vchan.lock, flags);
xdma_chan->busy = false;
+ xdma_chan->stop_requested = true;
vd = vchan_next_desc(&xdma_chan->vchan);
if (vd) {
list_del(&vd->node);
@@ -542,6 +542,13 @@ static int xdma_terminate_all(struct dma_chan *chan)
static void xdma_synchronize(struct dma_chan *chan)
{
struct xdma_chan *xdma_chan = to_xdma_chan(chan);
+ struct xdma_device *xdev = xdma_chan->xdev_hdl;
+ int st = 0;
+
+ /* If the engine continues running, wait for the last interrupt */
+ regmap_read(xdev->rmap, xdma_chan->base + XDMA_CHAN_STATUS, &st);
+ if (st & XDMA_CHAN_STATUS_BUSY)
+ wait_for_completion_timeout(&xdma_chan->last_interrupt, msecs_to_jiffies(1000));
vchan_synchronize(&xdma_chan->vchan);
}
@@ -876,6 +883,9 @@ static irqreturn_t xdma_channel_isr(int irq, void *dev_id)
u32 st;
bool repeat_tx;
+ if (xchan->stop_requested)
+ complete(&xchan->last_interrupt);
+
spin_lock(&xchan->vchan.lock);
/* get submitted request */
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] dmaengine: xilinx: xdma: Various fixes for xdma
From: Louis Chauvet @ 2024-03-27 9:58 UTC (permalink / raw)
To: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Vinod Koul, Michal Simek,
Jan Kuliga, Miquel Raynal
Cc: dmaengine, linux-arm-kernel, linux-kernel, stable, Louis Chauvet
The current driver have some issues, this series fixes them.
PATCH 1 is fixing a wrong offset computation in the dma descriptor address
PATCH 2 is fixing the xdma_synchronize callback, which was not waiting
properly for the last transfer.
PATCH 3 is clarifing the documentation for xdma_fill_descs
---
Louis Chauvet (1):
dmaengine: xilinx: xdma: Fix synchronization issue
Miquel Raynal (2):
dmaengine: xilinx: xdma: Fix wrong offsets in the buffers addresses in dma descriptor
dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver
drivers/dma/xilinx/xdma-regs.h | 3 +++
drivers/dma/xilinx/xdma.c | 42 +++++++++++++++++++++++++++---------------
2 files changed, 30 insertions(+), 15 deletions(-)
---
base-commit: 8e938e39866920ddc266898e6ae1fffc5c8f51aa
change-id: 20240322-digigram-xdma-fixes-aa13451b7474
Best regards,
--
Louis Chauvet <louis.chauvet@bootlin.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dmaengine: xilinx: xdma: Fix wrong offsets in the buffers addresses in dma descriptor
From: Louis Chauvet @ 2024-03-27 9:58 UTC (permalink / raw)
To: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Vinod Koul, Michal Simek,
Jan Kuliga, Miquel Raynal
Cc: dmaengine, linux-arm-kernel, linux-kernel, stable, Louis Chauvet
In-Reply-To: <20240327-digigram-xdma-fixes-v1-0-45f4a52c0283@bootlin.com>
From: Miquel Raynal <miquel.raynal@bootlin.com>
The addition of interleaved transfers slightly changed the way
addresses inside DMA descriptors are derived, breaking cyclic
transfers.
Fixes: 3e184e64c2e5 ("dmaengine: xilinx: xdma: Prepare the introduction of interleaved DMA transfers")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
drivers/dma/xilinx/xdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c
index 170017ff2aad..b9788aa8f6b7 100644
--- a/drivers/dma/xilinx/xdma.c
+++ b/drivers/dma/xilinx/xdma.c
@@ -704,7 +704,7 @@ xdma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t address,
desc_num = 0;
for (i = 0; i < periods; i++) {
desc_num += xdma_fill_descs(sw_desc, *src, *dst, period_size, desc_num);
- addr += i * period_size;
+ addr += period_size;
}
tx_desc = vchan_tx_prep(&xdma_chan->vchan, &sw_desc->vdesc, flags);
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver
From: Louis Chauvet @ 2024-03-27 9:58 UTC (permalink / raw)
To: Lizhi Hou, Brian Xu, Raj Kumar Rampelli, Vinod Koul, Michal Simek,
Jan Kuliga, Miquel Raynal
Cc: dmaengine, linux-arm-kernel, linux-kernel, stable, Louis Chauvet
In-Reply-To: <20240327-digigram-xdma-fixes-v1-0-45f4a52c0283@bootlin.com>
From: Miquel Raynal <miquel.raynal@bootlin.com>
Clarify the kernel doc of xdma_fill_descs(), especially how big chunks
will be handled.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
drivers/dma/xilinx/xdma.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c
index 5a3a3293b21b..313b217388fe 100644
--- a/drivers/dma/xilinx/xdma.c
+++ b/drivers/dma/xilinx/xdma.c
@@ -554,12 +554,14 @@ static void xdma_synchronize(struct dma_chan *chan)
}
/**
- * xdma_fill_descs - Fill hardware descriptors with contiguous memory block addresses
- * @sw_desc: tx descriptor state container
- * @src_addr: Value for a ->src_addr field of a first descriptor
- * @dst_addr: Value for a ->dst_addr field of a first descriptor
- * @size: Total size of a contiguous memory block
- * @filled_descs_num: Number of filled hardware descriptors for corresponding sw_desc
+ * xdma_fill_descs() - Fill hardware descriptors for one contiguous memory chunk.
+ * More than one descriptor will be used if the size is bigger
+ * than XDMA_DESC_BLEN_MAX.
+ * @sw_desc: Descriptor container
+ * @src_addr: First value for the ->src_addr field
+ * @dst_addr: First value for the ->dst_addr field
+ * @size: Size of the contiguous memory block
+ * @filled_descs_num: Index of the first descriptor to take care of in @sw_desc
*/
static inline u32 xdma_fill_descs(struct xdma_desc *sw_desc, u64 src_addr,
u64 dst_addr, u32 size, u32 filled_descs_num)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH v1 1/4] mm: Introduce ptep_get_lockless_norecency()
From: Ryan Roberts @ 2024-03-27 9:57 UTC (permalink / raw)
To: David Hildenbrand, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <6777213f-6273-4942-86be-e712ee5ebd1a@redhat.com>
On 27/03/2024 09:28, David Hildenbrand wrote:
> On 26.03.24 17:39, Ryan Roberts wrote:
>> On 26/03/2024 16:27, David Hildenbrand wrote:
>>> On 15.02.24 13:17, Ryan Roberts wrote:
>>>> With the introduction of contpte mapping support for arm64, that
>>>> architecture's implementation of ptep_get_lockless() has become very
>>>> complex due to the need to gather access and dirty bits from across all
>>>> of the ptes in the contpte block. This requires careful implementation
>>>> to ensure the returned value is consistent (because its not possible to
>>>> read all ptes atomically), but even in the common case when there is no
>>>> racing modification, we have to read all ptes, which gives an ~O(n^2)
>>>> cost if the core-mm is iterating over a range, and performing a
>>>> ptep_get_lockless() on each pte.
>>>>
>>>> Solve this by introducing ptep_get_lockless_norecency(), which does not
>>>> make any guarantees about access and dirty bits. Therefore it can simply
>>>> read the single target pte.
>>>>
>>>> At the same time, convert all call sites that previously used
>>>> ptep_get_lockless() but don't care about access and dirty state.
>>>>
>>>
>>> I'd probably split that part off.
>>
>> I thought the general guidance was to introduce new APIs in same patch they are
>> first used in? If I split this off, I'll have one patch for a new (unused) API,
>> then another for the first users.
>
> I don't know what exact guidance there is, but I tend to leave "non trivial
> changes" to separate patches.
>
> Some of the changes here are rather trivial (mm/hugetlb.c), and I agree that we
> can perform them here.
>
> At least the "vmf.orig_pte" looked "non-trivial" to me, thus my comment.
got it.
>
>>
>>>
>>>> We may want to do something similar for ptep_get() (i.e.
>>>> ptep_get_norecency()) in future; it doesn't suffer from the consistency
>>>> problem because the PTL serializes it with any modifications, but does
>>>> suffer the same O(n^2) cost.
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>> ---
>>>> include/linux/pgtable.h | 37 ++++++++++++++++++++++++++++++++++---
>>>> kernel/events/core.c | 2 +-
>>>> mm/hugetlb.c | 2 +-
>>>> mm/khugepaged.c | 2 +-
>>>> mm/memory.c | 2 +-
>>>> mm/swap_state.c | 2 +-
>>>> mm/swapfile.c | 2 +-
>>>> 7 files changed, 40 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>> index a36cf4e124b0..9dd40fdbd825 100644
>>>> --- a/include/linux/pgtable.h
>>>> +++ b/include/linux/pgtable.h
>>>> @@ -528,16 +528,47 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp)
>>>> #endif /* CONFIG_PGTABLE_LEVELS > 2 */
>>>> #endif /* CONFIG_GUP_GET_PXX_LOW_HIGH */
>>>>
>>>> -/*
>>>> - * We require that the PTE can be read atomically.
>>>> - */
>>>> #ifndef ptep_get_lockless
>>>> +/**
>>>> + * ptep_get_lockless - Get a pte without holding the page table lock. Young
>>>> and
>>>> + * dirty bits are guaranteed to accurately reflect the
>>>> state
>>>> + * of the pte at the time of the call.
>>>> + * @ptep: Page table pointer for pte to get.
>>>> + *
>>>> + * If young and dirty information is not required, use
>>>> + * ptep_get_lockless_norecency() which can be faster on some architectures.
>>>> + *
>>>> + * May be overridden by the architecture; otherwise, implemented using
>>>> + * ptep_get(), on the assumption that it is atomic.
>>>> + *
>>>> + * Context: Any.
>>>> + */
>>>
>>> I think we usually say "Any context.". But I would just do it like idr.h:
>>>
>>> "Any context. It is safe to call this function without locking in your code."
>>>
>>> ... but is this true? We really want to say "without page table lock". Because
>>> there must be some way to prevent against concurrent page table freeing. For
>>> example, GUP-fast disables IRQs, whereby page table freeing code frees using
>>> RCU.
>>
>> How about:
>>
>> "
>> Context: Any context that guarrantees the page table can't be freed
>
> s/guarrantees/guarantees/
>
>> concurrently. The page table lock is not required.
>> "
>>
>
> Sounds good.
Great!
>
>>>
>>>> static inline pte_t ptep_get_lockless(pte_t *ptep)
>>>> {
>>>> return ptep_get(ptep);
>>>> }
>>>> #endif
>>>>
>>>> +#ifndef ptep_get_lockless_norecency
>>>> +/**
>>>> + * ptep_get_lockless_norecency - Get a pte without holding the page table
>>>> lock.
>>>> + * Young and dirty bits may not be accurate.
>>>> + * @ptep: Page table pointer for pte to get.
>>>> + *
>>>> + * Prefer this over ptep_get_lockless() when young and dirty information is
>>>> not
>>>> + * required since it can be faster on some architectures.
>>>> + *
>>>> + * May be overridden by the architecture; otherwise, implemented using the
>>>> more
>>>> + * precise ptep_get_lockless().
>>>> + *
>>>> + * Context: Any.
>>>
>>> Same comment.
>>>
>>>> + */
>>>> +static inline pte_t ptep_get_lockless_norecency(pte_t *ptep)
>>>> +{
>>>> + return ptep_get_lockless(ptep);
>>>> +}
>>>> +#endif
>>>
>>> [...]
>>>
>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>>> index 68283e54c899..41dc44eb8454 100644
>>>> --- a/mm/hugetlb.c
>>>> +++ b/mm/hugetlb.c
>>>> @@ -7517,7 +7517,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct
>>>> vm_area_struct *vma,
>>>> }
>>>>
>>>> if (pte) {
>>>> - pte_t pteval = ptep_get_lockless(pte);
>>>> + pte_t pteval = ptep_get_lockless_norecency(pte);
>>>>
>>>> BUG_ON(pte_present(pteval) && !pte_huge(pteval));
>>>> }
>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>> index 2771fc043b3b..1a6c9ed8237a 100644
>>>> --- a/mm/khugepaged.c
>>>> +++ b/mm/khugepaged.c
>>>> @@ -1019,7 +1019,7 @@ static int __collapse_huge_page_swapin(struct mm_struct
>>>> *mm,
>>>> }
>>>> }
>>>>
>>>> - vmf.orig_pte = ptep_get_lockless(pte);
>>>> + vmf.orig_pte = ptep_get_lockless_norecency(pte);
>>>> if (!is_swap_pte(vmf.orig_pte))
>>>> continue;
>>>
>>>
>>> Hm, I think you mentioned that we want to be careful with vmf.orig_pte.
>>
>> Yeah good point. So I guess this should move to patch 3 (which may be dropped -
>> tbd)?
>>
>
> Yes. Or a separate one where you explain in detail why do_swap_page() can handle
> it just fine.
Ahh no wait - I remember now; the reason I believe this is a "trivial" case is
because we only leak vmf.orig_pte to the rest of the world if its a swap entry.
And if its a swap entry, then ptep_get_lockless_norecency() is equivalent to
ptep_get_lockless() - the pte is not present so there are no access or dirty
bits. So I think this can stay here?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Improvement around mtk_vcodec_mem_free() logging and usage
From: Sebastian Fricke @ 2024-03-27 9:57 UTC (permalink / raw)
To: Fei Shao
Cc: Hans Verkuil, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne, Tiffany Lin, Xiaoyong Lu,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek, AngeloGioacchino Del Regno
In-Reply-To: <CAC=S1njAtbvjy1KBoVNtsw8WDKL1Zoh76mG3HvcUaOUBprEMkQ@mail.gmail.com>
Hey Fei,
On 27.03.2024 17:18, Fei Shao wrote:
>On Thu, Dec 21, 2023 at 5:23 PM Fei Shao <fshao@chromium.org> wrote:
>>
>> Hi,
>>
>> This series includes some improvements around mtk_vcodec_mem_free() in
>> mtk_vcodec_util.c.
>>
>> I noticed that mtk_vcodec_mem_free() generates a spurious error if the
>> target DMA buffer has been freed previously:
>> mtk_vcodec_mem_free(),69: [MTK_V4L2][ERROR] 18000000.video-codec
>> dma_free size=0 failed!
>>
>> The warning is harmless, but it brings some confusion to our developers
>> and testing infra, so I sent this series to fix that with some minor
>> improvement for the driver alongside.
>>
>> The first two patches are for aesthetic and style improvements, the
>> third tries to make the error logs more informative, and the last adds
>> back the missing checks when calling the free function.
>>
>> Regards,
>> Fei
>>
>> v1: https://lore.kernel.org/all/20231113123049.4117280-1-fshao@chromium.org/
>>
>> Changes in v2:
>> - rebased on top of next-20231219
>> - revise commit message for clearer intention and rationale
>> - update the error messages based on the suggestion
>>
>> Fei Shao (4):
>> media: mediatek: vcodec: Replace dev_name in error string
>> media: mediatek: vcodec: Drop unnecessary variable
>> media: mediatek: vcodec: Update mtk_vcodec_mem_free() error messages
>> media: mediatek: vcodec: Only free buffer VA that is not NULL
>>
>> .../mediatek/vcodec/common/mtk_vcodec_util.c | 23 +++++++++----------
>> .../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 22 ++++++++++++------
>> .../vcodec/encoder/venc/venc_h264_if.c | 5 ++--
>> 3 files changed, 29 insertions(+), 21 deletions(-)
>
>Hi Hans,
>
>I'd like to get some attention for this series in case it has been
>overlooked. It still applies to next-20240327 without conflict.
>Please let me know if you have any feedback or concerns on this.
Sorry this seems to have slipped through my fingers, I'll put it on my
list. Thanks for the notification.
>
>Thank you,
>Fei
Greetings,
Sebastian
>>
>> --
>> 2.43.0.472.g3155946c3a-goog
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 3/4] mm/memory: Use ptep_get_lockless_norecency() for orig_pte
From: Ryan Roberts @ 2024-03-27 9:51 UTC (permalink / raw)
To: David Hildenbrand, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <6aaff470-c510-469b-8f4f-2e4c5cf07d56@redhat.com>
On 26/03/2024 17:58, David Hildenbrand wrote:
>>>>>
>>>>> vmf->orig_pte = ptep_get_lockless_norecency(vmf->pte)
>>>>> /* not dirty */
>>>>>
>>>>> /* Now, thread 2 ends up setting the PTE dirty under PT lock. */
>>
>> Ahh, this comment about thread 2 is not referring to the code immediately below
>> it. It all makes much more sense now. :)
>
> Sorry :)
>
>>
>>>>>
>>>>> spin_lock(vmf->ptl);
>>>>> entry = vmf->orig_pte;
>>>>> if (unlikely(!pte_same(ptep_get(vmf->pte), entry))) {
>>>>> ...
>>>>> }
>>>>> ...
>>>>> entry = pte_mkyoung(entry);
>>>>
>>>> Do you mean pte_mkdirty() here? You're talking about dirty everywhere else.
>>>
>>> No, that is just thread 1 seeing "oh, nothing to do" and then goes ahead and
>>> unconditionally does that in handle_pte_fault().
>>>
>>>>
>>>>> if (ptep_set_access_flags(vmf->vma, ...)
>>>>> ...
>>>>> pte_unmap_unlock(vmf->pte, vmf->ptl);
>>>>>
>>>>>
>>>>> Generic ptep_set_access_flags() will do another pte_same() check and realize
>>>>> "hey, there was a change!" let's update the PTE!
>>>>>
>>>>> set_pte_at(vma->vm_mm, address, ptep, entry);
>>>>
>>>> This is called from the generic ptep_set_access_flags() in your example, right?
>>>>
>>>
>>> Yes.
>>>
>>>>>
>>>>> would overwrite the dirty bit set by thread 2.
>>>>
>>>> I'm not really sure what you are getting at... Is your concern that there is a
>>>> race where the page could become dirty in the meantime and it now gets lost? I
>>>> think that's why arm64 overrides ptep_set_access_flags(); since the hw can
>>>> update access/dirty we have to deal with the races.
>>>
>>> My concern is that your patch can in subtle ways lead to use losing PTE dirty
>>> bits on architectures that don't have the HW-managed dirty bit. They do exist ;)
>>
>> But I think the example you give can already happen today? Thread 1 reads
>> orig_pte = ptep_get_lockless(). So that's already racy, if thread 2 is going to
>> set dirty just after the get, then thread 1 is going to set the PTE back to (a
>> modified version of) orig_pte. Isn't it already broken?
>
> No, because the pte_same() check under PTL would have detected it, and we would
> have backed out. And I think the problem comes to live when we convert
> pte_same()->pte_same_norecency(), because we fail to protect PTE access/dirty
> changes that happend under PTL from another thread.
Ahh yep. Got it. I absolutely knew that you would be correct, but I still walked
right into it!
I think one could argue that the generic ptep_set_access_flags() is not
implementing its own spec:
"
... Only sets the access flags (dirty, accessed), as well as write permission.
Furthermore, we know it always gets set to a "more permissive" setting ...
"
Surely it should be folding the access and dirty bits from *ptep into entry if
they are set?
Regardless, I think this example proves that its fragile and subtle. I'm not
really sure how to fix it more generally/robustly. Any thoughts? If not perhaps
we are better off keeping ptep_get_lockless() around and only using
ptep_get_lockless_norecency() for the really obviously correct cases?
>
> But could be I am missing something :)
>
>>> Arm64 should be fine in that regard.
>>>
>>
>> There is plenty of arm64 HW that doesn't do HW access/dirty update. But our
>> ptep_set_access_flags() can always deal with a racing update, even if that
>> update originates from SW.
>>
>> Why do I have the feeling you're about to explain (very patiently) exactly why
>> I'm wrong?... :)
>
> heh ... or you'll tell me (vary patiently) why I am wrong :)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 05/27] iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry()
From: Mostafa Saleh @ 2024-03-27 9:45 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <20240326222758.GB946323@nvidia.com>
On Tue, Mar 26, 2024 at 07:27:58PM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 26, 2024 at 07:12:53PM +0000, Mostafa Saleh wrote:
> > On Tue, Mar 26, 2024 at 03:30:55PM -0300, Jason Gunthorpe wrote:
> > > On Sat, Mar 23, 2024 at 01:02:15PM +0000, Mostafa Saleh wrote:
> > > > > +static void arm_smmu_get_cd_used(const __le64 *ent, __le64 *used_bits)
> > > > > +{
> > > > > + used_bits[0] = cpu_to_le64(CTXDESC_CD_0_V);
> > > > > + if (!(ent[0] & cpu_to_le64(CTXDESC_CD_0_V)))
> > > > > + return;
> > > > > + memset(used_bits, 0xFF, sizeof(struct arm_smmu_cd));
> > > >
> > > > This is a slightly different approach than what the driver does for STEs,
> > > > where it explicitly sets the used bits. Is there a reason for that?
> > >
> > > It is just more compact this way
> >
> > IMHO, it seems too much to have this mechanism for CDs for just one
> > SVA case, but I'll need to go through the whole seires first to make
> > sure I am not missing anything.
>
> It is pretty ugly if you try to do it that way. You still need to
> create some ops because the entry_set should be re-used (I mean I
> guess you could copy it as well). Then you have to open code the
> logic. And then the EPD0 path is somewhat fragile. Something sort of
> like this:
>
> void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
> struct arm_smmu_cd *cdptr,
> const struct arm_smmu_cd *target)
> {
> bool target_valid = target->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
> bool cur_valid = cdptr->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
> struct arm_smmu_cd_writer cd_writer = {
> .writer = {
> .ops = &arm_smmu_cd_writer_ops,
> .master = master,
> },
> .ssid = ssid,
> };
>
> if (ssid != IOMMU_NO_PASID && cur_valid != target_valid) {
> if (cur_valid)
> master->cd_table.used_ssids--;
> else
> master->cd_table.used_ssids++;
> }
>
> /* Force a V=0/V=1 update*/
> __le64 update = target[0] & ~cpu_to_le64(CTXDESC_CD_0_V);
> entry_set(&cd_writer.writer, cdptr->data, &update, 0, 1);
> entry_set(&cd_writer.writer, cdptr->data, target->data, 1, NUM_ENTRY_QWORDS - 1);
> entry_set(&cd_writer.writer, cdptr->data, target->data, 0, 1);
> }
>
> void arm_smmu_write_cd_entry_epd0(struct arm_smmu_master *master, int ssid,
> struct arm_smmu_cd *cdptr,
> const struct arm_smmu_cd *target)
> {
> struct arm_smmu_cd_writer cd_writer = {
> .writer = {
> .ops = &arm_smmu_cd_writer_ops,
> .master = master,
> },
> .ssid = ssid,
> };
>
> /*
> * Target must the EPD0 = 1 version of the existing CD entry, caller
> * must enforce it. Assume used_ssids doesn't need updating
> * for this reason.
> */
> /* Update EPD0 */
> entry_set(&cd_writer.writer, cdptr->data, target->data, 0, 1);
> /* Update everthing else */
> entry_set(&cd_writer.writer, cdptr->data, target->data, 0, NUM_ENTRY_QWORDS - 1);
> }
>
> IMOH, at this point it is saner to have just implemented the used
> function and use the mechanism robustly. Less special cases, less
> fragility, less duplication.
>
But that adds extra cost of adding ops, indirection, modifying STE
code..., for a case that is not common, so I think special casing it
is actually better for readability and maintainability.
But again, I need to finish going through the series to get the
full context.
Thanks,
Mostafa
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 8/8] PCI: endpoint: Remove "core_init_notifier" flag
From: Niklas Cassel @ 2024-03-27 9:41 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Marek Vasut, Yoshihiro Shimoda,
Thierry Reding, Jonathan Hunter, Vidya Sagar, Vignesh Raghavendra,
Richard Zhu, Lucas Stach, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Minghuan Lian, Mingkai Hu, Roy Zang, Kunihiko Hayashi,
Masami Hiramatsu, Kishon Vijay Abraham I, Jesper Nilsson,
Srikanth Thokala, Shawn Lin, Heiko Stuebner, linux-pci,
linux-kernel, linux-renesas-soc, linux-arm-msm, linux-tegra,
linux-omap, linux-arm-kernel, linuxppc-dev, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20240327-pci-dbi-rework-v12-8-082625472414@linaro.org>
On Wed, Mar 27, 2024 at 02:43:37PM +0530, Manivannan Sadhasivam wrote:
> "core_init_notifier" flag is set by the glue drivers requiring refclk from
> the host to complete the DWC core initialization. Also, those drivers will
> send a notification to the EPF drivers once the initialization is fully
> completed using the pci_epc_init_notify() API. Only then, the EPF drivers
> will start functioning.
>
> For the rest of the drivers generating refclk locally, EPF drivers will
> start functioning post binding with them. EPF drivers rely on the
> 'core_init_notifier' flag to differentiate between the drivers.
> Unfortunately, this creates two different flows for the EPF drivers.
>
> So to avoid that, let's get rid of the "core_init_notifier" flag and follow
> a single initialization flow for the EPF drivers. This is done by calling
> the dw_pcie_ep_init_notify() from all glue drivers after the completion of
> dw_pcie_ep_init_registers() API. This will allow all the glue drivers to
> send the notification to the EPF drivers once the initialization is fully
> completed.
>
> Only difference here is that, the drivers requiring refclk from host will
> send the notification once refclk is received, while others will send it
> during probe time itself.
>
> But this also requires the EPC core driver to deliver the notification
> after EPF driver bind. Because, the glue driver can send the notification
> before the EPF drivers bind() and in those cases the EPF drivers will miss
> the event. To accommodate this, EPC core is now caching the state of the
> EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
> notification to EPF drivers based on that after each EPF driver bind.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
Reviewed-by: Niklas Cassel <cassel@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 9:34 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <c3ca3d90-898e-44b0-ad0f-dd78c09c5fcd@linaro.org>
On Wed, 2024-03-27 at 10:23 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 09:39, Krzysztof Kozlowski wrote:
> > On 27/03/2024 06:57, yu-chang.lee wrote:
> >> Add Smart Multimedia Interface Local Arbiter to mediatek
> >> power domain.
> >>
> >> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
> >> ---
> >> .../devicetree/bindings/power/mediatek,power-controller.yaml | 4
> ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git
> a/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> b/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> >> index 8985e2df8a56..228c0dec5253 100644
> >> --- a/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> >> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
> controller.yaml
> >> @@ -125,6 +125,10 @@ $defs:
> >> $ref: /schemas/types.yaml#/definitions/phandle
> >> description: phandle to the device containing the SMI
> register range.
> >>
> >> + mediatek,larb:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description: phandle to the device containing the LARB
> register range.
> >
> > Why do you need it?
> >
> > Plus I also see mediatek,larbs and mediatek,larb-id... so now we
> have
> > third one similar.
>
> ... and not even tested!
>
> Best regards,
> Krzysztof
>
Hi,
I will double check the format of yaml for the next version, sorry for
inconvenience. But I did test it on mt8188 chromebook, the reason why
power domain need larb node is that when mtcmos power on, signal glitch
may produce. Power domain driver must reset larb when this happen to
prevent dummy transaction on bus. That why I need larb node in dts.
Best Regards,
Yu-chang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64
From: David Hildenbrand @ 2024-03-27 9:34 UTC (permalink / raw)
To: Ryan Roberts, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <86680856-2532-495b-951a-ea7b2b93872f@arm.com>
On 26.03.24 18:51, Ryan Roberts wrote:
> On 26/03/2024 17:39, David Hildenbrand wrote:
>> On 26.03.24 18:32, Ryan Roberts wrote:
>>> On 26/03/2024 17:04, David Hildenbrand wrote:
>>>>>>>>
>>>>>>>> Likely, we just want to read "the real deal" on both sides of the pte_same()
>>>>>>>> handling.
>>>>>>>
>>>>>>> Sorry I'm not sure I understand? You mean read the full pte including
>>>>>>> access/dirty? That's the same as dropping the patch, right? Of course if
>>>>>>> we do
>>>>>>> that, we still have to keep pte_get_lockless() around for this case. In an
>>>>>>> ideal
>>>>>>> world we would convert everything over to ptep_get_lockless_norecency() and
>>>>>>> delete ptep_get_lockless() to remove the ugliness from arm64.
>>>>>>
>>>>>> Yes, agreed. Patch #3 does not look too crazy and it wouldn't really affect
>>>>>> any
>>>>>> architecture.
>>>>>>
>>>>>> I do wonder if pte_same_norecency() should be defined per architecture and the
>>>>>> default would be pte_same(). So we could avoid the mkold etc on all other
>>>>>> architectures.
>>>>>
>>>>> Wouldn't that break it's semantics? The "norecency" of
>>>>> ptep_get_lockless_norecency() means "recency information in the returned pte
>>>>> may
>>>>> be incorrect". But the "norecency" of pte_same_norecency() means "ignore the
>>>>> access and dirty bits when you do the comparison".
>>>>
>>>> My idea was that ptep_get_lockless_norecency() would return the actual result on
>>>> these architectures. So e.g., on x86, there would be no actual change in
>>>> generated code.
>>>
>>> I think this is a bad plan... You'll end up with subtle differences between
>>> architectures.
>>>
>>>>
>>>> But yes, the documentation of these functions would have to be improved.
>>>>
>>>> Now I wonder if ptep_get_lockless_norecency() should actively clear
>>>> dirty/accessed bits to more easily find any actual issues where the bits still
>>>> matter ...
>>>
>>> I did a version that took that approach. Decided it was not as good as this way
>>> though. Now for the life of me, I can't remember my reasoning.
>>
>> Maybe because there are some code paths that check accessed/dirty without
>> "correctness" implications? For example, if the PTE is already dirty, no need to
>> set it dirty etc?
>
> I think I decided I was penalizing the architectures that don't care because all
> their ptep_get_norecency() and ptep_get_lockless_norecency() need to explicitly
> clear access/dirty. And I would have needed ptep_get_norecency() from day 1 so
> that I could feed its result into pte_same().
True. With ptep_get_norecency() you're also penalizing other
architectures. Therefore my original thought about making the behavior
arch-specific, but the arch has to make sure to get the combination of
ptep_get_lockless_norecency()+ptep_same_norecency() is right.
So if an arch decide to ignore bits in ptep_get_lockless_norecency(), it
must make sure to also ignore them in ptep_same_norecency(), and must be
able to handle access/dirty bit changes differently.
Maybe one could have one variant for "hw-managed access/dirty" vs. "sw
managed accessed or dirty". Only the former would end up ignoring stuff
here, the latter would not.
But again, just some random thoughts how this affects other
architectures and how we could avoid it. The issue I describe in patch
#3 would be gone if ptep_same_norecency() would just do a ptep_same()
check on other architectures -- and would make it easier to sell :)
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] PCI: keystone: Fix pci_ops for AM654x SoC
From: Siddharth Vadapalli @ 2024-03-27 9:31 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Siddharth Vadapalli, lpieralisi, kw, robh, bhelgaas,
manivannan.sadhasivam, fancer.lancer, u.kleine-koenig, cassel,
dlemoal, yoshihiro.shimoda.uh, linux-pci, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <20240326232403.GA1502764@bhelgaas>
On Tue, Mar 26, 2024 at 06:24:03PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 26, 2024 at 08:12:58PM +0530, Siddharth Vadapalli wrote:
> > In the process of converting .scan_bus() callbacks to .add_bus(), the
> > ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
> > The .scan_bus() method belonged to ks_pcie_host_ops which was specific
> > to controller version 3.65a, while the .add_bus() method had been added
> > to ks_pcie_ops which is shared between the controller versions 3.65a and
> > 4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
> > ks_pcie_v3_65_add_bus() method is applicable to the controller version
> > 4.90a which is present in AM654x SoCs.
> >
> > Thus, as a fix, move the contents of "ks_pcie_v3_65_add_bus()" to the
> > .msi_init callback "ks_pcie_msi_host_init()" which is specific to the
> > 3.65a controller. Also, move the definitions of ks_pcie_set_dbi_mode()
> > and ks_pcie_clear_dbi_mode() above ks_pcie_msi_host_init() in order to
> > avoid forward declaration.
>
> If it's possible to split this into two patches (one that strictly
> *moves* the code without otherwise changing it, and another that makes
> the actual fix), it would be easier to review the fix. It's a pain to
> have to compare the code in the old location with that in the new
> location.
Sure. I will do so and post the v7 patch.
Regards,
Siddharth.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/4] mm: Introduce ptep_get_lockless_norecency()
From: David Hildenbrand @ 2024-03-27 9:28 UTC (permalink / raw)
To: Ryan Roberts, Mark Rutland, Catalin Marinas, Will Deacon,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
Andrew Morton, Muchun Song
Cc: linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <5c8dbda1-5b89-4599-9bc2-f840e7bc6a74@arm.com>
On 26.03.24 17:39, Ryan Roberts wrote:
> On 26/03/2024 16:27, David Hildenbrand wrote:
>> On 15.02.24 13:17, Ryan Roberts wrote:
>>> With the introduction of contpte mapping support for arm64, that
>>> architecture's implementation of ptep_get_lockless() has become very
>>> complex due to the need to gather access and dirty bits from across all
>>> of the ptes in the contpte block. This requires careful implementation
>>> to ensure the returned value is consistent (because its not possible to
>>> read all ptes atomically), but even in the common case when there is no
>>> racing modification, we have to read all ptes, which gives an ~O(n^2)
>>> cost if the core-mm is iterating over a range, and performing a
>>> ptep_get_lockless() on each pte.
>>>
>>> Solve this by introducing ptep_get_lockless_norecency(), which does not
>>> make any guarantees about access and dirty bits. Therefore it can simply
>>> read the single target pte.
>>>
>>> At the same time, convert all call sites that previously used
>>> ptep_get_lockless() but don't care about access and dirty state.
>>>
>>
>> I'd probably split that part off.
>
> I thought the general guidance was to introduce new APIs in same patch they are
> first used in? If I split this off, I'll have one patch for a new (unused) API,
> then another for the first users.
I don't know what exact guidance there is, but I tend to leave "non
trivial changes" to separate patches.
Some of the changes here are rather trivial (mm/hugetlb.c), and I agree
that we can perform them here.
At least the "vmf.orig_pte" looked "non-trivial" to me, thus my comment.
>
>>
>>> We may want to do something similar for ptep_get() (i.e.
>>> ptep_get_norecency()) in future; it doesn't suffer from the consistency
>>> problem because the PTL serializes it with any modifications, but does
>>> suffer the same O(n^2) cost.
>>>
>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>> ---
>>> include/linux/pgtable.h | 37 ++++++++++++++++++++++++++++++++++---
>>> kernel/events/core.c | 2 +-
>>> mm/hugetlb.c | 2 +-
>>> mm/khugepaged.c | 2 +-
>>> mm/memory.c | 2 +-
>>> mm/swap_state.c | 2 +-
>>> mm/swapfile.c | 2 +-
>>> 7 files changed, 40 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>> index a36cf4e124b0..9dd40fdbd825 100644
>>> --- a/include/linux/pgtable.h
>>> +++ b/include/linux/pgtable.h
>>> @@ -528,16 +528,47 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp)
>>> #endif /* CONFIG_PGTABLE_LEVELS > 2 */
>>> #endif /* CONFIG_GUP_GET_PXX_LOW_HIGH */
>>>
>>> -/*
>>> - * We require that the PTE can be read atomically.
>>> - */
>>> #ifndef ptep_get_lockless
>>> +/**
>>> + * ptep_get_lockless - Get a pte without holding the page table lock. Young and
>>> + * dirty bits are guaranteed to accurately reflect the state
>>> + * of the pte at the time of the call.
>>> + * @ptep: Page table pointer for pte to get.
>>> + *
>>> + * If young and dirty information is not required, use
>>> + * ptep_get_lockless_norecency() which can be faster on some architectures.
>>> + *
>>> + * May be overridden by the architecture; otherwise, implemented using
>>> + * ptep_get(), on the assumption that it is atomic.
>>> + *
>>> + * Context: Any.
>>> + */
>>
>> I think we usually say "Any context.". But I would just do it like idr.h:
>>
>> "Any context. It is safe to call this function without locking in your code."
>>
>> ... but is this true? We really want to say "without page table lock". Because
>> there must be some way to prevent against concurrent page table freeing. For
>> example, GUP-fast disables IRQs, whereby page table freeing code frees using RCU.
>
> How about:
>
> "
> Context: Any context that guarrantees the page table can't be freed
s/guarrantees/guarantees/
> concurrently. The page table lock is not required.
> "
>
Sounds good.
>>
>>> static inline pte_t ptep_get_lockless(pte_t *ptep)
>>> {
>>> return ptep_get(ptep);
>>> }
>>> #endif
>>>
>>> +#ifndef ptep_get_lockless_norecency
>>> +/**
>>> + * ptep_get_lockless_norecency - Get a pte without holding the page table lock.
>>> + * Young and dirty bits may not be accurate.
>>> + * @ptep: Page table pointer for pte to get.
>>> + *
>>> + * Prefer this over ptep_get_lockless() when young and dirty information is not
>>> + * required since it can be faster on some architectures.
>>> + *
>>> + * May be overridden by the architecture; otherwise, implemented using the more
>>> + * precise ptep_get_lockless().
>>> + *
>>> + * Context: Any.
>>
>> Same comment.
>>
>>> + */
>>> +static inline pte_t ptep_get_lockless_norecency(pte_t *ptep)
>>> +{
>>> + return ptep_get_lockless(ptep);
>>> +}
>>> +#endif
>>
>> [...]
>>
>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>> index 68283e54c899..41dc44eb8454 100644
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -7517,7 +7517,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct
>>> vm_area_struct *vma,
>>> }
>>>
>>> if (pte) {
>>> - pte_t pteval = ptep_get_lockless(pte);
>>> + pte_t pteval = ptep_get_lockless_norecency(pte);
>>>
>>> BUG_ON(pte_present(pteval) && !pte_huge(pteval));
>>> }
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 2771fc043b3b..1a6c9ed8237a 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -1019,7 +1019,7 @@ static int __collapse_huge_page_swapin(struct mm_struct
>>> *mm,
>>> }
>>> }
>>>
>>> - vmf.orig_pte = ptep_get_lockless(pte);
>>> + vmf.orig_pte = ptep_get_lockless_norecency(pte);
>>> if (!is_swap_pte(vmf.orig_pte))
>>> continue;
>>
>>
>> Hm, I think you mentioned that we want to be careful with vmf.orig_pte.
>
> Yeah good point. So I guess this should move to patch 3 (which may be dropped -
> tbd)?
>
Yes. Or a separate one where you explain in detail why do_swap_page()
can handle it just fine.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Krzysztof Kozlowski @ 2024-03-27 9:23 UTC (permalink / raw)
To: Abel Vesa, Stephen Boyd, Matthias Brugger, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, Neil Armstrong,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Srini Kandagatla, Johan Hovold, linux-kernel, linux-arm-kernel,
linux-arm-msm, linux-mediatek, devicetree
In-Reply-To: <20240326-spmi-multi-master-support-v6-0-1c87d8306c5b@linaro.org>
On 26/03/2024 17:28, Abel Vesa wrote:
> This RFC prepares for and adds support for 2 buses, which is supported
> in HW starting with version 7. Until now, none of the currently
> supported platforms in upstream have used the second bus. The X1E80100
> platform, on the other hand, needs the second bus for the USB2.0 to work
> as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
> all found on the second bus.
>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---
> Changes in v6:
> - Changed the compatible to platform specific (X1E80100) along with the
> schema. Fixed the spmi buses unit addresses and added the empty ranges
Why resending after few days? And why without reviews?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] firmware: arm_ffa: support running as a guest in a vm
From: Jens Wiklander @ 2024-03-27 9:23 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel, linux-arm-kernel, Marc Bonnici, Olivier Deprez,
Lorenzo Pieralisi, Bertrand Marquis
In-Reply-To: <ZgLrQ7FtDy3INX8F@bogus>
On Tue, Mar 26, 2024 at 4:35 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Mon, Mar 25, 2024 at 09:13:35AM +0100, Jens Wiklander wrote:
> > Add support for running the driver in a guest to a hypervisor. The main
> > difference is introducing notification pending interrupt and that
> > FFA_NOTIFICATION_BITMAP_CREATE doesn't need to be called.
> >
> > The guest may need to use a notification pending interrupt instead of or
> > in addition to the schedule receiver interrupt.
>
> The above statement makes me worry a bit that we are still not on the same
> page about NPI vs SRI. NPI need not exist in addition to SRI. And in v1
> you did mention you have SRI in the guest as well. Then why do we need
> NPI in addition to that. As part of SRI, the callback ffa_self_notif_handle
> gets registered and will be called as part of SRI handling. What you
> do in notif_pend_irq_handler(), exactly what ffa_self_notif_handle()
> already does.
That's my understanding of what an NPI handler should do to be able to
receive per-vCPU notifications.
>
> I am still struggling to understand the usecase here. If you just have
> NPI and no SRI when running the driver in the VM, then it aligns with
> my understanding of possible use-case(not the one you mentioned in v1:
> where FF-A driver in VM will have SRI as OPTEE is the secondary scheduler)
OP-TEE is not a secondary scheduler. OP-TEE (the SP) is scheduled as
usual by the normal world using direct request. OP-TEE doesn't receive
FF-A notifications and I'm not sure it will ever be needed.
>
> If we are supporting NPI or SRI, I think we can see if we can further
> simplify this change, but I want to get to an agreement with usage model
> before we dig into implementation details in this patch.
The spec doesn't as far as I know explicitly make NPI and SRI mutually
exclusive, it doesn't make sense to use both in all configurations.
I'm trying to be as dynamic as possible when configuring the NPI and
SRI handlers.
If the kernel is a physical endpoint, it's easy, it only uses SRI and
the SPMC will not give an NPI when asked.
If the kernel is a virtual endpoint it might be more complicated since
a VM may need to act as a secondary scheduler. That's not fully
supported in this patch, since it can only schedule itself. SRI is not
used in my current configuration. If a hypervisor injects an SRI I
expect it to filter what's returned by FFA_NOTIFICATION_INFO_GET for
this VM so it doesn't interfere with notifications for other VMs.
In my current configuration, the hypervisor uses NPI to signal pending
notifications to the guest. I do not need a secondary scheduler since
OP-TEE doesn't receive notifications. At a later time, we may have SPs
that need to be scheduled, but that's not a problem I'm trying to
solve here.
Thanks,
Jens
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 9:23 UTC (permalink / raw)
To: yu-chang.lee, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Matthias Brugger, AngeloGioacchino Del Regno,
MandyJH Liu
Cc: devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, fan.chen,
xiufeng.li
In-Reply-To: <6dd9959e-f741-47af-b10a-1894f72ae78f@linaro.org>
On 27/03/2024 09:39, Krzysztof Kozlowski wrote:
> On 27/03/2024 06:57, yu-chang.lee wrote:
>> Add Smart Multimedia Interface Local Arbiter to mediatek
>> power domain.
>>
>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
>> ---
>> .../devicetree/bindings/power/mediatek,power-controller.yaml | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> index 8985e2df8a56..228c0dec5253 100644
>> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> @@ -125,6 +125,10 @@ $defs:
>> $ref: /schemas/types.yaml#/definitions/phandle
>> description: phandle to the device containing the SMI register range.
>>
>> + mediatek,larb:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: phandle to the device containing the LARB register range.
>
> Why do you need it?
>
> Plus I also see mediatek,larbs and mediatek,larb-id... so now we have
> third one similar.
... and not even tested!
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Suzuki K Poulose @ 2024-03-27 9:22 UTC (permalink / raw)
To: Krzysztof Kozlowski, Russell King, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <f23f2e60-e5c0-4c3c-9722-dba63a6e7ef6@linaro.org>
On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>> Hi Krzysztof
>>
>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>
>> Are you able to provide a stable branch with these patches once you pull
>
> I doubt I will be merging this. I think amba code goes through Russell.
>
>> them in to "one tree" here ? We have changes coming up in the coresight
>> tree, which would conflict with the changes here (horribly).
>>
>
> You mean conflict with coresight conversion to platform driver? Worst
Yes.
> case it is solveable: just drop .owner.
Or, we could merge the CoreSight changes (as they are really not
affected by the problem this series is trying to address) after the
base changes land in AMBA, via the CoreSight tree.
Suzuki
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [syzbot] Monthly arm report (Mar 2024)
From: syzbot @ 2024-03-27 9:21 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, syzkaller-bugs
Hello arm maintainers/developers,
This is a 31-day syzbot report for the arm subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/arm
During the period, 0 new issues were detected and 0 were fixed.
In total, 4 issues are still open and 4 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 924 Yes BUG: bad usercopy in fpa_set
https://syzkaller.appspot.com/bug?extid=cb76c2983557a07cdb14
<2> 22 No WARNING in delayed_work_timer_fn
https://syzkaller.appspot.com/bug?extid=e13e654d315d4da1277c
<3> 8 No WARNING in do_sve_acc
https://syzkaller.appspot.com/bug?extid=95ffb6a83b20ea7f4f55
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] Improvement around mtk_vcodec_mem_free() logging and usage
From: Fei Shao @ 2024-03-27 9:18 UTC (permalink / raw)
To: Hans Verkuil
Cc: Andrew-CT Chen, Matthias Brugger, Mauro Carvalho Chehab,
Nicolas Dufresne, Tiffany Lin, Xiaoyong Lu, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek,
AngeloGioacchino Del Regno
In-Reply-To: <20231221092226.1395427-1-fshao@chromium.org>
On Thu, Dec 21, 2023 at 5:23 PM Fei Shao <fshao@chromium.org> wrote:
>
> Hi,
>
> This series includes some improvements around mtk_vcodec_mem_free() in
> mtk_vcodec_util.c.
>
> I noticed that mtk_vcodec_mem_free() generates a spurious error if the
> target DMA buffer has been freed previously:
> mtk_vcodec_mem_free(),69: [MTK_V4L2][ERROR] 18000000.video-codec
> dma_free size=0 failed!
>
> The warning is harmless, but it brings some confusion to our developers
> and testing infra, so I sent this series to fix that with some minor
> improvement for the driver alongside.
>
> The first two patches are for aesthetic and style improvements, the
> third tries to make the error logs more informative, and the last adds
> back the missing checks when calling the free function.
>
> Regards,
> Fei
>
> v1: https://lore.kernel.org/all/20231113123049.4117280-1-fshao@chromium.org/
>
> Changes in v2:
> - rebased on top of next-20231219
> - revise commit message for clearer intention and rationale
> - update the error messages based on the suggestion
>
> Fei Shao (4):
> media: mediatek: vcodec: Replace dev_name in error string
> media: mediatek: vcodec: Drop unnecessary variable
> media: mediatek: vcodec: Update mtk_vcodec_mem_free() error messages
> media: mediatek: vcodec: Only free buffer VA that is not NULL
>
> .../mediatek/vcodec/common/mtk_vcodec_util.c | 23 +++++++++----------
> .../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 22 ++++++++++++------
> .../vcodec/encoder/venc/venc_h264_if.c | 5 ++--
> 3 files changed, 29 insertions(+), 21 deletions(-)
Hi Hans,
I'd like to get some attention for this series in case it has been
overlooked. It still applies to next-20240327 without conflict.
Please let me know if you have any feedback or concerns on this.
Thank you,
Fei
>
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 8/8] PCI: endpoint: Remove "core_init_notifier" flag
From: Manivannan Sadhasivam @ 2024-03-27 9:13 UTC (permalink / raw)
To: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Marek Vasut, Yoshihiro Shimoda,
Thierry Reding, Jonathan Hunter, Vidya Sagar, Vignesh Raghavendra,
Richard Zhu, Lucas Stach, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Minghuan Lian, Mingkai Hu, Roy Zang, Kunihiko Hayashi,
Masami Hiramatsu, Kishon Vijay Abraham I, Jesper Nilsson,
Srikanth Thokala, Shawn Lin, Heiko Stuebner,
Kishon Vijay Abraham I
Cc: linux-pci, linux-kernel, linux-renesas-soc, linux-arm-msm,
linux-tegra, linux-omap, linux-arm-kernel, linuxppc-dev,
Niklas Cassel, linux-arm-kernel, linux-rockchip,
Manivannan Sadhasivam
In-Reply-To: <20240327-pci-dbi-rework-v12-0-082625472414@linaro.org>
"core_init_notifier" flag is set by the glue drivers requiring refclk from
the host to complete the DWC core initialization. Also, those drivers will
send a notification to the EPF drivers once the initialization is fully
completed using the pci_epc_init_notify() API. Only then, the EPF drivers
will start functioning.
For the rest of the drivers generating refclk locally, EPF drivers will
start functioning post binding with them. EPF drivers rely on the
'core_init_notifier' flag to differentiate between the drivers.
Unfortunately, this creates two different flows for the EPF drivers.
So to avoid that, let's get rid of the "core_init_notifier" flag and follow
a single initialization flow for the EPF drivers. This is done by calling
the dw_pcie_ep_init_notify() from all glue drivers after the completion of
dw_pcie_ep_init_registers() API. This will allow all the glue drivers to
send the notification to the EPF drivers once the initialization is fully
completed.
Only difference here is that, the drivers requiring refclk from host will
send the notification once refclk is received, while others will send it
during probe time itself.
But this also requires the EPC core driver to deliver the notification
after EPF driver bind. Because, the glue driver can send the notification
before the EPF drivers bind() and in those cases the EPF drivers will miss
the event. To accommodate this, EPC core is now caching the state of the
EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
notification to EPF drivers based on that after each EPF driver bind.
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/controller/cadence/pcie-cadence-ep.c | 2 ++
drivers/pci/controller/dwc/pci-dra7xx.c | 2 ++
drivers/pci/controller/dwc/pci-imx6.c | 2 ++
drivers/pci/controller/dwc/pci-keystone.c | 2 ++
drivers/pci/controller/dwc/pci-layerscape-ep.c | 2 ++
drivers/pci/controller/dwc/pcie-artpec6.c | 2 ++
drivers/pci/controller/dwc/pcie-designware-ep.c | 1 +
drivers/pci/controller/dwc/pcie-designware-plat.c | 2 ++
drivers/pci/controller/dwc/pcie-keembay.c | 2 ++
drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 -
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 ++
drivers/pci/controller/dwc/pcie-tegra194.c | 1 -
drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 ++
drivers/pci/controller/pcie-rcar-ep.c | 2 ++
drivers/pci/controller/pcie-rockchip-ep.c | 2 ++
drivers/pci/endpoint/functions/pci-epf-test.c | 18 +++++-------------
drivers/pci/endpoint/pci-ep-cfs.c | 9 +++++++++
drivers/pci/endpoint/pci-epc-core.c | 22 ++++++++++++++++++++++
include/linux/pci-epc.h | 7 ++++---
19 files changed, 65 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 81c50dc64da9..55c42ca2b777 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -746,6 +746,8 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
spin_lock_init(&ep->lock);
+ pci_epc_init_notify(epc);
+
return 0;
free_epc_mem:
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
index 395042b29ffc..d2d17d37d3e0 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -474,6 +474,8 @@ static int dra7xx_add_pcie_ep(struct dra7xx_pcie *dra7xx,
return ret;
}
+ dw_pcie_ep_init_notify(ep);
+
return 0;
}
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 8d28ecc381bc..917c69edee1d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1131,6 +1131,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
return ret;
}
+ dw_pcie_ep_init_notify(ep);
+
/* Start LTSSM. */
imx6_pcie_ltssm_enable(dev);
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 81ebac520650..d3a7d14ee685 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -1293,6 +1293,8 @@ static int ks_pcie_probe(struct platform_device *pdev)
goto err_ep_init;
}
+ dw_pcie_ep_init_notify(&pci->ep);
+
break;
default:
dev_err(dev, "INVALID device type %d\n", mode);
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index 9eb2233e3d7f..7dde6d5fa4d8 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -286,6 +286,8 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
return ret;
}
+ dw_pcie_ep_init_notify(&pci->ep);
+
return ls_pcie_ep_interrupt_init(pcie, pdev);
}
diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c b/drivers/pci/controller/dwc/pcie-artpec6.c
index a6095561db4a..a4630b92489b 100644
--- a/drivers/pci/controller/dwc/pcie-artpec6.c
+++ b/drivers/pci/controller/dwc/pcie-artpec6.c
@@ -452,6 +452,8 @@ static int artpec6_pcie_probe(struct platform_device *pdev)
return ret;
}
+ dw_pcie_ep_init_notify(&pci->ep);
+
break;
default:
dev_err(dev, "INVALID device type %d\n", artpec6_pcie->mode);
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 2063cf2049e5..47391d7d3a73 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -632,6 +632,7 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
dw_pcie_edma_remove(pci);
+ ep->epc->init_complete = false;
}
EXPORT_SYMBOL_GPL(dw_pcie_ep_cleanup);
diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c b/drivers/pci/controller/dwc/pcie-designware-plat.c
index ca9b22e654cd..8490c5d6ff9f 100644
--- a/drivers/pci/controller/dwc/pcie-designware-plat.c
+++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
@@ -154,6 +154,8 @@ static int dw_plat_pcie_probe(struct platform_device *pdev)
dw_pcie_ep_deinit(&pci->ep);
}
+ dw_pcie_ep_init_notify(&pci->ep);
+
break;
default:
dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode);
diff --git a/drivers/pci/controller/dwc/pcie-keembay.c b/drivers/pci/controller/dwc/pcie-keembay.c
index b2556dbcffb5..98bbc83182b4 100644
--- a/drivers/pci/controller/dwc/pcie-keembay.c
+++ b/drivers/pci/controller/dwc/pcie-keembay.c
@@ -442,6 +442,8 @@ static int keembay_pcie_probe(struct platform_device *pdev)
return ret;
}
+ dw_pcie_ep_init_notify(&pci->ep);
+
break;
default:
dev_err(dev, "Invalid device type %d\n", pcie->mode);
diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
index 3697b4a944cc..2fb8c15e7a91 100644
--- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
+++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
@@ -775,7 +775,6 @@ static void qcom_pcie_ep_init_debugfs(struct qcom_pcie_ep *pcie_ep)
static const struct pci_epc_features qcom_pcie_epc_features = {
.linkup_notifier = true,
- .core_init_notifier = true,
.msi_capable = true,
.msix_capable = false,
.align = SZ_4K,
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index e155a905fb4f..cfeccc2f9ee1 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -437,6 +437,8 @@ static int rcar_gen4_add_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
rcar_gen4_pcie_ep_deinit(rcar);
}
+ dw_pcie_ep_init_notify(ep);
+
return ret;
}
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index db043f579fbe..ddc23602eca7 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -2006,7 +2006,6 @@ static int tegra_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
static const struct pci_epc_features tegra_pcie_epc_features = {
.linkup_notifier = true,
- .core_init_notifier = true,
.msi_capable = false,
.msix_capable = false,
.bar[BAR_0] = { .type = BAR_FIXED, .fixed_size = SZ_1M,
diff --git a/drivers/pci/controller/dwc/pcie-uniphier-ep.c b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
index 0e5e7344de48..a2b844268e28 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier-ep.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
@@ -410,6 +410,8 @@ static int uniphier_pcie_ep_probe(struct platform_device *pdev)
return ret;
}
+ dw_pcie_ep_init_notify(&priv->pci.ep);
+
return 0;
}
diff --git a/drivers/pci/controller/pcie-rcar-ep.c b/drivers/pci/controller/pcie-rcar-ep.c
index 05967c6c0b42..047e2cef5afc 100644
--- a/drivers/pci/controller/pcie-rcar-ep.c
+++ b/drivers/pci/controller/pcie-rcar-ep.c
@@ -542,6 +542,8 @@ static int rcar_pcie_ep_probe(struct platform_device *pdev)
goto err_pm_put;
}
+ pci_epc_init_notify(epc);
+
return 0;
err_pm_put:
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c
index c9046e97a1d2..8613df8184df 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -609,6 +609,8 @@ static int rockchip_pcie_ep_probe(struct platform_device *pdev)
rockchip_pcie_write(rockchip, PCIE_CLIENT_CONF_ENABLE,
PCIE_CLIENT_CONFIG);
+ pci_epc_init_notify(epc);
+
return 0;
err_epc_mem_exit:
pci_epc_mem_exit(epc);
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index cd4ffb39dcdc..212fc303fb63 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -753,6 +753,7 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
const struct pci_epc_features *epc_features;
struct pci_epc *epc = epf->epc;
struct device *dev = &epf->dev;
+ bool linkup_notifier = false;
bool msix_capable = false;
bool msi_capable = true;
int ret;
@@ -795,6 +796,10 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
}
}
+ linkup_notifier = epc_features->linkup_notifier;
+ if (!linkup_notifier)
+ queue_work(kpcitest_workqueue, &epf_test->cmd_handler.work);
+
return 0;
}
@@ -890,8 +895,6 @@ static int pci_epf_test_bind(struct pci_epf *epf)
const struct pci_epc_features *epc_features;
enum pci_barno test_reg_bar = BAR_0;
struct pci_epc *epc = epf->epc;
- bool linkup_notifier = false;
- bool core_init_notifier = false;
if (WARN_ON_ONCE(!epc))
return -EINVAL;
@@ -902,8 +905,6 @@ static int pci_epf_test_bind(struct pci_epf *epf)
return -EOPNOTSUPP;
}
- linkup_notifier = epc_features->linkup_notifier;
- core_init_notifier = epc_features->core_init_notifier;
test_reg_bar = pci_epc_get_first_free_bar(epc_features);
if (test_reg_bar < 0)
return -EINVAL;
@@ -916,21 +917,12 @@ static int pci_epf_test_bind(struct pci_epf *epf)
if (ret)
return ret;
- if (!core_init_notifier) {
- ret = pci_epf_test_core_init(epf);
- if (ret)
- return ret;
- }
-
epf_test->dma_supported = true;
ret = pci_epf_test_init_dma_chan(epf_test);
if (ret)
epf_test->dma_supported = false;
- if (!linkup_notifier && !core_init_notifier)
- queue_work(kpcitest_workqueue, &epf_test->cmd_handler.work);
-
return 0;
}
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c
index 0ea64e24ed61..3b21e28f9b59 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -64,6 +64,9 @@ static int pci_secondary_epc_epf_link(struct config_item *epf_item,
return ret;
}
+ /* Send any pending EPC initialization complete to the EPF driver */
+ pci_epc_notify_pending_init(epc, epf);
+
return 0;
}
@@ -125,6 +128,9 @@ static int pci_primary_epc_epf_link(struct config_item *epf_item,
return ret;
}
+ /* Send any pending EPC initialization complete to the EPF driver */
+ pci_epc_notify_pending_init(epc, epf);
+
return 0;
}
@@ -230,6 +236,9 @@ static int pci_epc_epf_link(struct config_item *epc_item,
return ret;
}
+ /* Send any pending EPC initialization complete to the EPF driver */
+ pci_epc_notify_pending_init(epc, epf);
+
return 0;
}
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index da3fc0795b0b..47d27ec7439d 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -748,10 +748,32 @@ void pci_epc_init_notify(struct pci_epc *epc)
epf->event_ops->core_init(epf);
mutex_unlock(&epf->lock);
}
+ epc->init_complete = true;
mutex_unlock(&epc->list_lock);
}
EXPORT_SYMBOL_GPL(pci_epc_init_notify);
+/**
+ * pci_epc_notify_pending_init() - Notify the pending EPC device initialization
+ * complete to the EPF device
+ * @epc: the EPC device whose core initialization is pending to be notified
+ * @epf: the EPF device to be notified
+ *
+ * Invoke to notify the pending EPC device initialization complete to the EPF
+ * device. This is used to deliver the notification if the EPC initialization
+ * got completed before the EPF driver bind.
+ */
+void pci_epc_notify_pending_init(struct pci_epc *epc, struct pci_epf *epf)
+{
+ if (epc->init_complete) {
+ mutex_lock(&epf->lock);
+ if (epf->event_ops && epf->event_ops->core_init)
+ epf->event_ops->core_init(epf);
+ mutex_unlock(&epf->lock);
+ }
+}
+EXPORT_SYMBOL_GPL(pci_epc_notify_pending_init);
+
/**
* pci_epc_bme_notify() - Notify the EPF device that the EPC device has received
* the BME event from the Root complex
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cc2f70d061c8..acc5f96161fe 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -128,6 +128,8 @@ struct pci_epc_mem {
* @group: configfs group representing the PCI EPC device
* @lock: mutex to protect pci_epc ops
* @function_num_map: bitmap to manage physical function number
+ * @init_complete: flag to indicate whether the EPC initialization is complete
+ * or not
*/
struct pci_epc {
struct device dev;
@@ -143,6 +145,7 @@ struct pci_epc {
/* mutex to protect against concurrent access of EP controller */
struct mutex lock;
unsigned long function_num_map;
+ bool init_complete;
};
/**
@@ -179,8 +182,6 @@ struct pci_epc_bar_desc {
/**
* struct pci_epc_features - features supported by a EPC device per function
* @linkup_notifier: indicate if the EPC device can notify EPF driver on link up
- * @core_init_notifier: indicate cores that can notify about their availability
- * for initialization
* @msi_capable: indicate if the endpoint function has MSI capability
* @msix_capable: indicate if the endpoint function has MSI-X capability
* @bar: array specifying the hardware description for each BAR
@@ -188,7 +189,6 @@ struct pci_epc_bar_desc {
*/
struct pci_epc_features {
unsigned int linkup_notifier : 1;
- unsigned int core_init_notifier : 1;
unsigned int msi_capable : 1;
unsigned int msix_capable : 1;
struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
@@ -225,6 +225,7 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
void pci_epc_linkup(struct pci_epc *epc);
void pci_epc_linkdown(struct pci_epc *epc);
void pci_epc_init_notify(struct pci_epc *epc);
+void pci_epc_notify_pending_init(struct pci_epc *epc, struct pci_epf *epf);
void pci_epc_bme_notify(struct pci_epc *epc);
void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf,
enum pci_epc_interface_type type);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox