* Re: [PATCH v10 23/23] iommu/mediatek: Clean up struct mtk_smi_iommu
From: Matthias Brugger @ 2019-08-22 14:07 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Robin Murphy, Will Deacon
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, ming-fan.chen, anan.sun,
Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <1566395606-7975-24-git-send-email-yong.wu@mediatek.com>
On 21/08/2019 15:53, Yong Wu wrote:
> Remove the "struct mtk_smi_iommu" to simplify the code since it has only
> one item in it right now.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/iommu/mtk_iommu.c | 4 ++--
> drivers/iommu/mtk_iommu.h | 6 +++---
> drivers/iommu/mtk_iommu_v1.c | 4 ++--
> drivers/memory/mtk-smi.c | 6 +++---
> include/soc/mediatek/smi.h | 4 ----
> 5 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index cc81de2..400066d 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -278,7 +278,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
> for (i = 0; i < fwspec->num_ids; ++i) {
> larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
> portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
> - larb_mmu = &data->smi_imu.larb_imu[larbid];
> + larb_mmu = &data->larb_imu[larbid];
>
> dev_dbg(dev, "%s iommu port: %d\n",
> enable ? "enable" : "disable", portid);
> @@ -680,7 +680,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> of_node_put(larbnode);
> return -EPROBE_DEFER;
> }
> - data->smi_imu.larb_imu[id].dev = &plarbdev->dev;
> + data->larb_imu[id].dev = &plarbdev->dev;
>
> component_match_add_release(dev, &match, release_of,
> compare_of, larbnode);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 56b579c..fc0f16e 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -56,7 +56,6 @@ struct mtk_iommu_data {
> struct mtk_iommu_suspend_reg reg;
> struct mtk_iommu_domain *m4u_dom;
> struct iommu_group *m4u_group;
> - struct mtk_smi_iommu smi_imu; /* SMI larb iommu info */
> bool enable_4GB;
> bool tlb_flush_active;
>
> @@ -64,6 +63,7 @@ struct mtk_iommu_data {
> const struct mtk_iommu_plat_data *plat_data;
>
> struct list_head list;
> + struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> };
>
> static inline int compare_of(struct device *dev, void *data)
> @@ -80,14 +80,14 @@ static inline int mtk_iommu_bind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
>
> - return component_bind_all(dev, &data->smi_imu);
> + return component_bind_all(dev, &data->larb_imu);
> }
>
> static inline void mtk_iommu_unbind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
>
> - component_unbind_all(dev, &data->smi_imu);
> + component_unbind_all(dev, &data->larb_imu);
> }
>
> #endif
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index 3922358..860926c 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -206,7 +206,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
> for (i = 0; i < fwspec->num_ids; ++i) {
> larbid = mt2701_m4u_to_larb(fwspec->ids[i]);
> portid = mt2701_m4u_to_port(fwspec->ids[i]);
> - larb_mmu = &data->smi_imu.larb_imu[larbid];
> + larb_mmu = &data->larb_imu[larbid];
>
> dev_dbg(dev, "%s iommu port: %d\n",
> enable ? "enable" : "disable", portid);
> @@ -610,7 +610,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> }
> }
>
> - data->smi_imu.larb_imu[larb_nr].dev = &plarbdev->dev;
> + data->larb_imu[larb_nr].dev = &plarbdev->dev;
> component_match_add_release(dev, &match, release_of,
> compare_of, larb_spec.np);
> larb_nr++;
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index d6dc62f..439d7d8 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -143,13 +143,13 @@ void mtk_smi_larb_put(struct device *larbdev)
> mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
> {
> struct mtk_smi_larb *larb = dev_get_drvdata(dev);
> - struct mtk_smi_iommu *smi_iommu = data;
> + struct mtk_smi_larb_iommu *larb_mmu = data;
> unsigned int i;
>
> for (i = 0; i < MTK_LARB_NR_MAX; i++) {
> - if (dev == smi_iommu->larb_imu[i].dev) {
> + if (dev == larb_mmu[i].dev) {
> larb->larbid = i;
> - larb->mmu = &smi_iommu->larb_imu[i].mmu;
> + larb->mmu = &larb_mmu[i].mmu;
> return 0;
> }
> }
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 6f0b00c..5a34b87 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -20,10 +20,6 @@ struct mtk_smi_larb_iommu {
> unsigned int mmu;
> };
>
> -struct mtk_smi_iommu {
> - struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> -};
> -
> /*
> * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
> * It also initialize some basic setting(like iommu).
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] watchdog/aspeed: add support for dual boot
From: Guenter Roeck @ 2019-08-22 13:55 UTC (permalink / raw)
To: Ivan Mikhaylov
Cc: linux-watchdog, linux-aspeed, Andrew Jeffery, Alexander Amelkin,
linux-kernel, Joel Stanley, Wim Van Sebroeck, linux-arm-kernel
In-Reply-To: <a022c0590f0fbf22cc8476b5ef3f1c22746429ac.camel@yadro.com>
On Thu, Aug 22, 2019 at 12:15:20PM +0300, Ivan Mikhaylov wrote:
> On Wed, 2019-08-21 at 09:32 -0700, Guenter Roeck wrote:
> >
> > > + writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
> > > + wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
> > > + wdt->wdd.bootstatus |= WDIOF_EXTERN1;
> >
> > The variable reflects the _boot status_. It should not change after booting.
>
> Okay, then perhaps may we set 'status' handler for watchdog device and check
> 'status' file? Right now 'bootstatus' and 'status' are same because there is no
> handler for 'status'.
>
You would still have to redefine one of the status bits to mean something
driver specific. You would also still have two different flags to read
and control cs0 - to read the status, you would read an ioctl (or the
status sysfs attribute), to write it you would write into access_cs0.
I guess I must be missing something. What is the problem with using
access_cs0 for both ?
Guenter
> > > +
> > > + return size;
> > > +}
> > > +static DEVICE_ATTR_WO(access_cs0);
> > > +
> > > +static struct attribute *bswitch_attrs[] = {
> > > + &dev_attr_access_cs0.attr,
> > > + NULL
> > > +};
> > > +ATTRIBUTE_GROUPS(bswitch);
> > > +
> > > static const struct watchdog_ops aspeed_wdt_ops = {
> > > .start = aspeed_wdt_start,
> > > .stop = aspeed_wdt_stop,
> > > @@ -223,6 +248,9 @@ static int aspeed_wdt_probe(struct platform_device
> > > *pdev)
> > >
> > > wdt->ctrl = WDT_CTRL_1MHZ_CLK;
> > >
> > > + if (of_property_read_bool(np, "aspeed,alt-boot"))
> > > + wdt->wdd.groups = bswitch_groups;
> > > +
> > Why does this have to be separate to the existing evaluation of
> > aspeed,alt-boot, and why does the existing code not work ?
> >
> > Also, is it guaranteed that this does not interfer with existing
> > support for alt-boot ?
>
> It doesn't, it just provides for ast2400 switch to cs0 at side 1(cs1). Problem
> is that only one flash chip(side 1/cs1) is accessible on alternate boot, there
> is citation from the documentation in commit body. So if by some reason side 0
> is corrupted, need to switch into alternate boot to cs1, do the load from it,
> drop that bit to make side 0 accessible and do the flash of first side. On
> ast2500/2600 this problem is solved already, in alternate boot there both flash
> chips are present. It's additional requirement for alternate boot on ast2400, to
> make the possibility to access at all side 0 flash chip after we boot to the
> alternate side.
>
_______________________________________________
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 RFC v1 2/2] mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host
From: Ulf Hansson @ 2019-08-22 13:52 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Mark Rutland, DTML, jianxin.pan, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring,
open list:ARM/Amlogic Meson..., Linux ARM
In-Reply-To: <20190708173330.13217-3-martin.blumenstingl@googlemail.com>
On Mon, 8 Jul 2019 at 19:33, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> WiP - only partially working - see performance numbers.
>
> Odroid-C1 eMMC (HS-200):
> Amlogic's vendor driver @ Linux 3.10:
> 7781351936 bytes (7.8 GB) copied, 134.714 s, 57.8 MB/s
> This driver:
> 7781351936 bytes (7.8 GB, 7.2 GiB) copied, 189.02 s, 41.2 MB/s
>
> EC-100 eMMC (HS MMC):
> Amlogic's vendor driver @ Linux 3.10:
> 15762194432 bytes (16 GB) copied, 422.967 s, 37.3 MB/s
> This driver:
> 15762194432 bytes (16 GB, 15 GiB) copied, 9232.65 s, 1.7 MB/s
>
> 1) Amlogic's vendor driver does some magic with the divider:
> clk_div = input_rate / clk_ios - !(input_rate%clk_ios);
> if (!(clk_div & 0x01)) // if even number, turn it to an odd one
> clk_div++;
> It's not clear to me whether what the reason behind this is, what is
> supposed to be achieved with this?
>
> 2) The hardcoded RX clock phases are taken from the vendor driver. It
> seems that these are only valid when fclk_div3 is used as input
> clock (however, there are four more inputs). It's not clear to me how
> to calculate the RX clock phases in set_ios based on the input clock
> and the ios rate.
>
> 3) The hardware supports a timeout IRQ but the max_busy_timeout is not
> documented anywhere.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Martin, overall this looks good to me. Once you moved from RFC to a
formal patch I will check again, of course.
There are a couple of calls to readl_poll_timeout(), for different
reasons, that I have some questions about, but we can discuss those in
the next step.
[...]
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4, 6/8] PM / OPP: Support adjusting OPP voltages at runtime
From: Matthias Brugger @ 2019-08-22 13:51 UTC (permalink / raw)
To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Rob Herring, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Nishanth Menon, Stephen Boyd
Cc: devicetree, srv_heupstream, linux-pm, Roger Lu, Stephen Boyd,
linux-kernel, fan.chen, linux-mediatek, linux-arm-kernel
In-Reply-To: <1565703113-31479-7-git-send-email-andrew-sh.cheng@mediatek.com>
On 13/08/2019 15:31, Andrew-sh.Cheng wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> On some SoCs the Adaptive Voltage Scaling (AVS) technique is
> employed to optimize the operating voltage of a device. At a
> given frequency, the hardware monitors dynamic factors and either
> makes a suggestion for how much to adjust a voltage for the
> current frequency, or it automatically adjusts the voltage
> without software intervention. Add an API to the OPP library for
> the former case, so that AVS type devices can update the voltages
> for an OPP when the hardware determines the voltage should
> change. The assumption is that drivers like CPUfreq or devfreq
> will register for the OPP notifiers and adjust the voltage
> according to suggestions that AVS makes.
>
> This patch is devired from [1] submitted by Stephen.
> [1] https://lore.kernel.org/patchwork/patch/599279/
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Nit: your signed-off-by tag is missing.
Regards,
Matthias
> ---
> drivers/opp/core.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pm_opp.h | 11 +++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index c094d5d20fd7..407a07f29b12 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2054,6 +2054,69 @@ static int _opp_set_availability(struct device *dev, unsigned long freq,
> }
>
> /**
> + * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP
> + * @dev: device for which we do this operation
> + * @freq: OPP frequency to adjust voltage of
> + * @u_volt: new OPP voltage
> + *
> + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> + * copy operation, returns 0 if no modifcation was done OR modification was
> + * successful.
> + */
> +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
> + unsigned long u_volt)
> +{
> + struct opp_table *opp_table;
> + struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV);
> + int r = 0;
> +
> + /* Find the opp_table */
> + opp_table = _find_opp_table(dev);
> + if (IS_ERR(opp_table)) {
> + r = PTR_ERR(opp_table);
> + dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);
> + return r;
> + }
> +
> + mutex_lock(&opp_table->lock);
> +
> + /* Do we have the frequency? */
> + list_for_each_entry(tmp_opp, &opp_table->opp_list, node) {
> + if (tmp_opp->rate == freq) {
> + opp = tmp_opp;
> + break;
> + }
> + }
> +
> + if (IS_ERR(opp)) {
> + r = PTR_ERR(opp);
> + goto adjust_unlock;
> + }
> +
> + /* Is update really needed? */
> + if (opp->supplies->u_volt == u_volt)
> + goto adjust_unlock;
> +
> + opp->supplies->u_volt = u_volt;
> +
> + dev_pm_opp_get(opp);
> + mutex_unlock(&opp_table->lock);
> +
> + /* Notify the voltage change of the OPP */
> + blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_ADJUST_VOLTAGE,
> + opp);
> +
> + dev_pm_opp_put(opp);
> + goto adjust_put_table;
> +
> +adjust_unlock:
> + mutex_unlock(&opp_table->lock);
> +adjust_put_table:
> + dev_pm_opp_put_opp_table(opp_table);
> + return r;
> +}
> +
> +/**
> * dev_pm_opp_enable() - Enable a specific OPP
> * @dev: device for which we do this operation
> * @freq: OPP frequency to enable
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index af5021f27cb7..86947d53e8c4 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -22,6 +22,7 @@ struct opp_table;
>
> enum dev_pm_opp_event {
> OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_ENABLE, OPP_EVENT_DISABLE,
> + OPP_EVENT_ADJUST_VOLTAGE,
> };
>
> /**
> @@ -111,6 +112,9 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq,
> void dev_pm_opp_remove(struct device *dev, unsigned long freq);
> void dev_pm_opp_remove_all_dynamic(struct device *dev);
>
> +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
> + unsigned long u_volt);
> +
> int dev_pm_opp_enable(struct device *dev, unsigned long freq);
>
> int dev_pm_opp_disable(struct device *dev, unsigned long freq);
> @@ -234,6 +238,13 @@ static inline void dev_pm_opp_remove_all_dynamic(struct device *dev)
> {
> }
>
> +static inline int
> +dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
> + unsigned long u_volt)
> +{
> + return 0;
> +}
> +
> static inline int dev_pm_opp_enable(struct device *dev, unsigned long freq)
> {
> return 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: [RESEND PATCH] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Marc Zyngier @ 2019-08-22 13:48 UTC (permalink / raw)
To: Andre Przywara, Zenghui Yu
Cc: Dave Martin, Julien Grall, kvmarm, linux-arm-kernel,
Christoffer Dall
In-Reply-To: <20190822144224.12d51380@donnerap.cambridge.arm.com>
On 22/08/2019 14:42, Andre Przywara wrote:
> On Thu, 22 Aug 2019 01:13:32 +0800
> Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> Hi,
>
>> On 2019/8/22 1:00, Andre Przywara wrote:
>>> At the moment we initialise the target *mask* of a virtual IRQ to the
>>> VCPU it belongs to, even though this mask is only defined for GICv2 and
>>> quickly runs out of bits for many GICv3 guests.
>>> This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
>>> ------
>>> [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
>>> [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
>>> ------
>>> Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
>>> dump is wrong, due to this very same problem.
>>>
>>> Fix both issues by only initialising vgic_irq->targets for a vGICv2 guest,
>>> and by initialising vgic_irq->mpdir for vGICv3 guests instead. We can't
>>> use the actual MPIDR for that, as the VCPU's system register is not
>>> initialised at this point yet. This is not really an issue, as ->mpidr
>>> is just used for the debugfs output and the IROUTER MMIO register, which
>>> does not exist in redistributors (dealing with SGIs and PPIs).
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> Reported-by: Dave Martin <dave.martin@arm.com>
>>> ---
>>> Hi,
>>>
>>> this came up here again, I think it fell through the cracks back in
>>> March:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637209.html
>>>
>>> Cheers,
>>> Andre.
>>>
>>> virt/kvm/arm/vgic/vgic-init.c | 9 ++++++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
>>> index 80127ca9269f..8bce2f75e0c1 100644
>>> --- a/virt/kvm/arm/vgic/vgic-init.c
>>> +++ b/virt/kvm/arm/vgic/vgic-init.c
>>> @@ -210,7 +210,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
>>> irq->intid = i;
>>> irq->vcpu = NULL;
>>> irq->target_vcpu = vcpu;
>>> - irq->targets = 1U << vcpu->vcpu_id;
>>> kref_init(&irq->refcount);
>>> if (vgic_irq_is_sgi(i)) {
>>> /* SGIs */
>>> @@ -221,10 +220,14 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
>>> irq->config = VGIC_CONFIG_LEVEL;
>>> }
>>>
>>> - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
>>> + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
>>
>> I still think that if user-space create VCPUs before vGIC (like what
>> Qemu does), the actual vGIC model will be unknown here. The UBSAN
>> warning will still show up when booting a vGIC-v3 guest (with Qemu).
>
> Yes, you are right. I vaguely remembered this issue, but couldn't
> find anything on the list about it. So thanks for the heads up!
>
> So I think I have a solution, where we drop the initialisation part
> here altogether, instead initialise mpdir/targets together with the
> group in vgic_init(). Unless there is some code which needs
> irq->group before that point?
You may want to check save/restore of a GICv3 guest using a mix of
group-0/1 interrupts. I seem to remember some breakage in that area.
> Will send a patch shortly.
OK. In the meantime, I'll drop your initial patch.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles
From: Krzysztof Kozlowski @ 2019-08-22 13:45 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+YZ9KdCCT1grtpf7Z1o=-mFuq3O=o7iVGSAhJYO1-=Ww@mail.gmail.com>
On Thu, 22 Aug 2019 at 14:52, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Aug 21, 2019 at 12:55 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Tue, Aug 20, 2019 at 03:27:39PM -0500, Rob Herring wrote:
> > > > I see. If I understand the schema correctly, this should look like:
> > >
> > > Looks correct, but a couple of comments.
> > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > index 7294ac36f4c0..eb263d1ccf13 100644
> > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > @@ -161,6 +161,22 @@ properties:
> > > > items:
> > > > - enum:
> > > > - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> > > > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> > >
> > > Is the SOM ever used alone? If not, then no point in listing this here.
> >
> > SoM alone: no, because it requires some type of base board. However it
> > will be used by some customer designs with some amount of
> > changes/addons.
> >
> > Looking at other aproaches, usually SoMs have their own compatible. In
> > such case - I should document it somewhere.
>
> I wasn't suggesting not having the compatible for it, but you don't
> need it in this list because that is not valid. You have to list it
> with the base board compatibles.
The diff against v7 would be like this then:
---
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1f440817fc03..7219c15f6185 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,7 +161,6 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- - kontron,imx6ul-n6310-som # Kontron N6310 SOM
- const: fsl,imx6ul
- description: Kontron N6310 S Board
---
This passes the dtbs_check.
I'll send v8
_______________________________________________
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: [RESEND PATCH] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Andre Przywara @ 2019-08-22 13:42 UTC (permalink / raw)
To: Zenghui Yu
Cc: Marc Zyngier, Christoffer Dall, kvmarm, Julien Grall, Dave Martin,
linux-arm-kernel
In-Reply-To: <6d2ff99a-a97b-bb4d-3df1-8e22e804aa6a@huawei.com>
On Thu, 22 Aug 2019 01:13:32 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
Hi,
> On 2019/8/22 1:00, Andre Przywara wrote:
> > At the moment we initialise the target *mask* of a virtual IRQ to the
> > VCPU it belongs to, even though this mask is only defined for GICv2 and
> > quickly runs out of bits for many GICv3 guests.
> > This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
> > ------
> > [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
> > [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
> > ------
> > Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
> > dump is wrong, due to this very same problem.
> >
> > Fix both issues by only initialising vgic_irq->targets for a vGICv2 guest,
> > and by initialising vgic_irq->mpdir for vGICv3 guests instead. We can't
> > use the actual MPIDR for that, as the VCPU's system register is not
> > initialised at this point yet. This is not really an issue, as ->mpidr
> > is just used for the debugfs output and the IROUTER MMIO register, which
> > does not exist in redistributors (dealing with SGIs and PPIs).
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > Reported-by: Dave Martin <dave.martin@arm.com>
> > ---
> > Hi,
> >
> > this came up here again, I think it fell through the cracks back in
> > March:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637209.html
> >
> > Cheers,
> > Andre.
> >
> > virt/kvm/arm/vgic/vgic-init.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
> > index 80127ca9269f..8bce2f75e0c1 100644
> > --- a/virt/kvm/arm/vgic/vgic-init.c
> > +++ b/virt/kvm/arm/vgic/vgic-init.c
> > @@ -210,7 +210,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
> > irq->intid = i;
> > irq->vcpu = NULL;
> > irq->target_vcpu = vcpu;
> > - irq->targets = 1U << vcpu->vcpu_id;
> > kref_init(&irq->refcount);
> > if (vgic_irq_is_sgi(i)) {
> > /* SGIs */
> > @@ -221,10 +220,14 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
> > irq->config = VGIC_CONFIG_LEVEL;
> > }
> >
> > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
> > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
>
> I still think that if user-space create VCPUs before vGIC (like what
> Qemu does), the actual vGIC model will be unknown here. The UBSAN
> warning will still show up when booting a vGIC-v3 guest (with Qemu).
Yes, you are right. I vaguely remembered this issue, but couldn't find anything on the list about it. So thanks for the heads up!
So I think I have a solution, where we drop the initialisation part here altogether, instead initialise mpdir/targets together with the group in vgic_init(). Unless there is some code which needs irq->group before that point?
Will send a patch shortly.
Cheers,
Andre.
> > irq->group = 1;
> > - else
> > + /* The actual MPIDR is not initialised at this point. */
> > + irq->mpidr = 0;
> > + } else {
> > irq->group = 0;
> > + irq->targets = 1U << vcpu->vcpu_id;
> > + }
> > }
> >
> > if (!irqchip_in_kernel(vcpu->kvm))
> >
>
_______________________________________________
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 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
From: Ulf Hansson @ 2019-08-22 13:38 UTC (permalink / raw)
To: Manish Narani
Cc: mark.rutland@arm.com, kernel@esmil.dk, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, Jolly Shah, tony.xie@rock-chips.com,
philipp.tomsich@theobroma-systems.com, heiko@sntech.de,
Rob Herring, linux-rockchip@lists.infradead.org, Rajan Vaja,
Michal Simek, devicetree@vger.kernel.org, Nava kishore Manne,
scott.branden@broadcom.com, ayaka@soulik.info, mdf@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
adrian.hunter@intel.com, olof@lixom.net,
christoph.muellner@theobroma-systems.com
In-Reply-To: <MN2PR02MB60299EB8B83C4EA68A0F2B33C1A80@MN2PR02MB6029.namprd02.prod.outlook.com>
[...]
> > > > > ---
> > > > > Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15
> > ++++++++++-
> > > > ----
> > > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > index 1edbb04..15c6397 100644
> > > > > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > @@ -23,6 +23,10 @@ Required Properties:
> > > > > - reg: From mmc bindings: Register location and length.
> > > > > - clocks: From clock bindings: Handles to clock inputs.
> > > > > - clock-names: From clock bindings: Tuple including "clk_xin" and
> > "clk_ahb"
> > > > > + Apart from these two there is one more optional clock which
> > > > > + is "clk_sdcard". This clock represents output clock from
> > > > > + controller and card. This must be specified when #clock-cells
> > > > > + is specified.
> > > > > - interrupts: Interrupt specifier
> > > > >
> > > > > Required Properties for "arasan,sdhci-5.1":
> > > > > @@ -36,9 +40,10 @@ Optional Properties:
> > > > > - clock-output-names: If specified, this will be the name of the card
> > clock
> > > > > which will be exposed by this device. Required if #clock-cells is
> > > > > specified.
> > > > > - - #clock-cells: If specified this should be the value <0>. With this
> > property
> > > > > - in place we will export a clock representing the Card Clock. This clock
> > > > > - is expected to be consumed by our PHY. You must also specify
> > > > > + - #clock-cells: If specified this should be the value <0>. With this
> > > > > + property in place we will export one clock representing the Card
> > > > > + Clock. This clock is expected to be consumed by our PHY. You must
> > also
> > > > > + specify
> > > >
> > > > specify what?
> > > I think this line was already there, I missed to correct it, Will update in v3.
> > >
> > > >
> > > > The 3rd clock input I assume? This statement means any existing users
> > > > with 2 clock inputs and #clock-cells are in error now. Is that correct?
> > > Yes, this is correct. So far there was only one vendor using '#clock-cells'
> > which is Rockchip. I have sent DT patch (02/11) for that also.
> > > Here this is needed as earlier implementation isn't correct as suggested by
> > Uffe. (https://lkml.org/lkml/2019/6/20/486) .
> >
> > I am not sure how big of a problem the backwards compatible thingy
> > with DT is, in general we must not break it. What do you say Manish?
>
> Though I agree with Uffe on this, there is no other way from my understanding. Please suggest.
>
> >
> > As a workaround, would it be possible to use
> > of_clk_get_from_provider() somehow to address the compatibility issue?
>
> For this to be used we have to parse 'clkspec' from the DT node and pass the same as an argument to this function. In this case also the DT node needs to be updated, which is same as we have done in this series.
Alright. I guess breaking DTBs for Rockchip platforms isn't
acceptable, especially if those are already widely deployed, which I
have no idea of....
And having support for both options in the driver seems not a great
option either, so it looks like you need to convert back into the old
v1 approach. Huh, sorry.
Kind regards
Uffe
_______________________________________________
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/4] rtc: Add support for the MediaTek MT2712 RTC
From: Alexandre Belloni @ 2019-08-22 13:36 UTC (permalink / raw)
To: Ran Bi
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <1566480361.12318.50.camel@mhfsdcap03>
On 22/08/2019 21:26:01+0800, Ran Bi wrote:
> On Thu, 2019-08-22 at 14:46 +0200, Alexandre Belloni wrote:
> > On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> > > >
> > > > This should be written when setting the time after power was lost.
> > > >
> > >
> > > I suppose we can move this into mt2712_rtc_read_time function's "if
> > > (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> > > which will be added at next patch. We need additional flag to mark this
> > > condition or another if condition in mt2712_rtc_set_time fucntion if we
> > > put these code in mt2712_rtc_set_time function.
> > >
> >
> > It is fine to test both in read_time and in set_time.
> >
>
> Do you mean that we can test powerkey and then set powerkey both in
> read_time and in set_time?
>
I mean that can test in read_time and test and set in set_time
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-22 13:26 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190822124628.GS27031@piout.net>
On Thu, 2019-08-22 at 14:46 +0200, Alexandre Belloni wrote:
> On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> > >
> > > This should be written when setting the time after power was lost.
> > >
> >
> > I suppose we can move this into mt2712_rtc_read_time function's "if
> > (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> > which will be added at next patch. We need additional flag to mark this
> > condition or another if condition in mt2712_rtc_set_time fucntion if we
> > put these code in mt2712_rtc_set_time function.
> >
>
> It is fine to test both in read_time and in set_time.
>
Do you mean that we can test powerkey and then set powerkey both in
read_time and in set_time?
_______________________________________________
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] arm64: dts: mt8183: add I2C nodes
From: Matthias Brugger @ 2019-08-22 13:21 UTC (permalink / raw)
To: qii.wang, robh+dt
Cc: mark.rutland, devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-arm-kernel
In-Reply-To: <1566477316-13245-1-git-send-email-qii.wang@mediatek.com>
On 22/08/2019 14:35, qii.wang@mediatek.com wrote:
> From: Qii Wang <qii.wang@mediatek.com>
>
> Add i2c nodes to mt8183 and mt8183-evb.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Applied, thanks
> ---
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 96 ++++++++++++++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 189 ++++++++++++++++++++++++++++
> 2 files changed, 285 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index d8e555c..1fb195c 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -30,7 +30,103 @@
> status = "okay";
> };
>
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_0>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_1>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_2>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_3>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_4>;
> + status = "okay";
> + clock-frequency = <1000000>;
> +};
> +
> +&i2c5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_5>;
> + status = "okay";
> + clock-frequency = <1000000>;
> +};
> +
> &pio {
> + i2c_pins_0: i2c0{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO82__FUNC_SDA0>,
> + <PINMUX_GPIO83__FUNC_SCL0>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_1: i2c1{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO81__FUNC_SDA1>,
> + <PINMUX_GPIO84__FUNC_SCL1>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_2: i2c2{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO103__FUNC_SCL2>,
> + <PINMUX_GPIO104__FUNC_SDA2>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_3: i2c3{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
> + <PINMUX_GPIO51__FUNC_SDA3>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_4: i2c4{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO105__FUNC_SCL4>,
> + <PINMUX_GPIO106__FUNC_SDA4>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_5: i2c5{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
> + <PINMUX_GPIO49__FUNC_SDA5>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> spi_pins_0: spi0{
> pins_spi{
> pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>,
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4..ab71291 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -16,6 +16,21 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
> + i2c5 = &i2c5;
> + i2c6 = &i2c6;
> + i2c7 = &i2c7;
> + i2c8 = &i2c8;
> + i2c9 = &i2c9;
> + i2c10 = &i2c10;
> + i2c11 = &i2c11;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -294,6 +309,64 @@
> status = "disabled";
> };
>
> + i2c6: i2c@11005000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11005000 0 0x1000>,
> + <0 0x11000600 0 0x80>;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C6>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c@11007000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11007000 0 0x1000>,
> + <0 0x11000080 0 0x80>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C0>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c@11008000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11008000 0 0x1000>,
> + <0 0x11000100 0 0x80>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C1>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C1_ARBITER>;
> + clock-names = "main", "dma","arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@11009000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11009000 0 0x1000>,
> + <0 0x11000280 0 0x80>;
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C2>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C2_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi0: spi@1100a000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -307,6 +380,20 @@
> status = "disabled";
> };
>
> + i2c3: i2c@1100f000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1100f000 0 0x1000>,
> + <0 0x11000400 0 0x80>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C3>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi1: spi@11010000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -320,6 +407,20 @@
> status = "disabled";
> };
>
> + i2c1: i2c@11011000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11011000 0 0x1000>,
> + <0 0x11000480 0 0x80>;
> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C4>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi2: spi@11012000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -346,6 +447,66 @@
> status = "disabled";
> };
>
> + i2c9: i2c@11014000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11014000 0 0x1000>,
> + <0 0x11000180 0 0x80>;
> + interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C1_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C1_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c10: i2c@11015000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11015000 0 0x1000>,
> + <0 0x11000300 0 0x80>;
> + interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C2_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C2_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c5: i2c@11016000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11016000 0 0x1000>,
> + <0 0x11000500 0 0x80>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C5>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C5_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c11: i2c@11017000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11017000 0 0x1000>,
> + <0 0x11000580 0 0x80>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C5_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C5_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi4: spi@11018000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -372,6 +533,34 @@
> status = "disabled";
> };
>
> + i2c7: i2c@1101a000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1101a000 0 0x1000>,
> + <0 0x11000680 0 0x80>;
> + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C7>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c8: i2c@1101b000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1101b000 0 0x1000>,
> + <0 0x11000700 0 0x80>;
> + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C8>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> audiosys: syscon@11220000 {
> compatible = "mediatek,mt8183-audiosys", "syscon";
> reg = <0 0x11220000 0 0x1000>;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
From: Kamil Konieczny @ 2019-08-22 13:18 UTC (permalink / raw)
To: MyungJoo Ham
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, Rob Herring,
Bartlomiej Zolnierkiewicz, Stephen Boyd, Viresh Kumar, linux-pm,
linux-kernel, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
Kukjin Kim, linux-arm-kernel, devicetree, Marek Szyprowski
In-Reply-To: <20190808090234.12577-1-k.konieczny@partner.samsung.com>
Dear MyungJoo,
On 08.08.2019 11:02, Kamil Konieczny wrote:
> Hi,
>
> The main purpose of this patch series is to add coupled regulators for
> Exynos5422/5800 to keep constrain on voltage difference between vdd_arm
> and vdd_int to be at most 300mV. In exynos-bus instead of using
> regulator_set_voltage_tol() with default voltage tolerance it should be
> used regulator_set_voltage_triplet() with volatege range, and this is
> already present in opp/core.c code, so it can be reused. While at this,
> move setting regulators into opp/core.
>
> This patchset was tested on Odroid XU3.
>
> The DTS coupled regulators patch depends on previous patches.
>
> Changes:
> v5:
> - squashed last patch "remove exynos_bus_passive_target()" into second
> - added Acked-by to patch "correct clock enable sequence"
Could you please merge patches 1/4 and 2/4 for v5.4
(they were already Ack-ed by Chanwoo Choi)?
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
> v4:
> - removed "opp: core: add regulators enable and disable" from patchset
> as it was applied by Viresh Kumar and changed cover letter
> - fix patch "devfreq: exynos-bus: correct clock enable sequence" to
> correct order of enable/disable
> - removed unrelated changes in "devfreq: exynos-bus: convert to use
> dev_pm_opp_set_rate()"
> - added new patch "devfreq: exynos-bus: remove exynos_bus_passive_target()"
> as suggested by Chanwoo Choi
> v3:
> - added new exynos-bus patch to correct clock and regulator enabling
> and disabling sequence as suggested by Chanwoo Choi
> - corrected error path in enable and improved commit message in opp/core
> - improve comment in devfreq/exynos-bus.c before devfreq_recommended_opp()
> - change cover letter as there is new patch
> - added note before Signed-off-by in 4th patch
> v2:
> - improve regulators enable/disable code in opp/core as suggested by
> Viresh Kumar
> - add new patch for remove unused dt-bindings as suggested by Krzysztof
> Kozlowski
>
> Kamil Konieczny (3):
> devfreq: exynos-bus: correct clock enable sequence
> devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
> dt-bindings: devfreq: exynos-bus: remove unused property
>
> Marek Szyprowski (1):
> ARM: dts: exynos: add initial data for coupled regulators for
> Exynos5422/5800
>
> .../bindings/devfreq/exynos-bus.txt | 2 -
> arch/arm/boot/dts/exynos5420.dtsi | 34 ++--
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 +
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +
> arch/arm/boot/dts/exynos5800.dtsi | 32 ++--
> drivers/devfreq/exynos-bus.c | 153 +++++-------------
> 6 files changed, 78 insertions(+), 151 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] [PATCH v3 2/2] drm/bridge: Add NWL MIPI DSI host controller support
From: Robert Chiras @ 2019-08-22 13:18 UTC (permalink / raw)
To: dl-linux-imx, narmstrong@baylibre.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org, lee.jones@linaro.org,
devicetree@vger.kernel.org, agx@sigxcpu.org, festevam@gmail.com,
jernej.skrabec@siol.net, daniel@ffwll.ch, mark.rutland@arm.com,
a.hajda@samsung.com, dri-devel@lists.freedesktop.org,
jonas@kwiboo.se, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, sam@ravnborg.org,
airlied@linux.ie, Laurent.pinchart@ideasonboard.com,
kernel@pengutronix.de, arnd@arndb.de, s.hauer@pengutronix.de
In-Reply-To: <ae518de22f7f0033c607e10ed8ef5330c7b2dff4.1566470526.git.agx@sigxcpu.org>
Hi Guido,
I added my signed-off, plus some comments inline.
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> It has been tested on the Librem 5 devkit using mxsfb.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> Co-developed-by: Robert Chiras <robert.chiras@nxp.com>
> ---
> drivers/gpu/drm/bridge/Kconfig | 2 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501 ++++++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> +++++++++++++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 ++++
> 8 files changed, 1401 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig
> b/drivers/gpu/drm/bridge/Kconfig
> index 1cc9f502c1f2..7980b5c2156f 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>
> +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> +
> source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..d9f6c0f77592 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> new file mode 100644
> index 000000000000..3b157a9f2229
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> @@ -0,0 +1,16 @@
> +config DRM_NWL_MIPI_DSI
> + tristate "Support for Northwest Logic MIPI DSI Host
> controller"
> + depends on DRM
> + depends on COMMON_CLK
> + depends on OF && HAS_IOMEM
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> + select MFD_SYSCON
> + select MULTIPLEXER
> + select REGMAP_MMIO
> + help
> + This enables the Northwest Logic MIPI DSI Host controller
> as
> + for example found on NXP's i.MX8 Processors.
> +
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> new file mode 100644
> index 000000000000..804baf2f1916
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> +header-test-y += nwl-drv.h nwl-dsi.h
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> new file mode 100644
> index 000000000000..e457438738c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> @@ -0,0 +1,501 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX8 NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/irq.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/mux/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/sys_soc.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
> +
> +#define DRV_NAME "nwl-dsi"
> +
> +/* Possible platform specific clocks */
> +#define NWL_DSI_CLK_CORE "core"
> +
> +static const struct regmap_config nwl_dsi_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = NWL_DSI_IRQ_MASK2,
> + .name = DRV_NAME,
> +};
> +
> +struct nwl_dsi_platform_data {
> + int (*poweron)(struct nwl_dsi *dsi);
> + int (*poweroff)(struct nwl_dsi *dsi);
> + int (*select_input)(struct nwl_dsi *dsi);
> + int (*deselect_input)(struct nwl_dsi *dsi);
> + struct nwl_dsi_plat_clk_config
> clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
> +};
> +
> +static inline struct nwl_dsi *bridge_to_dsi(struct drm_bridge
> *bridge)
> +{
> + return container_of(bridge, struct nwl_dsi, bridge);
> +}
> +
> +static int nwl_dsi_set_platform_clocks(struct nwl_dsi *dsi, bool
> enable)
> +{
> + struct device *dev = dsi->dev;
> + const char *id;
> + struct clk *clk;
> + size_t i;
> + unsigned long rate;
> + int ret, result = 0;
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "%s platform clocks\n",
> + enable ? "enabling" : "disabling");
> + for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
> + if (!dsi->clk_config[i].present)
> + continue;
> + id = dsi->clk_config[i].id;
> + clk = dsi->clk_config[i].clk;
> +
> + if (enable) {
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev,
> + "Failed to enable %s
> clk: %d\n",
> + id, ret);
> + result = result ?: ret;
> + }
> + rate = clk_get_rate(clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "Enabled %s clk
> @%lu Hz\n",
> + id, rate);
> + } else {
> + clk_disable_unprepare(clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "Disabled %s
> clk\n", id);
> + }
> + }
> +
> + return result;
> +}
> +
> +static int nwl_dsi_plat_enable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> + int ret;
> +
> + if (dsi->pdata->select_input)
> + dsi->pdata->select_input(dsi);
> +
> + ret = nwl_dsi_set_platform_clocks(dsi, true);
> + if (ret < 0)
> + return ret;
> +
> + ret = dsi->pdata->poweron(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "Failed to power on DSI: %d\n",
> ret);
> + return ret;
> +}
> +
> +static void nwl_dsi_plat_disable(struct nwl_dsi *dsi)
> +{
> + dsi->pdata->poweroff(dsi);
> + nwl_dsi_set_platform_clocks(dsi, false);
> + if (dsi->pdata->deselect_input)
> + dsi->pdata->deselect_input(dsi);
> +}
> +
> +static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + nwl_dsi_disable(dsi);
> + nwl_dsi_plat_disable(dsi);
> + pm_runtime_put(dsi->dev);
> +}
> +
> +static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
> + const struct drm_display_mode
> *mode,
> + union phy_configure_opts
> *phy_opts)
> +{
> + unsigned long rate;
> + int ret;
> +
> + if (dsi->lanes < 1 || dsi->lanes > 4)
> + return -EINVAL;
> +
> + /*
> + * So far the DPHY spec minimal timings work for both mixel
> + * dphy and nwl dsi host
> + */
> + ret = phy_mipi_dphy_get_default_config(
> + mode->crtc_clock * 1000,
> + mipi_dsi_pixel_format_to_bpp(dsi->format), dsi-
> >lanes,
> + &phy_opts->mipi_dphy);
> + if (ret < 0)
> + return ret;
> +
> + rate = clk_get_rate(dsi->tx_esc_clk);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "LP clk is @%lu Hz\n", rate);
> + phy_opts->mipi_dphy.lp_clk_rate = rate;
> +
> + return 0;
> +}
> +
> +static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode,
> + struct drm_display_mode
> *adjusted_mode)
> +{
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> +
> + return true;
> +}
> +
> +static enum drm_mode_status
> +nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + if (mode->clock * bpp > 15000000)
> + return MODE_CLOCK_HIGH;
> +
> + if (mode->clock * bpp < 80000)
> + return MODE_CLOCK_LOW;
These limits (80MBPS min and 1500MBPS max) are per lane, so you should
involve the numbers of lanes here, too. According to this formula, you
limit the maximum DSI throughput to 1.5Gbps, while the maximum is 6Gbps
(1.5 * 4 lanes)
> +
> + return MODE_OK;
> +}
> +
> +static void
> +nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> + struct device *dev = dsi->dev;
> + union phy_configure_opts new_cfg;
> + unsigned long phy_ref_rate;
> + int ret;
> +
> + ret = nwl_dsi_get_dphy_params(dsi, adjusted_mode, &new_cfg);
> + if (ret < 0)
> + return;
> +
> + /*
> + * If hs clock is unchanged, we're all good - all parameters
> are
> + * derived from it atm.
> + */
> + if (new_cfg.mipi_dphy.hs_clk_rate == dsi-
> >phy_cfg.mipi_dphy.hs_clk_rate)
> + return;
> +
> + phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n",
> phy_ref_rate);
> + /* Save the new desired phy config */
> + memcpy(&dsi->phy_cfg, &new_cfg, sizeof(new_cfg));
> +
> + memcpy(&dsi->mode, adjusted_mode, sizeof(dsi->mode));
> + drm_mode_debug_printmodeline(adjusted_mode);
> +}
> +
> +static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + pm_runtime_get_sync(dsi->dev);
> + nwl_dsi_plat_enable(dsi);
> + nwl_dsi_enable(dsi);
> +}
> +
> +static int nwl_dsi_bridge_attach(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge->driver_private;
> +
> + return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
> bridge);
> +}
> +
> +static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
> + .pre_enable = nwl_dsi_bridge_pre_enable,
> + .disable = nwl_dsi_bridge_disable,
> + .mode_fixup = nwl_dsi_bridge_mode_fixup,
> + .mode_set = nwl_dsi_bridge_mode_set,
> + .mode_valid = nwl_dsi_bridge_mode_valid,
> + .attach = nwl_dsi_bridge_attach,
> +};
> +
> +static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> +{
> + struct platform_device *pdev = to_platform_device(dsi->dev);
> + struct clk *clk;
> + const char *clk_id;
> + void __iomem *base;
> + int i, ret;
> +
> + dsi->phy = devm_phy_get(dsi->dev, "dphy");
> + if (IS_ERR(dsi->phy)) {
> + ret = PTR_ERR(dsi->phy);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dsi->dev, "Could not get PHY:
> %d\n", ret);
> + return ret;
> + }
> +
> + /* Platform dependent clocks */
> + memcpy(dsi->clk_config, dsi->pdata->clk_config,
> + sizeof(dsi->pdata->clk_config));
> +
> + for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
> + if (!dsi->clk_config[i].present)
> + continue;
> +
> + clk_id = dsi->clk_config[i].id;
> + clk = devm_clk_get(dsi->dev, clk_id);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get %s
> clock: %d\n",
> + clk_id, ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Setup clk %s (rate:
> %lu)\n",
> + clk_id, clk_get_rate(clk));
> + dsi->clk_config[i].clk = clk;
> + }
> +
> + /* DSI clocks */
> + clk = devm_clk_get(dsi->dev, "phy_ref");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get phy_ref clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->phy_ref_clk = clk;
> +
> + clk = devm_clk_get(dsi->dev, "rx_esc");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get rx_esc clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->rx_esc_clk = clk;
> +
> + clk = devm_clk_get(dsi->dev, "tx_esc");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get tx_esc clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->tx_esc_clk = clk;
> +
> + dsi->mux = devm_mux_control_get(dsi->dev, NULL);
> + if (IS_ERR(dsi->mux)) {
> + ret = PTR_ERR(dsi->mux);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dsi->dev, "Failed to get mux:
> %d\n", ret);
> + return ret;
> + }
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + dsi->regmap =
> + devm_regmap_init_mmio(dsi->dev, base,
> &nwl_dsi_regmap_config);
> + if (IS_ERR(dsi->regmap)) {
> + ret = PTR_ERR(dsi->regmap);
> + DRM_DEV_ERROR(dsi->dev, "Failed to create NWL DSI
> regmap: %d\n",
> + ret);
> + return ret;
> + }
> +
> + dsi->irq = platform_get_irq(pdev, 0);
> + if (dsi->irq < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to get device IRQ:
> %d\n",
> + dsi->irq);
> + return dsi->irq;
> + }
> +
> + dsi->rstc = devm_reset_control_array_get(dsi->dev, false,
> true);
> + if (IS_ERR(dsi->rstc)) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to get resets:
> %ld\n",
> + PTR_ERR(dsi->rstc));
> + return PTR_ERR(dsi->rstc);
> + }
> +
> + return 0;
> +}
> +
> +static int imx8mq_dsi_select_input(struct nwl_dsi *dsi)
> +{
> + struct device_node *remote;
> + u32 use_dcss = 1;
> + int ret;
> +
> + remote = of_graph_get_remote_node(dsi->dev->of_node, 0, 0);
> + if (strcmp(remote->name, "lcdif") == 0)
> + use_dcss = 0;
> +
> + DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
> + (use_dcss) ? "DCSS" : "LCDIF");
> +
> + ret = mux_control_try_select(dsi->mux, use_dcss);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to select input:
> %d\n", ret);
> +
> + of_node_put(remote);
> + return ret;
> +}
> +
> +
> +static int imx8mq_dsi_deselect_input(struct nwl_dsi *dsi)
> +{
> + int ret;
> +
> + ret = mux_control_deselect(dsi->mux);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to deselect input:
> %d\n", ret);
> +
> + return ret;
> +}
> +
> +
> +static int imx8mq_dsi_poweron(struct nwl_dsi *dsi)
> +{
> + int ret = 0;
> +
> + /* otherwise the display stays blank */
> + usleep_range(200, 300);
> +
> + if (dsi->rstc)
> + ret = reset_control_deassert(dsi->rstc);
> +
> + return ret;
> +}
> +
> +static int imx8mq_dsi_poweroff(struct nwl_dsi *dsi)
> +{
> + int ret = 0;
> +
> + if (dsi->quirks & SRC_RESET_QUIRK)
> + return 0;
> +
> + if (dsi->rstc)
> + ret = reset_control_assert(dsi->rstc);
> + return ret;
> +}
> +
> +static const struct drm_bridge_timings nwl_dsi_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_DE_LOW,
> +};
> +
> +static const struct nwl_dsi_platform_data imx8mq_dev = {
> + .poweron = &imx8mq_dsi_poweron,
> + .poweroff = &imx8mq_dsi_poweroff,
> + .select_input = &imx8mq_dsi_select_input,
> + .deselect_input = &imx8mq_dsi_deselect_input,
> + .clk_config = {
> + { .id = NWL_DSI_CLK_CORE, .present = true },
> + },
> +};
> +
> +static const struct of_device_id nwl_dsi_dt_ids[] = {
> + { .compatible = "fsl,imx8mq-nwl-dsi", .data = &imx8mq_dev, },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, nwl_dsi_dt_ids);
> +
> +static const struct soc_device_attribute nwl_dsi_quirks_match[] = {
> + { .soc_id = "i.MX8MQ", .revision = "2.0",
> + .data = (void *)(E11418_HS_MODE_QUIRK | SRC_RESET_QUIRK) },
> + { /* sentinel. */ },
> +};
> +
> +static int nwl_dsi_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct of_device_id *of_id =
> of_match_device(nwl_dsi_dt_ids, dev);
> + const struct nwl_dsi_platform_data *pdata = of_id->data;
> + const struct soc_device_attribute *attr;
> + struct nwl_dsi *dsi;
> + int ret;
> +
> + dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> + if (!dsi)
> + return -ENOMEM;
> +
> + dsi->dev = dev;
> + dsi->pdata = pdata;
> +
> + ret = nwl_dsi_parse_dt(dsi);
> + if (ret)
> + return ret;
> +
> + ret = devm_request_irq(dev, dsi->irq, nwl_dsi_irq_handler, 0,
> + dev_name(dev), dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to request IRQ %d: %d\n",
> dsi->irq,
> + ret);
> + return ret;
> + }
> +
> + dsi->dsi_host.ops = &nwl_dsi_host_ops;
> + dsi->dsi_host.dev = dev;
> + ret = mipi_dsi_host_register(&dsi->dsi_host);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "Failed to register MIPI host:
> %d\n", ret);
> + return ret;
> + }
> +
> + attr = soc_device_match(nwl_dsi_quirks_match);
> + if (attr)
> + dsi->quirks = (uintptr_t)attr->data;
> +
> + dsi->bridge.driver_private = dsi;
> + dsi->bridge.funcs = &nwl_dsi_bridge_funcs;
> + dsi->bridge.of_node = dev->of_node;
> + dsi->bridge.timings = &nwl_dsi_timings;
> +
> + drm_bridge_add(&dsi->bridge);
> +
> + dev_set_drvdata(dev, dsi);
> + pm_runtime_enable(dev);
> + return 0;
> +}
> +
> +static int nwl_dsi_remove(struct platform_device *pdev)
> +{
> + struct nwl_dsi *dsi = platform_get_drvdata(pdev);
> +
> + mipi_dsi_host_unregister(&dsi->dsi_host);
> + pm_runtime_disable(&pdev->dev);
> + return 0;
> +}
> +
> +static struct platform_driver nwl_dsi_driver = {
> + .probe = nwl_dsi_probe,
> + .remove = nwl_dsi_remove,
> + .driver = {
> + .of_match_table = nwl_dsi_dt_ids,
> + .name = DRV_NAME,
> + },
> +};
> +
> +module_platform_driver(nwl_dsi_driver);
> +
> +MODULE_AUTHOR("NXP Semiconductor");
> +MODULE_AUTHOR("Purism SPC");
> +MODULE_DESCRIPTION("Northwest Logic MIPI-DSI driver");
> +MODULE_LICENSE("GPL"); /* GPLv2 or later */
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> new file mode 100644
> index 000000000000..1e72a9221401
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#ifndef __NWL_DRV_H__
> +#define __NWL_DRV_H__
> +
> +#include <linux/mux/consumer.h>
> +#include <linux/phy/phy.h>
> +
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_mipi_dsi.h>
> +
> +struct nwl_dsi_platform_data;
> +
> +/* i.MX8 NWL quirks */
> +/* i.MX8MQ errata E11418 */
> +#define E11418_HS_MODE_QUIRK BIT(0)
> +/* Skip DSI bits in SRC on disable to avoid blank display on enable
> */
> +#define SRC_RESET_QUIRK BIT(1)
> +
> +#define NWL_DSI_MAX_PLATFORM_CLOCKS 1
> +struct nwl_dsi_plat_clk_config {
> + const char *id;
> + struct clk *clk;
> + bool present;
> +};
> +
> +struct nwl_dsi {
> + struct drm_bridge bridge;
> + struct mipi_dsi_host dsi_host;
> + struct drm_bridge *panel_bridge;
> + struct device *dev;
> + struct phy *phy;
> + union phy_configure_opts phy_cfg;
> + unsigned int quirks;
> +
> + struct regmap *regmap;
> + int irq;
> + struct reset_control *rstc;
> + struct mux_control *mux;
> +
> + /* DSI clocks */
> + struct clk *phy_ref_clk;
> + struct clk *rx_esc_clk;
> + struct clk *tx_esc_clk;
> + /* Platform dependent clocks */
> + struct nwl_dsi_plat_clk_config
> clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
> +
> + /* dsi lanes */
> + u32 lanes;
> + enum mipi_dsi_pixel_format format;
> + struct drm_display_mode mode;
> + unsigned long dsi_mode_flags;
> +
> + struct nwl_dsi_transfer *xfer;
> +
> + const struct nwl_dsi_platform_data *pdata;
> +};
> +
> +#endif /* __NWL_DRV_H__ */
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> new file mode 100644
> index 000000000000..fd030af55bb4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> @@ -0,0 +1,700 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/irq.h>
> +#include <linux/regmap.h>
> +#include <linux/time64.h>
> +
> +#include <video/mipi_display.h>
> +#include <video/videomode.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
> +
> +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> +
> +/*
> + * PKT_CONTROL format:
> + * [15: 0] - word count
> + * [17:16] - virtual channel
> + * [23:18] - data type
> + * [24] - LP or HS select (0 - LP, 1 - HS)
> + * [25] - perform BTA after packet is sent
> + * [26] - perform BTA only, no packet tx
> + */
> +#define NWL_DSI_WC(x) FIELD_PREP(GENMASK(15, 0), (x))
> +#define NWL_DSI_TX_VC(x) FIELD_PREP(GENMASK(17, 16), (x))
> +#define NWL_DSI_TX_DT(x) FIELD_PREP(GENMASK(23, 18), (x))
> +#define NWL_DSI_HS_SEL(x) FIELD_PREP(GENMASK(24, 24), (x))
> +#define NWL_DSI_BTA_TX(x) FIELD_PREP(GENMASK(25, 25), (x))
> +#define NWL_DSI_BTA_NO_TX(x) FIELD_PREP(GENMASK(26, 26), (x))
> +
> +/*
> + * RX_PKT_HEADER format:
> + * [15: 0] - word count
> + * [21:16] - data type
> + * [23:22] - virtual channel
> + */
> +#define NWL_DSI_RX_DT(x) FIELD_GET(GENMASK(21, 16), (x))
> +#define NWL_DSI_RX_VC(x) FIELD_GET(GENMASK(23, 22), (x))
> +
> +/* DSI Video mode */
> +#define NWL_DSI_VM_BURST_MODE_WITH_SYNC_PULSES 0
> +#define NWL_DSI_VM_NON_BURST_MODE_WITH_SYNC_EVENTS BIT(0)
> +#define NWL_DSI_VM_BURST_MODE BIT(1)
> +
> +/* * DPI color coding */
> +#define NWL_DSI_DPI_16_BIT_565_PACKED 0
> +#define NWL_DSI_DPI_16_BIT_565_ALIGNED 1
> +#define NWL_DSI_DPI_16_BIT_565_SHIFTED 2
> +#define NWL_DSI_DPI_18_BIT_PACKED 3
> +#define NWL_DSI_DPI_18_BIT_ALIGNED 4
> +#define NWL_DSI_DPI_24_BIT 5
> +
> +/* * DPI Pixel format */
> +#define NWL_DSI_PIXEL_FORMAT_16 0
> +#define NWL_DSI_PIXEL_FORMAT_18 BIT(0)
> +#define NWL_DSI_PIXEL_FORMAT_18L BIT(1)
> +#define NWL_DSI_PIXEL_FORMAT_24 (BIT(0) | BIT(1))
> +
> +enum transfer_direction {
> + DSI_PACKET_SEND,
> + DSI_PACKET_RECEIVE,
> +};
> +
> +struct nwl_dsi_transfer {
> + const struct mipi_dsi_msg *msg;
> + struct mipi_dsi_packet packet;
> + struct completion completed;
> +
> + int status; /* status of transmission */
> + enum transfer_direction direction;
> + bool need_bta;
> + u8 cmd;
> + u16 rx_word_count;
> + size_t tx_len; /* in bytes */
> + size_t rx_len; /* in bytes */
> +};
> +
> +static int nwl_dsi_write(struct nwl_dsi *dsi, unsigned int reg, u32
> val)
> +{
> + int ret;
> +
> + ret = regmap_write(dsi->regmap, reg, val);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev,
> + "Failed to write NWL DSI reg 0x%x:
> %d\n", reg,
> + ret);
> + return ret;
> +}
> +
> +static u32 nwl_dsi_read(struct nwl_dsi *dsi, u32 reg)
> +{
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(dsi->regmap, reg, &val);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to read NWL DSI reg
> 0x%x: %d\n",
> + reg, ret);
> +
> + return val;
> +}
> +
> +static u32 nwl_dsi_get_dpi_pixel_format(enum mipi_dsi_pixel_format
> format)
> +{
> + switch (format) {
> + case MIPI_DSI_FMT_RGB565:
> + return NWL_DSI_PIXEL_FORMAT_16;
> + case MIPI_DSI_FMT_RGB666:
> + return NWL_DSI_PIXEL_FORMAT_18L;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return NWL_DSI_PIXEL_FORMAT_18;
> + case MIPI_DSI_FMT_RGB888:
> + return NWL_DSI_PIXEL_FORMAT_24;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +#define PSEC_PER_SEC 1000000000000LL
> +/*
> + * ps2bc - Picoseconds to byte clock cycles
> + */
> +static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long ps)
> +{
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + return DIV_ROUND_UP(ps * dsi->mode.clock * 1000 * bpp,
> + dsi->lanes * 8 * PSEC_PER_SEC);
> +}
> +
> +/*
> + * ui2bc - UI time periods to byte clock cycles
> + */
> +static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
> +{
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + return DIV_ROUND_UP(ui * dsi->lanes, dsi->mode.clock * 1000 *
> bpp);
> +}
> +
> +/*
> + * us2bc - micro seconds to lp clock cycles
> + */
> +static u32 us2lp(u32 lp_clk_rate, unsigned long us)
> +{
> + return DIV_ROUND_UP(us * lp_clk_rate, USEC_PER_SEC);
> +}
> +
> +static int nwl_dsi_config_host(struct nwl_dsi *dsi)
> +{
> + u32 cycles;
> + struct phy_configure_opts_mipi_dphy *cfg = &dsi-
> >phy_cfg.mipi_dphy;
> +
> + if (dsi->lanes < 1 || dsi->lanes > 4)
> + return -EINVAL;
> +
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "DSI Lanes %d\n", dsi->lanes);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NUM_LANES, dsi->lanes - 1);
> +
> + if (dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK,
> 0x01);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP,
> 0x01);
> + } else {
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK,
> 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP,
> 0x00);
> + }
> +
> + /* values in byte clock cycles */
> + cycles = ui2bc(dsi, cfg->clk_pre);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_T_PRE, cycles);
> + cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg-
> >clk_zero);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x\n",
> cycles);
> + cycles += ui2bc(dsi, cfg->clk_pre);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_T_POST, cycles);
> + cycles = ps2bc(dsi, cfg->hs_exit);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_TX_GAP, cycles);
> +
> + nwl_dsi_write(dsi, NWL_DSI_CFG_EXTRA_CMDS_AFTER_EOTP, 0x01);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_HTX_TO_COUNT, 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_LRX_H_TO_COUNT, 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_BTA_H_TO_COUNT, 0x00);
> + /* In LP clock cycles */
> + cycles = us2lp(cfg->lp_clk_rate, cfg->wakeup);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_twakeup: 0x%x\n",
> cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_TWAKEUP, cycles);
> +
> + return 0;
> +}
> +
> +static int nwl_dsi_config_dpi(struct nwl_dsi *dsi)
> +{
> + u32 color_format, mode;
> + bool burst_mode;
> + int hfront_porch, hback_porch, vfront_porch, vback_porch;
> + int hsync_len, vsync_len;
> +
> + hfront_porch = dsi->mode.hsync_start - dsi->mode.hdisplay;
> + hsync_len = dsi->mode.hsync_end - dsi->mode.hsync_start;
> + hback_porch = dsi->mode.htotal - dsi->mode.hsync_end;
> +
> + vfront_porch = dsi->mode.vsync_start - dsi->mode.vdisplay;
> + vsync_len = dsi->mode.vsync_end - dsi->mode.vsync_start;
> + vback_porch = dsi->mode.vtotal - dsi->mode.vsync_end;
> +
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hfront_porch = %d\n",
> hfront_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hback_porch = %d\n",
> hback_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hsync_len = %d\n",
> hsync_len);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hdisplay = %d\n", dsi-
> >mode.hdisplay);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vfront_porch = %d\n",
> vfront_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vback_porch = %d\n",
> vback_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vsync_len = %d\n",
> vsync_len);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vactive = %d\n", dsi-
> >mode.vdisplay);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "clock = %d kHz\n", dsi-
> >mode.clock);
> +
> + color_format = nwl_dsi_get_dpi_pixel_format(dsi->format);
> + if (color_format < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Invalid color format
> 0x%x\n",
> + dsi->format);
> + return color_format;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "pixel fmt = %d\n", dsi-
> >format);
> +
> + nwl_dsi_write(dsi, NWL_DSI_INTERFACE_COLOR_CODING,
> NWL_DSI_DPI_24_BIT);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FORMAT, color_format);
> + /*
> + * Adjusting input polarity based on the video mode results
> in
> + * a black screen so always pick active low:
> + */
> + nwl_dsi_write(dsi, NWL_DSI_VSYNC_POLARITY,
> + NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW);
> + nwl_dsi_write(dsi, NWL_DSI_HSYNC_POLARITY,
> + NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW);
> +
> + burst_mode = (dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_BURST) &&
> + !(dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE);
> +
> + if (burst_mode) {
> + nwl_dsi_write(dsi, NWL_DSI_VIDEO_MODE,
> NWL_DSI_VM_BURST_MODE);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FIFO_SEND_LEVEL,
> 256);
> + } else {
> + mode = ((dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE) ?
> + NWL_DSI_VM_BURST_MODE_WITH_SYNC_PULSE
> S :
> + NWL_DSI_VM_NON_BURST_MODE_WITH_SYNC_E
> VENTS);
> + nwl_dsi_write(dsi, NWL_DSI_VIDEO_MODE, mode);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FIFO_SEND_LEVEL,
> + dsi->mode.hdisplay);
> + }
> +
> + nwl_dsi_write(dsi, NWL_DSI_HFP, hfront_porch);
> + nwl_dsi_write(dsi, NWL_DSI_HBP, hback_porch);
> + nwl_dsi_write(dsi, NWL_DSI_HSA, hsync_len);
> +
> + nwl_dsi_write(dsi, NWL_DSI_ENABLE_MULT_PKTS, 0x0);
> + nwl_dsi_write(dsi, NWL_DSI_BLLP_MODE, 0x1);
> + nwl_dsi_write(dsi, NWL_DSI_ENABLE_MULT_PKTS, 0x0);
NWL_DSI_ENABLE_MULT_PKTS is written twice, by mistake, so remove this
line. I did the same mistake on NXP tree, I think you got it from there
:)
> + nwl_dsi_write(dsi, NWL_DSI_USE_NULL_PKT_BLLP, 0x0);
> + nwl_dsi_write(dsi, NWL_DSI_VC, 0x0);
> +
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_PAYLOAD_SIZE, dsi-
> >mode.hdisplay);
> + nwl_dsi_write(dsi, NWL_DSI_VACTIVE, dsi->mode.vdisplay - 1);
VACTIVE shold contain the number of lines in the vertical area. "-1"
subtraction was actually wrong.
> + nwl_dsi_write(dsi, NWL_DSI_VBP, vback_porch);
> + nwl_dsi_write(dsi, NWL_DSI_VFP, vfront_porch);
> +
> + return 0;
> +}
> +
> +static void nwl_dsi_init_interrupts(struct nwl_dsi *dsi)
> +{
> + u32 irq_enable;
> +
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, 0xffffffff);
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK2, 0x7);
> +
> + irq_enable = ~(u32)(NWL_DSI_TX_PKT_DONE_MASK |
> + NWL_DSI_RX_PKT_HDR_RCVD_MASK |
> + NWL_DSI_TX_FIFO_OVFLW_MASK |
> + NWL_DSI_HS_TX_TIMEOUT_MASK);
> +
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, irq_enable);
> +}
> +
> +static int nwl_dsi_host_attach(struct mipi_dsi_host *dsi_host,
> + struct mipi_dsi_device *device)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> + struct device *dev = dsi->dev;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> + int ret;
> +
> + DRM_DEV_INFO(dev, "lanes=%u, format=0x%x flags=0x%lx\n",
> device->lanes,
> + device->format, device->mode_flags);
> +
> + if (device->lanes < 1 || device->lanes > 4)
> + return -EINVAL;
> +
> + dsi->lanes = device->lanes;
> + dsi->format = device->format;
> + dsi->dsi_mode_flags = device->mode_flags;
> +
> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
> &panel,
> + &bridge);
> + if (ret)
> + return ret;
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add(panel,
> DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
> + }
> +
> + dsi->panel_bridge = bridge;
> + drm_bridge_add(&dsi->bridge);
> +
> + return 0;
> +}
> +
> +static int nwl_dsi_host_detach(struct mipi_dsi_host *dsi_host,
> + struct mipi_dsi_device *device)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> +
> + drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
> + drm_bridge_remove(&dsi->bridge);
> +
> + return 0;
> +}
> +
> +static bool nwl_dsi_read_packet(struct nwl_dsi *dsi, u32 status)
> +{
> + struct device *dev = dsi->dev;
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + u8 *payload = xfer->msg->rx_buf;
> + u32 val;
> + u16 word_count;
> + u8 channel;
> + u8 data_type;
> +
> + xfer->status = 0;
> +
> + if (xfer->rx_word_count == 0) {
> + if (!(status & NWL_DSI_RX_PKT_HDR_RCVD))
> + return false;
> + /* Get the RX header and parse it */
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PKT_HEADER);
> + word_count = NWL_DSI_WC(val);
> + channel = NWL_DSI_RX_VC(val);
> + data_type = NWL_DSI_RX_DT(val);
> +
> + if (channel != xfer->msg->channel) {
> + DRM_DEV_ERROR(dev,
> + "[%02X] Channel mismatch (%u !=
> %u)\n",
> + xfer->cmd, channel, xfer->msg-
> >channel);
> + return true;
> + }
> +
> + switch (data_type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + /* Fall through */
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + if (xfer->msg->rx_len > 1) {
> + /* read second byte */
> + payload[1] = word_count >> 8;
> + ++xfer->rx_len;
> + }
> + /* Fall through */
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + /* Fall through */
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + if (xfer->msg->rx_len > 0) {
> + /* read first byte */
> + payload[0] = word_count & 0xff;
> + ++xfer->rx_len;
> + }
> + xfer->status = xfer->rx_len;
> + return true;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + word_count &= 0xff;
> + DRM_DEV_ERROR(dev, "[%02X] DSI error report:
> 0x%02x\n",
> + xfer->cmd, word_count);
> + xfer->status = -EPROTO;
> + return true;
> + }
> +
> + if (word_count > xfer->msg->rx_len) {
> + DRM_DEV_ERROR(
> + dev,
> + "[%02X] Receive buffer too small: %lu
> (< %u)\n",
> + xfer->cmd, xfer->msg->rx_len,
> word_count);
> + return true;
> + }
> +
> + xfer->rx_word_count = word_count;
> + } else {
> + /* Set word_count from previous header read */
> + word_count = xfer->rx_word_count;
> + }
> +
> + /* If RX payload is not yet received, wait for it */
> + if (!(status & NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD))
> + return false;
> +
> + /* Read the RX payload */
> + while (word_count >= 4) {
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PAYLOAD);
> + payload[0] = (val >> 0) & 0xff;
> + payload[1] = (val >> 8) & 0xff;
> + payload[2] = (val >> 16) & 0xff;
> + payload[3] = (val >> 24) & 0xff;
> + payload += 4;
> + xfer->rx_len += 4;
> + word_count -= 4;
> + }
> +
> + if (word_count > 0) {
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PAYLOAD);
> + switch (word_count) {
> + case 3:
> + payload[2] = (val >> 16) & 0xff;
> + ++xfer->rx_len;
> + /* Fall through */
> + case 2:
> + payload[1] = (val >> 8) & 0xff;
> + ++xfer->rx_len;
> + /* Fall through */
> + case 1:
> + payload[0] = (val >> 0) & 0xff;
> + ++xfer->rx_len;
> + break;
> + }
> + }
> +
> + xfer->status = xfer->rx_len;
> +
> + return true;
> +}
> +
> +static void nwl_dsi_finish_transmission(struct nwl_dsi *dsi, u32
> status)
> +{
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + bool end_packet = false;
> +
> + if (!xfer)
> + return;
> +
> + if (status & NWL_DSI_TX_FIFO_OVFLW) {
> + DRM_DEV_ERROR_RATELIMITED(dsi->dev, "tx fifo
> overflow\n");
> + return;
> + }
> +
> + if (status & NWL_DSI_HS_TX_TIMEOUT) {
> + DRM_DEV_ERROR_RATELIMITED(dsi->dev, "HS tx
> timeout\n");
> + return;
> + }
> +
> + if (xfer->direction == DSI_PACKET_SEND &&
> + status & NWL_DSI_TX_PKT_DONE) {
> + xfer->status = xfer->tx_len;
> + end_packet = true;
> + } else if (status & NWL_DSI_DPHY_DIRECTION &&
> + ((status & (NWL_DSI_RX_PKT_HDR_RCVD |
> + NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD)))) {
> + end_packet = nwl_dsi_read_packet(dsi, status);
> + }
> +
> + if (end_packet)
> + complete(&xfer->completed);
> +}
> +
> +static void nwl_dsi_begin_transmission(struct nwl_dsi *dsi)
> +{
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + struct mipi_dsi_packet *pkt = &xfer->packet;
> + const u8 *payload;
> + size_t length;
> + u16 word_count;
> + u8 hs_mode;
> + u32 val;
> + u32 hs_workaround = 0;
> +
> + /* Send the payload, if any */
> + length = pkt->payload_length;
> + payload = pkt->payload;
> +
> + while (length >= 4) {
> + val = *(u32 *)payload;
> + hs_workaround |= !(val & 0xFFFF00);
> + nwl_dsi_write(dsi, NWL_DSI_TX_PAYLOAD, val);
> + payload += 4;
> + length -= 4;
> + }
> + /* Send the rest of the payload */
> + val = 0;
> + switch (length) {
> + case 3:
> + val |= payload[2] << 16;
> + /* Fall through */
> + case 2:
> + val |= payload[1] << 8;
> + hs_workaround |= !(val & 0xFFFF00);
> + /* Fall through */
> + case 1:
> + val |= payload[0];
> + nwl_dsi_write(dsi, NWL_DSI_TX_PAYLOAD, val);
> + break;
> + }
> + xfer->tx_len = pkt->payload_length;
> +
> + /*
> + * Send the header
> + * header[0] = Virtual Channel + Data Type
> + * header[1] = Word Count LSB (LP) or first param (SP)
> + * header[2] = Word Count MSB (LP) or second param (SP)
> + */
> + word_count = pkt->header[1] | (pkt->header[2] << 8);
> + if (hs_workaround && (dsi->quirks & E11418_HS_MODE_QUIRK)) {
> + DRM_DEV_DEBUG_DRIVER(dsi->dev,
> + "Using hs mode workaround for
> cmd 0x%x\n",
> + xfer->cmd);
> + hs_mode = 1;
> + } else {
> + hs_mode = (xfer->msg->flags & MIPI_DSI_MSG_USE_LPM) ?
> 0 : 1;
> + }
> + val = NWL_DSI_WC(word_count) | NWL_DSI_TX_VC(xfer->msg-
> >channel) |
> + NWL_DSI_TX_DT(xfer->msg->type) |
> NWL_DSI_HS_SEL(hs_mode) |
> + NWL_DSI_BTA_TX(xfer->need_bta);
> + nwl_dsi_write(dsi, NWL_DSI_PKT_CONTROL, val);
> +
> + /* Send packet command */
> + nwl_dsi_write(dsi, NWL_DSI_SEND_PACKET, 0x1);
> +}
> +
> +static ssize_t nwl_dsi_host_transfer(struct mipi_dsi_host *dsi_host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> + struct nwl_dsi_transfer xfer;
> + ssize_t ret = 0;
> +
> + /* Create packet to be sent */
> + dsi->xfer = &xfer;
> + ret = mipi_dsi_create_packet(&xfer.packet, msg);
> + if (ret < 0) {
> + dsi->xfer = NULL;
> + return ret;
> + }
> +
> + if ((msg->type & MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM ||
> + msg->type & MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM ||
> + msg->type & MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM ||
> + msg->type & MIPI_DSI_DCS_READ) &&
> + msg->rx_len > 0 && msg->rx_buf != NULL)
> + xfer.direction = DSI_PACKET_RECEIVE;
> + else
> + xfer.direction = DSI_PACKET_SEND;
> +
> + xfer.need_bta = (xfer.direction == DSI_PACKET_RECEIVE);
> + xfer.need_bta |= (msg->flags & MIPI_DSI_MSG_REQ_ACK) ? 1 : 0;
> + xfer.msg = msg;
> + xfer.status = -ETIMEDOUT;
> + xfer.rx_word_count = 0;
> + xfer.rx_len = 0;
> + xfer.cmd = 0x00;
> + if (msg->tx_len > 0)
> + xfer.cmd = ((u8 *)(msg->tx_buf))[0];
> + init_completion(&xfer.completed);
> +
> + ret = clk_prepare_enable(dsi->rx_esc_clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable rx_esc clk:
> %zd\n",
> + ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Enabled rx_esc clk @%lu
> Hz\n",
> + clk_get_rate(dsi->rx_esc_clk));
This will be printed every time a DSI command is sent, of course, when
debugging only, but still: are you sure you need this info?
> +
> + /* Initiate the DSI packet transmision */
> + nwl_dsi_begin_transmission(dsi);
> +
> + if (!wait_for_completion_timeout(&xfer.completed,
> + NWL_DSI_MIPI_FIFO_TIMEOUT))
> {
> + DRM_DEV_ERROR(dsi_host->dev, "[%02X] DSI transfer
> timed out\n",
> + xfer.cmd);
> + ret = -ETIMEDOUT;
> + } else {
> + ret = xfer.status;
> + }
> +
> + clk_disable_unprepare(dsi->rx_esc_clk);
> +
> + return ret;
> +}
> +
> +const struct mipi_dsi_host_ops nwl_dsi_host_ops = {
> + .attach = nwl_dsi_host_attach,
> + .detach = nwl_dsi_host_detach,
> + .transfer = nwl_dsi_host_transfer,
> +};
> +
> +irqreturn_t nwl_dsi_irq_handler(int irq, void *data)
> +{
> + u32 irq_status;
> + struct nwl_dsi *dsi = data;
> +
> + irq_status = nwl_dsi_read(dsi, NWL_DSI_IRQ_STATUS);
> +
> + if (irq_status & NWL_DSI_TX_PKT_DONE ||
> + irq_status & NWL_DSI_RX_PKT_HDR_RCVD ||
> + irq_status & NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD)
> + nwl_dsi_finish_transmission(dsi, irq_status);
> +
> + return IRQ_HANDLED;
> +}
> +
> +int nwl_dsi_enable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> + union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
> + int ret;
> +
> + if (!dsi->lanes) {
> + DRM_DEV_ERROR(dev, "Need DSI lanes: %d\n", dsi-
> >lanes);
> + return -EINVAL;
> + }
> +
> + ret = phy_init(dsi->phy);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to init DSI phy: %d\n",
> ret);
> + return ret;
> + }
> +
> + ret = phy_configure(dsi->phy, phy_cfg);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to configure DSI phy:
> %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dsi->tx_esc_clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable tx_esc clk:
> %d\n",
> + ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Enabled tx_esc clk @%lu
> Hz\n",
> + clk_get_rate(dsi->tx_esc_clk));
> +
> + ret = nwl_dsi_config_host(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set up DSI: %d", ret);
> + return ret;
> + }
> +
> + ret = nwl_dsi_config_dpi(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set up DPI: %d", ret);
> + return ret;
> + }
> +
> + ret = phy_power_on(dsi->phy);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to power on DPHY (%d)\n",
> ret);
> + return ret;
> + }
> +
> + nwl_dsi_init_interrupts(dsi);
> +
> + return 0;
> +}
I see that you do all the initialization from the pre_enable stage. If
you power on the DPHY, the DSI host block will start transmitting pixel
data on the data lanes. We had some customers that complained about
this, so I think is better to hold on the pixel flow until the whole
pixel pipe is completely initialized.
What I recommend here, is to also use the enable stage in the bridge
and move nwl_dsi_config_host in there. Thus, the call flow will be:
1. bridge->pre_enable (DSI is configured, but not streaming since the
host is not yet configured)
2. panel->prepare (panel will use the DSI APB block to send DSI
commands)
3. bridge->enable (DSI host block is configured, DSI starts streamming
pixels)
3. panel->enable (panel is ready to display the pixel flow)
> +
> +int nwl_dsi_disable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "Disabling clocks and phy\n");
> +
> + phy_power_off(dsi->phy);
> + phy_exit(dsi->phy);
> +
> + /* Disabling the clock before the phy breaks enabling dsi
> again */
> + clk_disable_unprepare(dsi->tx_esc_clk);
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> new file mode 100644
> index 000000000000..579b366de652
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> @@ -0,0 +1,112 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +#ifndef __NWL_DSI_H__
> +#define __NWL_DSI_H__
> +
> +#include <linux/irqreturn.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +
> +#include "nwl-drv.h"
> +
> +/* DSI HOST registers */
> +#define NWL_DSI_CFG_NUM_LANES 0x0
> +#define NWL_DSI_CFG_NONCONTINUOUS_CLK 0x4
> +#define NWL_DSI_CFG_T_PRE 0x8
> +#define NWL_DSI_CFG_T_POST 0xc
> +#define NWL_DSI_CFG_TX_GAP 0x10
> +#define NWL_DSI_CFG_AUTOINSERT_EOTP 0x14
> +#define NWL_DSI_CFG_EXTRA_CMDS_AFTER_EOTP 0x18
> +#define NWL_DSI_CFG_HTX_TO_COUNT 0x1c
> +#define NWL_DSI_CFG_LRX_H_TO_COUNT 0x20
> +#define NWL_DSI_CFG_BTA_H_TO_COUNT 0x24
> +#define NWL_DSI_CFG_TWAKEUP 0x28
> +#define NWL_DSI_CFG_STATUS_OUT 0x2c
> +#define NWL_DSI_RX_ERROR_STATUS 0x30
> +
> +/* DSI DPI registers */
> +#define NWL_DSI_PIXEL_PAYLOAD_SIZE 0x200
> +#define NWL_DSI_PIXEL_FIFO_SEND_LEVEL 0x204
> +#define NWL_DSI_INTERFACE_COLOR_CODING 0x208
> +#define NWL_DSI_PIXEL_FORMAT 0x20c
> +#define NWL_DSI_VSYNC_POLARITY 0x210
> +#define NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW 0
> +#define NWL_DSI_VSYNC_POLARITY_ACTIVE_HIGH BIT(1)
> +
> +#define NWL_DSI_HSYNC_POLARITY 0x214
> +#define NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW 0
> +#define NWL_DSI_HSYNC_POLARITY_ACTIVE_HIGH BIT(1)
> +
> +#define NWL_DSI_VIDEO_MODE 0x218
> +#define NWL_DSI_HFP 0x21c
> +#define NWL_DSI_HBP 0x220
> +#define NWL_DSI_HSA 0x224
> +#define NWL_DSI_ENABLE_MULT_PKTS 0x228
> +#define NWL_DSI_VBP 0x22c
> +#define NWL_DSI_VFP 0x230
> +#define NWL_DSI_BLLP_MODE 0x234
> +#define NWL_DSI_USE_NULL_PKT_BLLP 0x238
> +#define NWL_DSI_VACTIVE 0x23c
> +#define NWL_DSI_VC 0x240
> +
> +/* DSI APB PKT control */
> +#define NWL_DSI_TX_PAYLOAD 0x280
> +#define NWL_DSI_PKT_CONTROL 0x284
> +#define NWL_DSI_SEND_PACKET 0x288
> +#define NWL_DSI_PKT_STATUS 0x28c
> +#define NWL_DSI_PKT_FIFO_WR_LEVEL 0x290
> +#define NWL_DSI_PKT_FIFO_RD_LEVEL 0x294
> +#define NWL_DSI_RX_PAYLOAD 0x298
> +#define NWL_DSI_RX_PKT_HEADER 0x29c
> +
> +/* DSI IRQ handling */
> +#define NWL_DSI_IRQ_STATUS 0x2a0
> +#define NWL_DSI_SM_NOT_IDLE BIT(0)
> +#define NWL_DSI_TX_PKT_DONE BIT(1)
> +#define NWL_DSI_DPHY_DIRECTION BIT(2)
> +#define NWL_DSI_TX_FIFO_OVFLW BIT(3)
> +#define NWL_DSI_TX_FIFO_UDFLW BIT(4)
> +#define NWL_DSI_RX_FIFO_OVFLW BIT(5)
> +#define NWL_DSI_RX_FIFO_UDFLW BIT(6)
> +#define NWL_DSI_RX_PKT_HDR_RCVD BIT(7)
> +#define NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD BIT(8)
> +#define NWL_DSI_BTA_TIMEOUT BIT(29)
> +#define NWL_DSI_LP_RX_TIMEOUT BIT(30)
> +#define NWL_DSI_HS_TX_TIMEOUT BIT(31)
> +
> +#define NWL_DSI_IRQ_STATUS2 0x2a4
> +#define NWL_DSI_SINGLE_BIT_ECC_ERR BIT(0)
> +#define NWL_DSI_MULTI_BIT_ECC_ERR BIT(1)
> +#define NWL_DSI_CRC_ERR BIT(2)
> +
> +#define NWL_DSI_IRQ_MASK 0x2a8
> +#define NWL_DSI_SM_NOT_IDLE_MASK BIT(0)
> +#define NWL_DSI_TX_PKT_DONE_MASK BIT(1)
> +#define NWL_DSI_DPHY_DIRECTION_MASK BIT(2)
> +#define NWL_DSI_TX_FIFO_OVFLW_MASK BIT(3)
> +#define NWL_DSI_TX_FIFO_UDFLW_MASK BIT(4)
> +#define NWL_DSI_RX_FIFO_OVFLW_MASK BIT(5)
> +#define NWL_DSI_RX_FIFO_UDFLW_MASK BIT(6)
> +#define NWL_DSI_RX_PKT_HDR_RCVD_MASK BIT(7)
> +#define NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD_MASK BIT(8)
> +#define NWL_DSI_BTA_TIMEOUT_MASK BIT(29)
> +#define NWL_DSI_LP_RX_TIMEOUT_MASK BIT(30)
> +#define NWL_DSI_HS_TX_TIMEOUT_MASK BIT(31)
> +
> +#define NWL_DSI_IRQ_MASK2 0x2ac
> +#define NWL_DSI_SINGLE_BIT_ECC_ERR_MASK BIT(0)
> +#define NWL_DSI_MULTI_BIT_ECC_ERR_MASK BIT(1)
> +#define NWL_DSI_CRC_ERR_MASK BIT(2)
> +
> +extern const struct mipi_dsi_host_ops nwl_dsi_host_ops;
> +
> +irqreturn_t nwl_dsi_irq_handler(int irq, void *data);
> +int nwl_dsi_enable(struct nwl_dsi *dsi);
> +int nwl_dsi_disable(struct nwl_dsi *dsi);
> +
> +#endif /* __NWL_DSI_H__ */
> --
> 2.20.1
>
>
Best regards,
Robert
_______________________________________________
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 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles
From: Rob Herring @ 2019-08-22 12:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190821175458.GA25168@kozik-lap>
On Wed, Aug 21, 2019 at 12:55 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Aug 20, 2019 at 03:27:39PM -0500, Rob Herring wrote:
> > > I see. If I understand the schema correctly, this should look like:
> >
> > Looks correct, but a couple of comments.
> >
> > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > index 7294ac36f4c0..eb263d1ccf13 100644
> > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > @@ -161,6 +161,22 @@ properties:
> > > items:
> > > - enum:
> > > - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> > > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> >
> > Is the SOM ever used alone? If not, then no point in listing this here.
>
> SoM alone: no, because it requires some type of base board. However it
> will be used by some customer designs with some amount of
> changes/addons.
>
> Looking at other aproaches, usually SoMs have their own compatible. In
> such case - I should document it somewhere.
I wasn't suggesting not having the compatible for it, but you don't
need it in this list because that is not valid. You have to list it
with the base board compatibles.
Rob
_______________________________________________
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,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Jungo Lin @ 2019-08-22 12:48 UTC (permalink / raw)
To: Rob Herring
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190821201758.GB15270@bogus>
Hi, Rob:
On Wed, 2019-08-21 at 15:17 -0500, Rob Herring wrote:
> On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> > This patch adds DT binding document for the Pass 1 (P1) unit
> > in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> > data out from the sensor interface, applies ISP image effects
> > from tuning data and outputs the image data or statistics data to DRAM.
> >
> > Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> > ---
> > .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> > 1 file changed, 73 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > new file mode 100644
> > index 000000000000..fa2713acceca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > @@ -0,0 +1,73 @@
> > +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> > +
> > +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> > +from the sensor interface, applies ISP effects from tuning data and outputs
> > +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> > +the ability to output two different resolutions frames at the same time to
> > +increase the performance of the camera application.
> > +
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> > +- reg: Physical base address of the camera function block register and
> > + length of memory mapped region. Must contain an entry for each entry
> > + in reg-names.
> > +- reg-names: Must include the following entries:
> > + "cam_sys": Camera base function block
> > + "cam_uni": Camera UNI function block
> > + "cam_a": Camera ISP P1 hardware unit A
> > + "cam_b": Camera ISP P1 hardware unit B
> > + "cam_c": Camera ISP P1 hardware unit C
> > +- interrupts: Must contain an entry for each entry in interrupt-names.
> > +- interrupt-names : Must include the following entries:
> > + "cam_uni": Camera UNI interrupt
> > + "cam_a": Camera unit A interrupt
> > + "cam_b": Camera unit B interrupt
> > + "cam_c": Camera unit C interrupt
> > +- iommus: Shall point to the respective IOMMU block with master port
> > + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +- clocks: A list of phandle and clock specifier pairs as listed
> > + in clock-names property, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> > +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> > + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,scp : The node of system control processor (SCP), see
> > + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> > +
> > +Example:
> > +SoC specific DT entry:
> > +
> > + camisp: camisp@1a000000 {
>
> Also, you can remove 2 levels of indentation here.
>
Ok, got it.
We will change to use one level of indentation.
Thanks,
Jungo
> > + compatible = "mediatek,mt8183-camisp", "syscon";
> > + reg = <0 0x1a000000 0 0x1000>,
> > + <0 0x1a003000 0 0x1000>,
> > + <0 0x1a004000 0 0x2000>,
> > + <0 0x1a006000 0 0x2000>,
> > + <0 0x1a008000 0 0x2000>;
> > + reg-names = "cam_sys",
> > + "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> > + clocks = <&camsys CLK_CAM_CAM>,
> > + <&camsys CLK_CAM_CAMTG>;
> > + clock-names = "camsys_cam_cgpdn",
> > + "camsys_camtg_cgpdn";
> > + mediatek,larb = <&larb3>,
> > + <&larb6>;
> > + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> > + mediatek,scp = <&scp>;
> > + };
> > --
> > 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: [RFC,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Jungo Lin @ 2019-08-22 12:47 UTC (permalink / raw)
To: Rob Herring
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190821194752.GA15270@bogus>
Hi, Rob:
On Wed, 2019-08-21 at 14:47 -0500, Rob Herring wrote:
> On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> > This patch adds DT binding document for the Pass 1 (P1) unit
> > in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> > data out from the sensor interface, applies ISP image effects
> > from tuning data and outputs the image data or statistics data to DRAM.
> >
> > Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> > ---
> > .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> > 1 file changed, 73 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > new file mode 100644
> > index 000000000000..fa2713acceca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > @@ -0,0 +1,73 @@
> > +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> > +
> > +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> > +from the sensor interface, applies ISP effects from tuning data and outputs
> > +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> > +the ability to output two different resolutions frames at the same time to
> > +increase the performance of the camera application.
> > +
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> > +- reg: Physical base address of the camera function block register and
> > + length of memory mapped region. Must contain an entry for each entry
> > + in reg-names.
> > +- reg-names: Must include the following entries:
> > + "cam_sys": Camera base function block
> > + "cam_uni": Camera UNI function block
> > + "cam_a": Camera ISP P1 hardware unit A
> > + "cam_b": Camera ISP P1 hardware unit B
> > + "cam_c": Camera ISP P1 hardware unit C
> > +- interrupts: Must contain an entry for each entry in interrupt-names.
> > +- interrupt-names : Must include the following entries:
> > + "cam_uni": Camera UNI interrupt
> > + "cam_a": Camera unit A interrupt
> > + "cam_b": Camera unit B interrupt
> > + "cam_c": Camera unit C interrupt
> > +- iommus: Shall point to the respective IOMMU block with master port
> > + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +- clocks: A list of phandle and clock specifier pairs as listed
> > + in clock-names property, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> > +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> > + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,scp : The node of system control processor (SCP), see
> > + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> > +
> > +Example:
> > +SoC specific DT entry:
> > +
> > + camisp: camisp@1a000000 {
> > + compatible = "mediatek,mt8183-camisp", "syscon";
>
> syscon doesn't seem appropriate nor is it documented.
>
Thanks for your comment.
I will remove "syscon" in next patch.
Best regards,
Jungo
> > + reg = <0 0x1a000000 0 0x1000>,
> > + <0 0x1a003000 0 0x1000>,
> > + <0 0x1a004000 0 0x2000>,
> > + <0 0x1a006000 0 0x2000>,
> > + <0 0x1a008000 0 0x2000>;
> > + reg-names = "cam_sys",
> > + "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> > + clocks = <&camsys CLK_CAM_CAM>,
> > + <&camsys CLK_CAM_CAMTG>;
> > + clock-names = "camsys_cam_cgpdn",
> > + "camsys_camtg_cgpdn";
> > + mediatek,larb = <&larb3>,
> > + <&larb6>;
> > + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> > + mediatek,scp = <&scp>;
> > + };
> > --
> > 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 v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Alexandre Belloni @ 2019-08-22 12:46 UTC (permalink / raw)
To: Ran Bi
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <1566477254.12318.41.camel@mhfsdcap03>
On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> >
> > This should be written when setting the time after power was lost.
> >
>
> I suppose we can move this into mt2712_rtc_read_time function's "if
> (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> which will be added at next patch. We need additional flag to mark this
> condition or another if condition in mt2712_rtc_set_time fucntion if we
> put these code in mt2712_rtc_set_time function.
>
It is fine to test both in read_time and in set_time.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/19] dt-bindings: arm: mrvl: Document MMP3 compatible string
From: Rob Herring @ 2019-08-22 12:42 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <c859d12167d18c21dda13b30c2dd3256f407d1d9.camel@v3.sk>
On Thu, Aug 22, 2019 at 3:12 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> On Wed, 2019-08-21 at 16:03 -0500, Rob Herring wrote:
> > On Fri, Aug 09, 2019 at 11:31:41AM +0200, Lubomir Rintel wrote:
> > > Marvel MMP3 is a successor to MMP2, containing similar peripherals with two
> > > PJ4B cores.
> > >
> > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> > > ---
> > > Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > index 951687528efb0..66e1e1414245b 100644
> > > --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > @@ -12,3 +12,7 @@ Required root node properties:
> > > MMP2 Brownstone Board
> > > Required root node properties:
> > > - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> > > +
> > > +MMP3 SoC
> > > +Required root node properties:
> > > + - compatible = "marvell,mmp3";
> >
> > Please convert this file to DT schema before adding new SoCs.
>
> Is this something that should generally be done for all new or changed
> DT bindings?
Preferred, but not quite yet required everywhere. It depends on the
maintainer/subsystem still. But for board level bindings, you'll
notice most of them are converted. Marvell, Broadcom, and TI are the
main ones left.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: mt8183: add I2C nodes
From: qii.wang @ 2019-08-22 12:35 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, qii.wang, matthias.bgg, linux-arm-kernel
From: Qii Wang <qii.wang@mediatek.com>
Add i2c nodes to mt8183 and mt8183-evb.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 96 ++++++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 189 ++++++++++++++++++++++++++++
2 files changed, 285 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index d8e555c..1fb195c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -30,7 +30,103 @@
status = "okay";
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_0>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_1>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_2>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_3>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_4>;
+ status = "okay";
+ clock-frequency = <1000000>;
+};
+
+&i2c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_5>;
+ status = "okay";
+ clock-frequency = <1000000>;
+};
+
&pio {
+ i2c_pins_0: i2c0{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO82__FUNC_SDA0>,
+ <PINMUX_GPIO83__FUNC_SCL0>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_1: i2c1{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO81__FUNC_SDA1>,
+ <PINMUX_GPIO84__FUNC_SCL1>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_2: i2c2{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO103__FUNC_SCL2>,
+ <PINMUX_GPIO104__FUNC_SDA2>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_3: i2c3{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
+ <PINMUX_GPIO51__FUNC_SDA3>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_4: i2c4{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO105__FUNC_SCL4>,
+ <PINMUX_GPIO106__FUNC_SDA4>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_5: i2c5{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
+ <PINMUX_GPIO49__FUNC_SDA5>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
spi_pins_0: spi0{
pins_spi{
pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>,
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c2749c4..ab71291 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -16,6 +16,21 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -294,6 +309,64 @@
status = "disabled";
};
+ i2c6: i2c@11005000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11005000 0 0x1000>,
+ <0 0x11000600 0 0x80>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C6>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@11007000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11007000 0 0x1000>,
+ <0 0x11000080 0 0x80>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C0>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@11008000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11008000 0 0x1000>,
+ <0 0x11000100 0 0x80>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C1>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C1_ARBITER>;
+ clock-names = "main", "dma","arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@11009000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11009000 0 0x1000>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C2>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C2_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi0: spi@1100a000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -307,6 +380,20 @@
status = "disabled";
};
+ i2c3: i2c@1100f000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1100f000 0 0x1000>,
+ <0 0x11000400 0 0x80>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C3>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi1: spi@11010000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -320,6 +407,20 @@
status = "disabled";
};
+ i2c1: i2c@11011000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11011000 0 0x1000>,
+ <0 0x11000480 0 0x80>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C4>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi2: spi@11012000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -346,6 +447,66 @@
status = "disabled";
};
+ i2c9: i2c@11014000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11014000 0 0x1000>,
+ <0 0x11000180 0 0x80>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C1_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C1_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c10: i2c@11015000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11015000 0 0x1000>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C2_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C2_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@11016000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11016000 0 0x1000>,
+ <0 0x11000500 0 0x80>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C5>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C5_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c@11017000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11017000 0 0x1000>,
+ <0 0x11000580 0 0x80>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C5_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C5_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi4: spi@11018000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -372,6 +533,34 @@
status = "disabled";
};
+ i2c7: i2c@1101a000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1101a000 0 0x1000>,
+ <0 0x11000680 0 0x80>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C7>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c8: i2c@1101b000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1101b000 0 0x1000>,
+ <0 0x11000700 0 0x80>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C8>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
audiosys: syscon@11220000 {
compatible = "mediatek,mt8183-audiosys", "syscon";
reg = <0 0x11220000 0 0x1000>;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-22 12:34 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190820201744.GZ3545@piout.net>
Hi,
> > +
> > +#define MTK_RTC_DEV KBUILD_MODNAME
>
> You probably shouldn't do that and have a static string for the driver
> name. I probably doesn't matter much though because DT is used to probe
> the driver.
>
Will change it at next patch.
> > +/* we map HW YEAR 0 to 2000 because 2000 is the leap year */
> > +#define MT2712_MIN_YEAR 2000
> > +#define MT2712_BASE_YEAR 1900
> > +#define MT2712_MIN_YEAR_OFFSET (MT2712_MIN_YEAR - MT2712_BASE_YEAR)
> > +#define MT2712_MAX_YEAR_OFFSET (MT2712_MIN_YEAR_OFFSET + 127)
> > +
>
> All those defines are unecessary, see below.
>
Will change it at next patch.
> > +struct mt2712_rtc {
> > + struct device *dev;
>
> Looking at the code closely, it seems this is only used for debug and
> error messages. Maybe you could use rtc_dev->dev instead.
>
Will change it at next patch.
> > + mutex_lock(&rtc->rtc_dev->ops_lock);
> > +
> > + irqsta = mt2712_readl(rtc, MT2712_IRQ_STA);
>
> Do you have to lock that read? Is the register cleared on read?
>
Yes, this register is read clear register.
> > + do {
> > + __mt2712_rtc_read_time(rtc, tm, &sec);
> > + } while (sec < tm->tm_sec); /* SEC has carried */
>
> Shouldn't that be while (tm->tm_sec < sec)?
>
In __mt2712_rtc_read_time function, we read tm->tm_sec before read sec.
Sometimes we can meet situation like "tm->tm_sec == 59" and "sec == 0".
It means that TC_SEC has carried and we need to reload the tm struct. I
suppose it was correct that using "while (sec < tm->tm_sec)"
> > +
> > + /* HW register use 7 bits to store year data, minus
> > + * MT2712_MIN_YEAR_OFFSET brfore write year data to register, and plus
> > + * MT2712_MIN_YEAR_OFFSET back after read year from register
> > + */
> > + tm->tm_year += MT2712_MIN_YEAR_OFFSET;
>
> Simply add 100 in __mt2712_rtc_read_time
>
Will change it at next patch.
> > +
> > + /* HW register start mon from one, but tm_mon start from zero. */
> > + tm->tm_mon--;
> > +
>
> You can also do that in __mt2712_rtc_read_time.
>
Will change it at next patch.
> > + if (rtc_valid_tm(tm)) {
>
> This check is unnecessary, the validity is always checked by the core.
>
Will remove this at next patch.
> > + if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
> > + dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
> > + 1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
> > + 1900 + MT2712_MAX_YEAR_OFFSET);
> > + return -EINVAL;
> > + }
>
> This check is unnecessary, see below.
>
Will change it at next patch.
> > +
> > + tm->tm_year -= MT2712_MIN_YEAR_OFFSET;
> > + tm->tm_mon++;
>
> You should probably avoid modifying tm, move the substraction and
> addition in the mt2712_writel calls.
>
Will change it at next patch.
> > + if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
> > + dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
> > + 1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
> > + 1900 + MT2712_MAX_YEAR_OFFSET);
> > + return -EINVAL;
> > + }
> > +
>
> Unnecessary check.
>
Will change it at next patch.
> > + p1 = mt2712_readl(rtc, MT2712_POWERKEY1);
> > + p2 = mt2712_readl(rtc, MT2712_POWERKEY2);
> > + if (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)
> > + dev_dbg(rtc->dev, "powerkey not set (lost power)\n");
> > +
>
> This info is valuable, you should check that when reading the time and
> return -EINVAL if power was lost.
>
Will change it at next patch.
>
> > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
>
> This should be written when setting the time after power was lost.
>
I suppose we can move this into mt2712_rtc_read_time function's "if
(p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
which will be added at next patch. We need additional flag to mark this
condition or another if condition in mt2712_rtc_set_time fucntion if we
put these code in mt2712_rtc_set_time function.
> > +static const struct rtc_class_ops mt2712_rtc_ops = {
> > + .read_time = mt2712_rtc_read_time,
> > + .set_time = mt2712_rtc_set_time,
> > + .read_alarm = mt2712_rtc_read_alarm,
> > + .set_alarm = mt2712_rtc_set_alarm,
>
> For proper operations, you should also provide the .alarm_irq_enable
> callback.
>
Will change it at next patch.
> > + rtc->rtc_dev->ops = &mt2712_rtc_ops;
>
> If you set the range properly here using rtc_dev->range_min and
> rtc_dev->range_max, then the core will be able to do range checking and
> will also take care of the year offset/windowing calculations instead of
> having to hardcode that in the driver.
>
Will change it at next patch.
Best Regards,
Ran
_______________________________________________
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] clk: imx: pll14xx: avoid glitch when set rate
From: Leonard Crestez @ 2019-08-22 12:34 UTC (permalink / raw)
To: Peng Fan, sboyd@kernel.org
Cc: Jacky Bai, Anson Huang, shawnguo@kernel.org,
mturquette@baylibre.com, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, Abel Vesa
In-Reply-To: <AM0PR04MB44818E133AD735E3EB2789E288A50@AM0PR04MB4481.eurprd04.prod.outlook.com>
On 22.08.2019 12:18, Peng Fan wrote:
>> Subject: Re: [PATCH] clk: imx: pll14xx: avoid glitch when set rate
>>
>> On 20.08.2019 05:17, Peng Fan wrote:
>>> According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB
>>> is changed from 0 to 1, FOUT starts to output unstable clock until
>>> lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT."
>>>
>>> So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
>>> In the end of set rate, BYPASS will be cleared.
>>>
>>> @@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
>> unsigned long drate,
>>> tmp &= ~RST_MASK;
>>> writel_relaxed(tmp, pll->base);
>>>
>>> + /* Enable BYPASS */
>>> + tmp |= BYPASS_MASK;
>>> + writel(tmp, pll->base);
>>> +
>>
>> Shouldn't BYPASS be set before reset?
>
> No. the glitch happens when RESET changes from 0 to 1, not from 1 to 0.
You're right, sorry.
>> Also, isn't a similar bypass/unbypass dance also needed in
>> clk_pll14xx_prepare? As far as I understand that could also output glitches
>> until the PLL is locked. It could be a separate patch.
>
> Yes, that might also output glitch. Fix in v2.
>
>>
>> It's strange that this BYPASS bit is also handled by muxes like
>> audio_pll1_bypass in clk-imx8mm.c but that's a separate issue not strictly
>> related to the glitches you're trying to fix here.
>
> Yes, need use EXT_BYPASS for the mux usage.
Might make sense to post as a series.
_______________________________________________
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 2/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Leonard Crestez @ 2019-08-22 12:24 UTC (permalink / raw)
To: Chanwoo Choi, Viresh Kumar
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Krzysztof Kozlowski, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, cpgs (cpgs@samsung.com),
Georgi Djakov, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4bdc0742-42ab-1ab6-4868-409eb9738cd8@samsung.com>
On 22.08.2019 14:06, Chanwoo Choi wrote:
> On 19. 8. 22. 오후 7:58, Leonard Crestez wrote:
>> On 8/22/2019 1:03 PM, Chanwoo Choi wrote:
>>> This patch doesn't check the range of input value
>>> with the supported frequencies of devfreq device.
>>>
>>> For example,
>>> The devfreq0 device has the following available frequencies
>>> 100000000 200000000 300000000
>>>
>>> and then user enters the 500000000 as following:
>>> echo 500000000 > /sys/class/devfreq/devfreq0/min_freq
>>>
>>> In result, get_effective_min_freq() will return the 500000000.
>>> It is wrong value. it show the unsupported frequency through
>>> min_freq sysfs path.
>>
>> Through dev_pm_qos devices can also ask for a freq higher than the
>> maximum OPP and unlike sysfs there is no way to reject such requests,
>> instead PM qos claims it's based on "best effort".
>>
>> There are many requests in the kernel for "PM_QOS_CPU_DMA_LATENCY 0" and
>> I think that DEV_PM_QOS_MIN_FREQUENCY, MAX_S32 is a reasonable way for a
>> device to request "max performance" from devfreq.
>>
>> Rejecting min > max is complicated (what happens to rejected requests
>> when max goes back up?) and I think it's better to just stick with a
>> "max overrides min" policy since it can already deal with conflicts.
>>
>> Do you have a usecase for rejecting out-of-range min_freq from
>> userspace? cpufreq also accepts arbitrary min/max values and handles them.
>
> I don't mean the rejecting when user enter the out-of-range frequency.
> As I commented, user can enter the value they want. But, we should
> check the range of input because devfreq have to show the correct supported
> frequency through sysfs.
We can avoid showing an out-of-range value in min_freq by printing
min(min_freq, max_freq).
The max_freq value from pm_qos can still be between OPPs so maybe print
devfreq_recommended_opp(max_freq, DEVFREQ_FLAG_LEAST_UPPER_BOUND).
>> In theory pm_qos could be extended to differentiate between "soft"
>> requests (current behavior) and "hard" requests which return errors if
>> they can't be guaranteed but this is far out of scope.
>
> I think that you agreed the limitation of dev_pm_qos when entering
> or requesting the unsupported frequency.
Yes, "best effort qos" is acceptable for now.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Ulf Hansson @ 2019-08-22 12:14 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, linux-aspeed, Ryan Chen, linux-mmc,
Adrian Hunter, Linux Kernel Mailing List, Rob Herring,
Joel Stanley, Linux ARM
In-Reply-To: <c78d4c45-477b-4078-b269-aec72571c8cd@www.fastmail.com>
On Thu, 22 Aug 2019 at 13:55, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Thu, 22 Aug 2019, at 21:15, Ulf Hansson wrote:
> > On Thu, 15 Aug 2019 at 07:37, Andrew Jeffery <andrew@aj.id.au> wrote:
> > >
> > >
> > >
> > > On Thu, 15 Aug 2019, at 15:06, Joel Stanley wrote:
> > > > On Wed, 7 Aug 2019 at 00:38, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > > >
> > > > > The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
> > > > > SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> > > > > data bus if only a single slot is enabled.
> > > > >
> > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > >
> > > > Reviewed-by: Joel Stanley <joel@jms.id.au>
> > > >
> > > > Two minor comments below.
> > > >
> > > > > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > > > @@ -0,0 +1,105 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > > >
> > > > No "Copyright IBM" ?
> > >
> > > I'm going rogue.
> > >
> > > That reminds me I should chase up where we got to with the binding
> > > licensing.
> > >
> > > >
> > > > > +%YAML 1.2
> > > > > +---
> > > >
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/aspeed-clock.h>
> > > > > + sdc@1e740000 {
> > > > > + compatible = "aspeed,ast2500-sd-controller";
> > > > > + reg = <0x1e740000 0x100>;
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges = <0 0x1e740000 0x10000>;
> > > >
> > > > According to the datasheet this could be 0x20000. It does not matter
> > > > though, as there's nothing in it past 0x300.
> > >
> > > Good catch.
> > >
> >
> > Are you planning on sending a v6 or you want me to apply this and you
> > can post a patch on top?
>
> Yeah, sorry, I wasn't very clear there. I was hoping just to do a follow-up
> patch with the cleanups if you're okay with that?
That's fine. V5 applied for next, thanks!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: fix controller busy issue and add 24bits segment support
From: Ulf Hansson @ 2019-08-22 12:13 UTC (permalink / raw)
To: Chaotian Jing
Cc: srv_heupstream, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, linux-mediatek, Matthias Brugger,
Linux ARM
In-Reply-To: <20190822064741.11196-1-chaotian.jing@mediatek.com>
On Thu, 22 Aug 2019 at 08:47, Chaotian Jing <chaotian.jing@mediatek.com> wrote:
>
> the below 2 patches fix controller busy issue when plug out SD card
> and add 24bits segment size support.
>
> Chaotian Jing (2):
> mmc: mediatek: fix controller busy when plug out SD
> mmc: mediatek: support 24bits segment size
>
> drivers/mmc/host/mtk-sd.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
Applied for next, thanks!
Kind regards
Uffe
_______________________________________________
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 4/4] mmc: sdhci-of-esdhc: add erratum A011334 support in ls1028a 1.0 SoC
From: Ulf Hansson @ 2019-08-22 12:13 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Adrian Hunter,
Catalin Horghidan, linux-mmc@vger.kernel.org, DTML, Rajesh Bhagat,
Alison Wang, Ashish Kumar, Claudiu Manoil, Rob Herring,
Vabhav Sharma, Linux ARM, Amit Jain, Alex Marginean,
Linux Kernel Mailing List, Li Yang, Rajat Srivastava, Yangbo Lu,
Jiafei Pan, linuxppc-dev, Xiaobo Xie
In-Reply-To: <20190814072649.8237-4-yinbo.zhu@nxp.com>
On Wed, 14 Aug 2019 at 09:24, Yinbo Zhu <yinbo.zhu@nxp.com> wrote:
>
> This patch is to add erratum A011334 support in ls1028a 1.0 SoC
>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index b16f7d440f78..eb2b290447fc 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1006,6 +1006,7 @@ static struct soc_device_attribute soc_incorrect_hostver[] = {
> static struct soc_device_attribute soc_fixup_sdhc_clkdivs[] = {
> { .family = "QorIQ LX2160A", .revision = "1.0", },
> { .family = "QorIQ LX2160A", .revision = "2.0", },
> + { .family = "QorIQ LS1028A", .revision = "1.0", },
> { },
> };
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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