* [PATCH linux-next v4 4/4] clocksource/drivers/timer-mediatek: Make timer-mediatek become loadable module
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, Chun-Hung Wu, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20230421034649.15247-1-walter.chang@mediatek.com>
From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Make the timer-mediatek driver which can register
an always-on timer as tick_broadcast_device on
MediaTek SoCs become loadable module in GKI.
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Signed-off-by: Walter Chang <walter.chang@mediatek.com>
Tested-by: Walter Chang <walter.chang@mediatek.com>
---
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/timer-mediatek.c | 33 ++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 526382dc7482..62103c0807f7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -472,7 +472,7 @@ config SYS_SUPPORTS_SH_CMT
bool
config MTK_TIMER
- bool "Mediatek timer driver" if COMPILE_TEST
+ tristate "MediaTek timer driver"
depends on HAS_IOMEM
select TIMER_OF
select CLKSRC_MMIO
diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 7bcb4a3f26fb..afeacb509481 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -13,6 +13,9 @@
#include <linux/clocksource.h>
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
#include <linux/sched_clock.h>
#include <linux/slab.h>
#include "timer-of.h"
@@ -337,5 +340,35 @@ static int __init mtk_gpt_init(struct device_node *node)
return 0;
}
+
+#ifndef MODULE
TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
TIMER_OF_DECLARE(mtk_mt6765, "mediatek,mt6765-timer", mtk_syst_init);
+#else
+static int mtk_timer_probe(struct platform_device *pdev)
+{
+ int (*timer_init)(struct device_node *node);
+ struct device_node *np = pdev->dev.of_node;
+
+ timer_init = of_device_get_match_data(&pdev->dev);
+ return timer_init(np);
+}
+
+static const struct of_device_id mtk_timer_match_table[] = {
+ { .compatible = "mediatek,mt6577-timer", .data = mtk_gpt_init },
+ { .compatible = "mediatek,mt6765-timer", .data = mtk_syst_init },
+ { /* sentinel */ }
+};
+
+static struct platform_driver mtk_timer_driver = {
+ .probe = mtk_timer_probe,
+ .driver = {
+ .name = "mediatek-timer",
+ .of_match_table = mtk_timer_match_table,
+ },
+};
+module_platform_driver(mtk_timer_driver);
+
+MODULE_DESCRIPTION("MediaTek Timer driver");
+MODULE_LICENSE("GPL v2");
+#endif
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH linux-next v4 1/4] time/sched_clock: Export sched_clock_register()
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, Chun-Hung Wu, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20230421034649.15247-1-walter.chang@mediatek.com>
From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
clocksource driver may use sched_clock_register()
to resigter itself as a sched_clock source.
Export it to support building such driver
as module, like timer-mediatek.c
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
---
kernel/time/sched_clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 8464c5acc913..8e49e87d1221 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -150,8 +150,7 @@ static enum hrtimer_restart sched_clock_poll(struct hrtimer *hrt)
return HRTIMER_RESTART;
}
-void __init
-sched_clock_register(u64 (*read)(void), int bits, unsigned long rate)
+void sched_clock_register(u64 (*read)(void), int bits, unsigned long rate)
{
u64 res, wrap, new_mask, new_epoch, cyc, ns;
u32 new_mult, new_shift;
@@ -223,6 +222,7 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned long rate)
pr_debug("Registered %pS as sched_clock source\n", read);
}
+EXPORT_SYMBOL_GPL(sched_clock_register);
void __init generic_sched_clock_init(void)
{
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH linux-next v4 3/4] clocksource/drivers/timer-of: Remove __init markings
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, Chun-Hung Wu, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20230421034649.15247-1-walter.chang@mediatek.com>
From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Remove __init markings to allow timer drivers
can be compiled as modules.
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
---
drivers/clocksource/timer-of.c | 23 ++++++++++++-----------
drivers/clocksource/timer-of.h | 6 +++---
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
index c3f54d9912be..59bc5921acad 100644
--- a/drivers/clocksource/timer-of.c
+++ b/drivers/clocksource/timer-of.c
@@ -19,7 +19,7 @@
*
* Free the irq resource
*/
-static __init void timer_of_irq_exit(struct of_timer_irq *of_irq)
+static void timer_of_irq_exit(struct of_timer_irq *of_irq)
{
struct timer_of *to = container_of(of_irq, struct timer_of, of_irq);
@@ -47,8 +47,8 @@ static __init void timer_of_irq_exit(struct of_timer_irq *of_irq)
*
* Returns 0 on success, < 0 otherwise
*/
-static __init int timer_of_irq_init(struct device_node *np,
- struct of_timer_irq *of_irq)
+static int timer_of_irq_init(struct device_node *np,
+ struct of_timer_irq *of_irq)
{
int ret;
struct timer_of *to = container_of(of_irq, struct timer_of, of_irq);
@@ -91,7 +91,7 @@ static __init int timer_of_irq_init(struct device_node *np,
*
* Disables and releases the refcount on the clk
*/
-static __init void timer_of_clk_exit(struct of_timer_clk *of_clk)
+static void timer_of_clk_exit(struct of_timer_clk *of_clk)
{
of_clk->rate = 0;
clk_disable_unprepare(of_clk->clk);
@@ -107,8 +107,8 @@ static __init void timer_of_clk_exit(struct of_timer_clk *of_clk)
*
* Returns 0 on success, < 0 otherwise
*/
-static __init int timer_of_clk_init(struct device_node *np,
- struct of_timer_clk *of_clk)
+static int timer_of_clk_init(struct device_node *np,
+ struct of_timer_clk *of_clk)
{
int ret;
@@ -146,13 +146,13 @@ static __init int timer_of_clk_init(struct device_node *np,
goto out;
}
-static __init void timer_of_base_exit(struct of_timer_base *of_base)
+static void timer_of_base_exit(struct of_timer_base *of_base)
{
iounmap(of_base->base);
}
-static __init int timer_of_base_init(struct device_node *np,
- struct of_timer_base *of_base)
+static int timer_of_base_init(struct device_node *np,
+ struct of_timer_base *of_base)
{
of_base->base = of_base->name ?
of_io_request_and_map(np, of_base->index, of_base->name) :
@@ -165,7 +165,7 @@ static __init int timer_of_base_init(struct device_node *np,
return 0;
}
-int __init timer_of_init(struct device_node *np, struct timer_of *to)
+int timer_of_init(struct device_node *np, struct timer_of *to)
{
int ret = -EINVAL;
int flags = 0;
@@ -209,6 +209,7 @@ int __init timer_of_init(struct device_node *np, struct timer_of *to)
timer_of_base_exit(&to->of_base);
return ret;
}
+EXPORT_SYMBOL_GPL(timer_of_init);
/**
* timer_of_cleanup - release timer_of resources
@@ -217,7 +218,7 @@ int __init timer_of_init(struct device_node *np, struct timer_of *to)
* Release the resources that has been used in timer_of_init().
* This function should be called in init error cases
*/
-void __init timer_of_cleanup(struct timer_of *to)
+void timer_of_cleanup(struct timer_of *to)
{
if (to->flags & TIMER_OF_IRQ)
timer_of_irq_exit(&to->of_irq);
diff --git a/drivers/clocksource/timer-of.h b/drivers/clocksource/timer-of.h
index a5478f3e8589..5d1472846346 100644
--- a/drivers/clocksource/timer-of.h
+++ b/drivers/clocksource/timer-of.h
@@ -66,9 +66,9 @@ static inline unsigned long timer_of_period(struct timer_of *to)
return to->of_clk.period;
}
-extern int __init timer_of_init(struct device_node *np,
- struct timer_of *to);
+extern int timer_of_init(struct device_node *np,
+ struct timer_of *to);
-extern void __init timer_of_cleanup(struct timer_of *to);
+extern void timer_of_cleanup(struct timer_of *to);
#endif
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH linux-next v4 2/4] clocksource/drivers/mmio: Export clocksource_mmio_init()
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, Chun-Hung Wu, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20230421034649.15247-1-walter.chang@mediatek.com>
From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Export clocksource_mmio_init() and clocksource_mmio_readl_up()
to support building clocksource driver as module,
such as timer-mediatek.c.
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
---
drivers/clocksource/mmio.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index 9de751531831..b08b2f9d7a8b 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -21,6 +21,7 @@ u64 clocksource_mmio_readl_up(struct clocksource *c)
{
return (u64)readl_relaxed(to_mmio_clksrc(c)->reg);
}
+EXPORT_SYMBOL_GPL(clocksource_mmio_readl_up);
u64 clocksource_mmio_readl_down(struct clocksource *c)
{
@@ -46,9 +47,9 @@ u64 clocksource_mmio_readw_down(struct clocksource *c)
* @bits: Number of valid bits
* @read: One of clocksource_mmio_read*() above
*/
-int __init clocksource_mmio_init(void __iomem *base, const char *name,
- unsigned long hz, int rating, unsigned bits,
- u64 (*read)(struct clocksource *))
+int clocksource_mmio_init(void __iomem *base, const char *name,
+ unsigned long hz, int rating, unsigned bits,
+ u64 (*read)(struct clocksource *))
{
struct clocksource_mmio *cs;
@@ -68,3 +69,4 @@ int __init clocksource_mmio_init(void __iomem *base, const char *name,
return clocksource_register_hz(&cs->clksrc, hz);
}
+EXPORT_SYMBOL_GPL(clocksource_mmio_init);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH linux-next v4 0/4] Support timer drivers as loadable modules
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, linux-kernel, linux-arm-kernel, linux-mediatek
From: Walter Chang <walter.chang@mediatek.com>
This set of patches aims to make SoC related timer drivers, such as
timer-mediatek.c become loadable modules for the Generic Kernel Image
(GKI).
This driver registers an always-on timer as tick_broadcast_device on
MediaTek SoCs. If the system does not load this module at startup,
system will also boot normally by using built-in `bc_hrtimer` instead.
Besides, the previous experiment [1] indicates that the SYST/GPT, in
combination with a loadable module, is fully operational.
The first three patches export functions and remove __init markings to
support loadable timer modules.
The fourth patch makes timer-mediatek.c become loadable module for GKI.
[1]
https://lore.kernel.org/all/32777456f8e0f98e4cd5b950f421d21f71b149cf.camel@mediatek.com/#t
[v4]
- Fix review comments pointed by Angelo
[v3]
- Rebase on linux-next
[v2]
- Convert timer-mediatek.c driver to loadable module
Chun-Hung Wu (4):
time/sched_clock: Export sched_clock_register()
clocksource/drivers/mmio: Export clocksource_mmio_init()
clocksource/drivers/timer-of: Remove __init markings
clocksource/drivers/timer-mediatek: Make timer-mediatek become
loadable module
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/mmio.c | 8 ++++---
drivers/clocksource/timer-mediatek.c | 33 ++++++++++++++++++++++++++++
drivers/clocksource/timer-of.c | 23 +++++++++----------
drivers/clocksource/timer-of.h | 6 ++---
kernel/time/sched_clock.c | 4 ++--
6 files changed, 56 insertions(+), 20 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] KVM: arm64: Acquire mp_state_lock in kvm_arch_vcpu_ioctl_vcpu_init()
From: Reiji Watanabe @ 2023-04-21 3:27 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, kvmarm, kvm, linux-arm-kernel, James Morse,
Alexandru Elisei, Zenghui Yu, Suzuki K Poulose, Paolo Bonzini,
Ricardo Koller, Jing Zhang, Raghavendra Rao Anata, Will Deacon
In-Reply-To: <86y1mnj7dg.wl-maz@kernel.org>
On Thu, Apr 20, 2023 at 1:16 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 20 Apr 2023 03:13:02 +0100,
> Reiji Watanabe <reijiw@google.com> wrote:
> >
> > Hi Marc,
> >
> > On Wed, Apr 19, 2023 at 08:12:45AM +0100, Marc Zyngier wrote:
> > > On Wed, 19 Apr 2023 03:18:51 +0100,
> > > Reiji Watanabe <reijiw@google.com> wrote:
> > > > kvm_arch_vcpu_ioctl_vcpu_init() doesn't acquire mp_state_lock
> > > > when setting the mp_state to KVM_MP_STATE_RUNNABLE. Fix the
> > > > code to acquire the lock.
> > > >
> > > > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > > > ---
> > > > arch/arm64/kvm/arm.c | 5 ++++-
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > > index fbafcbbcc463..388aa4f18f21 100644
> > > > --- a/arch/arm64/kvm/arm.c
> > > > +++ b/arch/arm64/kvm/arm.c
> > > > @@ -1244,8 +1244,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> > > > */
> > > > if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> > > > kvm_arm_vcpu_power_off(vcpu);
> > > > - else
> > > > + else {
> > > > + spin_lock(&vcpu->arch.mp_state_lock);
> > > > WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
> > > > + spin_unlock(&vcpu->arch.mp_state_lock);
> > > > + }
> > > >
> > > > return 0;
> > > > }
> > >
> > > I'm not entirely convinced that this fixes anything. What does the
> > > lock hazard against given that the write is atomic? But maybe a
> >
> > It appears that kvm_psci_vcpu_on() expects the vCPU's mp_state
> > to not be changed by holding the lock. Although I don't think this
> > code practically causes any real issues now, I am a little concerned
> > about leaving one instance that updates mpstate without acquiring the
> > lock, in terms of future maintenance, as holding the lock won't prevent
> > mp_state from being updated.
> >
> > What do you think ?
>
> Right, fair enough. It is probably better to take the lock and not
> have to think of this sort of things... I'm becoming more lazy by the
> minute!
>
> >
> > > slightly more readable of this would be to expand the critical section
> > > this way:
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index 4ec888fdd4f7..bb21d0c25de7 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -1246,11 +1246,15 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> > > /*
> > > * Handle the "start in power-off" case.
> > > */
> > > + spin_lock(&vcpu->arch.mp_state_lock);
> > > +
> > > if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> > > - kvm_arm_vcpu_power_off(vcpu);
> > > + __kvm_arm_vcpu_power_off(vcpu);
> > > else
> > > WRITE_ONCE(vcpu->arch.mp_state.mp_state, KVM_MP_STATE_RUNNABLE);
> > >
> > > + spin_unlock(&vcpu->arch.mp_state_lock);
> > > +
> > > return 0;
> > > }
> > >
> > > Thoughts?
> >
> > Yes, it looks better!
>
> Cool. I've applied this change to your patch, applied the series to
> the lock inversion branch, and remerged the branch in -next.
>
> We're getting there! ;-)
Thank you, Marc!
Reiji
_______________________________________________
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 4/4] spi: s3c64xx: support interrupt based pio mode
From: Jaewon Kim @ 2023-04-21 3:05 UTC (permalink / raw)
To: Andi Shyti
Cc: Mark Brown, Krzysztof Kozlowski, Andi Shyti, Alim Akhtar,
linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419160320.ydgqqftsfn3y33p4@intel.intel>
Hi Andy,
On 23. 4. 20. 01:03, Andi Shyti wrote:
> Hi Jaewon,
>
> On Wed, Apr 19, 2023 at 03:06:39PM +0900, Jaewon Kim wrote:
>> Interrupt based pio mode is supported to reduce CPU load.
>> If transfer size is larger than 32 byte, it is processed using interrupt.
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 82 ++++++++++++++++++++++++++++++++-------
>> 1 file changed, 67 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index cf3060b2639b..ce1afb9a4ed4 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -58,6 +58,8 @@
>> #define S3C64XX_SPI_MODE_BUS_TSZ_HALFWORD (1<<17)
>> #define S3C64XX_SPI_MODE_BUS_TSZ_WORD (2<<17)
>> #define S3C64XX_SPI_MODE_BUS_TSZ_MASK (3<<17)
>> +#define S3C64XX_SPI_MODE_RX_RDY_LVL GENMASK(16, 11)
>> +#define S3C64XX_SPI_MODE_RX_RDY_LVL_SHIFT 11
>> #define S3C64XX_SPI_MODE_SELF_LOOPBACK (1<<3)
>> #define S3C64XX_SPI_MODE_RXDMA_ON (1<<2)
>> #define S3C64XX_SPI_MODE_TXDMA_ON (1<<1)
>> @@ -114,6 +116,8 @@
>>
>> #define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
>>
>> +#define S3C64XX_SPI_POLLING_SIZE 32
>> +
>> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
>> #define is_polling(x) (x->cntrlr_info->polling)
>>
>> @@ -552,10 +556,11 @@ static int s3c64xx_wait_for_dma(struct s3c64xx_spi_driver_data *sdd,
>> }
>>
>> static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>> - struct spi_transfer *xfer)
>> + struct spi_transfer *xfer, int use_irq)
> bool use_irq
Okay, I will change it to bool.
>
>> {
>> void __iomem *regs = sdd->regs;
>> unsigned long val;
>> + unsigned long time;
> this time is used only in "if (use_irq)" can you move its
> declaration under the if?
>
>> u32 status;
>> int loops;
>> u32 cpy_len;
>> @@ -563,17 +568,24 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>> int ms;
>> u32 tx_time;
>>
>> - /* sleep during signal transfer time */
>> - status = readl(regs + S3C64XX_SPI_STATUS);
>> - if (RX_FIFO_LVL(status, sdd) < xfer->len) {
>> - tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
>> - usleep_range(tx_time / 2, tx_time);
>> - }
>> -
>> /* millisecs to xfer 'len' bytes @ 'cur_speed' */
>> ms = xfer->len * 8 * 1000 / sdd->cur_speed;
>> ms += 10; /* some tolerance */
>>
>> + if (use_irq) {
>> + val = msecs_to_jiffies(ms);
>> + time = wait_for_completion_timeout(&sdd->xfer_completion, val);
>> + if (!time)
>> + return -EIO;
>> + } else {
>> + /* sleep during signal transfer time */
>> + status = readl(regs + S3C64XX_SPI_STATUS);
>> + if (RX_FIFO_LVL(status, sdd) < xfer->len) {
>> + tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
>> + usleep_range(tx_time / 2, tx_time);
> yeah... just use 'ms'.
As I mentioned in the previous mail, the unit of tx_time is us.
>
>> + }
>> + }
>> +
>> val = msecs_to_loops(ms);
>> do {
>> cpu_relax();
>> @@ -737,10 +749,13 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
>> void *rx_buf = NULL;
>> int target_len = 0, origin_len = 0;
>> int use_dma = 0;
>> + int use_irq = 0;
>> int status;
>> u32 speed;
>> u8 bpw;
>> unsigned long flags;
>> + u32 rdy_lv;
>> + u32 val;
>>
>> reinit_completion(&sdd->xfer_completion);
>>
>> @@ -761,17 +776,46 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
>> sdd->rx_dma.ch && sdd->tx_dma.ch) {
>> use_dma = 1;
>>
>> - } else if (xfer->len > fifo_len) {
>> + } else if (xfer->len >= fifo_len) {
>> tx_buf = xfer->tx_buf;
>> rx_buf = xfer->rx_buf;
>> origin_len = xfer->len;
>> -
>> target_len = xfer->len;
>> - if (xfer->len > fifo_len)
>> - xfer->len = fifo_len;
>> + xfer->len = fifo_len - 1;
>> }
> Is this change related to this patch?
Yes, it is related to this patch.
If data is filled as much as the size of FIFO, underrun/overrun IRQ occurs.
In CPU polling mode, it did not occur because the FIFO was read before
the IRQ was set.
So, I set xfer->len to fifo_len-1.
>
> The rest looks good.
>
> Andi
Thanks
Jaewon Kim
_______________________________________________
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 3/4] spi: s3c64xx: add sleep during transfer
From: Jaewon Kim @ 2023-04-21 2:53 UTC (permalink / raw)
To: Andi Shyti
Cc: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar,
linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419155617.gobedupbdmdaj4kz@intel.intel>
Hi Andi,
On 23. 4. 20. 00:56, Andi Shyti wrote:
> Hi Jaewon,
>
>>>> In polling mode, the status register is constantly read to check transfer
>>>> completion. It cause excessive CPU usage.
>>>> So, it calculates the SPI transfer time and made it sleep.
>>>>
>>>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>>>> ---
>>>> drivers/spi/spi-s3c64xx.c | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>>>> index 886722fb40ea..cf3060b2639b 100644
>>>> --- a/drivers/spi/spi-s3c64xx.c
>>>> +++ b/drivers/spi/spi-s3c64xx.c
>>>> @@ -561,6 +561,14 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>>>> u32 cpy_len;
>>>> u8 *buf;
>>>> int ms;
>>>> + u32 tx_time;
>>>> +
>>>> + /* sleep during signal transfer time */
>>>> + status = readl(regs + S3C64XX_SPI_STATUS);
>>>> + if (RX_FIFO_LVL(status, sdd) < xfer->len) {
>>>> + tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
>>>> + usleep_range(tx_time / 2, tx_time);
>>>> + }
>>> Did you actually check the delays introduced by it? Is it worth?
>> Yes, I already test it.
>>
>> Throughput was the same, CPU utilization decreased to 30~40% from 100%.
>>
>> Tested board is ExynosAutov9 SADK.
>>
>>
>>>>
>>>> /* millisecs to xfer 'len' bytes @ 'cur_speed' */
>>>> ms = xfer->len * 8 * 1000 / sdd->cur_speed;
>>> You have now some code duplication so this could be combined.
> you could put the 'if' under the 'ms = ...' and just use ms
> without declaring any tx_time.
>
> Andi
The unit of 'tx_time' is 'us'.
tx_time = (xfer->len * 8 * 1000 * 1000) / sdd->cur_speed;
ms = xfer->len * 8 * 1000 / sdd->cur_speed;
I add tx_time to minimize existing code modifications.
If we are not using tx_time, we need to change ms to us and change the
related code.
Thanks
Jaewon Kim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to create ordered workqueues
From: Tejun Heo @ 2023-04-21 2:50 UTC (permalink / raw)
To: jiangshanlai
Cc: linux-kernel, kernel-team, Tejun Heo, Sunil Goutham,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-arm-kernel, netdev
In-Reply-To: <20230421025046.4008499-1-tj@kernel.org>
BACKGROUND
==========
When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be used which can be created
with alloc_ordered_workqueue().
However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.
While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements, this
isn't a state we wanna be in forever.
This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.
WHAT TO LOOK FOR
================
The conversions are from
alloc_workqueue(WQ_UNBOUND | flags, 1, args..)
to
alloc_ordered_workqueue(flags, args...)
which don't cause any functional changes. If you know that fully ordered
execution is not ncessary, please let me know. I'll drop the conversion and
instead add a comment noting the fact to reduce confusion while conversion
is in progress.
If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.
As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Sunil Goutham <sgoutham@marvell.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 7eb2ddbe9bad..a317feb8decb 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -1126,8 +1126,7 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
}
poll:
- lmac->check_link = alloc_workqueue("check_link", WQ_UNBOUND |
- WQ_MEM_RECLAIM, 1);
+ lmac->check_link = alloc_ordered_workqueue("check_link", WQ_MEM_RECLAIM);
if (!lmac->check_link)
return -ENOMEM;
INIT_DELAYED_WORK(&lmac->dwork, bgx_poll_for_link);
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drm/mediatek: fix uninitialized symbol
From: Nancy Lin (林欣螢) @ 2023-04-21 2:11 UTC (permalink / raw)
To: p.zabel@pengutronix.de, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com, chunkuang.hu@kernel.org
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Singo Chang (張興國), daniel@ffwll.ch,
dri-devel@lists.freedesktop.org,
Project_Global_Chrome_Upstream_Group, airlied@gmail.com,
clang-built-linux@googlegroups.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e1619d7a-2ac3-55bf-bcf1-cad3f07d20fe@collabora.com>
Hi Angelo,
On Thu, 2023-04-20 at 14:01 +0200, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Il 20/04/23 12:51, Nancy.Lin ha scritto:
> > fix Smatch static checker warning
> > - uninitialized symbol comp_pdev in mtk_ddp_comp_init.
> >
> > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
>
> I agree with this commit, but please add a Fixes tag.
>
> Thanks,
> Angelo
Thanks for the review. I will resend it with Fixes tag.
Regards,
Nancy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] drm/mediatek: fix uninitialized symbol
From: Nancy.Lin @ 2023-04-21 2:16 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: David Airlie, Daniel Vetter, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel, clang-built-linux,
Project_Global_Chrome_Upstream_Group, singo.chang, Nancy.Lin
fix Smatch static checker warning
- uninitialized symbol comp_pdev in mtk_ddp_comp_init.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
---
v2: add Fixes tag
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index f114da4d36a9..e987ac4481bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -546,7 +546,7 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
unsigned int comp_id)
{
- struct platform_device *comp_pdev;
+ struct platform_device *comp_pdev = NULL;
enum mtk_ddp_comp_type type;
struct mtk_ddp_comp_dev *priv;
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
@@ -588,6 +588,9 @@ int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
type == MTK_DSI)
return 0;
+ if (!comp_pdev)
+ return -EPROBE_DEFER;
+
priv = devm_kzalloc(comp->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/4] spi: s3c64xx: add cpu_relax in polling loop
From: Jaewon Kim @ 2023-04-21 1:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <01d22e48-40f0-b1dd-aa00-cf484c4364ee@linaro.org>
On 23. 4. 21. 00:39, Krzysztof Kozlowski wrote:
> On 19/04/2023 13:13, Jaewon Kim wrote:
>> On 23. 4. 19. 17:14, Krzysztof Kozlowski wrote:
>>> On 19/04/2023 08:06, Jaewon Kim wrote:
>>>> Adds cpu_relax() to prevent long busy-wait.
>>> How cpu_relax prevents long waiting?
>> As I know, cpu_relax() can be converted to yield. This can prevent
>> excessive use of the CPU in busy-loop.
> That's ok, you just wrote that it will prevent long waiting, so I assume
> it will shorten the wait time.
>
>> I'll replace poor sentence like below in v3.
>>
>> ("Adds cpu_relax() to allow CPU relaxation in busy-loop")
>>
>>>> There is busy-wait loop to check data transfer completion in polling mode.
>>>>
>>>> Signed-off-by: Jaewon Kim<jaewon02.kim@samsung.com>
>>>> ---
>>>> drivers/spi/spi-s3c64xx.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>>>> index 273aa02322d9..886722fb40ea 100644
>>>> --- a/drivers/spi/spi-s3c64xx.c
>>>> +++ b/drivers/spi/spi-s3c64xx.c
>>>> @@ -568,6 +568,7 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>>>>
>>>> val = msecs_to_loops(ms);
>>>> do {
>>>> + cpu_relax();
>>> Shouldn't this be just readl_poll_timeout()? Or the syntax would be too
>>> complicated?
>> I think we can replace this while() loop to readl_poll_timeout().
>>
>> However, we should use 0 value as 'delay_us' parameter. Because delay
>> can affect throughput.
>>
>>
>> My purpose is add relax to this busy-loop.
>>
>> we cannot give relax if we change to readl_poll_timeout().
> readl_poll_timeout() will know to do the best. You do not need to add
> cpu_relax there.
Okay, I will change it to readl_poll_timeout()
>
> Best regards,
> Krzysztof
>
>
Thanks
Jaewon Kim
_______________________________________________
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 1/4] spi: s3c64xx: changed to PIO mode if there is no DMA
From: Jaewon Kim @ 2023-04-21 1:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <087ba4df-7575-acce-309a-efb5115a987d@linaro.org>
On 23. 4. 21. 00:40, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> Polling mode supported with qurik if there was no DMA in the SOC.
>> However, there are cased where we cannot or do not want to use DMA.
>> To support this case, if DMA is not set, it is switched to polling mode.
>>
> (...)
>
>> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
>> -#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
>> +#define is_polling(x) (x->cntrlr_info->polling)
>>
>> #define RXBUSY (1<<2)
>> #define TXBUSY (1<<3)
>> @@ -1067,6 +1066,11 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
>> sci->num_cs = temp;
>> }
>>
>> + if (!of_find_property(dev->of_node, "dmas", NULL)) {
> of_property_present()
I will change it to of_property_present().
>
> Best regards,
> Krzysztof
>
>
Thanks
Jaewon Kim
_______________________________________________
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 1/4] spi: s3c64xx: changed to PIO mode if there is no DMA
From: Jaewon Kim @ 2023-04-21 1:43 UTC (permalink / raw)
To: Andi Shyti
Cc: Mark Brown, Krzysztof Kozlowski, Andi Shyti, Alim Akhtar,
linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <20230419154657.h2kp7ouddy6m7l4r@intel.intel>
Hi Andi,
On 23. 4. 20. 00:46, Andi Shyti wrote:
> Hi Jaewon,
>
> On Wed, Apr 19, 2023 at 03:06:36PM +0900, Jaewon Kim wrote:
>> Polling mode supported with qurik if there was no DMA in the SOC.
> I think you want to say here that "Through quirks we choose to
> use polling mode whenever there is no DMA in the SoC".
>
>> However, there are cased where we cannot or do not want to use DMA.
> /cased/cases/
>
>> To support this case, if DMA is not set, it is switched to polling mode.
> You haven't really described what you are doing here... you could
> just write something like: "Use DTS properties to select wether
> to use polling or DMA mode."
>
> Side note, please use the imperative form when you want to
> describe what you have done to fix the issue.
Thanks for guide.
I will change description in v3.
>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 8 ++++++--
>> include/linux/platform_data/spi-s3c64xx.h | 1 +
>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index 71d324ec9a70..273aa02322d9 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -19,7 +19,6 @@
>> #include <linux/platform_data/spi-s3c64xx.h>
>>
>> #define MAX_SPI_PORTS 12
>> -#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
>> #define S3C64XX_SPI_QUIRK_CS_AUTO (1 << 1)
>> #define AUTOSUSPEND_TIMEOUT 2000
>>
>> @@ -116,7 +115,7 @@
>> #define S3C64XX_SPI_TRAILCNT S3C64XX_SPI_MAX_TRAILCNT
>>
>> #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
>> -#define is_polling(x) (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
>> +#define is_polling(x) (x->cntrlr_info->polling)
>>
>> #define RXBUSY (1<<2)
>> #define TXBUSY (1<<3)
>> @@ -1067,6 +1066,11 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
>> sci->num_cs = temp;
>> }
>>
>> + if (!of_find_property(dev->of_node, "dmas", NULL)) {
>> + dev_warn(dev, "cannot find DMA, changed to PIO mode\n");
>> + sci->polling = 1;
> sci->polling = true;
>
> But it could be even better:
>
> sci->polling = !of_find_property(dev->of_node, "dmas", NULL));
>
> and you get rid of the dev_warn() that is not required.
>
> Andi
Okay, I will change 1 to 'true'..
Thanks
Jaewon Kim
_______________________________________________
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 1/3] ARM: dts: sun5i: chip: Enable bluetooth
From: Saravana Kannan @ 2023-04-21 1:43 UTC (permalink / raw)
To: Jonathan McDowell
Cc: Andre Przywara, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <ZEGOk1isRhaekk3h@earth.li>
On Thu, Apr 20, 2023 at 12:12 PM Jonathan McDowell <noodles@earth.li> wrote:
>
> On Sun, Apr 16, 2023 at 01:24:21AM +0100, Andre Przywara wrote:
> > On Sat, 15 Apr 2023 18:46:03 +0100
> > Jonathan McDowell <noodles@earth.li> wrote:
> >
> > > The C.H.I.P has an rtl8723bs device with the bluetooth interface hooked
> > > up on UART3. Support for this didn't exist in mainline when the DTS was
> > > initially added, but it does now, so enable it.
> > >
> > > Signed-off-by: Jonathan McDowell <noodles@earth.li>
> > > ---
> > > arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
> > > index fd37bd1f3920..4d72a181d8aa 100644
> > > --- a/arch/arm/boot/dts/sun5i-r8-chip.dts
> > > +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
> > > @@ -255,6 +255,10 @@ &uart3 {
> > > pinctrl-0 = <&uart3_pg_pins>,
> > > <&uart3_cts_rts_pg_pins>;
> > > status = "okay";
> > > +
> > > + bluetooth {
> > > + compatible = "realtek,rtl8723bs-bt";
> > > + }
> >
> > As the kernel test robot already pointed out, there is a semicolon
> > missing here.
> > Otherwise looks good (dt-validate passes), but don't know if there are
> > any wakeup GPIOs connected (can't seem to find a schematic?).
>
> So there are wakeups, but if I add:
>
> device-wake-gpios = <&axp_gpio 3 GPIO_ACTIVE_LOW>;
> host-wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>
> then some odd sort of dependency issue happens where the serial port
> load is deferred waiting for the GPIO to appear, and then the device
> doesn't work.
When you say your device doesn't work, are you saying it never probes?
<debugfs>/devices_deferred should tell you what devices have deferred and why.
> Error in dmesg is:
>
> serial serial0-0: deferred probe pending
>
> on 6.3-rc and on 6.1 I get:
>
> dw-apb-uart 1c28c00.serial: Failed to create device link (0x180) with axp20x-gpio
This error message doesn't block anything. So I don't think this is
the cause of your blocking issue. But I still want to understand why
this error message is showing up.
> I'm not clear why it's trying to link the serial port to the GPIO; it
> seems that it should be the bluetooth device that depends on both the
> UART and the GPIO,
A fix for the device link error message went in on v6.3-rc3. Is that
the 6.3 version you tested this on?
Also, I tried looking into the UART driver
(drivers/tty/serial/8250/8250_dw.c) but it wasn't clear how it ends up
populating the bluetooth serial device. If you can point that out,
that'd be helpful (assuming 6.3-rc3 still shows that error message).
> and that the GPIO is actually optional so shouldn't
> hold up loading, but I can't see how that should be represented.
Optional dependencies should get ignored after the default
deferred_probe_timeout runs out and the supplier driver hasn't been
loaded yet.
-Saravana
> Adding Greg + Saravana in the hope they can tell me what I've done wrong
> here. The LED driver using a different GPIO line on the axp209 works
> fine, so the device is definitely loaded and working ok.
_______________________________________________
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 v3 1/2] dt-bindings: usb: mtk-xhci: add an optional frame count clock
From: Chunfeng Yun (云春峰) @ 2023-04-21 1:33 UTC (permalink / raw)
To: gregkh@linuxfoundation.org
Cc: linux-mediatek@lists.infradead.org, robh+dt@kernel.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, mathias.nyman@intel.com,
krzysztof.kozlowski@linaro.org,
Tianping Fang (方天平),
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com
In-Reply-To: <ZEDy1bTsU7AsF2kR@kroah.com>
On Thu, 2023-04-20 at 10:07 +0200, Greg Kroah-Hartman wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On Mon, Apr 17, 2023 at 10:42:12AM +0800, Chunfeng Yun wrote:
> > Add optional clock 'frmcnt_ck' used on 4nm or advanced process SoC
> >
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > Reviewed-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delregno@collabora.com>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > v3: add acked-by and Reviewed-by tags
>
> There's never a need to do this as our tools pick them up
> automatically.
> This resend did nothing but move it later in the queue to review :(
Got it, thanks a lot
>
> thanks,
>
> greg k-h
_______________________________________________
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 v10 2/2] i2c: aspeed: support ast2600 i2c new register mode driver
From: Andi Shyti @ 2023-04-21 0:05 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, Brendan Higgins, Benjamin Herrenschmidt, Joel Stanley,
Rob Herring, Krzysztof Kozlowski, Andrew Jeffery, Philipp Zabel,
Wolfram Sang, Andy Shevchenko, linux-i2c, Florian Fainelli,
Jean Delvare, William Zhang, Tyrone Ting, Tharun Kumar P,
Conor Dooley, Phil Edworthy, openbmc, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20230415012848.1777768-3-ryan_chen@aspeedtech.com>
Hi Ryan,
On Sat, Apr 15, 2023 at 09:28:48AM +0800, Ryan Chen wrote:
> Add i2c new register mode driver to support AST2600 i2c
> new register mode. AST2600 i2c controller have legacy and
> new register mode. The new register mode have global register
> support 4 base clock for scl clock selection, and new clock
> divider mode. The i2c new register mode have separate register
> set to control i2c master and slave.
This commit message is a bit messy, could you please write it
more clear?
[...]
> +static int ast2600_i2c_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device *dev = &pdev->dev;
> + struct ast2600_i2c_bus *i2c_bus;
> + struct resource *res;
> + u32 global_ctrl;
> + int ret = 0;
> +
> + i2c_bus = devm_kzalloc(dev, sizeof(*i2c_bus), GFP_KERNEL);
> + if (!i2c_bus)
> + return -ENOMEM;
Let's use dev_err_probe whenever possible, at least we keep a
coherent style.
[...]
> + ret = devm_request_irq(dev, i2c_bus->irq, ast2600_i2c_bus_irq, 0,
> + dev_name(dev), i2c_bus);
isn't it better to use threaded irq? You have quite an elaborate
irq handler, you may want to use a thread for it.
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Unable to request irq %d\n", i2c_bus->irq);
> +
> + if (of_property_read_bool(dev->of_node, "smbus-alert")) {
> + i2c_bus->alert_enable = 1;
true;
alert_enable is boolean, make it bool.
> + i2c_bus->ara = i2c_new_smbus_alert_device(&i2c_bus->adap, &i2c_bus->alert_data);
> + if (!i2c_bus->ara)
> + dev_warn(dev, "Failed to register ARA client\n");
> +
> + writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER | AST2600_I2CM_SMBUS_ALT,
> + i2c_bus->reg_base + AST2600_I2CM_IER);
> + } else {
> + i2c_bus->alert_enable = 0;
false;
I'm not going to review any further, please send the patch after
you have run checkpatch.pl on it. Thanks!
Andi
_______________________________________________
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 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
From: Vishal Moola @ 2023-04-20 23:32 UTC (permalink / raw)
To: David Hildenbrand
Cc: Andrew Morton, Matthew Wilcox, linux-mm, linux-arch,
linux-arm-kernel, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linuxppc-dev, linux-riscv,
linux-s390, linux-sh, sparclinux, linux-um, xen-devel, kvm
In-Reply-To: <e0c0ad67-f23f-ff35-80bf-841dcfd43d99@redhat.com>
On Wed, Apr 19, 2023 at 12:54 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 18.04.23 23:33, Vishal Moola wrote:
> > On Tue, Apr 18, 2023 at 8:45 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> On 17.04.23 22:50, Vishal Moola (Oracle) wrote:
> >>> s390 uses page->index to keep track of page tables for the guest address
> >>> space. In an attempt to consolidate the usage of page fields in s390,
> >>> replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap.
> >>>
> >>> This will help with the splitting of struct ptdesc from struct page, as
> >>> well as allow s390 to use _pt_frag_refcount for fragmented page table
> >>> tracking.
> >>>
> >>> Since page->_pt_s390_gaddr aliases with mapping, ensure its set to NULL
> >>> before freeing the pages as well.
> >>>
> >>> Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> >>> index 3fc9e680f174..2616d64c0e8c 100644
> >>> --- a/include/linux/mm_types.h
> >>> +++ b/include/linux/mm_types.h
> >>> @@ -144,7 +144,7 @@ struct page {
> >>> struct { /* Page table pages */
> >>> unsigned long _pt_pad_1; /* compound_head */
> >>> pgtable_t pmd_huge_pte; /* protected by page->ptl */
> >>> - unsigned long _pt_pad_2; /* mapping */
> >>> + unsigned long _pt_s390_gaddr; /* mapping */
> >>> union {
> >>> struct mm_struct *pt_mm; /* x86 pgds only */
> >>> atomic_t pt_frag_refcount; /* powerpc */
> >>
> >> The confusing part is, that these gmap page tables are not ordinary
> >> process page tables that we would ordinarily place into this section
> >> here. That's why they are also not allocated/freed using the typical
> >> page table constructor/destructor ...
> >
> > I initially thought the same, so I was quite confused when I saw
> > __gmap_segment_gaddr was using pmd_pgtable_page().
> >
> > Although they are not ordinary process page tables, since we
> > eventually want to move them out of struct page, I think shifting them
> > to be in ptdescs, being a memory descriptor for page tables, makes
> > the most sense.
>
> Seeing utilities like tlb_remove_page_ptdesc() that don't really apply
> to such page tables, I wonder if we should much rather treat such
> shadow/auxiliary/... page tables (just like other architectures like
> x86, arm, ... employ as well) as a distinct type.
>
> And have ptdesc be the common type for all process page tables.
Although I do like the idea of having a distinct type for them, I'm not sure
I see the merits of having another type specifically for those types of
page tables.
As it currently is, tlb_remove_table() is only distinct from tlb_remove_page()
when an architecture defines its own removal function. I'm not too familiar
with most of their differences, but we can probably continue to let them do
that. As of now, I'm not too sure what a distinct type would look like that
could meet all their needs holistically.
> >
> > Another option is to leave pmd_pgtable_page() as is just for this case.
> > Or we can revert commit 7e25de77bc5ea which uses the function here
> > then figure out where these gmap pages table pages will go later.
>
> I'm always confused when reading gmap code, so let me have another look :)
>
> The confusing part is that s390x shares the lowest level page tables
> (PTE tables) between the process and gmap ("guest mapping", similar to
> EPT on x86-64). It maps these process PTE tables (covering 1 MiB) into
> gmap-specific PMD tables.
Especially in cases like this. If the architecture wants to share page tables
then everything being in form ptdesc would make that easiest, and
continue to let them define their own niche functions for their needs.
> pmd_pgtable_page() should indeed always give us a gmap-specific
> PMD-table. In fact, something allocated via gmap_alloc_table().
>
> Decoupling both concepts sounds like a good idea.
Yeah, I'm not a fan of how this gmap caller is the only external caller
using this to get a page for their own purposes. I'll update that in v2.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] pwm: mediatek: Add support for MT7981
From: Daniel Golle @ 2023-04-20 23:23 UTC (permalink / raw)
To: linux-pwm, linux-mediatek, linux-arm-kernel, linux-kernel,
Thierry Reding, Uwe Kleine-König, Matthias Brugger,
AngeloGioacchino Del Regno, John Crispin
In-Reply-To: <cover.1682007088.git.daniel@makrotopia.org>
The PWM unit on MT7981 uses different register offsets than previous
MediaTek PWM units. Add support for these new offsets and add support
for PWM on MT7981 which has 3 PWM channels, one of them is typically
used for a temperature controlled fan.
While at it, also reorder pwm_mediatek_of_data entries to restore
alphabetic order.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/pwm/pwm-mediatek.c | 39 ++++++++++++++++++++++++++++++--------
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 5b5eeaff35da6..7a51d210a8778 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -38,6 +38,7 @@ struct pwm_mediatek_of_data {
unsigned int num_pwms;
bool pwm45_fixup;
bool has_ck_26m_sel;
+ const unsigned int *reg_offset;
};
/**
@@ -59,10 +60,14 @@ struct pwm_mediatek_chip {
const struct pwm_mediatek_of_data *soc;
};
-static const unsigned int pwm_mediatek_reg_offset[] = {
+static const unsigned int mtk_pwm_reg_offset_v1[] = {
0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
};
+static const unsigned int mtk_pwm_reg_offset_v2[] = {
+ 0x0080, 0x00c0, 0x0100, 0x0140, 0x0180, 0x01c0, 0x0200, 0x0240
+};
+
static inline struct pwm_mediatek_chip *
to_pwm_mediatek_chip(struct pwm_chip *chip)
{
@@ -111,7 +116,7 @@ static inline void pwm_mediatek_writel(struct pwm_mediatek_chip *chip,
unsigned int num, unsigned int offset,
u32 value)
{
- writel(value, chip->regs + pwm_mediatek_reg_offset[num] + offset);
+ writel(value, chip->regs + chip->soc->reg_offset[num] + offset);
}
static int pwm_mediatek_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -285,60 +290,77 @@ static const struct pwm_mediatek_of_data mt2712_pwm_data = {
.num_pwms = 8,
.pwm45_fixup = false,
.has_ck_26m_sel = false,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt6795_pwm_data = {
.num_pwms = 7,
.pwm45_fixup = false,
.has_ck_26m_sel = false,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt7622_pwm_data = {
.num_pwms = 6,
.pwm45_fixup = false,
.has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt7623_pwm_data = {
.num_pwms = 5,
.pwm45_fixup = true,
.has_ck_26m_sel = false,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt7628_pwm_data = {
.num_pwms = 4,
.pwm45_fixup = true,
.has_ck_26m_sel = false,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt7629_pwm_data = {
.num_pwms = 1,
.pwm45_fixup = false,
.has_ck_26m_sel = false,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
-static const struct pwm_mediatek_of_data mt8183_pwm_data = {
- .num_pwms = 4,
+static const struct pwm_mediatek_of_data mt7981_pwm_data = {
+ .num_pwms = 3,
.pwm45_fixup = false,
.has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v2,
};
-static const struct pwm_mediatek_of_data mt8365_pwm_data = {
- .num_pwms = 3,
+static const struct pwm_mediatek_of_data mt7986_pwm_data = {
+ .num_pwms = 2,
.pwm45_fixup = false,
.has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
-static const struct pwm_mediatek_of_data mt7986_pwm_data = {
- .num_pwms = 2,
+static const struct pwm_mediatek_of_data mt8183_pwm_data = {
+ .num_pwms = 4,
+ .pwm45_fixup = false,
+ .has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v1,
+};
+
+static const struct pwm_mediatek_of_data mt8365_pwm_data = {
+ .num_pwms = 3,
.pwm45_fixup = false,
.has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct pwm_mediatek_of_data mt8516_pwm_data = {
.num_pwms = 5,
.pwm45_fixup = false,
.has_ck_26m_sel = true,
+ .reg_offset = mtk_pwm_reg_offset_v1,
};
static const struct of_device_id pwm_mediatek_of_match[] = {
@@ -348,6 +370,7 @@ static const struct of_device_id pwm_mediatek_of_match[] = {
{ .compatible = "mediatek,mt7623-pwm", .data = &mt7623_pwm_data },
{ .compatible = "mediatek,mt7628-pwm", .data = &mt7628_pwm_data },
{ .compatible = "mediatek,mt7629-pwm", .data = &mt7629_pwm_data },
+ { .compatible = "mediatek,mt7981-pwm", .data = &mt7981_pwm_data },
{ .compatible = "mediatek,mt7986-pwm", .data = &mt7986_pwm_data },
{ .compatible = "mediatek,mt8183-pwm", .data = &mt8183_pwm_data },
{ .compatible = "mediatek,mt8365-pwm", .data = &mt8365_pwm_data },
--
2.40.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 v3 1/2] dt-bindings: pwm: mediatek: Add mediatek,mt7981 compatible
From: Daniel Golle @ 2023-04-20 23:22 UTC (permalink / raw)
To: devicetree, linux-pwm, linux-mediatek, linux-arm-kernel,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Thierry Reding,
Uwe Kleine-König, Matthias Brugger,
AngeloGioacchino Del Regno, John Crispin
In-Reply-To: <cover.1682007088.git.daniel@makrotopia.org>
Add compatible string for the PWM unit found of the MediaTek MT7981 SoC.
This is in preparation to adding support in the pwm-mediatek.c driver.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
index 8e176ba7a525f..0fbe8a6469eb2 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
@@ -22,6 +22,7 @@ properties:
- mediatek,mt7623-pwm
- mediatek,mt7628-pwm
- mediatek,mt7629-pwm
+ - mediatek,mt7981-pwm
- mediatek,mt7986-pwm
- mediatek,mt8183-pwm
- mediatek,mt8365-pwm
--
2.40.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 v3 0/2] Support PWM on MediaTek MT7981
From: Daniel Golle @ 2023-04-20 23:22 UTC (permalink / raw)
To: devicetree, linux-pwm, linux-mediatek, linux-arm-kernel,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Thierry Reding,
Uwe Kleine-König, Matthias Brugger,
AngeloGioacchino Del Regno, John Crispin
Add support for PWM on the MediaTek MT7981 to pwm-mediatek.c as well
as new mediatek,mt7981-pwm compatible string to the existing bindings.
Changes since v2:
* improve commit message, adding that alphabetic order is restored
Changes since v1:
* use pointer to reg_offset instead of u8 reg_ver and if-else
Daniel Golle (2):
dt-bindings: pwm: mediatek: Add mediatek,mt7981 compatible
pwm: mediatek: Add support for MT7981
.../bindings/pwm/mediatek,mt2712-pwm.yaml | 1 +
drivers/pwm/pwm-mediatek.c | 39 +++++++++++++++----
2 files changed, 32 insertions(+), 8 deletions(-)
base-commit: 44bf136283e567b2b62653be7630e7511da41da2
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 10/13] drm/msm: mdss: Add SM6375 support
From: Konrad Dybcio @ 2023-04-20 23:06 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Clark, Abhinav Kumar, Sean Paul,
David Airlie, Daniel Vetter, Rob Herring, Krzysztof Kozlowski,
Krishna Manikandan, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Marijn Suijten, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel, linux-arm-kernel, iommu
In-Reply-To: <26832d5c-f55c-1dd0-947a-0278bcbf08de@linaro.org>
On 21.04.2023 00:50, Dmitry Baryshkov wrote:
> On 21/04/2023 01:31, Konrad Dybcio wrote:
>> Add support for MDSS on SM6375.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>> drivers/gpu/drm/msm/msm_mdss.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
>> index 4e3a5f0c303c..f2470ce699f7 100644
>> --- a/drivers/gpu/drm/msm/msm_mdss.c
>> +++ b/drivers/gpu/drm/msm/msm_mdss.c
>> @@ -546,6 +546,15 @@ static const struct msm_mdss_data sm6350_data = {
>> .highest_bank_bit = 1,
>> };
>> +static const struct msm_mdss_data sm6375_data = {
>> + .ubwc_version = UBWC_2_0,
>> + .ubwc_dec_version = UBWC_2_0,
>> + .ubwc_swizzle = 6,
>> + .ubwc_static = 0x1e,
>> + /* Possibly 0 for LPDDR3 */
>> + .highest_bank_bit = 1,
>> +};
>
> Nit: we can use sm6350 data here, can't we?
Nice catch!
Konrad
>
>> +
>> static const struct msm_mdss_data sm8150_data = {
>> .ubwc_version = UBWC_3_0,
>> .ubwc_dec_version = UBWC_3_0,
>> @@ -580,6 +589,7 @@ static const struct of_device_id mdss_dt_match[] = {
>> { .compatible = "qcom,sc8280xp-mdss", .data = &sc8280xp_data },
>> { .compatible = "qcom,sm6115-mdss", .data = &sm6115_data },
>> { .compatible = "qcom,sm6350-mdss", .data = &sm6350_data },
>> + { .compatible = "qcom,sm6375-mdss", .data = &sm6375_data },
>> { .compatible = "qcom,sm8150-mdss", .data = &sm8150_data },
>> { .compatible = "qcom,sm8250-mdss", .data = &sm8250_data },
>> { .compatible = "qcom,sm8350-mdss", .data = &sm8250_data },
>>
>
_______________________________________________
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 07/13] drm/msm/dpu: Add SM6350 support
From: Dmitry Baryshkov @ 2023-04-20 23:06 UTC (permalink / raw)
To: Konrad Dybcio, Rob Clark, Abhinav Kumar, Sean Paul, David Airlie,
Daniel Vetter, Rob Herring, Krzysztof Kozlowski,
Krishna Manikandan, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Marijn Suijten, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel, linux-arm-kernel, iommu, Konrad Dybcio
In-Reply-To: <4da9bd19-9403-812e-4554-847b18df78c9@linaro.org>
On 21/04/2023 02:05, Konrad Dybcio wrote:
>
>
> On 21.04.2023 00:41, Dmitry Baryshkov wrote:
>> On 21/04/2023 01:31, Konrad Dybcio wrote:
>>> Add SM6350 support to the DPU1 driver to enable display output.
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>> ---
> [...]
>
>>> +
>>> +static const struct dpu_sspp_cfg sm6350_sspp[] = {
>>> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
>>> + sc7180_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
>>> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
>>> + sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
>>> + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
>>> + sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
>>
>> DPU_CLK_CTRL_DMA0
This is DPU_CLK_CTRL_DMA1, I made a typo
>>
>>> + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
>>> + sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
>>
>> DPU_CLK_CTRL_DMA2
> _DMA1?
>
And this is DMA2, I was correct.
>
>>
>>
>>> +};
>>> +
>
>>> +static const struct dpu_qos_lut_entry sm6350_qos_linear_macrotile[] = {
>>> + {.fl = 0, .lut = 0x0011223344556677 },
>>> + {.fl = 0, .lut = 0x0011223445566777 },
>>
>> Do we need two equal entries here?
> Hmm.. looks like the SDE driver dropped the fill level
> logic in 4.19 times and that might have thrown me off
> when porting this Since the [0] entry has what looks
> like a lower LUT value, should I give it .fl=1?
>
>
>>
>> Also please push the qos to the dpu_hw_catalog.c, I want to take another look at these structures and it is easier if all of them are beneath one's eyes.
> Will do.
>
>>
>>> +};
>>> +
>>> +static const struct dpu_perf_cfg sm6350_perf_data = {
>>> + .max_bw_low = 4200000,
>>> + .max_bw_high = 5100000,
>>> + .min_core_ib = 2500000,
>>> + .min_llcc_ib = 0,
>>> + .min_dram_ib = 1600000,
>>> + .min_prefill_lines = 35,
>>> + /* TODO: confirm danger_lut_tbl */
>>> + .danger_lut_tbl = {0xffff, 0xffff, 0x0, 0x0, 0xffff},
> [...]
>
>
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>>> @@ -320,6 +320,8 @@ enum dpu_qos_lut_usage {
>>> DPU_QOS_LUT_USAGE_LINEAR,
>>> DPU_QOS_LUT_USAGE_MACROTILE,
>>> DPU_QOS_LUT_USAGE_NRT,
>>> + DPU_QOS_LUT_USAGE_CWB,
>>> + DPU_QOS_LUT_USAGE_MACROTILE_QSEED,
>>
>> This should probably be removed. It would be nice to clean these things up, but not as a part of sm6350.
> Well, I won't be able to fill in the danger LUT table otherwise!
>
> Konrad
>>
>>> DPU_QOS_LUT_USAGE_MAX,
>>> };
>>> @@ -880,6 +882,7 @@ extern const struct dpu_mdss_cfg dpu_sc8180x_cfg;
>>> extern const struct dpu_mdss_cfg dpu_sm8250_cfg;
>>> extern const struct dpu_mdss_cfg dpu_sc7180_cfg;
>>> extern const struct dpu_mdss_cfg dpu_sm6115_cfg;
>>> +extern const struct dpu_mdss_cfg dpu_sm6350_cfg;
>>> extern const struct dpu_mdss_cfg dpu_qcm2290_cfg;
>>> extern const struct dpu_mdss_cfg dpu_sm8350_cfg;
>>> extern const struct dpu_mdss_cfg dpu_sc7280_cfg;
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> index 0e7a68714e9e..46be7ad8d615 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>>> @@ -1286,6 +1286,7 @@ static const struct of_device_id dpu_dt_match[] = {
>>> { .compatible = "qcom,sc8180x-dpu", .data = &dpu_sc8180x_cfg, },
>>> { .compatible = "qcom,sc8280xp-dpu", .data = &dpu_sc8280xp_cfg, },
>>> { .compatible = "qcom,sm6115-dpu", .data = &dpu_sm6115_cfg, },
>>> + { .compatible = "qcom,sm6350-dpu", .data = &dpu_sm6350_cfg, },
>>> { .compatible = "qcom,sm8150-dpu", .data = &dpu_sm8150_cfg, },
>>> { .compatible = "qcom,sm8250-dpu", .data = &dpu_sm8250_cfg, },
>>> { .compatible = "qcom,sm8350-dpu", .data = &dpu_sm8350_cfg, },
>>>
>>
--
With best wishes
Dmitry
_______________________________________________
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 07/13] drm/msm/dpu: Add SM6350 support
From: Konrad Dybcio @ 2023-04-20 23:05 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Clark, Abhinav Kumar, Sean Paul,
David Airlie, Daniel Vetter, Rob Herring, Krzysztof Kozlowski,
Krishna Manikandan, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Marijn Suijten, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel, linux-arm-kernel, iommu, Konrad Dybcio
In-Reply-To: <fd2f43eb-aa10-eaf4-62f8-945a3152a28a@linaro.org>
On 21.04.2023 00:41, Dmitry Baryshkov wrote:
> On 21/04/2023 01:31, Konrad Dybcio wrote:
>> Add SM6350 support to the DPU1 driver to enable display output.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
[...]
>> +
>> +static const struct dpu_sspp_cfg sm6350_sspp[] = {
>> + SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1f8, VIG_SC7180_MASK,
>> + sc7180_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
>> + SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1f8, DMA_SDM845_MASK,
>> + sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
>> + SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1f8, DMA_CURSOR_SDM845_MASK,
>> + sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR0),
>
> DPU_CLK_CTRL_DMA0
>
>> + SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1f8, DMA_CURSOR_SDM845_MASK,
>> + sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_CURSOR1),
>
> DPU_CLK_CTRL_DMA2
_DMA1?
>
>
>> +};
>> +
>> +static const struct dpu_qos_lut_entry sm6350_qos_linear_macrotile[] = {
>> + {.fl = 0, .lut = 0x0011223344556677 },
>> + {.fl = 0, .lut = 0x0011223445566777 },
>
> Do we need two equal entries here?
Hmm.. looks like the SDE driver dropped the fill level
logic in 4.19 times and that might have thrown me off
when porting this Since the [0] entry has what looks
like a lower LUT value, should I give it .fl=1?
>
> Also please push the qos to the dpu_hw_catalog.c, I want to take another look at these structures and it is easier if all of them are beneath one's eyes.
Will do.
>
>> +};
>> +
>> +static const struct dpu_perf_cfg sm6350_perf_data = {
>> + .max_bw_low = 4200000,
>> + .max_bw_high = 5100000,
>> + .min_core_ib = 2500000,
>> + .min_llcc_ib = 0,
>> + .min_dram_ib = 1600000,
>> + .min_prefill_lines = 35,
>> + /* TODO: confirm danger_lut_tbl */
>> + .danger_lut_tbl = {0xffff, 0xffff, 0x0, 0x0, 0xffff},
[...]
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> @@ -320,6 +320,8 @@ enum dpu_qos_lut_usage {
>> DPU_QOS_LUT_USAGE_LINEAR,
>> DPU_QOS_LUT_USAGE_MACROTILE,
>> DPU_QOS_LUT_USAGE_NRT,
>> + DPU_QOS_LUT_USAGE_CWB,
>> + DPU_QOS_LUT_USAGE_MACROTILE_QSEED,
>
> This should probably be removed. It would be nice to clean these things up, but not as a part of sm6350.
Well, I won't be able to fill in the danger LUT table otherwise!
Konrad
>
>> DPU_QOS_LUT_USAGE_MAX,
>> };
>> @@ -880,6 +882,7 @@ extern const struct dpu_mdss_cfg dpu_sc8180x_cfg;
>> extern const struct dpu_mdss_cfg dpu_sm8250_cfg;
>> extern const struct dpu_mdss_cfg dpu_sc7180_cfg;
>> extern const struct dpu_mdss_cfg dpu_sm6115_cfg;
>> +extern const struct dpu_mdss_cfg dpu_sm6350_cfg;
>> extern const struct dpu_mdss_cfg dpu_qcm2290_cfg;
>> extern const struct dpu_mdss_cfg dpu_sm8350_cfg;
>> extern const struct dpu_mdss_cfg dpu_sc7280_cfg;
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>> index 0e7a68714e9e..46be7ad8d615 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
>> @@ -1286,6 +1286,7 @@ static const struct of_device_id dpu_dt_match[] = {
>> { .compatible = "qcom,sc8180x-dpu", .data = &dpu_sc8180x_cfg, },
>> { .compatible = "qcom,sc8280xp-dpu", .data = &dpu_sc8280xp_cfg, },
>> { .compatible = "qcom,sm6115-dpu", .data = &dpu_sm6115_cfg, },
>> + { .compatible = "qcom,sm6350-dpu", .data = &dpu_sm6350_cfg, },
>> { .compatible = "qcom,sm8150-dpu", .data = &dpu_sm8150_cfg, },
>> { .compatible = "qcom,sm8250-dpu", .data = &dpu_sm8250_cfg, },
>> { .compatible = "qcom,sm8350-dpu", .data = &dpu_sm8350_cfg, },
>>
>
_______________________________________________
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 13/13] iommu/arm-smmu-qcom: Sort the compatible list alphabetically
From: Dmitry Baryshkov @ 2023-04-20 22:53 UTC (permalink / raw)
To: Konrad Dybcio, Rob Clark, Abhinav Kumar, Sean Paul, David Airlie,
Daniel Vetter, Rob Herring, Krzysztof Kozlowski,
Krishna Manikandan, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Marijn Suijten, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel, linux-arm-kernel, iommu
In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-13-5def73f50980@linaro.org>
On 21/04/2023 01:31, Konrad Dybcio wrote:
> It got broken at some point, fix it up.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
This should probably come before patches 11 and 12.
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 2daaa600ac75..e64c737724c4 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -251,12 +251,12 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = {
> { .compatible = "qcom,sc7280-mss-pil" },
> { .compatible = "qcom,sc8180x-mdss" },
> { .compatible = "qcom,sc8280xp-mdss" },
> - { .compatible = "qcom,sm8150-mdss" },
> - { .compatible = "qcom,sm8250-mdss" },
> { .compatible = "qcom,sdm845-mdss" },
> { .compatible = "qcom,sdm845-mss-pil" },
> { .compatible = "qcom,sm6350-mdss" },
> { .compatible = "qcom,sm6375-mdss" },
> + { .compatible = "qcom,sm8150-mdss" },
> + { .compatible = "qcom,sm8250-mdss" },
> { }
> };
>
>
--
With best wishes
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox