[PATCH] drm/mediatek: dsi: Use IRQF_TRIGGER_NONE for dsi irq trigger type
The interrupt trigger is already set by OF. When do devm_request_irq()
in driver, please use IRQF_TRIGGER_NONE and don't specify trigger type
again.
Change-Id: Ie59d7bd9a44a130420890b169cc2e6fee3ad7633
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4a188a942c38..1d6248930bdf 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1128,9 +1128,8 @@ static int mtk_dsi_probe(struct platform_device *pdev)
goto err_unregister_host;
}
- irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
ret = devm_request_irq(&pdev->dev, irq_num, mtk_dsi_irq,
- IRQF_TRIGGER_LOW, dev_name(&pdev->dev), dsi);
+ IRQF_TRIGGER_NONE, dev_name(&pdev->dev), dsi);
if (ret) {
dev_err(&pdev->dev, "failed to request mediatek dsi irq\n");
goto err_unregister_host;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/v3d: Minor improvements
On 12/23/2020 12:27 PM, Stefan Wahren wrote: > This small series of v3d patches is a preparation for the upcoming bcm2711 > support. The bcm2711 support will be send separate, because it involves > bigger changes. > > I'm not sure that the schema conversion patch is sufficient. > > Patch 2,3 are directly taken from Raspberry Pi 4 vendor tree. > > Nicolas Saenz Julienne (1): > drm/v3d: Use platform_get_irq_optional() to get optional IRQs > > Phil Elwell (2): > drm/v3d: Set dma_mask as well as coherent_dma_mask > drm/v3d: Don't clear MMU control bits on exception You need to amend your Signed-off-by to all of those 3 patches that you did not author. -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
23.12.2020 08:57, Viresh Kumar пишет:
> On 22-12-20, 22:39, Dmitry Osipenko wrote:
>> 22.12.2020 22:21, Dmitry Osipenko пишет:
> + if (IS_ERR(opp)) {
> + dev_err(&genpd->dev, "failed to find OPP for level %u: %pe\n",
> + level, opp);
> + return PTR_ERR(opp);
> + }
> +
> + err = dev_pm_opp_set_voltage(&genpd->dev, opp);
IIUC, you implemented this callback because you want to use the voltage
triplet
present in the OPP table ?
And so you are setting the regulator ("power") later in this patch ?
>>> yes
>>>
I am not in favor of implementing this routine, as it just adds a wrapper
above
the regulator API. What you should be doing rather is get the regulator by
yourself here (instead of depending on the OPP core). And then you can do
dev_pm_opp_get_voltage() here and set the voltage yourself. You may want to
implement a version supporting triplet here though for the same.
And you won't require the sync version of the API as well then.
>>> That's what I initially did for this driver. I don't mind to revert back
>>> to the initial variant in v3, it appeared to me that it will be nicer
>>> and cleaner to have OPP API managing everything here.
>>
>> I forgot one important detail (why the initial variant wasn't good)..
>> OPP entries that have unsupportable voltages should be filtered out and
>> OPP core performs the filtering only if regulator is assigned to the OPP
>> table.
>>
>> If regulator is assigned to the OPP table, then we need to use OPP API
>> for driving the regulator, hence that's why I added
>> dev_pm_opp_sync_regulators() and dev_pm_opp_set_voltage().
>>
>> Perhaps it should be possible to add dev_pm_opp_get_regulator() that
>
> What's wrong with getting the regulator in the driver as well ? Apart from the
> OPP core ?
The voltage syncing should be done for each consumer regulator
individually [1].
Secondly, regulator core doesn't work well today if the same regulator
is requested more than one time for the same device.
>> will return the OPP table regulator in order to allow driver to use the
>> regulator directly. But I'm not sure whether this is a much better
>> option than the opp_sync_regulators() and opp_set_voltage() APIs.
>
> set_voltage() is still fine as there is some data that the OPP core has, but
> sync_regulator() has nothing to do with OPP core.
>
> And this may lead to more wrapper helpers in the OPP core, which I am afraid
> of.
> And so even if it is not the best, I would like the OPP core to provide the
> data
> and not get into this. Ofcourse there is an exception to this, opp_set_rate.
>
The regulator_sync_voltage() should be invoked only if voltage was
changed previously [1].
The OPP core already has the info about whether voltage was changed and
it provides the necessary locking for both set_voltage() and
sync_regulator(). Perhaps I'll need to duplicate that functionality in
the PD driver, instead of making it all generic and re-usable by other
drivers.
[1]
https://elixir.bootlin.com/linux/v5.10.2/source/drivers/regulator/core.c#L4107
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/radeon: use writel to avoid gcc optimization
When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon: [ 11.240414] pc : __memset+0x4c/0x188 [ 11.244101] lr : radeon_uvd_get_create_msg+0x114/0x1d0 [radeon] [ 11.249995] sp : 0d7eb700 [ 11.253295] x29: 0d7eb700 x28: 8001f632a868 [ 11.258585] x27: 0004 x26: 0de0 [ 11.263875] x25: 0125 x24: 0001 [ 11.269168] x23: x22: 0005 [ 11.274459] x21: 0df24000 x20: 8001f74b4000 [ 11.279753] x19: 00124000 x18: 0020 [ 11.285043] x17: x16: [ 11.290336] x15: 09309000 x14: [ 11.290340] x13: 094b6f88 x12: 094b6bd2 [ 11.290343] x11: 0d7eb700 x10: 0d7eb700 [ 11.306246] x9 : 0d7eb700 x8 : 0df2402c [ 11.306254] x7 : x6 : 094b626a [ 11.306257] x5 : x4 : 0004 [ 11.306262] x3 : x2 : 0fd4 [ 11.306265] x1 : x0 : 0df2402c [ 11.306272] Call trace: [ 11.306316] __memset+0x4c/0x188 [ 11.306638] uvd_v1_0_ib_test+0x70/0x1c0 [radeon] [ 11.306758] radeon_ib_ring_tests+0x54/0xe0 [radeon] [ 11.309961] IPv6: ADDRCONF(NETDEV_UP): enp5s0f0: link is not ready [ 11.354628] radeon_device_init+0x53c/0xbdc [radeon] [ 11.354693] radeon_driver_load_kms+0x6c/0x1b0 [radeon] [ 11.364788] drm_dev_register+0x130/0x1c0 [ 11.364794] drm_get_pci_dev+0x8c/0x14c [ 11.372704] radeon_pci_probe+0xb0/0x110 [radeon] [ 11.372715] local_pci_probe+0x3c/0xb0 [ 11.381129] pci_device_probe+0x114/0x1b0 [ 11.385121] really_probe+0x23c/0x400 [ 11.388757] driver_probe_device+0xdc/0x130 [ 11.392921] __driver_attach+0x128/0x150 [ 11.396826] bus_for_each_dev+0x70/0xbc [ 11.400643] driver_attach+0x20/0x2c [ 11.404201] bus_add_driver+0x160/0x260 [ 11.408019] driver_register+0x74/0x120 [ 11.411837] __pci_register_driver+0x40/0x50 [ 11.416149] radeon_init+0x78/0x1000 [radeon] [ 11.420489] do_one_initcall+0x54/0x154 [ 11.424310] do_init_module+0x54/0x260 [ 11.428041] load_module+0x1ccc/0x20b0 [ 11.431773] __se_sys_finit_module+0xac/0x10c [ 11.436109] __arm64_sys_finit_module+0x18/0x20 [ 11.440622] el0_svc_common+0x70/0x164 [ 11.444353] el0_svc_handler+0x2c/0x80 [ 11.448084] el0_svc+0x8/0xc [ 11.450954] Code: d65f03c0 cb0803e4 f2400c84 5480 (a9001d07) Obviously, the __memset call is generated by gcc(8.3.1). It optimizes this for loop into memset. But this may break on some platforms which cannot map device memory correctly. So, just invoke `writel` to handle this. Signed-off-by: chenli --- v1->v2: * Convert the other assignments of msg as well. * Casting types to avoid static checker warnings. --- drivers/gpu/drm/radeon/radeon_uvd.c | 34 ++--- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c index 39c1c339be7b..e576470402b9 100644 --- a/drivers/gpu/drm/radeon/radeon_uvd.c +++ b/drivers/gpu/drm/radeon/radeon_uvd.c @@ -791,19 +791,19 @@ int radeon_uvd_get_create_msg(struct radeon_device *rdev, int ring, return r; /* stitch together an UVD create msg */ - msg[0] = cpu_to_le32(0x0de4); - msg[1] = cpu_to_le32(0x); - msg[2] = cpu_to_le32(handle); - msg[3] = cpu_to_le32(0x); - msg[4] = cpu_to_le32(0x); - msg[5] = cpu_to_le32(0x); - msg[6] = cpu_to_le32(0x); - msg[7] = cpu_to_le32(0x0780); - msg[8] = cpu_to_le32(0x0440); - msg[9] = cpu_to_le32(0x); - msg[10] = cpu_to_le32(0x01b37000); + writel(cpu_to_le32(0x0de4), (void __iomem *)&msg[0]); + writel(0x0, (void __iomem *)&msg[1]); + writel(cpu_to_le32(handle), (void __iomem *)&msg[2]); + writel(0x0, (void __iomem *)&msg[3]); + writel(0x0, (void __iomem *)&msg[4]); + writel(0x0, (void __iomem *)&msg[5]); + writel(0x0, (void __iomem *)&msg[6]); + writel(cpu_to_le32(0x0780), (void __iomem *)&msg[7]); + writel(cpu_to_le32(0x0440), (void __iomem *)&msg[8]); + writel(0x0, (void __iomem *)&msg[9]); + writel(cpu_to_le32(0x01b37000), (void __iomem *)&msg[10]); for (i = 11; i < 1024; ++i) - msg[i] = cpu_to_le32(0x0); + writel(0x0, (void __iomem *)&msg[i]); r = radeon_uvd_send_msg(rdev, ring, addr, fence); radeon_bo_unreserve(rdev->uvd.vcpu_bo); @@ -827,12 +827,12 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, int ring, return r; /* stitch together an UVD destroy msg */ - msg[0] = cpu_to_le32(0x0de4); - msg[1] = cpu_to_le32(0x0002); - msg[2] = cpu_to_le32(handle); - msg[3] = cpu_to_le32(0x); + write
[PATCH] drm/etnaviv: dump: fix sparse warnings
This patch fixes the following sparse warnings, by adding the missing endianess
conversion functions.
| etnaviv/etnaviv_dump.c:78:26: warning: restricted __le32 degrades to integer
| etnaviv/etnaviv_dump.c:88:26: warning: incorrect type in assignment
(different base types)
| etnaviv/etnaviv_dump.c:88:26:expected restricted __le32 [usertype] reg
| etnaviv/etnaviv_dump.c:88:26:got unsigned short const
| etnaviv/etnaviv_dump.c:89:28: warning: incorrect type in assignment
(different base types)
| etnaviv/etnaviv_dump.c:89:28:expected restricted __le32 [usertype] value
| etnaviv/etnaviv_dump.c:89:28:got unsigned int
| etnaviv/etnaviv_dump.c:210:43: warning: incorrect type in assignment
(different base types)
| etnaviv/etnaviv_dump.c:210:43:expected restricted __le32
| etnaviv/etnaviv_dump.c:210:43:got long
Signed-off-by: Marc Kleine-Budde
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 706af0304ca4..f418e0b75772 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -75,7 +75,7 @@ static void etnaviv_core_dump_header(struct
core_dump_iterator *iter,
hdr->file_size = cpu_to_le32(data_end - iter->data);
iter->hdr++;
- iter->data += hdr->file_size;
+ iter->data += le32_to_cpu(hdr->file_size);
}
static void etnaviv_core_dump_registers(struct core_dump_iterator *iter,
@@ -85,8 +85,8 @@ static void etnaviv_core_dump_registers(struct
core_dump_iterator *iter,
unsigned int i;
for (i = 0; i < ARRAY_SIZE(etnaviv_dump_registers); i++, reg++) {
- reg->reg = etnaviv_dump_registers[i];
- reg->value = gpu_read(gpu, etnaviv_dump_registers[i]);
+ reg->reg = cpu_to_le32(etnaviv_dump_registers[i]);
+ reg->value = cpu_to_le32(gpu_read(gpu,
etnaviv_dump_registers[i]));
}
etnaviv_core_dump_header(iter, ETDUMP_BUF_REG, reg);
@@ -207,7 +207,7 @@ void etnaviv_core_dump(struct etnaviv_gem_submit *submit)
if (!IS_ERR(pages)) {
int j;
- iter.hdr->data[0] = bomap - bomap_start;
+ iter.hdr->data[0] = cpu_to_le32((bomap - bomap_start));
for (j = 0; j < obj->base.size >> PAGE_SHIFT; j++)
*bomap++ = cpu_to_le64(page_to_phys(*pages++));
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 2/4] drm/v3d: Set dma_mask as well as coherent_dma_mask
On Wed, 2020-12-23 at 21:35 +0100, Stefan Wahren wrote: > From: Phil Elwell > > Both coherent_dma_mask and dma_mask act as constraints on allocations > and bounce buffer usage, so be sure to set dma_mask to the appropriate > value otherwise the effective mask could be incorrect. > > Signed-off-by: Phil Elwell > Signed-off-by: Stefan Wahren > --- Reviewed-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/48] opp: Filter out OPPs based on availability of a required-OPP
23.12.2020 07:22, Viresh Kumar пишет:
> On 22-12-20, 22:17, Dmitry Osipenko wrote:
>> 22.12.2020 11:59, Viresh Kumar пишет:
>>> On 17-12-20, 21:06, Dmitry Osipenko wrote:
A required OPP may not be available, and thus, all OPPs which are using
this required OPP should be unavailable too.
Signed-off-by: Dmitry Osipenko
---
drivers/opp/core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> Please send a separate patchset for fixes, as these can also go to 5.11
>>> itself.
>>
>> Alright, although I don't think that this patch fixes any problems for
>> existing OPP users.
>
> Because nobody is using this feature, but otherwise this is a fix for me.
>
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index d9feb7639598..3d02fe33630b 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1588,7 +1588,7 @@ int _opp_add(struct device *dev, struct dev_pm_opp
*new_opp,
struct opp_table *opp_table, bool rate_not_available)
{
struct list_head *head;
- int ret;
+ int i, ret;
mutex_lock(&opp_table->lock);
head = &opp_table->opp_list;
@@ -1615,6 +1615,15 @@ int _opp_add(struct device *dev, struct dev_pm_opp
*new_opp,
__func__, new_opp->rate);
}
+ for (i = 0; i < opp_table->required_opp_count && new_opp->available;
i++) {
+ if (new_opp->required_opps[i]->available)
+ continue;
+
+ new_opp->available = false;
+ dev_warn(dev, "%s: OPP not supported by required OPP %pOF
(%lu)\n",
+ __func__, new_opp->required_opps[i]->np,
new_opp->rate);
>>>
>>> Why not just break from here ?
>>
>> The new_opp could be already marked as unavailable by a previous voltage
>> check, hence this loop should be skipped entirely in that case.
>
> Then add a separate check for that before the loop as we don't need that check
> on every iteration here.
>
Perhaps the break will be a better option in this case, since it won't
hurt at all to print the additional message even if OPP was already
disabled by another check. I'll update it in next revision, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Fix memleak in nv50_wndw_new_
When nv50_lut_init() fails, *pwndw should be freed
just like when drm_universal_plane_init() fails.
It's the same for the subsequent error paths.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 0356474ad6f6..47ce1df2ae5f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -732,18 +732,15 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct
drm_device *dev,
format, nformat,
nouveau_display(dev)->format_modifiers,
type, "%s-%d", name, index);
- if (ret) {
- kfree(*pwndw);
- *pwndw = NULL;
- return ret;
- }
+ if (ret)
+ goto err_free;
drm_plane_helper_add(&wndw->plane, &nv50_wndw_helper);
if (wndw->func->ilut) {
ret = nv50_lut_init(disp, mmu, &wndw->ilut);
if (ret)
- return ret;
+ goto err_free;
}
wndw->notify.func = nv50_wndw_notify;
@@ -752,26 +749,31 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct
drm_device *dev,
ret = drm_plane_create_zpos_property(&wndw->plane,
nv50_wndw_zpos_default(&wndw->plane), 0, 254);
if (ret)
- return ret;
+ goto err_free;
ret = drm_plane_create_alpha_property(&wndw->plane);
if (ret)
- return ret;
+ goto err_free;
ret = drm_plane_create_blend_mode_property(&wndw->plane,
BIT(DRM_MODE_BLEND_PIXEL_NONE) |
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE));
if (ret)
- return ret;
+ goto err_free;
} else {
ret = drm_plane_create_zpos_immutable_property(&wndw->plane,
nv50_wndw_zpos_default(&wndw->plane));
if (ret)
- return ret;
+ goto err_free;
}
return 0;
+
+err_free:
+ kfree(*pwndw);
+ *pwndw = NULL;
+ return ret;
}
int
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if rate is unavailable
On 23-12-20, 23:36, Dmitry Osipenko wrote:
> 23.12.2020 07:34, Viresh Kumar пишет:
> > On 22-12-20, 22:19, Dmitry Osipenko wrote:
> >> 22.12.2020 12:12, Viresh Kumar пишет:
> >>> rate will be 0 for both the OPPs here if rate_not_available is true and
> >>> so this
> >>> change shouldn't be required.
> >>
> >> The rate_not_available is negated in the condition. This change is
> >> required because both rates are 0 and then we should proceed to the
> >> levels comparison.
> >
> > Won't that happen without this patch ?
>
> No
This is how the code looks like currently:
int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
{
if (opp1->rate != opp2->rate)
return opp1->rate < opp2->rate ? -1 : 1;
if (opp1->bandwidth && opp2->bandwidth &&
opp1->bandwidth[0].peak != opp2->bandwidth[0].peak)
return opp1->bandwidth[0].peak < opp2->bandwidth[0].peak ? -1 :
1;
if (opp1->level != opp2->level)
return opp1->level < opp2->level ? -1 : 1;
return 0;
}
Lets consider the case you are focussing on, where rate is 0 for both the OPPs,
bandwidth isn't there and we want to run the level comparison here.
Since both the rates are 0, (opp1->rate != opp2->rate) will fail and so we will
move to bandwidth check which will fail too. And so we will get to the level
comparison.
What am I missing here ? I am sure there is something for sure as you won't have
missed this..
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: Convert Arm Mali Valhall GPU to DT schema
Convert the Arm Valhall GPU binding to DT schema format.
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
new file mode 100644
index ..3dba202bec95
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
@@ -0,0 +1,252 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/arm,mali-vallhall.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Mali Valhall GPU
+
+maintainers:
+ - Rob Herring
+
+properties:
+ $nodename:
+pattern: '^gpu@[a-f0-9]+$'
+
+ compatible:
+items:
+ - enum:
+ - mediatek,mt8192-mali
+ - const: arm,mali-valhall # Mali Valhall GPU model/revision is fully
discoverable
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: GPU interrupt
+ - description: MMU interrupt
+ - description: Job interrupt
+
+ interrupt-names:
+items:
+ - const: gpu
+ - const: mmu
+ - const: job
+
+ clocks:
+minItems: 1
+
+ power-domains:
+minItems: 1
+maxItems: 5
+
+ mali-supply: true
+ sram-supply: true
+
+ operating-points-v2: true
+
+ "#cooling-cells":
+const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: mediatek,mt8192-mali
+then:
+ properties:
+sram-supply: true
+power-domains:
+ description:
+List of phandle and PM domain specifier as documented in
+Documentation/devicetree/bindings/power/power_domain.txt
+ minItems: 5
+ maxItems: 5
+power-domain-names:
+ items:
+- const: core0
+- const: core1
+- const: core2
+- const: core3
+- const: core4
+
+ required:
+- sram-supply
+- power-domains
+
+examples:
+ - |
+#include
+#include
+
+gpu@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0x1300 0x4000>;
+ interrupts =
+ ,
+ ,
+ ;
+ interrupt-names =
+ "gpu",
+ "mmu",
+ "job";
+
+ clocks = <&mfgcfg 0>;
+
+ power-domains =
+ <&scpsys 4>,
+ <&scpsys 5>,
+ <&scpsys 6>,
+ <&scpsys 7>,
+ <&scpsys 8>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+ mali-supply = <&mt6315_7_vbuck1>;
+ sram-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
+gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+/bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+/bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+ <75>;
+ };
+
+ opp-44000 {
+ opp-hz = /bits/ 64 <44000>;
+ opp-hz-real = /bits/ 64 <44000>,
+/bits/ 64 <44000>;
+ opp-microvolt = <631250>,
+ <75>;
+ };
+
+ opp-48200 {
+ opp-hz = /bits/ 64 <48200>;
+ opp-hz-real = /bits/ 64 <48200>,
+/bits/ 64 <48200>;
+ opp-microvolt = <643750>,
+ <75>;
+ };
+
+ opp-52300 {
+ opp-hz = /bits/ 64 <52300>;
+ opp-hz-real = /bits/ 64 <52300>,
+/bits/ 64 <52300>;
+ opp-microvolt = <656250>,
+ <75>;
+ };
+
+ opp-56400 {
+ opp-hz = /bits/ 64 <56400>;
+ opp-hz-real = /bits/ 64 <56400>,
+/bits/ 64 <56400>;
+ opp-microvolt = <668750>,
+ <75>;
+ };
+
+ opp-60500 {
+ opp-hz = /bits/ 64 <60500>;
+ opp-hz-real = /bits/
[PATCH -next] video: fbdev: omap2: Use DEFINE_SPINLOCK() for spinlock
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Zheng Yongjun
---
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/apply.c
b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
index c71021091828..acca991c7540 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/apply.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/apply.c
@@ -108,7 +108,7 @@ static struct {
} dss_data;
/* protects dss_data */
-static spinlock_t data_lock;
+static DEFINE_SPINLOCK(data_lock);
/* lock for blocking functions */
static DEFINE_MUTEX(apply_lock);
static DECLARE_COMPLETION(extra_updated_completion);
@@ -131,8 +131,6 @@ static void apply_init_priv(void)
struct mgr_priv_data *mp;
int i;
- spin_lock_init(&data_lock);
-
for (i = 0; i < num_ovls; ++i) {
struct ovl_priv_data *op;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/48] opp: Support set_opp() customization without requiring to use regulators
23.12.2020 09:01, Viresh Kumar пишет:
> On 17-12-20, 21:06, Dmitry Osipenko wrote:
>> Support set_opp() customization without requiring to use regulators. This
>> is needed by drivers which want to use dev_pm_opp_set_rate() for changing
>> rates of a multiple clocks and don't need to touch regulator.
>>
>> One example is NVIDIA Tegra30/114 SoCs which have two sibling 3D hardware
>> units which should be use to the same clock rate, meanwhile voltage
>> scaling is done using a power domain. In this case OPP table doesn't have
>> a regulator, causing a NULL dereference in _set_opp_custom().
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/opp/core.c | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>> index 3d02fe33630b..625dae7a5ecb 100644
>> --- a/drivers/opp/core.c
>> +++ b/drivers/opp/core.c
>> @@ -828,17 +828,25 @@ static int _set_opp_custom(const struct opp_table
>> *opp_table,
>> struct dev_pm_opp_supply *old_supply,
>> struct dev_pm_opp_supply *new_supply)
>> {
>> -struct dev_pm_set_opp_data *data;
>> +struct dev_pm_set_opp_data *data, tmp_data;
>> +unsigned int regulator_count;
>> int size;
>>
>> -data = opp_table->set_opp_data;
>> +if (opp_table->set_opp_data) {
>> +data = opp_table->set_opp_data;
>> +regulator_count = opp_table->regulator_count;
>> +} else {
>> +data = &tmp_data;
>> +regulator_count = 0;
>> +}
>> +
>
> We should use the same structure, you can add some checks but not replace the
> structure altogether.
Well, there is no "same structure", the opp_table->set_opp_data is NULL
there.
I can re-write it like this if it looks better to you:
static int _set_opp_custom(...)
{
struct dev_pm_set_opp_data *data;
unsigned int regulator_count;
int size;
+ if (!opp_table->set_opp_data) {
+ struct dev_pm_set_opp_data freq_data = {};
+
+ freq_data.dev = dev;
+ freq_data.clk = opp_table->clk;
+ freq_data.new_opp.rate = freq;
+ freq_data.old_opp.rate = old_freq;
+
+ return opp_table->set_opp(&freq_data);
+ }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/v3d: Minor improvements
On 12/23/2020 1:39 PM, Florian Fainelli wrote: > > > On 12/23/2020 12:27 PM, Stefan Wahren wrote: >> This small series of v3d patches is a preparation for the upcoming bcm2711 >> support. The bcm2711 support will be send separate, because it involves >> bigger changes. >> >> I'm not sure that the schema conversion patch is sufficient. >> >> Patch 2,3 are directly taken from Raspberry Pi 4 vendor tree. >> >> Nicolas Saenz Julienne (1): >> drm/v3d: Use platform_get_irq_optional() to get optional IRQs >> >> Phil Elwell (2): >> drm/v3d: Set dma_mask as well as coherent_dma_mask >> drm/v3d: Don't clear MMU control bits on exception > > You need to amend your Signed-off-by to all of those 3 patches that you > did not author. Looks like you fixed it in v2 about 10 minutes after, sorry for the noise. -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] iommu/io-pgtable: Introduce dynamic io-pgtable fmt registration
Hi Isaac,
On 22.12.20 2:44, Isaac J. Manjarres wrote:
The io-pgtable code constructs an array of init functions for each
page table format at compile time. This is not ideal, as this
increases the footprint of the io-pgtable code, as well as prevents
io-pgtable formats from being built as kernel modules.
In preparation for modularizing the io-pgtable formats, switch to a
dynamic registration scheme, where each io-pgtable format can register
their init functions with the io-pgtable code at boot or module
insertion time.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 34 +-
drivers/iommu/io-pgtable-arm.c | 90 ++--
drivers/iommu/io-pgtable.c | 94 --
include/linux/io-pgtable.h | 51 +
4 files changed, 209 insertions(+), 60 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 1d92ac9..89aad2f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -28,6 +28,7 @@
[..]
+static int __init arm_lpae_init(void)
+{
+ int ret, i;
+
+ for (i = 0; i < ARRAY_SIZE(io_pgtable_arm_lpae_init_fns); i++) {
+ ret = io_pgtable_ops_register(&io_pgtable_arm_lpae_init_fns[i]);
+ if (ret < 0) {
+ pr_err("Failed to register ARM LPAE fmt: %d\n");
I guess we want to print the format here?
Thanks,
Georgi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
Convert usb-device.txt to YAML schema usb-device.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob:
1. limit the pattern length
2. remove properties description for hard wired USB devices in usb-hcd.yaml
depends on series:
https://patchwork.kernel.org/project/linux-usb/list/?series=399561
[v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v4: no changes, update dependent series:
https://patchwork.kernel.org/project/linux-usb/list/?series=399561
[v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v3:
1. remove $nodenmae and items key word for compatilbe;
2. add additionalProperties;
The followings are suggested by Rob:
3. merge the following patch
[v2,1/4] dt-bindings: usb: convert usb-device.txt to YAML schema
[v2,2/4] dt-bindings: usb: add properties for hard wired devices
4. define the unit-address for hard-wired device in usb-hcd.yaml,
also define its 'reg' and 'compatible';
5. This series is base on Serge's series:
https://patchwork.kernel.org/project/linux-usb/cover/2020090853.14112-1-sergey.se...@baikalelectronics.ru/
[v4,00/18] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v2 changes suggested by Rob:
1. modify pattern to support any USB class
2. convert usb-device.txt into usb-device.yaml
---
.../devicetree/bindings/usb/usb-device.txt| 102 --
.../devicetree/bindings/usb/usb-device.yaml | 124 ++
.../devicetree/bindings/usb/usb-hcd.yaml | 19 +++
3 files changed, 143 insertions(+), 102 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
create mode 100644 Documentation/devicetree/bindings/usb/usb-device.yaml
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
deleted file mode 100644
index 036be172b1ae..
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-Generic USB Device Properties
-
-Usually, we only use device tree for hard wired USB device.
-The reference binding doc is from:
-http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
-
-Four types of device-tree nodes are defined: "host-controller nodes"
-representing USB host controllers, "device nodes" representing USB devices,
-"interface nodes" representing USB interfaces and "combined nodes"
-representing simple USB devices.
-
-A combined node shall be used instead of a device node and an interface node
-for devices of class 0 or 9 (hub) with a single configuration and a single
-interface.
-
-A "hub node" is a combined node or an interface node that represents a USB
-hub.
-
-
-Required properties for device nodes:
-- compatible: "usbVID,PID", where VID is the vendor id and PID the product id.
- The textual representation of VID and PID shall be in lower case hexadecimal
- with leading zeroes suppressed. The other compatible strings from the above
- standard binding could also be used, but a device adhering to this binding
- may leave out all except for "usbVID,PID".
-- reg: the number of the USB hub port or the USB host-controller port to which
- this device is attached. The range is 1-255.
-
-
-Required properties for device nodes with interface nodes:
-- #address-cells: shall be 2
-- #size-cells: shall be 0
-
-
-Required properties for interface nodes:
-- compatible: "usbifVID,PID.configCN.IN", where VID is the vendor id, PID is
- the product id, CN is the configuration value and IN is the interface
- number. The textual representation of VID, PID, CN and IN shall be in lower
- case hexadecimal with leading zeroes suppressed. The other compatible
- strings from the above standard binding could also be used, but a device
- adhering to this binding may leave out all except for
- "usbifVID,PID.configCN.IN".
-- reg: the interface number and configuration value
-
-The configuration component is not included in the textual representation of
-an interface-node unit address for configuration 1.
-
-
-Required properties for combined nodes:
-- compatible: "usbVID,PID", where VID is the vendor id and PID the product id.
- The textual representation of VID and PID shall be in lower case hexadecimal
- with leading zeroes suppressed. The other compatible strings from the above
- standard binding could also be used, but a device adhering to this binding
- may leave out all except for "usbVID,PID".
-- reg: the number of the USB hub port or the USB host-controller port to which
- this device is attached. The range is 1-255.
-
-
-Required properties for hub nodes with device nodes:
-- #address-cells: shall be 1
-- #size-cells: shall be 0
-
-
-Required properties for host-controller nodes with device nodes:
-- #address-cells: shall be 1
-- #size-cells: shall be 0
-
-
-Example:
-
-&usb1 {/* host controller */
- #address-cells = <1>;
- #size-cells = <0>;
-
- hub@
Re: [PATCH V2 3/4] drm/v3d: Don't clear MMU control bits on exception
On Wed, 2020-12-23 at 21:35 +0100, Stefan Wahren wrote: > From: Phil Elwell > > MMU exception conditions are reported in the V3D_MMU_CTRL register as > write-1-to-clear (W1C) bits. The MMU interrupt handling code clears any > exceptions, but does so by masking out any other bits and writing the > result back. There are some important control bits in that register, > including MMU_ENABLE, so a safer approach is to simply write back the > value just read unaltered. > > Signed-off-by: Phil Elwell > Signed-off-by: Stefan Wahren > --- Reviewed-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2, 0/3] support gce on mt8192 platform
Change since v1: - move out shit jump patch - rmove usless patch Yongqiang Niu (3): dt-binding: gce: add gce header file for mt8192 arm64: dts: mt8192: add gce node mailbox: cmdq: add mt8192 support .../devicetree/bindings/mailbox/mtk-gce.txt| 7 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c | 1 + include/dt-bindings/gce/mt8192-gce.h | 419 + 4 files changed, 434 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h -- 1.8.1.1.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2, 1/3] dt-binding: gce: add gce header file for mt8192
Add documentation for the mt8192 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8192. Signed-off-by: Yongqiang Niu --- .../devicetree/bindings/mailbox/mtk-gce.txt| 7 +- include/dt-bindings/gce/mt8192-gce.h | 419 + 2 files changed, 423 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index cf48cd8..f48ae45 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,8 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or - "mediatek,mt6779-gce". +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce", + "mediatek,mt8192-gce" or "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -36,7 +36,8 @@ Optional properties for a client device: size: the total size of register address that GCE can access. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as +'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h' or +'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt8192-gce.h b/include/dt-bindings/gce/mt8192-gce.h new file mode 100644 index 000..0627544 --- /dev/null +++ b/include/dt-bindings/gce/mt8192-gce.h @@ -0,0 +1,419 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Yongqiang Niu + */ + +#ifndef _DT_BINDINGS_GCE_MT8192_H +#define _DT_BINDINGS_GCE_MT8192_H + +/* assign timeout 0 also means default */ +#define CMDQ_NO_TIMEOUT0x +#define CMDQ_TIMEOUT_DEFAULT 1000 + +/* GCE thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_11 +#define CMDQ_THR_PRIO_22 +#define CMDQ_THR_PRIO_33 +#define CMDQ_THR_PRIO_44 +#define CMDQ_THR_PRIO_55 +#define CMDQ_THR_PRIO_66 +#define CMDQ_THR_PRIO_HIGHEST 7 + +/* CPR count in 32bit register */ +#define GCE_CPR_COUNT 1312 + +/* GCE subsys table */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 +#define SUBSYS_NO_SUPPORT 99 + +/* GCE General Purpose Register (GPR) support + * Leave note for scenario usage here + */ +/* GCE: write mask */ +#define GCE_GPR_R000x00 +#define GCE_GPR_R010x01 +/* MDP: P1: JPEG dest */ +#define GCE_GPR_R020x02 +#define GCE_GPR_R030x03 +/* MDP: PQ color */ +#define GCE_GPR_R040x04 +/* MDP: 2D sharpness */ +#define GCE_GPR_R050x05 +/* DISP: poll esd */ +#define GCE_GPR_R060x06 +#define GCE_GPR_R070x07 +/* MDP: P4: 2D sharpness dst */ +#define GCE_GPR_R080x08 +#define GCE_GPR_R090x09 +/* VCU: poll with timeout for GPR timer */ +#define GCE_GPR_R100x0A +#define GCE_GPR_R110x0B +/* CMDQ: debug */ +#define GCE_GPR_R120x0C +#define GCE_GPR_R130x0D +/* CMDQ: P7: debug */ +#define GCE_GPR_R140x0E +#define GCE_GPR_R150x0F + +#define CMDQ_EVENT_VDEC_LAT_SOF_0 0 +#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_0
[PATCH v5 06/11] dt-bindings: phy: convert HDMI PHY binding to YAML schema
Convert HDMI PHY binding to YAML schema mediatek,hdmi-phy.yaml
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Chun-Kuang Hu
---
v5: add Reviewed-by Chun-Kuang
v4: add maintainer Philipp
v3: add Reviewed-by Rob
v2: fix binding check warning of reg in example
---
.../display/mediatek/mediatek,hdmi.txt| 18 +---
.../bindings/phy/mediatek,hdmi-phy.yaml | 92 +++
2 files changed, 93 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
index 6b1c586403e4..b284ca51b913 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
@@ -53,23 +53,7 @@ Required properties:
HDMI PHY
-
-The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
-output and drives the HDMI pads.
-
-Required properties:
-- compatible: "mediatek,-hdmi-phy"
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the module's registers
-- clocks: PLL reference clock
-- clock-names: must contain "pll_ref"
-- clock-output-names: must be "hdmitx_dig_cts" on mt8173
-- #phy-cells: must be <0>
-- #clock-cells: must be <0>
-
-Optional properties:
-- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
-- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+See phy/mediatek,hdmi-phy.yaml
Example:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
new file mode 100644
index ..4752517a1446
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
+
+maintainers:
+ - Chun-Kuang Hu
+ - Philipp Zabel
+ - Chunfeng Yun
+
+description: |
+ The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+ output and drives the HDMI pads.
+
+properties:
+ $nodename:
+pattern: "^hdmi-phy@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - mediatek,mt2701-hdmi-phy
+ - mediatek,mt7623-hdmi-phy
+ - mediatek,mt8173-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PLL reference clock
+
+ clock-names:
+items:
+ - const: pll_ref
+
+ clock-output-names:
+items:
+ - const: hdmitx_dig_cts
+
+ "#phy-cells":
+const: 0
+
+ "#clock-cells":
+const: 0
+
+ mediatek,ibias:
+description:
+ TX DRV bias current for < 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0xa
+
+ mediatek,ibias_up:
+description:
+ TX DRV bias current for >= 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0x1c
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-output-names
+ - "#phy-cells"
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+hdmi_phy: hdmi-phy@10209100 {
+compatible = "mediatek,mt8173-hdmi-phy";
+reg = <0x10209100 0x24>;
+clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+clock-names = "pll_ref";
+clock-output-names = "hdmitx_dig_cts";
+mediatek,ibias = <0xa>;
+mediatek,ibias_up = <0x1c>;
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
+
+...
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2, 2/3] arm64: dts: mt8192: add gce node
add gce node
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 69d45c7..e9684a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include
+#include
#include
#include
#include
@@ -272,6 +273,15 @@
clock-names = "clk13m";
};
+ gce: mailbox@10228000 {
+ compatible = "mediatek,mt8192-gce";
+ reg = <0 0x10228000 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <3>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
scp_adsp: syscon@1072 {
compatible = "mediatek,mt8192-scp_adsp", "syscon";
reg = <0 0x1072 0 0x1000>;
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm: gma500: use DEFINE_MUTEX (and mutex_init() had been too late)
Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/gma500/power.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c index bea8578846d1..b361e41c6acd 100644 --- a/drivers/gpu/drm/gma500/power.c +++ b/drivers/gpu/drm/gma500/power.c @@ -35,7 +35,7 @@ #include #include -static struct mutex power_mutex; /* Serialize power ops */ +static DEFINE_MUTEX(power_mutex); /* Serialize power ops */ static spinlock_t power_ctrl_lock; /* Serialize power claim */ /** @@ -56,7 +56,6 @@ void gma_power_init(struct drm_device *dev) dev_priv->display_count = 0;/* Currently no users */ dev_priv->suspended = false;/* And not suspended */ spin_lock_init(&power_ctrl_lock); - mutex_init(&power_mutex); if (dev_priv->ops->init_pm) dev_priv->ops->init_pm(dev); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
24.12.2020 09:51, Viresh Kumar пишет: > On 23-12-20, 23:37, Dmitry Osipenko wrote: >> 23.12.2020 08:57, Viresh Kumar пишет: >>> What's wrong with getting the regulator in the driver as well ? Apart from >>> the >>> OPP core ? >> >> The voltage syncing should be done for each consumer regulator >> individually [1]. >> >> Secondly, regulator core doesn't work well today if the same regulator >> is requested more than one time for the same device. > > Hmm... > will return the OPP table regulator in order to allow driver to use the regulator directly. But I'm not sure whether this is a much better option than the opp_sync_regulators() and opp_set_voltage() APIs. >>> >>> set_voltage() is still fine as there is some data that the OPP core has, but >>> sync_regulator() has nothing to do with OPP core. >>> >>> And this may lead to more wrapper helpers in the OPP core, which I am >>> afraid of. >>> And so even if it is not the best, I would like the OPP core to provide the >>> data >>> and not get into this. Ofcourse there is an exception to this, opp_set_rate. >>> >> >> The regulator_sync_voltage() should be invoked only if voltage was >> changed previously [1]. >> >> The OPP core already has the info about whether voltage was changed and >> it provides the necessary locking for both set_voltage() and >> sync_regulator(). Perhaps I'll need to duplicate that functionality in >> the PD driver, instead of making it all generic and re-usable by other >> drivers. >> >> [1] >> https://elixir.bootlin.com/linux/v5.10.2/source/drivers/regulator/core.c#L4107 > > Lets do it in the OPP core and see where we go. > Alright, thank you. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: Remove usage of drm_display_mode_to_videomode()
There is not much value in the extra conversion step, the calculations
required for the LTDC IP are different than what is used in the
drm_display_mode_to_videomode(), so just do the right ones in the LTDC
driver right away.
Signed-off-by: Marek Vasut
Cc: Alexandre Torgue
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/stm/ltdc.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 22c7e9fa5ab7..e8fc8fc50d94 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -545,7 +545,6 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_device *ddev = crtc->dev;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
- struct videomode vm;
u32 bus_flags = 0;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
@@ -565,31 +564,33 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
}
}
- drm_display_mode_to_videomode(mode, &vm);
-
DRM_DEBUG_DRIVER("CRTC:%d mode:%s\n", crtc->base.id, mode->name);
- DRM_DEBUG_DRIVER("Video mode: %dx%d", vm.hactive, vm.vactive);
+ DRM_DEBUG_DRIVER("Video mode: %dx%d", mode->hdisplay, mode->vdisplay);
DRM_DEBUG_DRIVER(" hfp %d hbp %d hsl %d vfp %d vbp %d vsl %d\n",
-vm.hfront_porch, vm.hback_porch, vm.hsync_len,
-vm.vfront_porch, vm.vback_porch, vm.vsync_len);
+mode->hsync_start - mode->hdisplay,
+mode->htotal - mode->hsync_end,
+mode->hsync_end - mode->hsync_start,
+mode->vsync_start - mode->vdisplay,
+mode->vtotal - mode->vsync_end,
+mode->vsync_end - mode->vsync_start);
/* Convert video timings to ltdc timings */
- hsync = vm.hsync_len - 1;
- vsync = vm.vsync_len - 1;
- accum_hbp = hsync + vm.hback_porch;
- accum_vbp = vsync + vm.vback_porch;
- accum_act_w = accum_hbp + vm.hactive;
- accum_act_h = accum_vbp + vm.vactive;
- total_width = accum_act_w + vm.hfront_porch;
- total_height = accum_act_h + vm.vfront_porch;
+ hsync = mode->hsync_end - mode->hsync_start - 1;
+ vsync = mode->vsync_end - mode->vsync_start - 1;
+ accum_hbp = mode->htotal - mode->hsync_start - 1;
+ accum_vbp = mode->vtotal - mode->vsync_start - 1;
+ accum_act_w = accum_hbp + mode->hdisplay;
+ accum_act_h = accum_vbp + mode->vdisplay;
+ total_width = mode->htotal - 1;
+ total_height = mode->vtotal - 1;
/* Configures the HS, VS, DE and PC polarities. Default Active Low */
val = 0;
- if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH)
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= GCR_HSPOL;
- if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= GCR_VSPOL;
if (bus_flags & DRM_BUS_FLAG_DE_LOW)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/11] dt-bindings: usb: convert mediatek, mtk-xhci.txt to YAML schema
Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob
1. refer to usb-xhci.yaml instead of usb-hcd.yaml
2. remove unnecessary maxItems
3. add items for all phys may be supported
4. change pattern, and limit pattern length of patternProperties
v4: update it according to Rob's suggestion
1. modify dictionary of phys
2. fix endentation in "mediatek,syscon-wakeup" items
3. remove reference to usb-hcd.yaml
v3:
1. fix yamllint warning
2. remove pinctrl* properties supported by default suggested by Rob
3. drop unused labels
4. modify description of mediatek,syscon-wakeup
5. remove type of imod-interval-ns
v2: new patch
---
.../bindings/usb/mediatek,mtk-xhci.txt| 121
.../bindings/usb/mediatek,mtk-xhci.yaml | 178 ++
2 files changed, 178 insertions(+), 121 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
deleted file mode 100644
index 42d8814f903a..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-MT8173 xHCI
-
-The device node for Mediatek SOC USB3.0 host controller
-
-There are two scenarios: the first one only supports xHCI driver;
-the second one supports dual-role mode, and the host is based on xHCI
-driver. Take account of backward compatibility, we divide bindings
-into two parts.
-
-1st: only supports xHCI driver
-
-
-Required properties:
- - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
- soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
- "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
- addition, one of:
- - "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
- - interrupts : interrupt used by the controller
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
-
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
- "sys_ck": controller clock used by normal mode,
- the following ones are optional:
- "ref_ck": reference clock used by low power mode etc,
- "mcu_ck": mcu_bus clock for register access,
- "dma_ck": dma_bus clock for data transfer by DMA,
- "xhci_ck": controller clock
-
- - phys : see usb-hcd.yaml in the current directory
-
-Optional properties:
- - wakeup-source : enable USB remote wakeup;
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between xHCI and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
- - vbus-supply : reference to the VBUS regulator;
- - usb3-lpm-capable : supports USB3.0 LPM
- - pinctrl-names : a pinctrl state named "default" must be defined
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
- - imod-interval-ns: default interrupt moderation interval is 5000ns
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Example:
-usb30: usb@1127 {
- compatible = "mediatek,mt8173-xhci";
- reg = <0 0x1127 0 0x1000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
- clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
-<&pericfg CLK_PERI_USB0>,
-<&pericfg CLK_PERI_USB1>;
- clock-names = "sys_ck", "ref_ck";
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
- vusb33-supply = <&mt6397_vusb_reg>;
- vbus-supply = <&usb_p1_vbus>;
- usb3-lpm-capable;
- mediatek,syscon-wakeup = <&pericfg 0x400 1>;
- wakeup-source;
- imod-interval-ns = <1>;
-};
-
-2nd: dual-role mode with xHCI driver
-
-
-In the case, xhci is added as subnode to mtu3. An example and the DT binding
-details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
-
-Required prop
[PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pixelclk-active",
same as the one used by display timings, and configure bus flags based on
this DT property.
Signed-off-by: Marek Vasut
Cc: Alexandre Torgue
Cc: Andrzej Hajda
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Biju Das
Cc: Laurent Pinchart
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
---
V2: - Limit the pixelclk-active to encoders only
- Update DT binding document
---
.../bindings/display/bridge/lvds-codec.yaml | 7 +++
drivers/gpu/drm/bridge/lvds-codec.c | 52 +--
2 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index e5e3c72630cf..399a6528780a 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -74,6 +74,13 @@ properties:
additionalProperties: false
+ pixelclk-active:
+description: |
+ Data sampling on rising or falling edge.
+ Use 0 to sample pixel data on rising edge and
+ Use 1 to sample pixel data on falling edge and
+enum: [0, 1]
+
powerdown-gpios:
description:
The GPIO used to control the power down line of this device.
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index dcf579a4cf83..cab81ccd895d 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -15,13 +15,18 @@
#include
#include
+struct lvds_codec_data {
+ u32 connector_type;
+ bool is_encoder;
+};
+
struct lvds_codec {
struct device *dev;
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+ struct drm_bridge_timings timings;
struct regulator *vcc;
struct gpio_desc *powerdown_gpio;
- u32 connector_type;
};
static inline struct lvds_codec *to_lvds_codec(struct drm_bridge *bridge)
@@ -76,17 +81,20 @@ static const struct drm_bridge_funcs funcs = {
static int lvds_codec_probe(struct platform_device *pdev)
{
+ const struct lvds_codec_data *data;
struct device *dev = &pdev->dev;
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
+ u32 val;
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
if (!lvds_codec)
return -ENOMEM;
+ data = of_device_get_match_data(dev);
+
lvds_codec->dev = &pdev->dev;
- lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->vcc = devm_regulator_get(lvds_codec->dev, "power");
if (IS_ERR(lvds_codec->vcc))
@@ -115,10 +123,22 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->panel_bridge =
devm_drm_panel_bridge_add_typed(dev, panel,
- lvds_codec->connector_type);
+ data->connector_type);
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
+ /*
+* Encoder might sample data on different clock edge than the display,
+* for example OnSemi FIN3385 has a dedicated strapping pin to select
+* the sampling edge.
+*/
+ if (data->is_encoder &&
+ !of_property_read_u32(dev->of_node, "pixelclk-active", &val)) {
+ lvds_codec->timings.input_bus_flags = val ?
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE :
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE;
+ }
+
/*
* The panel_bridge bridge is attached to the panel's of_node,
* but we need a bridge attached to our of_node for our user
@@ -126,6 +146,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
*/
lvds_codec->bridge.of_node = dev->of_node;
lvds_codec->bridge.funcs = &funcs;
+ lvds_codec->bridge.timings = &lvds_codec->timings;
drm_bridge_add(&lvds_codec->bridge);
platform_set_drvdata(pdev, lvds_codec);
@@ -142,19 +163,20 @@ static int lvds_codec_remove(struct platform_device *pdev)
return 0;
}
+static const struct lvds_codec_data decoder_data = {
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .is_encoder = false,
+};
+
+static const struct lvds_codec_data encoder_data = {
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+ .is_encoder = true,
+};
+
static const struct of_device_id lvds_codec_match[] = {
- {
- .compatible = "lvds-decoder",
- .data = (voi
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
23.12.2020 07:19, Viresh Kumar пишет: > On 22-12-20, 22:15, Dmitry Osipenko wrote: >> 22.12.2020 09:42, Viresh Kumar пишет: >>> On 17-12-20, 21:06, Dmitry Osipenko wrote: Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if levels don't start from 0 in OPP table and zero usually means a minimal level. Signed-off-by: Dmitry Osipenko >>> >>> Why doesn't the exact version work for you here ? >>> >> >> The exact version won't find OPP for level=0 if levels don't start with >> 0, where 0 means that minimal level is desired. > > Right, but why do you need to send 0 for your platform ? > To put power domain into the lowest performance state when device is idling. https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/opp/core.c#L897 https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/opp/core.c#L785 Also please see patch 32, tegra_clock_runtime_suspend(). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] video: backlight: use DEFINE_MUTEX (and mutex_init() had been too late)
Signed-off-by: Zheng Yongjun
---
drivers/video/backlight/backlight.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 537fe1b376ad..d7a09c422547 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -64,7 +64,7 @@
*/
static struct list_head backlight_dev_list;
-static struct mutex backlight_dev_list_mutex;
+static DEFINE_MUTEX(backlight_dev_list_mutex);
static struct blocking_notifier_head backlight_notifier;
static const char *const backlight_types[] = {
@@ -757,7 +757,6 @@ static int __init backlight_class_init(void)
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
INIT_LIST_HEAD(&backlight_dev_list);
- mutex_init(&backlight_dev_list_mutex);
BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
return 0;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if rate is unavailable
24.12.2020 09:28, Viresh Kumar пишет:
> On 23-12-20, 23:36, Dmitry Osipenko wrote:
>> 23.12.2020 07:34, Viresh Kumar пишет:
>>> On 22-12-20, 22:19, Dmitry Osipenko wrote:
22.12.2020 12:12, Viresh Kumar пишет:
> rate will be 0 for both the OPPs here if rate_not_available is true and
> so this
> change shouldn't be required.
The rate_not_available is negated in the condition. This change is
required because both rates are 0 and then we should proceed to the
levels comparison.
>>>
>>> Won't that happen without this patch ?
>>
>> No
>
> This is how the code looks like currently:
>
> int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
> {
> if (opp1->rate != opp2->rate)
> return opp1->rate < opp2->rate ? -1 : 1;
> if (opp1->bandwidth && opp2->bandwidth &&
> opp1->bandwidth[0].peak != opp2->bandwidth[0].peak)
> return opp1->bandwidth[0].peak < opp2->bandwidth[0].peak ? -1 :
> 1;
> if (opp1->level != opp2->level)
> return opp1->level < opp2->level ? -1 : 1;
> return 0;
> }
>
> Lets consider the case you are focussing on, where rate is 0 for both the
> OPPs,
> bandwidth isn't there and we want to run the level comparison here.
>
> Since both the rates are 0, (opp1->rate != opp2->rate) will fail and so we
> will
> move to bandwidth check which will fail too. And so we will get to the level
> comparison.
>
> What am I missing here ? I am sure there is something for sure as you won't
> have
> missed this..
>
Ah, you're right. It was me who was missing something as I see now,
after taking a closer look and trying to implement yours suggestion, my
bad. I'll improve this patch in the next revision, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if rate is unavailable
23.12.2020 07:34, Viresh Kumar пишет:
> On 22-12-20, 22:19, Dmitry Osipenko wrote:
>> 22.12.2020 12:12, Viresh Kumar пишет:
>>> On 17-12-20, 21:06, Dmitry Osipenko wrote:
Fix adding OPP entries in a wrong (opposite) order if OPP rate is
unavailable. The OPP comparison is erroneously skipped if OPP rate is
missing, thus OPPs are left unsorted.
Signed-off-by: Dmitry Osipenko
---
drivers/opp/core.c | 23 ---
drivers/opp/opp.h | 2 +-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 34f7e530d941..5c7f130a8de2 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1531,9 +1531,10 @@ static bool _opp_supported_by_regulators(struct
dev_pm_opp *opp,
return true;
}
-int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
+int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2,
+ bool rate_not_available)
{
- if (opp1->rate != opp2->rate)
+ if (!rate_not_available && opp1->rate != opp2->rate)
>>>
>>> rate will be 0 for both the OPPs here if rate_not_available is true and so
>>> this
>>> change shouldn't be required.
>>
>> The rate_not_available is negated in the condition. This change is
>> required because both rates are 0 and then we should proceed to the
>> levels comparison.
>
> Won't that happen without this patch ?
No
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
24.12.2020 09:43, Viresh Kumar пишет: > On 23-12-20, 23:37, Dmitry Osipenko wrote: >> 23.12.2020 07:19, Viresh Kumar пишет: >>> On 22-12-20, 22:15, Dmitry Osipenko wrote: 22.12.2020 09:42, Viresh Kumar пишет: > On 17-12-20, 21:06, Dmitry Osipenko wrote: >> Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if >> levels don't start from 0 in OPP table and zero usually means a minimal >> level. >> >> Signed-off-by: Dmitry Osipenko > > Why doesn't the exact version work for you here ? > The exact version won't find OPP for level=0 if levels don't start with 0, where 0 means that minimal level is desired. >>> >>> Right, but why do you need to send 0 for your platform ? >>> >> >> To put power domain into the lowest performance state when device is idling. > > I see. So you really want to set it to the lowest state or just take the vote > out ? Which may end up powering off the domain in the worst case ? > In a device driver I want to set PD to the lowest performance state by removing the performance vote when dev_pm_opp_set_rate(dev, 0) is invoked by the driver. The OPP core already does this, but if OPP levels don't start from 0 in a device-tree for PD, then it currently doesn't work since there is a need to get a rounded-up performance state because dev_pm_opp_set_voltage() takes OPP entry for the argument (patches 9 and 28). The PD powering off and performance-changes are separate from each other in the GENPD core. The GENPD core automatically turns off domain when all devices within the domain are suspended by system-suspend or RPM. The performance state of a power domain is controlled solely by a device driver. GENPD core only aggregates the performance requests, it doesn't change the performance state of a domain by itself when device is suspended or resumed, IIUC this is intentional. And I want to put domain into lowest performance state when device is suspended. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 -next] drm: gma500: use DEFINE_MUTEX() for mutex lock
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init(). Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/gma500/power.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c index bea8578846d1..b361e41c6acd 100644 --- a/drivers/gpu/drm/gma500/power.c +++ b/drivers/gpu/drm/gma500/power.c @@ -35,7 +35,7 @@ #include #include -static struct mutex power_mutex; /* Serialize power ops */ +static DEFINE_MUTEX(power_mutex); /* Serialize power ops */ static spinlock_t power_ctrl_lock; /* Serialize power claim */ /** @@ -56,7 +56,6 @@ void gma_power_init(struct drm_device *dev) dev_priv->display_count = 0;/* Currently no users */ dev_priv->suspended = false;/* And not suspended */ spin_lock_init(&power_ctrl_lock); - mutex_init(&power_mutex); if (dev_priv->ops->init_pm) dev_priv->ops->init_pm(dev); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] iommu/arm-smmu: Add dependency on io-pgtable format modules
On 2020-12-23 05:05, Robin Murphy wrote:
On 2020-12-22 19:49, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The SMMU driver depends on the availability of the ARM LPAE and
ARM V7S io-pgtable format code to work properly. In preparation
Nit: we don't really depend on v7s - we *can* use it if it's
available, address constraints are suitable, and the SMMU
implementation actually supports it (many don't), but we can still
quite happily not use it even so. LPAE is mandatory in the
architecture so that's our only hard requirement, embodied in the
kconfig select.
This does mean there may technically still be a corner case involving
ARM_SMMU=y and IO_PGTABLE_ARM_V7S=m, but at worst it's now a runtime
failure rather than a build error, so unless and until anyone
demonstrates that it actually matters I don't feel particularly
inclined to give it much thought.
Robin.
Okay, I'll fix up the commit message, as well as the code, so that it
only depends on io-pgtable-arm.
Well, IIUC it would make sense to keep the softdep for when the v7s
module *is* present; I just wanted to clarify that it's more of a
nice-to-have rather than a necessity.
Robin.
Understood, I will keep it there and reword the commit msg. I just tried
it out in an environment
where the io-pgtable-arm-v7s module isn't present, and I didn't see any
warnings or error messages, and the SMMU driver module was loaded
properly,
so yes, it's good to have it.
Thanks,
Isaac
Thanks,
Isaac
for having the io-pgtable formats as modules, add a "pre"
dependency with MODULE_SOFTDEP() to ensure that the io-pgtable
format modules are loaded before loading the ARM SMMU driver module.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfd..a72649f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -2351,3 +2351,4 @@ MODULE_DESCRIPTION("IOMMU API for ARM
architected SMMU implementations");
MODULE_AUTHOR("Will Deacon ");
MODULE_ALIAS("platform:arm-smmu");
MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("pre: io-pgtable-arm io-pgtable-arm-v7s");
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/48] opp: Support set_opp() customization without requiring to use regulators
On 23-12-20, 23:38, Dmitry Osipenko wrote: > Well, there is no "same structure", the opp_table->set_opp_data is NULL > there. Right, I saw that yesterday. What I meant was that we need to start allocating the structure for this case now. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 09/11] dt-bindings: usb: convert mediatek,mtk-xhci.txt to YAML schema
On Mon, 2020-12-21 at 12:23 -0700, Rob Herring wrote: > On Wed, Dec 16, 2020 at 05:30:10PM +0800, Chunfeng Yun wrote: > > Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml > > > > Signed-off-by: Chunfeng Yun > > --- > > v4: update it according to Rob's suggestion > > 1. modify dictionary of phys > > 2. fix endentation in "mediatek,syscon-wakeup" items > > 3. remove reference to usb-hcd.yaml > > > > v3: > > 1. fix yamllint warning > > 2. remove pinctrl* properties supported by default suggested by Rob > > 3. drop unused labels > > 4. modify description of mediatek,syscon-wakeup > > 5. remove type of imod-interval-ns > > > > v2: new patch > > --- > > .../bindings/usb/mediatek,mtk-xhci.txt| 121 - > > .../bindings/usb/mediatek,mtk-xhci.yaml | 171 ++ > > 2 files changed, 171 insertions(+), 121 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > create mode 100644 > > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > deleted file mode 100644 > > index 42d8814f903a.. > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > +++ /dev/null [...] > > +$id: http://devicetree.org/schemas/usb/mediatek,mtk-xhci.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MediaTek USB3 xHCI Device Tree Bindings > > + > > +maintainers: > > + - Chunfeng Yun > > + > > +allOf: > > + - $ref: "usb-hcd.yaml" > > This will need to reference Serge's xhci.yaml instead. Yes, I forgot it > > > + > > +description: | > > + There are two scenarios: > > + case 1: only supports xHCI driver; > > + case 2: supports dual-role mode, and the host is based on xHCI driver. > > + > > +properties: > > + # common properties for both case 1 and case 2 > > + compatible: > > +items: > > + - enum: > > + - mediatek,mt2712-xhci > > + - mediatek,mt7622-xhci > > + - mediatek,mt7629-xhci > > + - mediatek,mt8173-xhci > > + - mediatek,mt8183-xhci > > + - const: mediatek,mtk-xhci > > + > > + reg: > > +minItems: 1 > > +maxItems: 2 > > You can drop maxItems, as that is implied by length of 'items'. Ok, will drop it for the following ones > > > +items: > > + - description: the registers of xHCI MAC > > + - description: the registers of IP Port Control > > + > > + reg-names: > > +minItems: 1 > > +maxItems: 2 > > +items: > > + - const: mac > > + - const: ippc # optional, only needed for case 1. > > + > > + interrupts: > > +maxItems: 1 > > + > > + power-domains: > > +description: A phandle to USB power domain node to control USB's MTCMOS > > +maxItems: 1 > > + > > + clocks: > > +minItems: 1 > > +maxItems: 5 > > +items: > > + - description: Controller clock used by normal mode > > + - description: Reference clock used by low power mode etc > > + - description: Mcu bus clock for register access > > + - description: DMA bus clock for data transfer > > + - description: controller clock > > + > > + clock-names: > > +minItems: 1 > > +maxItems: 5 > > +items: > > + - const: sys_ck # required, the following ones are optional > > + - const: ref_ck > > + - const: mcu_ck > > + - const: dma_ck > > + - const: xhci_ck > > + > > + phys: > > +description: List of at most 5 USB2 PHYs and 4 USB3 PHYs on this HCD > > If it's less, how does one know what each phy is? The SoC's spec will tell how many phys used, but each project may use some phys of them, due to not all ports are used for some scenarios. > > > +minItems: 0 > > minItems: 0 is never correct. That's phys not being present. Ok, will modify it. But it's useful for the case that the phy is an external sub-board, and can works without initialization. (FPGA env.) > > > +maxItems: 9 > > + > > + vusb33-supply: > > +description: Regulator of USB AVDD3.3v > > + > > + vbus-supply: > > +description: Regulator of USB VBUS5v > > + > > + usb3-lpm-capable: > > +description: supports USB3.0 LPM > > +type: boolean > > + > > + imod-interval-ns: > > +description: > > + Interrupt moderation interval value, it is 8 times as much as that > > + defined in the xHCI spec on MTK's controller. > > +default: 5000 > > + > > + # the following properties are only used for case 1 > > + wakeup-source: > > +description: enable USB remote wakeup, see power/wakeup-source.txt > > +type: boolean > > + > > + mediatek,syscon-wakeup: > > +$ref: /schemas/types.yaml#/definitions/phandle-array > > +maxItems: 1 > > +description: > > + A phandle to syscon used to access the register of the USB wakeup > > glue > > + layer betw
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
23.12.2020 23:37, Dmitry Osipenko пишет:
> 23.12.2020 08:57, Viresh Kumar пишет:
>> On 22-12-20, 22:39, Dmitry Osipenko wrote:
>>> 22.12.2020 22:21, Dmitry Osipenko пишет:
>> +if (IS_ERR(opp)) {
>> +dev_err(&genpd->dev, "failed to find OPP for level %u:
>> %pe\n",
>> +level, opp);
>> +return PTR_ERR(opp);
>> +}
>> +
>> +err = dev_pm_opp_set_voltage(&genpd->dev, opp);
> IIUC, you implemented this callback because you want to use the voltage
> triplet
> present in the OPP table ?
>
> And so you are setting the regulator ("power") later in this patch ?
yes
> I am not in favor of implementing this routine, as it just adds a wrapper
> above
> the regulator API. What you should be doing rather is get the regulator by
> yourself here (instead of depending on the OPP core). And then you can do
> dev_pm_opp_get_voltage() here and set the voltage yourself. You may want
> to
> implement a version supporting triplet here though for the same.
>
> And you won't require the sync version of the API as well then.
>
That's what I initially did for this driver. I don't mind to revert back
to the initial variant in v3, it appeared to me that it will be nicer
and cleaner to have OPP API managing everything here.
>>>
>>> I forgot one important detail (why the initial variant wasn't good)..
>>> OPP entries that have unsupportable voltages should be filtered out and
>>> OPP core performs the filtering only if regulator is assigned to the OPP
>>> table.
>>>
>>> If regulator is assigned to the OPP table, then we need to use OPP API
>>> for driving the regulator, hence that's why I added
>>> dev_pm_opp_sync_regulators() and dev_pm_opp_set_voltage().
>>>
>>> Perhaps it should be possible to add dev_pm_opp_get_regulator() that
>>
>> What's wrong with getting the regulator in the driver as well ? Apart from
>> the
>> OPP core ?
>
> The voltage syncing should be done for each consumer regulator
> individually [1].
>
> Secondly, regulator core doesn't work well today if the same regulator
> is requested more than one time for the same device.
>
>>> will return the OPP table regulator in order to allow driver to use the
>>> regulator directly. But I'm not sure whether this is a much better
>>> option than the opp_sync_regulators() and opp_set_voltage() APIs.
>>
>> set_voltage() is still fine as there is some data that the OPP core has, but
>> sync_regulator() has nothing to do with OPP core.
>>
>> And this may lead to more wrapper helpers in the OPP core, which I am afraid
>> of.
>> And so even if it is not the best, I would like the OPP core to provide the
>> data
>> and not get into this. Ofcourse there is an exception to this, opp_set_rate.
>>
>
> The regulator_sync_voltage() should be invoked only if voltage was
> changed previously [1].
>
> The OPP core already has the info about whether voltage was changed and
> it provides the necessary locking for both set_voltage() and
> sync_regulator(). Perhaps I'll need to duplicate that functionality in
> the PD driver, instead of making it all generic and re-usable by other
> drivers.
>
> [1]
> https://elixir.bootlin.com/linux/v5.10.2/source/drivers/regulator/core.c#L4107
>
I just realized that the locking is missing in the v2 patches, something
to fix in the next revision :)
Still I'm in favor of extending the OPP API with the new common
functions. But if you have a strong opinion about that, then I'll try to
work around it in the PD driver in v3.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/hisilicon: Add load and unload callback functions
Add the callback functions of drm_driver structure member functions
load and unload, no need to call load in the hibmc_pci_probe function
and unload in the hibmc_pci_remove function.
v2:
remove the hibmc_unload called from hibmc_pic_remove.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 0d4e902..10042cf 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -27,6 +27,9 @@
DEFINE_DRM_GEM_FOPS(hibmc_fops);
+static int hibmc_load(struct drm_device *dev, unsigned long flags);
+static void hibmc_unload(struct drm_device *dev);
+
static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
{
struct drm_device *dev = (struct drm_device *)arg;
@@ -63,6 +66,8 @@ static const struct drm_driver hibmc_driver = {
.dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
.gem_prime_mmap = drm_gem_prime_mmap,
.irq_handler= hibmc_drm_interrupt,
+ .load = hibmc_load,
+ .unload = hibmc_unload,
};
static int __maybe_unused hibmc_pm_suspend(struct device *dev)
@@ -248,7 +253,7 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
return 0;
}
-static int hibmc_unload(struct drm_device *dev)
+static void hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
@@ -256,11 +261,9 @@ static int hibmc_unload(struct drm_device *dev)
drm_irq_uninstall(dev);
pci_disable_msi(dev->pdev);
-
- return 0;
}
-static int hibmc_load(struct drm_device *dev)
+static int hibmc_load(struct drm_device *dev, unsigned long flags)
{
struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
@@ -335,12 +338,6 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
goto err_return;
}
- ret = hibmc_load(dev);
- if (ret) {
- drm_err(dev, "failed to load hibmc: %d\n", ret);
- goto err_return;
- }
-
ret = drm_dev_register(dev, 0);
if (ret) {
drm_err(dev, "failed to register drv for userspace access:
%d\n",
@@ -363,7 +360,6 @@ static void hibmc_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
drm_dev_unregister(dev);
- hibmc_unload(dev);
}
static const struct pci_device_id hibmc_pci_table[] = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
On 23-12-20, 23:37, Dmitry Osipenko wrote: > 23.12.2020 07:19, Viresh Kumar пишет: > > On 22-12-20, 22:15, Dmitry Osipenko wrote: > >> 22.12.2020 09:42, Viresh Kumar пишет: > >>> On 17-12-20, 21:06, Dmitry Osipenko wrote: > Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if > levels don't start from 0 in OPP table and zero usually means a minimal > level. > > Signed-off-by: Dmitry Osipenko > >>> > >>> Why doesn't the exact version work for you here ? > >>> > >> > >> The exact version won't find OPP for level=0 if levels don't start with > >> 0, where 0 means that minimal level is desired. > > > > Right, but why do you need to send 0 for your platform ? > > > > To put power domain into the lowest performance state when device is idling. I see. So you really want to set it to the lowest state or just take the vote out ? Which may end up powering off the domain in the worst case ? -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] vermilion.c: use DEFINE_MUTEX (and mutex_init() had been too late)
Signed-off-by: Zheng Yongjun --- drivers/video/fbdev/vermilion/vermilion.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/vermilion/vermilion.c b/drivers/video/fbdev/vermilion/vermilion.c index ff61605b8764..cf41f3c50af8 100644 --- a/drivers/video/fbdev/vermilion/vermilion.c +++ b/drivers/video/fbdev/vermilion/vermilion.c @@ -35,7 +35,7 @@ #define VML_TOHW(_val, _width) _val) << (_width)) + 0x7FFF - (_val)) >> 16) -static struct mutex vml_mutex; +static DEFINE_MUTEX(vml_mutex); static struct list_head global_no_mode; static struct list_head global_has_mode; static struct fb_ops vmlfb_ops; @@ -1058,7 +1058,6 @@ static int __init vmlfb_init(void) #endif printk(KERN_DEBUG MODULE_NAME ": initializing\n"); - mutex_init(&vml_mutex); INIT_LIST_HEAD(&global_no_mode); INIT_LIST_HEAD(&global_has_mode); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7625: disable regulators when power off
On Wed, Dec 9, 2020 at 12:43 PM Hsin-Yi Wang wrote:
>
> On Mon, Nov 23, 2020 at 11:47 AM Hsin-Yi Wang wrote:
> >
> > When suspending the driver, anx7625_power_standby() will be called to
> > turn off reset-gpios and enable-gpios. However, power supplies are not
> > disabled. To save power, the driver can get the power supply regulators
> > and turn off them in anx7625_power_standby().
> >
> > Signed-off-by: Hsin-Yi Wang
>
> Gentle ping on the patch
>
After some testing, the powering sequence has some issue and would
cause i2c failures. The powering sequence needs to be rechecked.
> > ---
> > Change:
> > v2: none
> > ---
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 25 +++
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 65cc05982f82..eb9c4cc2504a 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -875,12 +876,20 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
> > static void anx7625_power_on(struct anx7625_data *ctx)
> > {
> > struct device *dev = &ctx->client->dev;
> > + int ret;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > return;
> > }
> >
> > + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->pdata.supplies),
> > + ctx->pdata.supplies);
> > + if (ret < 0) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot enable regulators %d\n",
> > ret);
> > + return;
> > + }
> > +
> > /* Power on pin enable */
> > gpiod_set_value(ctx->pdata.gpio_p_on, 1);
> > usleep_range(1, 11000);
> > @@ -894,6 +903,7 @@ static void anx7625_power_on(struct anx7625_data *ctx)
> > static void anx7625_power_standby(struct anx7625_data *ctx)
> > {
> > struct device *dev = &ctx->client->dev;
> > + int ret;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > @@ -904,6 +914,12 @@ static void anx7625_power_standby(struct anx7625_data
> > *ctx)
> > usleep_range(1000, 1100);
> > gpiod_set_value(ctx->pdata.gpio_p_on, 0);
> > usleep_range(1000, 1100);
> > +
> > + ret = regulator_bulk_disable(ARRAY_SIZE(ctx->pdata.supplies),
> > +ctx->pdata.supplies);
> > + if (ret < 0)
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot disable regulators %d\n",
> > ret);
> > +
> > DRM_DEV_DEBUG_DRIVER(dev, "power down\n");
> > }
> >
> > @@ -1742,6 +1758,15 @@ static int anx7625_i2c_probe(struct i2c_client
> > *client,
> > platform->client = client;
> > i2c_set_clientdata(client, platform);
> >
> > + pdata->supplies[0].supply = "vdd10";
> > + pdata->supplies[1].supply = "vdd18";
> > + pdata->supplies[2].supply = "vdd33";
> > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pdata->supplies),
> > + pdata->supplies);
> > + if (ret) {
> > + DRM_DEV_ERROR(dev, "fail to get power supplies: %d\n", ret);
> > + return ret;
> > + }
> > anx7625_init_gpio(platform);
> >
> > atomic_set(&platform->power_status, 0);
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > index 193ad86c5450..e4a086b3a3d7 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > @@ -350,6 +350,7 @@ struct s_edid_data {
> > struct anx7625_platform_data {
> > struct gpio_desc *gpio_p_on;
> > struct gpio_desc *gpio_reset;
> > + struct regulator_bulk_data supplies[3];
> > struct drm_bridge *panel_bridge;
> > int intp_irq;
> > u32 low_power_mode;
> > --
> > 2.29.2.454.gaff20da3a2-goog
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] arm64: dts: mt8192: Add node for the Mali GPU
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https://lore.kernel.org/patchwork/patch/1356037/
[4]https://patchwork.kernel.org/project/linux-mediatek/list/?series=405777
[5]https://lore.kernel.org/patchwork/patch/1356175/
[6]https://patchwork.kernel.org/project/linux-mediatek/patch/1605700894-32699-6-git-send-email-hsin-hsiung.w...@mediatek.com/
[7]https://patchwork.kernel.org/project/linux-mediatek/patch/1608104827-7937-10-git-send-email-hsin-hsiung.w...@mediatek.com/
---
---
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 7 +
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 176
2 files changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 6c1e2b3e8a60..48c0e240dd92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
#include "mt8192.dtsi"
+#include "mt6359.dtsi"
/ {
model = "MediaTek MT8192 evaluation board";
@@ -70,6 +71,12 @@
};
};
+&gpu {
+ supply-names = "mali","sram";
+ mali-supply = <&mt6315_7_vbuck1>;
+ sram-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index d6a4ad242a33..de166ea750af 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -822,6 +822,182 @@
#clock-cells = <1>;
};
+ gpu: mali@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0 0x1300 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ;
+ interrupt-names =
+ "GPU",
+ "MMU",
+ "JOB",
+ "EVENT",
+ "PWR";
+
+ clocks =
+ <&apmixedsys CLK_APMIXED_MFGPLL>,
+ <&topckgen CLK_TOP_MFG_PLL_SEL>,
+ <&topckgen CLK_TOP_MFG_REF_SEL>,
+ <&mfgcfg CLK_MFG_BG3D>;
+ clock-names =
+ "clk_main_parent",
+ "clk_mux",
+ "clk_sub_parent",
+ "subsys_mfg_cg";
+
+ power-domains =
+ <&scpsys MT8192_POWER_DOMAIN_MFG2>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG3>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG4>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG5>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG6>;
+ power-domain-names = "core0",
+"core1",
+"core2",
+"core3",
+"core4";
+
+ operating-points-v2 = <&gpu_opp_table>;
+ #cooling-cells = <2>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+ /bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+ /bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+ <75>;
+ };
+
+ opp-44000 {
+ opp-hz = /bits/ 64 <44000>;
+ opp-hz-real = /bits/ 64 <44000>,
+ /bits/ 64 <44000>;
+ opp-microvolt = <631250>,
+ <75>;
+
[PATCH v5 07/11] dt-bindings: phy: convert MIPI DSI PHY binding to YAML schema
Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Chun-Kuang Hu
---
v5: add Reviewed-by Rob & Chun-Kuang
v4:
1. add maintainer Philipp add support mt8183 suggested by Chun-Kuang
2. use keyword multipleOf suggested by Rob
3. fix typo of 'MIPI' in title
v3: new patch
---
.../display/mediatek/mediatek,dsi.txt | 18 +---
.../bindings/phy/mediatek,dsi-phy.yaml| 85 +++
2 files changed, 86 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index f06f24d405a5..8238a86686be 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -22,23 +22,7 @@ Required properties:
MIPI TX Configuration Module
-The MIPI TX configuration module controls the MIPI D-PHY.
-
-Required properties:
-- compatible: "mediatek,-mipi-tx"
-- the supported chips are mt2701, 7623, mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- clocks: PLL reference clock
-- clock-output-names: name of the output clock line to the DSI encoder
-- #clock-cells: must be <0>;
-- #phy-cells: must be <0>.
-
-Optional properties:
-- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
- the step is 200.
-- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
- unspecified default values shall be used.
-- nvmem-cell-names: Should be "calibration-data"
+See phy/mediatek,dsi-phy.yaml
Example:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
new file mode 100644
index ..71d4acea1f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
+
+maintainers:
+ - Chun-Kuang Hu
+ - Philipp Zabel
+ - Chunfeng Yun
+
+description: The MIPI DSI PHY supports up to 4-lane output.
+
+properties:
+ $nodename:
+pattern: "^dsi-phy@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - mediatek,mt2701-mipi-tx
+ - mediatek,mt7623-mipi-tx
+ - mediatek,mt8173-mipi-tx
+ - mediatek,mt8183-mipi-tx
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PLL reference clock
+
+ clock-output-names:
+maxItems: 1
+
+ "#phy-cells":
+const: 0
+
+ "#clock-cells":
+const: 0
+
+ nvmem-cells:
+maxItems: 1
+description: A phandle to the calibration data provided by a nvmem device,
+ if unspecified, default values shall be used.
+
+ nvmem-cell-names:
+items:
+ - const: calibration-data
+
+ drive-strength-microamp:
+description: adjust driving current
+multipleOf: 200
+minimum: 2000
+maximum: 6000
+default: 4600
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-output-names
+ - "#phy-cells"
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+dsi-phy@10215000 {
+compatible = "mediatek,mt8173-mipi-tx";
+reg = <0x10215000 0x1000>;
+clocks = <&clk26m>;
+clock-output-names = "mipi_tx0_pll";
+drive-strength-microamp = <4000>;
+nvmem-cells= <&mipi_tx_calibration>;
+nvmem-cell-names = "calibration-data";
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
+
+...
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Mon, 2020-12-21 at 12:26 -0700, Rob Herring wrote: > On Wed, Dec 16, 2020 at 05:30:11PM +0800, Chunfeng Yun wrote: > > Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml > > > > Signed-off-by: Chunfeng Yun > > --- > > v4: > > 1. refer to usb-drd.yaml insstead of usb/generic.txt > > the following ones suggested by Rob: > > 2. add the number of phys supported > > 3. fix indentation of wakeup > > 4. add examples for port and connector > > > > v3: > > 1. fix yamllint warning > > 2. remove pinctrl* properties > > 3. remove unnecessary '|' > > 4. drop unused labels in example > > > > v2: new patch > > --- > > .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 --- > > .../bindings/usb/mediatek,mtu3.yaml | 278 ++ > > 2 files changed, 278 insertions(+), 108 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > > [...] > > + > > + power-domains: > > +description: A phandle to USB power domain node to control USB's MTCMOS > > +maxItems: 1 > > + > > + clocks: > > +minItems: 1 > > +maxItems: 4 > > Don't need maxItems here. Ok, will remove it, and apply others > > > +items: > > + - description: Controller clock used by normal mode > > + - description: Reference clock used by low power mode etc > > + - description: Mcu bus clock for register access > > + - description: DMA bus clock for data transfer > > + > > + clock-names: > > +minItems: 1 > > +maxItems: 4 > > +items: > > + - const: sys_ck # required, the following ones are optional > > + - const: ref_ck > > + - const: mcu_ck > > + - const: dma_ck > > + > > + phys: > > +description: List of all the USB PHYs used > > +minItems: 0 > > +maxItems: 9 > > Need to define what each one is. Ok, will do it > > > + > > + vusb33-supply: > > +description: Regulator of USB AVDD3.3v > > + > > + vbus-supply: > > +deprecated: true > > +description: | > > + Regulator of USB VBUS5v, needed when supports dual-role mode. > > + Particularly, if use an output GPIO to control a VBUS regulator, > > should > > + model it as a regulator. See bindings/regulator/fixed-regulator.yaml > > + It's considered valid for compatibility reasons, not allowed for > > + new bindings, and put into a usb-connector node. > > + > > + dr_mode: > > +enum: [host, peripheral, otg] > > +default: otg > > + > > + maximum-speed: > > +enum: [super-speed-plus, super-speed, high-speed, full-speed] > > + > > + "#address-cells": > > +enum: [1, 2] > > + > > + "#size-cells": > > +enum: [1, 2] > > + > > + ranges: true > > + > > + extcon: > > +deprecated: true > > +description: | > > + Phandle to the extcon device detecting the IDDIG/VBUS state, neede > > + when supports dual-role mode. > > + It's considered valid for compatibility reasons, not allowed for > > + new bindings, and use "usb-role-switch" property instead. > > + > > + usb-role-switch: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: Support role switch. > > +type: boolean > > + > > + connector: > > +$ref: /connector/usb-connector.yaml# > > +description: > > + Connector for dual role switch, especially for "gpio-usb-b-connector" > > +type: object > > + > > + port: > > +description: > > + Any connector to the data bus of this controller should be modelled > > + using the OF graph bindings specified, if the "usb-role-switch" > > + property is used. See graph.txt > > +type: object > > + > > + enable-manual-drd: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: > > + supports manual dual-role switch via debugfs; usually used when > > + receptacle is TYPE-A and also wants to support dual-role mode. > > +type: boolean > > + > > + wakeup-source: > > +description: enable USB remote wakeup, see power/wakeup-source.txt > > +type: boolean > > + > > + mediatek,syscon-wakeup: > > +$ref: /schemas/types.yaml#/definitions/phandle-array > > +maxItems: 1 > > +description: > > + A phandle to syscon used to access the register of the USB wakeup > > glue > > + layer between xHCI and SPM, the field should always be 3 cells long. > > +items: > > + items: > > +- description: > > +The first cell represents a phandle to syscon > > +- description: > > +The second cell represents the register base address of the > > glue > > +layer in syscon > > +- description: > > +The third cell represents the hardware version of the glue > > layer, > > +1 is used by mt8173 etc, 2 is used by mt2712 etc > > + enum: [1, 2] > > + > > + mediatek,u3p-dis-msk: > > +$ref: /schemas/types.yaml#/def
Re: [PATCH v2 1/7] iommu/io-pgtable: Introduce dynamic io-pgtable fmt registration
On 2020-12-23 05:44, Robin Murphy wrote:
On 2020-12-22 19:54, isa...@codeaurora.org wrote:
On 2020-12-22 11:27, Robin Murphy wrote:
On 2020-12-22 00:44, Isaac J. Manjarres wrote:
The io-pgtable code constructs an array of init functions for each
page table format at compile time. This is not ideal, as this
increases the footprint of the io-pgtable code, as well as prevents
io-pgtable formats from being built as kernel modules.
In preparation for modularizing the io-pgtable formats, switch to a
dynamic registration scheme, where each io-pgtable format can
register
their init functions with the io-pgtable code at boot or module
insertion time.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 34 +-
drivers/iommu/io-pgtable-arm.c | 90
++--
drivers/iommu/io-pgtable.c | 94
--
include/linux/io-pgtable.h | 51 +
4 files changed, 209 insertions(+), 60 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 1d92ac9..89aad2f 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -835,7 +836,8 @@ static struct io_pgtable
*arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
return NULL;
}
-struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
+static struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
+ .fmt = ARM_V7S,
.alloc = arm_v7s_alloc_pgtable,
.free = arm_v7s_free_pgtable,
};
@@ -982,5 +984,33 @@ static int __init arm_v7s_do_selftests(void)
pr_info("self test ok\n");
return 0;
}
-subsys_initcall(arm_v7s_do_selftests);
+#else
+static int arm_v7s_do_selftests(void)
+{
+ return 0;
+}
#endif
+
+static int __init arm_v7s_init(void)
+{
+ int ret;
+
+ ret = io_pgtable_ops_register(&io_pgtable_arm_v7s_init_fns);
+ if (ret < 0) {
+ pr_err("Failed to register ARM V7S format\n");
Super-nit: I think "v7s" should probably be lowercase there. Also
general consistency WRT to showing the error code and whether or not
to abbreviate "format" would be nice.
Ok, I can fix this accordingly.
+ return ret;
+ }
+
+ ret = arm_v7s_do_selftests();
+ if (ret < 0)
+ io_pgtable_ops_unregister(&io_pgtable_arm_v7s_init_fns);
+
+ return ret;
+}
+core_initcall(arm_v7s_init);
+
+static void __exit arm_v7s_exit(void)
+{
+ io_pgtable_ops_unregister(&io_pgtable_arm_v7s_init_fns);
+}
+module_exit(arm_v7s_exit);
diff --git a/drivers/iommu/io-pgtable-arm.c
b/drivers/iommu/io-pgtable-arm.c
index 87def58..ff0ea2f 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1043,29 +1044,32 @@ arm_mali_lpae_alloc_pgtable(struct
io_pgtable_cfg *cfg, void *cookie)
return NULL;
}
-struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
- .alloc = arm_64_lpae_alloc_pgtable_s1,
- .free = arm_lpae_free_pgtable,
-};
-
-struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
- .alloc = arm_64_lpae_alloc_pgtable_s2,
- .free = arm_lpae_free_pgtable,
-};
-
-struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
- .alloc = arm_32_lpae_alloc_pgtable_s1,
- .free = arm_lpae_free_pgtable,
-};
-
-struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
- .alloc = arm_32_lpae_alloc_pgtable_s2,
- .free = arm_lpae_free_pgtable,
-};
-
-struct io_pgtable_init_fns io_pgtable_arm_mali_lpae_init_fns = {
- .alloc = arm_mali_lpae_alloc_pgtable,
- .free = arm_lpae_free_pgtable,
+static struct io_pgtable_init_fns io_pgtable_arm_lpae_init_fns[] =
{
+ {
+ .fmt = ARM_32_LPAE_S1,
+ .alloc = arm_32_lpae_alloc_pgtable_s1,
+ .free = arm_lpae_free_pgtable,
+ },
+ {
+ .fmt = ARM_32_LPAE_S2,
+ .alloc = arm_32_lpae_alloc_pgtable_s2,
+ .free = arm_lpae_free_pgtable,
+ },
+ {
+ .fmt = ARM_64_LPAE_S1,
+ .alloc = arm_64_lpae_alloc_pgtable_s1,
+ .free = arm_lpae_free_pgtable,
+ },
+ {
+ .fmt = ARM_64_LPAE_S2,
+ .alloc = arm_64_lpae_alloc_pgtable_s2,
+ .free = arm_lpae_free_pgtable,
+ },
+ {
+ .fmt = ARM_MALI_LPAE,
+ .alloc = arm_mali_lpae_alloc_pgtable,
+ .free = arm_lpae_free_pgtable,
+ },
};
#ifdef CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST
@@ -1250,5 +1254,43 @@ static int __init arm_lpae_do_selftests(void)
pr_info("selftest: completed with %d PASS %d FAIL\n", pass,
fail);
return fail ? -EFAULT : 0;
}
-subsys_initcall(arm_lpae_do_selftests);
+#else
+static int __init arm_lpae_do_selftests(void)
+{
+
[PATCH v5 02/11] dt-bindings: net: btusb: change reference file name
Due to usb-device.txt is converted into usb-device.yaml, so modify reference file names at the same time. Signed-off-by: Chunfeng Yun Acked-by: Rob Herring --- v5: add Acked-by Rob v2~v4: no changes --- Documentation/devicetree/bindings/net/btusb.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt index b1ad6ee68e90..a9c3f4277f69 100644 --- a/Documentation/devicetree/bindings/net/btusb.txt +++ b/Documentation/devicetree/bindings/net/btusb.txt @@ -4,7 +4,7 @@ Generic Bluetooth controller over USB (btusb driver) Required properties: - compatible : should comply with the format "usbVID,PID" specified in -Documentation/devicetree/bindings/usb/usb-device.txt +Documentation/devicetree/bindings/usb/usb-device.yaml At the time of writing, the only OF supported devices (more may be added later) are: -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/11] dt-bindings: usb: convert mediatek, musb.txt to YAML schema
Convert mediatek,musb.txt to YAML schema mediatek,musb.yaml
Cc: Min Guo
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
---
v4~v5: no changes
v3: add Reviewed-by Rob
v2: new patch
---
.../devicetree/bindings/usb/mediatek,musb.txt | 57 -
.../bindings/usb/mediatek,musb.yaml | 113 ++
2 files changed, 113 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
deleted file mode 100644
index 5eedb0296562..
--- a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-MediaTek musb DRD/OTG controller
-
-Required properties:
- - compatible : should be one of:
- "mediatek,mt2701-musb"
- ...
- followed by "mediatek,mtk-musb"
- - reg : specifies physical base address and size of
- the registers
- - interrupts : interrupt used by musb controller
- - interrupt-names : must be "mc"
- - phys: PHY specifier for the OTG phy
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
- - clocks : a list of phandle + clock-specifier pairs, one for
- each entry in clock-names
- - clock-names : must contain "main", "mcu", "univpll"
- for clocks of controller
-
-Optional properties:
- - power-domains : a phandle to USB power domain node to control USB's
- MTCMOS
-
-Required child nodes:
- usb connector node as defined in bindings/connector/usb-connector.yaml
-Optional properties:
- - id-gpios: input GPIO for USB ID pin.
- - vbus-gpios : input GPIO for USB VBUS pin.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode
- - usb-role-switch : use USB Role Switch to support dual-role switch, see
- usb/generic.txt.
-
-Example:
-
-usb2: usb@1120 {
- compatible = "mediatek,mt2701-musb",
-"mediatek,mtk-musb";
- reg = <0 0x1120 0 0x1000>;
- interrupts = ;
- interrupt-names = "mc";
- phys = <&u2port2 PHY_TYPE_USB2>;
- dr_mode = "otg";
- clocks = <&pericfg CLK_PERI_USB0>,
-<&pericfg CLK_PERI_USB0_MCU>,
-<&pericfg CLK_PERI_USB_SLV>;
- clock-names = "main","mcu","univpll";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
- usb-role-switch;
- connector{
- compatible = "gpio-usb-b-connector", "usb-b-connector";
- type = "micro";
- id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
- vbus-supply = <&usb_vbus>;
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
new file mode 100644
index ..790efe8b6274
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/mediatek,musb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MUSB DRD/OTG Controller Device Tree Bindings
+
+maintainers:
+ - Min Guo
+
+properties:
+ $nodename:
+pattern: '^usb@[0-9a-f]+$'
+
+ compatible:
+items:
+ - enum:
+ - mediatek,mt2701-musb
+ - const: mediatek,mtk-musb
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+items:
+ - const: mc
+
+ clocks:
+items:
+ - description: The main/core clock
+ - description: The system bus clock
+ - description: The 48Mhz clock
+
+ clock-names:
+items:
+ - const: main
+ - const: mcu
+ - const: univpll
+
+ phys:
+maxItems: 1
+
+ usb-role-switch:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Support role switch. See usb/generic.txt
+type: boolean
+
+ dr_mode:
+enum:
+ - host
+ - otg
+ - peripheral
+
+ power-domains:
+description: A phandle to USB power domain node to control USB's MTCMOS
+maxItems: 1
+
+ connector:
+$ref: /connector/usb-connector.yaml#
+description: Connector for dual role switch
+type: object
+
+dependencies:
+ usb-role-switch: [ 'connector' ]
+ connector: [ 'usb-role-switch' ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - phys
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+#include
+
+
[PATCH 1/2] drivers/gpu/drm/ast: Fix infinite loop if read fails
[Why] Similar to commit <298360af3> ast_init_dram_reg() configures a window in
order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.
[How]
Fix this by erroring out if an error is detected.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/ast/ast_post.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 8902c2f..ef19c70 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -287,7 +287,9 @@ static void ast_init_dram_reg(struct drm_device *dev)
ast_write32(ast, 0x10100, 0xa8);
do {
- ;
+ if (pci_channel_offline(dev->pdev))
+ return -EIO;
+
} while (ast_read32(ast, 0x10100) != 0xa8);
} else {/* AST2100/1100 */
if (ast->chip == AST2100 || ast->chip == 2200)
@@ -299,12 +301,14 @@ static void ast_init_dram_reg(struct drm_device *dev)
ast_write32(ast, 0xf000, 0x1);
ast_write32(ast, 0x12000, 0x1688A8A8);
do {
- ;
+ if (pci_channel_offline(dev->pdev))
+return -EIO;
} while (ast_read32(ast, 0x12000) != 0x01);
ast_write32(ast, 0x1, 0xfc600309);
do {
- ;
+ if (pci_channel_offline(dev->pdev))
+return -EIO;
} while (ast_read32(ast, 0x1) != 0x01);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drivers/gpu/drm/ast: Fix infinite loop if read fails
[Why] Similar to commit <298360af3> ast_init_dram_reg() configures a window in
order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.
[How]
Fix this by erroring out if an error is detected.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/ast/ast_post.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index ef19c70..86e4d23 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -302,13 +302,13 @@ static void ast_init_dram_reg(struct drm_device *dev)
ast_write32(ast, 0x12000, 0x1688A8A8);
do {
if (pci_channel_offline(dev->pdev))
-return -EIO;
+ return -EIO;
} while (ast_read32(ast, 0x12000) != 0x01);
ast_write32(ast, 0x1, 0xfc600309);
do {
if (pci_channel_offline(dev->pdev))
-return -EIO;
+ return -EIO;
} while (ast_read32(ast, 0x1) != 0x01);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/amdgpu: use GTT for uvd_get_create/destory_msg
On modern gpus, GTT (system memory) works as well here, and this may also be a workaround for platforms which cannot map vram correctly. Signed-off-by: chenli Reviewed-by: Christian König --- v1->v2: no change --- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c index 8b989670ed66..e2ed4689118a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c @@ -1170,7 +1170,7 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring, uint32_t handle, int r, i; r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE, - AMDGPU_GEM_DOMAIN_VRAM, + AMDGPU_GEM_DOMAIN_GTT, &bo, NULL, (void **)&msg); if (r) return r; @@ -1202,7 +1202,7 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring, uint32_t handle, int r, i; r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE, - AMDGPU_GEM_DOMAIN_VRAM, + AMDGPU_GEM_DOMAIN_GTT, &bo, NULL, (void **)&msg); if (r) return r; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
On 23-12-20, 23:37, Dmitry Osipenko wrote: > 23.12.2020 08:57, Viresh Kumar пишет: > > What's wrong with getting the regulator in the driver as well ? Apart from > > the > > OPP core ? > > The voltage syncing should be done for each consumer regulator > individually [1]. > > Secondly, regulator core doesn't work well today if the same regulator > is requested more than one time for the same device. Hmm... > >> will return the OPP table regulator in order to allow driver to use the > >> regulator directly. But I'm not sure whether this is a much better > >> option than the opp_sync_regulators() and opp_set_voltage() APIs. > > > > set_voltage() is still fine as there is some data that the OPP core has, but > > sync_regulator() has nothing to do with OPP core. > > > > And this may lead to more wrapper helpers in the OPP core, which I am > > afraid of. > > And so even if it is not the best, I would like the OPP core to provide the > > data > > and not get into this. Ofcourse there is an exception to this, opp_set_rate. > > > > The regulator_sync_voltage() should be invoked only if voltage was > changed previously [1]. > > The OPP core already has the info about whether voltage was changed and > it provides the necessary locking for both set_voltage() and > sync_regulator(). Perhaps I'll need to duplicate that functionality in > the PD driver, instead of making it all generic and re-usable by other > drivers. > > [1] > https://elixir.bootlin.com/linux/v5.10.2/source/drivers/regulator/core.c#L4107 Lets do it in the OPP core and see where we go. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/48] opp: Support set_opp() customization without requiring to use regulators
24.12.2020 07:10, Viresh Kumar пишет: > On 23-12-20, 23:38, Dmitry Osipenko wrote: >> Well, there is no "same structure", the opp_table->set_opp_data is NULL >> there. > > Right, I saw that yesterday. What I meant was that we need to start allocating > the structure for this case now. > Okay, that will be a bit bigger change than this v2. I'll try it implement yours suggestion in the next revision, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 04/11] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring --- v5: no changes v4: add Reviewed-by Rob v3: 1. fix dt_binding_check error in example after add mtu3.yaml Changes suggested by Rob: 2. fix wrong indentation 3. remove '|' due to no formatting to preserve 4. add a space after '#' 5. drop unused labels and status in examples 6. modify file mode v2: 1. modify description and compatible --- .../bindings/phy/mediatek,tphy.yaml | 260 ++ .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- 2 files changed, 260 insertions(+), 162 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml new file mode 100644 index ..602e6ff45785 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -0,0 +1,260 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek T-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The T-PHY controller supports physical layer functionality for a number of + controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. + + Layout differences of banks between T-PHY V1 (mt8173/mt2701) and + T-PHY V2 (mt2712) when works on USB mode: + --- + Version 1: + portoffsetbank + shared 0xSPLLC + 0x0100FMREG + u2 port00x0800U2PHY_COM + u3 port00x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000U2PHY_COM + u3 port10x1100U3PHYD + 0x1200U3PHYD_BANK2 + 0x1300U3PHYA + 0x1400U3PHYA_DA + u2 port20x1800U2PHY_COM + ... + + Version 2: + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u3 port00x0700SPLLC + 0x0800CHIP + 0x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u3 port10x1700SPLLC + 0x1800CHIP + 0x1900U3PHYD + 0x1a00U3PHYD_BANK2 + 0x1b00U3PHYA + 0x1c00U3PHYA_DA + u2 port20x2000MISC + ... + + SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back + into each port; a new bank MISC for u2 ports and CHIP for u3 ports are + added on V2. + +properties: + $nodename: +pattern: "^t-phy@[0-9a-f]+$" + + compatible: +oneOf: + - items: + - enum: + - mediatek,mt2701-tphy + - mediatek,mt7623-tphy + - mediatek,mt7622-tphy + - mediatek,mt8516-tphy + - const: mediatek,generic-tphy-v1 + - items: + - enum: + - mediatek,mt2712-tphy + - mediatek,mt7629-tphy + - mediatek,mt8183-tphy + - const: mediatek,generic-tphy-v2 + - const: mediatek,mt2701-u3phy +deprecated: true + - const: mediatek,mt2712-u3phy +deprecated: true + - const: mediatek,mt8173-u3phy + + reg: +description: + Register shared by multiple ports, exclude port's private register. + It is needed for T-PHY V1, such as mt2701 and mt8173, but not for + T-PHY V2, such as mt2712. +maxItems: 1 + + "#address-cells": +enum: [1, 2] + + "#size-cells": +enum: [1, 2] + + # Used with non-empty value if optional 'reg' is not provided. + # The format of the value is an arbitrary number of triplets of + # (child-bus-address, parent-bus-address, length). + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 28 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +minItems: 1 +
Re: [PATCH v2, 3/3] mailbox: cmdq: add mt8192 support
On Thu, 2020-12-24 at 22:28 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2020年12月24日 週四 上午8:55寫道：
> >
> > add mt8192 support
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > index 75378e3..7f243e1 100644
> > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > @@ -607,6 +607,7 @@ static int cmdq_probe(struct platform_device *pdev)
> > {.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
> > {.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
> > {.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
> > + {.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v4},
>
> In the view of hardware function, is mt8192-gce identical to
> mt6779-gce? If these two are identical, you need not to modify driver,
> and the compatible should be
>
> compatible = "mediatek,mt8192-gce", "mediatek,mt6779-gce";
>
> If they are not identical, what's the different?
>
> Regards,
> Chun-Kuang.
irq id is different
mt8192 dts
https://patchwork.kernel.org/project/linux-mediatek/patch/1608770889-9403-3-git-send-email-yongqiang@mediatek.com/
mt6779 dts
https://patchwork.kernel.org/project/linux-mediatek/patch/1574327552-11806-6-git-send-email-dennis-yc.hs...@mediatek.com/
and gce event id also different
https://patchwork.kernel.org/project/linux-mediatek/patch/1608770889-9403-2-git-send-email-yongqiang@mediatek.com/
https://patchwork.kernel.org/project/linux-mediatek/patch/1574327552-11806-2-git-send-email-dennis-yc.hs...@mediatek.com/
>
> > {}
> > };
> >
> > --
> > 1.8.1.1.dirty
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 -next] video: backlight: use DEFINE_MUTEX() for mutex lock
mutex lock can be initialized automatically with DEFINE_MUTEX()
rather than explicitly calling mutex_init().
Signed-off-by: Zheng Yongjun
---
drivers/video/backlight/backlight.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 537fe1b376ad..d7a09c422547 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -64,7 +64,7 @@
*/
static struct list_head backlight_dev_list;
-static struct mutex backlight_dev_list_mutex;
+static DEFINE_MUTEX(backlight_dev_list_mutex);
static struct blocking_notifier_head backlight_notifier;
static const char *const backlight_types[] = {
@@ -757,7 +757,6 @@ static int __init backlight_class_init(void)
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
INIT_LIST_HEAD(&backlight_dev_list);
- mutex_init(&backlight_dev_list_mutex);
BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
return 0;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/11] dt-bindings: phy: convert phy-mtk-ufs.txt to YAML schema
Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
Cc: Stanley Chu
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Stanley Chu
---
v5: no changes
v4: add Reviewed-by Stanley
v3: add Reviewed-by Rob
v2: fix binding check warning of reg in example
---
.../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
.../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 ---
2 files changed, 64 insertions(+), 38 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
diff --git a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
new file mode 100644
index ..3a9be82e7f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,ufs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Universal Flash Storage (UFS) M-PHY binding
+
+maintainers:
+ - Stanley Chu
+ - Chunfeng Yun
+
+description: |
+ UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
+ Each UFS M-PHY node should have its own node.
+ To bind UFS M-PHY with UFS host controller, the controller node should
+ contain a phandle reference to UFS M-PHY node.
+
+properties:
+ $nodename:
+pattern: "^ufs-phy@[0-9a-f]+$"
+
+ compatible:
+const: mediatek,mt8183-ufsphy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Unipro core control clock.
+ - description: M-PHY core control clock.
+
+ clock-names:
+items:
+ - const: unipro
+ - const: mp
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ufsphy: ufs-phy@11fa {
+compatible = "mediatek,mt8183-ufsphy";
+reg = <0x11fa 0xc000>;
+clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
+ <&infracfg CLK_INFRA_UFS_MP_SAP_BCLK>;
+clock-names = "unipro", "mp";
+#phy-cells = <0>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
b/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
deleted file mode 100644
index 5789029a1d42..
--- a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-MediaTek Universal Flash Storage (UFS) M-PHY binding
-
-
-UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
-Each UFS M-PHY node should have its own node.
-
-To bind UFS M-PHY with UFS host controller, the controller node should
-contain a phandle reference to UFS M-PHY node.
-
-Required properties for UFS M-PHY nodes:
-- compatible : Compatible list, contains the following controller:
- "mediatek,mt8183-ufsphy" for ufs phy
- persent on MT81xx chipsets.
-- reg: Address and length of the UFS M-PHY register set.
-- #phy-cells : This property shall be set to 0.
-- clocks : List of phandle and clock specifier pairs.
-- clock-names: List of clock input name strings sorted in the same
- order as the clocks property. Following clocks are
- mandatory.
- "unipro": Unipro core control clock.
- "mp": M-PHY core control clock.
-
-Example:
-
- ufsphy: phy@11fa {
- compatible = "mediatek,mt8183-ufsphy";
- reg = <0 0x11fa 0 0xc000>;
- #phy-cells = <0>;
-
- clocks = <&infracfg_ao INFRACFG_AO_UNIPRO_SCK_CG>,
-<&infracfg_ao INFRACFG_AO_UFS_MP_SAP_BCLK_CG>;
- clock-names = "unipro", "mp";
- };
-
- ufshci@1127 {
- ...
- phys = <&ufsphy>;
- };
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 10/11] dt-bindings: usb: convert mediatek, mtu3.txt to YAML schema
Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob
1. remove unnecessary maxItems
2. define all phys supported
v4:
1. refer to usb-drd.yaml insstead of usb/generic.txt
the following ones suggested by Rob:
2. add the number of phys supported
3. fix indentation of wakeup
4. add examples for port and connector
v3:
1. fix yamllint warning
2. remove pinctrl* properties
3. remove unnecessary '|'
4. drop unused labels in example
v2: new patch
---
.../devicetree/bindings/usb/mediatek,mtu3.txt | 108 ---
.../bindings/usb/mediatek,mtu3.yaml | 287 ++
2 files changed, 287 insertions(+), 108 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
deleted file mode 100644
index a82ca438aec1..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-The device node for Mediatek USB3.0 DRD controller
-
-Required properties:
- - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
- soc-model is the name of SoC, such as mt8173, mt2712 etc,
- when using "mediatek,mtu3" compatible string, you need SoC specific
- ones in addition, one of:
- - "mediatek,mt8173-mtu3"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for device IP and "ippc" for IP port control
- - interrupts : interrupt used by the device IP
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller,
- the following clocks are optional:
- "ref_ck", "mcu_ck" and "dma_ck";
- - phys : see usb-hcd.yaml in the current directory
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
-
-Optional properties:
- - #address-cells, #size-cells : should be '2' if the device has sub-nodes
- with 'reg' property
- - ranges : allows valid 1:1 translation between child's address space and
- parent's address space
- - extcon : external connector for vbus and idpin changes detection, needed
- when supports dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and use "usb-role-switch" property instead.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and put into a usb-connector node.
- see connector/usb-connector.yaml.
- - pinctrl-names : a pinctrl state named "default" is optional, and need be
- defined if auto drd switch is enabled, that means the property dr_mode
- is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
- is not set.
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
- - maximum-speed : valid arguments are "super-speed", "high-speed" and
- "full-speed"; refer to usb/generic.txt
- - usb-role-switch : use USB Role Switch to support dual-role switch, but
- not extcon; see usb/generic.txt.
- - enable-manual-drd : supports manual dual-role switch via debugfs; usually
- used when receptacle is TYPE-A and also wants to support dual-role
- mode.
- - wakeup-source: enable USB remote wakeup of host mode.
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between SSUSB and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Sub-nodes:
-The xhci should be added as subnode to mtu3 as shown in the following example
-if host mode is enabled. The DT binding details of xhci can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
-
-The port would be added as subnode if use "usb-role-switch" property.
- see graph.txt
-
-Example:
-ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
- reg = <0 0x11271000 0 0x3000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- phys = <&phy_port0 PH
[PATCH v5 03/11] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring --- v5: no changes v4: add Reviewed-by Rob v3: 1. remove type for property with standard unit suffix suggested by Rob 2. remove '|' for descritpion 3. fix yamllint warning v2: 1. modify description and compatible definition suggested by Rob --- .../bindings/phy/mediatek,xsphy.yaml | 199 ++ .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- 2 files changed, 199 insertions(+), 109 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml new file mode 100644 index ..598fd2b95c29 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek XS-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The XS-PHY controller supports physical layer functionality for USB3.1 + GEN2 controller on MediaTek SoCs. + + Banks layout of xsphy + -- + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u2 port20x2000MISC + ... + u31 common 0x3000DIG_GLB + 0x3100PHYA_GLB + u31 port0 0x3400DIG_LN_TOP + 0x3500DIG_LN_TX0 + 0x3600DIG_LN_RX0 + 0x3700DIG_LN_DAIF + 0x3800PHYA_LN + u31 port1 0x3a00DIG_LN_TOP + 0x3b00DIG_LN_TX0 + 0x3c00DIG_LN_RX0 + 0x3d00DIG_LN_DAIF + 0x3e00PHYA_LN + ... + DIG_GLB & PHYA_GLB are shared by U31 ports. + +properties: + $nodename: +pattern: "^xs-phy@[0-9a-f]+$" + + compatible: +items: + - enum: + - mediatek,mt3611-xsphy + - mediatek,mt3612-xsphy + - const: mediatek,xsphy + + reg: +description: + Register shared by multiple U3 ports, exclude port's private register, + if only U2 ports provided, shouldn't use the property. +maxItems: 1 + + "#address-cells": +enum: [1, 2] + + "#size-cells": +enum: [1, 2] + + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 17 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +items: + - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) + + clock-names: +items: + - const: ref + + "#phy-cells": +const: 1 +description: | + The cells contain the following arguments. + + - description: The PHY type + enum: +- PHY_TYPE_USB2 +- PHY_TYPE_USB3 + + # The following optional vendor properties are only for debug or HQA test + mediatek,eye-src: +description: + The value of slew rate calibrate (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-vrt: +description: + The selection of VRT reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-term: +description: + The selection of HS_TX TERM reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,efuse-intr: +description: + The selection of Internal Resistor (U2/U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 63 + + mediatek,efuse-tx-imp: +description: + The selection of TX Impedance (U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 31 + + mediatek,efuse-rx-imp: +descripti
[PATCH v2 -next] vermilion.c: use DEFINE_MUTEX() for mutex lock
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init(). Signed-off-by: Zheng Yongjun --- drivers/video/fbdev/vermilion/vermilion.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/vermilion/vermilion.c b/drivers/video/fbdev/vermilion/vermilion.c index ff61605b8764..cf41f3c50af8 100644 --- a/drivers/video/fbdev/vermilion/vermilion.c +++ b/drivers/video/fbdev/vermilion/vermilion.c @@ -35,7 +35,7 @@ #define VML_TOHW(_val, _width) _val) << (_width)) + 0x7FFF - (_val)) >> 16) -static struct mutex vml_mutex; +static DEFINE_MUTEX(vml_mutex); static struct list_head global_no_mode; static struct list_head global_has_mode; static struct fb_ops vmlfb_ops; @@ -1058,7 +1058,6 @@ static int __init vmlfb_init(void) #endif printk(KERN_DEBUG MODULE_NAME ": initializing\n"); - mutex_init(&vml_mutex); INIT_LIST_HEAD(&global_no_mode); INIT_LIST_HEAD(&global_has_mode); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2, 3/3] mailbox: cmdq: add mt8192 support
add mt8192 support
Signed-off-by: Yongqiang Niu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 75378e3..7f243e1 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -607,6 +607,7 @@ static int cmdq_probe(struct platform_device *pdev)
{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
{.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
+ {.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v4},
{}
};
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: bcm2835-vec: Add power-domains property
On 12/23/2020 11:24 AM, Stefan Wahren wrote: > Adding the missing property power-domains to the bcm2835-vec schema to fix > the following dtbs_check issue: > > vec@7e806000: 'power-domains' does not match any of the regexes: ... > > Signed-off-by: Stefan Wahren Acked-by: Florian Fainelli -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/stm: Fix bus_flags handling
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set,
and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
DISPLAY_FLAGS_DE_HIGH were always set.
The fix for this problem is taken almost verbatim from MXSFB driver. In
case there is a bridge attached to the LTDC, the bridge might have extra
polarity requirements, so extract bus_flags from the bridge and use them
for LTDC configuration. Otherwise, extract bus_flags from the connector,
which is the display.
Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
Signed-off-by: Marek Vasut
Cc: Alexandre Torgue
Cc: Antonio Borneo
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Philippe Cornu
Cc: Sam Ravnborg
Cc: Vincent Abriou
Cc: Yannick Fertre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
To: dri-devel@lists.freedesktop.org
---
V2: Check if ldev->bridge->timings is non-NULL before accessing it
---
drivers/gpu/drm/stm/ltdc.c | 22 --
drivers/gpu/drm/stm/ltdc.h | 2 ++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 1c9f18b4adfc..22c7e9fa5ab7 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -546,11 +546,17 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct drm_device *ddev = crtc->dev;
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
+ u32 bus_flags = 0;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
u32 val;
int ret;
+ if (ldev->bridge && ldev->bridge->timings)
+ bus_flags = ldev->bridge->timings->input_bus_flags;
+ else if (ldev->connector)
+ bus_flags = ldev->connector->display_info.bus_flags;
+
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);
if (ret) {
@@ -586,10 +592,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
- if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ if (bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= GCR_DEPOL;
- if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
val |= GCR_PCPOL;
reg_update_bits(ldev->regs, LTDC_GCR,
@@ -1098,6 +1104,8 @@ static const struct drm_encoder_helper_funcs
ltdc_encoder_helper_funcs = {
static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge
*bridge)
{
+ struct ltdc_device *ldev = ddev->dev_private;
+ struct drm_connector_list_iter iter;
struct drm_encoder *encoder;
int ret;
@@ -1119,6 +1127,16 @@ static int ltdc_encoder_init(struct drm_device *ddev,
struct drm_bridge *bridge)
return -EINVAL;
}
+ ldev->bridge = bridge;
+
+ /*
+* Get hold of the connector. This is a bit of a hack, until the bridge
+* API gives us bus flags and formats.
+*/
+ drm_connector_list_iter_begin(ddev, &iter);
+ ldev->connector = drm_connector_list_iter_next(&iter);
+ drm_connector_list_iter_end(&iter);
+
DRM_DEBUG_DRIVER("Bridge encoder:%d created\n", encoder->base.id);
return 0;
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index f153b908c70e..d0d2c81de29a 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -38,6 +38,8 @@ struct ltdc_device {
u32 irq_status;
struct fps_info plane_fpsi[LTDC_MAX_LAYER];
struct drm_atomic_state *suspend_state;
+ struct drm_bridge *bridge;
+ struct drm_connector *connector;
};
int ltdc_load(struct drm_device *ddev);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
On Mon, 2020-12-21 at 12:09 -0700, Rob Herring wrote:
> On Wed, Dec 16, 2020 at 05:30:02PM +0800, Chunfeng Yun wrote:
> > Convert usb-device.txt to YAML schema usb-device.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v4: no changes, update dependent series:
> > https://patchwork.kernel.org/project/linux-usb/list/?series=399561
> > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT
> > schema
[...]
> > diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml
> > b/Documentation/devicetree/bindings/usb/usb-device.yaml
> > new file mode 100644
> > index ..f31d8a85d3e6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/usb-device.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/usb/usb-device.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: The device tree bindings for the Generic USB Device
> > +
> > +maintainers:
> > + - Greg Kroah-Hartman
> > +
> > +description: |
> > + Usually, we only use device tree for hard wired USB device.
> > + The reference binding doc is from:
> > + http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
> > +
> > + Four types of device-tree nodes are defined: "host-controller nodes"
> > + representing USB host controllers, "device nodes" representing USB
> > devices,
> > + "interface nodes" representing USB interfaces and "combined nodes"
> > + representing simple USB devices.
> > +
> > + A combined node shall be used instead of a device node and an interface
> > node
> > + for devices of class 0 or 9 (hub) with a single configuration and a
> > single
> > + interface.
> > +
> > + A "hub node" is a combined node or an interface node that represents a
> > USB
> > + hub.
> > +
> > +properties:
> > + compatible:
> > +pattern: "^usb[0-9a-f]+,[0-9a-f]+$"
>
> You can refine the length allowed a bit: [0-9a-f]{1,4}
>
> Same applies elsewhere.
Ok
>
> > +description: Device nodes or combined nodes.
> > + "usbVID,PID", where VID is the vendor id and PID the product id.
> > + The textual representation of VID and PID shall be in lower case
> > + hexadecimal with leading zeroes suppressed. The other compatible
> > + strings from the above standard binding could also be used,
> > + but a device adhering to this binding may leave out all except
> > + for "usbVID,PID".
> > +
[...]
> > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > index 9881ac10380d..5d0c6b5500d6 100755
> > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > @@ -23,6 +23,32 @@ properties:
> >targeted hosts (non-PC hosts).
> > type: boolean
> >
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > +patternProperties:
> > + "@[0-9a-f]+$":
> > +type: object
> > +description: The hard wired USB devices
> > +
> > +properties:
> > + compatible:
> > +pattern: "^usb[0-9a-f]+,[0-9a-f]+$"
> > +$ref: /usb/usb-device.yaml
>
> This is wrong. It should be up a level.
Ok
> And no need to define
> 'compatible' or 'reg' here because those are defined within
> usb-device.yaml.
will drop it
>
> > +description: the string is 'usbVID,PID', where VID is the vendor id
> > + and PID is the product id
> > +
> > + reg:
> > +$ref: /usb/usb-device.yaml
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > additionalProperties: true
> >
> > examples:
> > @@ -30,4 +56,11 @@ examples:
> > usb {
> > phys = <&usb2_phy1>, <&usb3_phy1>;
> > phy-names = "usb";
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +hub@1 {
> > +compatible = "usb5e3,610";
> > +reg = <1>;
> > +};
> > };
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 11/11] MAINTAINERS: update MediaTek PHY/USB entry
Due to the phy/usb bindings are converted into YAML schema and also renamed, update entries. Meanwhile add drivers/usb/host/mtk-xhci* files. Signed-off-by: Chunfeng Yun --- v3~v5: no changes v2: new patch --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..360c6131b866 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2084,7 +2084,7 @@ M:Chunfeng Yun L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained -F: Documentation/devicetree/bindings/phy/phy-mtk-* +F: Documentation/devicetree/bindings/phy/mediatek,* F: drivers/phy/mediatek/ ARM/Microchip (AT91) SoC support @@ -11139,6 +11139,8 @@ L: linux-...@vger.kernel.org L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained +F: Documentation/devicetree/bindings/usb/mediatek,* +F: drivers/usb/host/xhci-mtk* F: drivers/usb/mtu3/ MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omapdrm: don't deref error pointer in the omap_fbdev_create error path
From: bodefang
Similar to commit <789d4c300>("drm/msm: don't deref error pointer in the
msm_fbdev_create error path")
the error pointer returned by omap_framebuffer_init gets passed to
drm_framebuffer_remove.
The latter handles only Null pointers,thus a nasty crash will occur.
Signed-off-by: bodefang
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 3f6cfc2..372afd4 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -141,8 +141,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
* to unref the bo:
*/
drm_gem_object_put(fbdev->bo);
- ret = PTR_ERR(fb);
- goto fail;
+ return PTR_ERR(fb);
}
/* note: this keeps the bo pinned.. which is perhaps not ideal,
@@ -200,10 +199,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
fail:
- if (ret) {
- if (fb)
- drm_framebuffer_remove(fb);
- }
+ drm_framebuffer_remove(fb);
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: avoid null pointer dereference in dm_set_vblank
[Why]
Similar to commit("drm/amd/display: Guard against null crtc in CRC
IRQ"),
a null pointer deference can occur if crtc is null in
dm_set_vblank.
[How]
Check that CRTC is non-null before accessing its fields.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e2b23486..df23d28 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4875,10 +4875,17 @@ static inline int dm_set_vupdate_irq(struct drm_crtc
*crtc, bool enable)
static inline int dm_set_vblank(struct drm_crtc *crtc, bool enable)
{
enum dc_irq_source irq_source;
- struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
- struct amdgpu_device *adev = drm_to_adev(crtc->dev);
- struct dm_crtc_state *acrtc_state = to_dm_crtc_state(crtc->state);
+ struct amdgpu_crtc *acrtc;
+ struct amdgpu_device *adev;
+ struct dm_crtc_state *acrtc_state;
int rc = 0;
+
+ if (crtc == NULL)
+ return rc;
+
+ acrtc = to_amdgpu_crtc(crtc);
+ adev = drm_to_adev(crtc->dev);
+ acrtc_state = to_dm_crtc_state(crtc->state);
if (enable) {
/* vblank irq on -> Only need vupdate irq in vrr mode */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/4] dt-bindings: display: Document the Xylon LogiCVC display controller
Hi, On Thu 24 Dec 20, 10:01, Rob Herring wrote: > On Wed, 23 Dec 2020 22:29:44 +0100, Paul Kocialkowski wrote: > > The Xylon LogiCVC is a display controller implemented as programmable > > logic in Xilinx FPGAs. > > > > Signed-off-by: Paul Kocialkowski > > Acked-by: Rob Herring > > --- > > .../display/xylon,logicvc-display.yaml| 313 ++ > > 1 file changed, 313 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/xylon,logicvc-display.example.dt.yaml: > logicvc@43c0: 'display@0' does not match any of the regexes: > '^gpio@[0-9a-f]+$', 'pinctrl-[0-9]+' > From schema: > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml > > See https://patchwork.ozlabs.org/patch/1420307 Just so you know, this specific issue is fixed in patch 2/4. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Convert Arm Mali Valhall GPU to DT schema
On Thu, 24 Dec 2020 20:31:18 +0800, Nick Fan wrote: > Convert the Arm Valhall GPU binding to DT schema format. > > Define a compatible string for the Mali Valhall GPU > for Mediatek's SoC platform. > > Signed-off-by: Nick Fan > --- > .../bindings/gpu/arm,mali-valhall.yaml| 252 ++ > 1 file changed, 252 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/gpu/arm,mali-valhall.yaml# See https://patchwork.ozlabs.org/patch/1420519 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting
On Fri, 25 Dec 2020 19:01:09 +0800, Xin Ji wrote:
> Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> swing setting for adjusting DP tx PHY swing
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 19
> +++
> 1 file changed, 19 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
encoder@58: anx,swing-setting: 'anyOf' conditional failed, one must be fixed:
[[0, 20], [1, 84], [2, 100], [3, 116], [4, 41], [5, 123], [6, 119], [7,
91], [8, 127], [12, 32], [13, 96], [16, 96], [18, 64], [19, 96], [20, 20], [21,
84], [22, 100], [23, 116], [24, 41], [25, 123], [26, 119], [27, 91], [28, 127],
[32, 32], [33, 96], [36, 96], [38, 64], [39, 96]] is too long
[0, 20] is too long
[1, 84] is too long
[2, 100] is too long
[3, 116] is too long
[4, 41] is too long
[5, 123] is too long
[6, 119] is too long
[7, 91] is too long
[8, 127] is too long
[12, 32] is too long
[13, 96] is too long
[16, 96] is too long
[18, 64] is too long
[19, 96] is too long
[20, 20] is too long
[21, 84] is too long
[22, 100] is too long
[23, 116] is too long
[24, 41] is too long
[25, 123] is too long
[26, 119] is too long
[27, 91] is too long
[28, 127] is too long
[32, 32] is too long
[33, 96] is too long
[36, 96] is too long
[38, 64] is too long
[39, 96] is too long
From schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
encoder@58: 'anx,mipi-dpi-in', 'anx,swing-setting' do not match any of the
regexes: '^#.*',
'^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*',
'^(keypad|m25p|max8952|max8997|max8998|mpmc),.*',
'^(pinctrl-single|#pinctrl-single|PowerPC),.*',
'^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*',
'^(simple-audio-card|st-plgpio|st-spics|ts),.*', '^70mai,.*', '^GEFanuc,.*',
'^ORCL,.*', '^SUNW,.*', '^[a-zA-Z0-9#_][a-zA-Z0-9+\\-._@]{0,63}$',
'^[a-zA-Z0-9+\\-._]*@[0-9a-zA-Z,]*$', '^abb,.*', '^abilis,.*', '^abracon,.*',
'^abt,.*', '^acer,.*', '^acme,.*', '^actions,.*', '^active-semi,.*', '^ad,.*',
'^adafruit,.*', '^adapteva,.*', '^adaptrum,.*', '^adh,.*', '^adi,.*',
'^advantech,.*', '^aeroflexgaisler,.*', '^al,.*', '^allegro,.*', '^allo,.*',
'^allwinner,.*', '^alphascale,.*', '^alps,.*', '^alt,.*', '^altr,.*',
'^amarula,.*', '^
amazon,.*', '^amcc,.*', '^amd,.*', '^amediatech,.*', '^amlogic,.*',
'^ampere,.*', '^ampire,.*', '^ams,.*', '^amstaos,.*', '^analogix,.*',
'^andestech,.*', '^anvo,.*', '^apm,.*', '^aptina,.*', '^arasan,.*',
'^archermind,.*', '^arctic,.*', '^arcx,.*', '^aries,.*', '^arm,.*',
'^armadeus,.*', '^arrow,.*', '^artesyn,.*', '^asahi-kasei,.*', '^asc,.*',
'^aspeed,.*', '^asus,.*', '^atlas,.*', '^atmel,.*', '^auo,.*', '^auvidea,.*',
'^avago,.*', '^avia,.*', '^avic,.*', '^avnet,.*', '^awinic,.*', '^axentia,.*',
'^axis,.*', '^azoteq,.*', '^azw,.*', '^baikal,.*', '^bananapi,.*',
'^beacon,.*', '^beagle,.*', '^bhf,.*', '^bitmain,.*', '^boe,.*', '^bosch,.*',
'^boundary,.*', '^brcm,.*', '^broadmobi,.*', '^bticino,.*', '^buffalo,.*',
'^bur,.*', '^calaosystems,.*', '^calxeda,.*', '^caninos,.*', '^capella,.*',
'^cascoda,.*', '^catalyst,.*', '^cavium,.*', '^cdns,.*', '^cdtech,.*',
'^cellwise,.*', '^ceva,.*', '^checkpoint,.*', '^chefree,.*', '^chipidea,.*',
'^chipone,.*', '^chipspark,.*', '^chrontel,.*',
'^chrp,.*', '^chunghwa,.*', '^chuwi,.*', '^ciaa,.*', '^cirrus,.*',
'^cloudengines,.*', '^cnm,.*', '^cnxt,.*', '^colorfly,.*', '^compulab,.*',
'^coreriver,.*', '^corpro,.*', '^cortina,.*', '^cosmic,.*', '^crane,.*',
'^creative,.*', '^crystalfontz,.*', '^csky,.*', '^csq,.*', '^cubietech,.*',
'^cypress,.*', '^cznic,.*', '^dallas,.*', '^dataimage,.*', '^davicom,.*',
'^dell,.*', '^delta,.*', '^denx,.*', '^devantech,.*', '^dfi,.*', '^dh,.*',
'^difrnce,.*', '^digi,.*', '^digilent,.*', '^dioo,.*', '^dlc,.*', '^dlg,.*',
'^dlink,.*', '^dmo,.*', '^domintech,.*', '^dongwoon,.*', '^dptechnics,.*',
'^dragino,.*', '^dserve,.*', '^dynaimage,.*', '^ea,.*', '^ebs-systart,.*',
'^ebv,.*', '^eckelmann,.*', '^edt,.*', '^eeti,.*', '^einfochips,.*',
'^elan,.*', '^element14,.*', '^elgin,.*', '^elida,.*', '^elimo,.*',
'^embest,.*', '^emlid,.*', '^emmicro,.*', '^empire-electronix,.*',
'^emtrion,.*', '^endless,.*', '^ene,.*', '^energymicro,.*', '^engicam,.*',
'^epcos,.*', '^epfl,.*', '^epson,.*', '^esp,.*', '^
est,.*', '^ettus,.*', '^eukrea,.*', '^everest,.*', '^everspin,.*',
