* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-05-29 16:51 UTC (permalink / raw)
To: Bartosz Golaszewski, Sean Wang, John Crispin, Matthias Brugger,
Mark Lee, Jakub Kicinski, David S . Miller
Cc: Stephane Le Provost, Fabien Parent, Pedro Tsai, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, netdev,
linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
On Thu, 28 May 2020 17:45:01 +0200, Bartosz Golaszewski wrote:
> I noticed that oftentimes I use regmap_update_bits() for simple bit
> setting or clearing. In this case the fourth argument is superfluous as
> it's always 0 or equal to the mask argument.
>
> This series proposes to add simple bit operations for setting, clearing
> and testing specific bits with regmap.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: provide helpers for simple bit operations
commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Mark Brown @ 2020-05-29 16:57 UTC (permalink / raw)
To: Bartosz Golaszewski, Sean Wang, John Crispin, Matthias Brugger,
Mark Lee, Jakub Kicinski, David S . Miller
Cc: Stephane Le Provost, Fabien Parent, Pedro Tsai, linux-kernel,
Bartosz Golaszewski, linux-mediatek, Andrew Perepech, netdev,
linux-arm-kernel
In-Reply-To: <159077110913.28779.5053923375043778782.b4-ty@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]
On Fri, May 29, 2020 at 05:52:00PM +0100, Mark Brown wrote:
> [1/1] regmap: provide helpers for simple bit operations
> commit: aa2ff9dbaeddabb5ad166db5f9f1a0580a8bbba8
Let me know if you need a pull request for this, given the merge window
is likely to open over the weekend I figured it's likely too late to
apply the second patch before then.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Lukasz Luba @ 2020-05-29 17:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Vincent Guittot, Kevin Hilman,
Andy Gross, Daniel Lezcano, steven.price, Chanwoo Choi,
Ingo Molnar, dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide,
Daniel Vetter, Linux PM, linux-arm-msm, Sascha Hauer,
Steven Rostedt, moderated list:ARM/Mediatek SoC...,
Matthias Brugger, Linux OMAP Mailing List, Dietmar Eggemann,
Linux ARM, David Airlie, Tomeu Vizoso, Quentin Perret,
Stephen Boyd, Randy Dunlap, Rafael J. Wysocki,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
Sascha Hauer, Sudeep Holla, patrick.bellasi, Shawn Guo
In-Reply-To: <CAJZ5v0g5whSUMkd4majCGj0j9TMeO+fCfhxB6FNWoaLpPsi6UA@mail.gmail.com>
On 5/29/20 5:18 PM, Rafael J. Wysocki wrote:
> On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Hi Rafael,
>>
>>
>> On 5/27/20 10:58 AM, Lukasz Luba wrote:
>>> Hi all,
>>>
>>> Background of this version:
>>> This is the v8 of the patch set and is has smaller scope. I had to split
>>> the series into two: EM changes and thermal changes due to devfreq
>>> dependencies. The patches from v7 9-14 which change devfreq cooling are
>>> going to be sent in separate patch series, just after this set get merged
>>> into mainline. These patches related to EM got acks and hopefully can go
>>> through linux-pm tree. The later thermal patches will go through thermal
>>> tree.
>>>
>>> The idea and purpose of the Energy Model framework changes:
>>> This patch set introduces support for devices in the Energy Model (EM)
>>> framework. It will unify the power model for thermal subsystem. It will
>>> make simpler to add support for new devices willing to use more
>>> advanced features (like Intelligent Power Allocation). Now it should
>>> require less knowledge and effort for driver developer to add e.g.
>>> GPU driver with simple energy model. A more sophisticated energy model
>>> in the thermal framework is also possible, driver needs to provide
>>> a dedicated callback function. More information can be found in the
>>> updated documentation file.
>>>
>>> First 7 patches are refactoring Energy Model framework to add support
>>> of other devices that CPUs. They change:
>>> - naming convention from 'capacity' to 'performance' state,
>>> - API arguments adding device pointer and not rely only on cpumask,
>>> - change naming when 'cpu' was used, now it's a 'device'
>>> - internal structure to maintain registered devices
>>> - update users to the new API
>>> Patch 8 updates OPP framework helper function to be more generic, not
>>> CPU specific.
>>>
>>> The patch set is based on linux-pm branch linux-next 813946019dfd.
>>>
>>
>> Could you take the patch set via your linux-pm?
>
> I can do that, but I didn't realize that it was targeted at me, so I
> need some more time to review the patches.
>
> Thanks!
>
No worries. Thank you for your time!
Regards,
Lukasz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Tzung-Bi Shih @ 2020-05-29 17:26 UTC (permalink / raw)
To: Mark Brown
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20200529130539.GK4610@sirena.org.uk>
On Fri, May 29, 2020 at 9:05 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 29, 2020 at 07:22:43PM +0800, Tzung-Bi Shih wrote:
> > On Fri, May 29, 2020 at 7:09 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > What is DMIC one wire mode? This doesn't sound like something I'd
> > > expect to vary at runtime.
>
> > It means: 1 PDM data wire carries 2 channel data (rising edge for left
> > and falling edge for right).
>
> I thought that was normal for DMICs - is this selecting between left and
> right or something?
Not sure what is the common name but use the same context here.
MT6358 accepts up to 2 PDM wires for 2 DMICs.
If one wire mode is on, MT6358 only accepts 1 PDM wire.
If one wire mode is off, MT6358 merges L/R from 2 PDM wires into 1
I2S-like to SoC.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v8 3/8] PM / EM: update callback structure and add device pointer
From: Daniel Lezcano @ 2020-05-29 17:43 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
linux-omap, linux-mediatek, linux-arm-msm, linux-imx
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
lorenzo.pieralisi, vincent.guittot, khilman, steven.price,
cw00.choi, mingo, mgorman, rui.zhang, alyssa.rosenzweig,
orjan.eide, daniel, b.zolnierkie, s.hauer, rostedt, matthias.bgg,
Dietmar.Eggemann, airlied, tomeu.vizoso, qperret, sboyd, rdunlap,
rjw, agross, kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <20200527095854.21714-4-lukasz.luba@arm.com>
On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
>
> Update the related users to use new function and new callback from the
> Energy Model.
>
> Acked-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt6358: support DMIC one-wire mode
From: Mark Brown @ 2020-05-29 18:16 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Hariprasad Kelam, Linux Kernel Mailing List, howie.huang,
Takashi Iwai, ALSA development, Jiaxin Yu, Liam Girdwood,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <CA+Px+wVhXoU=BdBmMW0sdPtUrnQH+Kn6dkFdW-n67qEDGceCEQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 657 bytes --]
On Sat, May 30, 2020 at 01:26:20AM +0800, Tzung-Bi Shih wrote:
> On Fri, May 29, 2020 at 9:05 PM Mark Brown <broonie@kernel.org> wrote:
> > I thought that was normal for DMICs - is this selecting between left and
> > right or something?
> Not sure what is the common name but use the same context here.
> MT6358 accepts up to 2 PDM wires for 2 DMICs.
> If one wire mode is on, MT6358 only accepts 1 PDM wire.
> If one wire mode is off, MT6358 merges L/R from 2 PDM wires into 1
> I2S-like to SoC.
Oh, interesting - so it's essentially a mixer? Not seen that before but
makes sense. In any case this definitely seems like a good fit for a DT
property.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
From: Logan Gunthorpe @ 2020-05-29 19:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Marek Szyprowski, Jean-Philippe Brucker, linux-samsung-soc,
Marc Zyngier, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, Andy Gross, linux-arm-kernel, linux-s390,
linux-arm-msm, intel-gfx, Jani Nikula, Alex Williamson,
linux-mediatek, Rodrigo Vivi, Matthias Brugger, Thomas Gleixner,
virtualization, Gerald Schaefer, David Woodhouse, Cornelia Huck,
linux-kernel, Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <20200529124523.GA11817@infradead.org>
On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
>>> This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
>>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51
>>>
>>> Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
>
> Mark did a big audit into the map_sg API abuse and initially had
> some i915 patches, but then gave up on them with this comment:
>
> "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix
> it fully. The driver creatively uses sg_table->orig_nents to store the
> size of the allocate scatterlist and ignores the number of the entries
> returned by dma_map_sg function. In this patchset I only fixed the
> sg_table objects exported by dmabuf related functions. I hope that I
> didn't break anything there."
>
> it would be really nice if the i915 maintainers could help with sorting
> that API abuse out.
>
I agree completely that the API abuse should be sorted out, but I think
that's much larger than just the i915 driver. Pretty much every dma-buf
map_dma_buf implementation I looked at ignores the returned nents of
sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See:
amdgpu_dma_buf_map
armada_gem_prime_map_dma_buf
drm_gem_map_dma_buf
i915_gem_map_dma_buf
tegra_gem_prime_map_dma_buf
So this should probably be addressed by the whole GPU community.
However, as Robin pointed out, there are other ugly tricks like stopping
iterating through the SGL when sg_dma_len() is zero. For example, the
AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
this trick and thus likely isn't buggy (otherwise, I'd expect someone to
have complained by now seeing AMD has already switched to IOMMU-DMA.
As I tried to point out in my previous email, i915 does not do this
trick. In fact, it completely ignores sg_dma_len() and is thus
completely broken. See i915_scatterlist.h and the __sgt_iter() function.
So it doesn't sound to me like Mark's fix would address the issue at
all. Per my previous email, I'd guess that it can be fixed simply by
adjusting the __sgt_iter() function to do something more sensible.
(Better yet, if possible, ditch __sgt_iter() and use the common DRM
function that AMD uses).
This would at least allow us to make progress with Tom's IOMMU-DMA patch
set and once that gets in, it will be harder for other drivers to make
the same mistake.
Logan
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Rob Herring @ 2020-05-29 19:24 UTC (permalink / raw)
To: EastL
Cc: mark.rutland, devicetree, wsd_upstream, Sean Wang, linux-kernel,
dmaengine, vkoul, linux-mediatek, matthias.bgg, linux-arm-kernel
In-Reply-To: <1590659832-31476-2-git-send-email-EastL.Lee@mediatek.com>
On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6779 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: EastL <EastL.Lee@mediatek.com>
Need a full name.
> ---
> .../devicetree/bindings/dma/mtk-cqdma.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> new file mode 100644
> index 0000000..045aa0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Command-Queue DMA controller Device Tree Binding
> +
> +maintainers:
> + - EastL <EastL.Lee@mediatek.com>
> +
> +description:
> + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> + is dedicated to memory-to-memory transfer through queue based
> + descriptor management.
> +
Need a $ref to dma-controller.yaml
> +properties:
> + "#dma-cells":
> + minimum: 1
> + # Should be enough
> + maximum: 255
> + description:
> + Used to provide DMA controller specific information.
> +
> + compatible:
> + const: mediatek,cqdma
Needs SoC specific compatible string(s).
> +
> + reg:
> + minItems: 1
> + maxItems: 255
You can have 255 register regions?
You need to define what each region is if more than 1.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 255
255 interrupts?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: cqdma
> +
> + dma-channel-mask:
> + description:
> + Bitmask of available DMA channels in ascending order that are
> + not reserved by firmware and are available to the
> + kernel. i.e. first channel corresponds to LSB.
> + The first item in the array is for channels 0-31, the second is for
> + channels 32-63, etc.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + items:
> + minItems: 1
> + # Should be enough
> + maxItems: 255
This already has a definition in dma-common.yaml. Don't copy-n-paste
it. Just add any constraints you have. Like what is the max number of
channels?
> +
> + dma-channels:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA channels supported by the controller.
> +
> + dma-requests:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA request signals supported by the controller.
Same comment on these 2.
> +
> +required:
> + - "#dma-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dma-channel-mask
> + - dma-channels
> + - dma-requests
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt6779-clk.h>
> + cqdma: dma-controller@10212000 {
> + compatible = "mediatek,cqdma";
> + reg = <0 0x10212000 0 0x80>,
> + <0 0x10212080 0 0x80>,
> + <0 0x10212100 0 0x80>;
Examples default to 1 cell each for address and size.
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channel-mask = <63>;
> + dma-channels = <3>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +...
> --
> 1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: Rob Herring @ 2020-05-29 19:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: devicetree, Stephane Le Provost, Fabien Parent, Pedro Tsai,
linux-kernel, Bartosz Golaszewski, Rob Herring, linux-mediatek,
Andrew Perepech, netdev, Matthias Brugger, Jakub Kicinski,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
On Thu, 28 May 2020 15:59:02 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
>
> .../net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/net/{mediatek,eth-mac.yaml => mediatek,star-emac.yaml} (96%)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH] net: ethernet: mtk-star-emac: remove unused variable
From: David Miller @ 2020-05-29 19:42 UTC (permalink / raw)
To: brgl
Cc: lkp, stephane.leprovost, bgolaszewski, netdev, sean.wang,
linux-kernel, fparent, pedro.tsai, linux-mediatek,
andrew.perepech, john, matthias.bgg, kuba, Mark-MC.Lee,
linux-arm-kernel
In-Reply-To: <20200529082648.19677-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Fri, 29 May 2020 10:26:48 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The desc pointer is set but not used. Remove it.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied, thanks.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
From: Marek Szyprowski @ 2020-05-29 21:11 UTC (permalink / raw)
To: Logan Gunthorpe, Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Jean-Philippe Brucker, linux-samsung-soc, Marc Zyngier,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Andy Gross,
linux-arm-kernel, linux-s390, linux-arm-msm, intel-gfx,
Jani Nikula, Alex Williamson, linux-mediatek, Rodrigo Vivi,
Matthias Brugger, Thomas Gleixner, virtualization,
Gerald Schaefer, David Woodhouse, Cornelia Huck, linux-kernel,
Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <33137cfb-603c-86e8-1091-f36117ecfaf3@deltatee.com>
Hi Logan,
On 29.05.2020 21:05, Logan Gunthorpe wrote:
> On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
>> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
>>>> This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
>>>> https://protect2.fireeye.com/url?k=ca25a34b-97f7b813-ca242804-0cc47a31c8b4-0ecdffc9f56851e1&q=1&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2F7e0165b2f1a912a06e381e91f0f4e495f4ac3736%2Fdrivers%2Fgpu%2Fdrm%2Fi915%2Fgem%2Fi915_gem_dmabuf.c%23L51
>>>>
>>>> Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
>> Mark did a big audit into the map_sg API abuse and initially had
>> some i915 patches, but then gave up on them with this comment:
>>
>> "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix
>> it fully. The driver creatively uses sg_table->orig_nents to store the
>> size of the allocate scatterlist and ignores the number of the entries
>> returned by dma_map_sg function. In this patchset I only fixed the
>> sg_table objects exported by dmabuf related functions. I hope that I
>> didn't break anything there."
>>
>> it would be really nice if the i915 maintainers could help with sorting
>> that API abuse out.
>>
> I agree completely that the API abuse should be sorted out, but I think
> that's much larger than just the i915 driver. Pretty much every dma-buf
> map_dma_buf implementation I looked at ignores the returned nents of
> sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See:
>
> amdgpu_dma_buf_map
> armada_gem_prime_map_dma_buf
> drm_gem_map_dma_buf
> i915_gem_map_dma_buf
> tegra_gem_prime_map_dma_buf
>
> So this should probably be addressed by the whole GPU community.
Patches are pending:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
> However, as Robin pointed out, there are other ugly tricks like stopping
> iterating through the SGL when sg_dma_len() is zero. For example, the
> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> have complained by now seeing AMD has already switched to IOMMU-DMA.
I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
somewhere documented.
> As I tried to point out in my previous email, i915 does not do this
> trick. In fact, it completely ignores sg_dma_len() and is thus
> completely broken. See i915_scatterlist.h and the __sgt_iter() function.
> So it doesn't sound to me like Mark's fix would address the issue at
> all. Per my previous email, I'd guess that it can be fixed simply by
> adjusting the __sgt_iter() function to do something more sensible.
> (Better yet, if possible, ditch __sgt_iter() and use the common DRM
> function that AMD uses).
>
> This would at least allow us to make progress with Tom's IOMMU-DMA patch
> set and once that gets in, it will be harder for other drivers to make
> the same mistake.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
From: Logan Gunthorpe @ 2020-05-29 21:21 UTC (permalink / raw)
To: Marek Szyprowski, Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Jean-Philippe Brucker, linux-samsung-soc, Marc Zyngier,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Andy Gross,
linux-arm-kernel, linux-s390, linux-arm-msm, intel-gfx,
Jani Nikula, Alex Williamson, linux-mediatek, Rodrigo Vivi,
Matthias Brugger, Thomas Gleixner, virtualization,
Gerald Schaefer, David Woodhouse, Cornelia Huck, linux-kernel,
Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <ef2150d5-7b6a-df25-c10d-e43316fe7812@samsung.com>
On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> Patches are pending:
> https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
Cool, nice! Though, I still don't think that fixes the issue in
i915_scatterlist.h given it still ignores sg_dma_len() and strictly
relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
is the bug that got in Tom's way.
>> However, as Robin pointed out, there are other ugly tricks like stopping
>> iterating through the SGL when sg_dma_len() is zero. For example, the
>> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
>> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
>> have complained by now seeing AMD has already switched to IOMMU-DMA.
>
> I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> somewhere documented.
Well whatever you want to call it, it is ugly to have some drivers doing
one thing with the returned value and others assuming there's an extra
zero at the end. It just causes confusion for people reading/copying the
code. It would be better if they are all consistent. However, I concede
stopping at zero should not be broken, presently.
Logan
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code
From: Jerry Snitselaar @ 2020-05-29 22:16 UTC (permalink / raw)
To: Joerg Roedel
Cc: Heiko Stuebner, virtualization, linux-tegra, Thierry Reding,
Will Deacon, Marek Szyprowski, Jean-Philippe Brucker,
linux-samsung-soc, iommu, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, Andy Gross, linux-s390, linux-arm-msm,
linux-mediatek, Matthias Brugger, Bjorn Andersson,
Gerald Schaefer, David Woodhouse, linux-kernel, Rob Clark,
Kukjin Kim, Robin Murphy, Lu Baolu
In-Reply-To: <20200414131542.25608-1-joro@8bytes.org>
On Tue Apr 14 20, Joerg Roedel wrote:
>Hi,
>
>here is the second version of this patch-set. The first version with
>some more introductory text can be found here:
>
> https://lore.kernel.org/lkml/20200407183742.4344-1-joro@8bytes.org/
>
>Changes v1->v2:
>
> * Rebased to v5.7-rc1
>
> * Re-wrote the arm-smmu changes as suggested by Robin Murphy
>
> * Re-worked the Exynos patches to hopefully not break the
> driver anymore
>
> * Fixed a missing mutex_unlock() reported by Marek Szyprowski,
> thanks for that.
>
>There is also a git-branch available with these patches applied:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-probe-device-v2
>
>Please review.
>
>Thanks,
>
> Joerg
>
>Joerg Roedel (32):
> iommu: Move default domain allocation to separate function
> iommu/amd: Implement iommu_ops->def_domain_type call-back
> iommu/vt-d: Wire up iommu_ops->def_domain_type
> iommu/amd: Remove dma_mask check from check_device()
> iommu/amd: Return -ENODEV in add_device when device is not handled by
> IOMMU
> iommu: Add probe_device() and remove_device() call-backs
> iommu: Move default domain allocation to iommu_probe_device()
> iommu: Keep a list of allocated groups in __iommu_probe_device()
> iommu: Move new probe_device path to separate function
> iommu: Split off default domain allocation from group assignment
> iommu: Move iommu_group_create_direct_mappings() out of
> iommu_group_add_device()
> iommu: Export bus_iommu_probe() and make is safe for re-probing
> iommu/amd: Remove dev_data->passthrough
> iommu/amd: Convert to probe/release_device() call-backs
> iommu/vt-d: Convert to probe/release_device() call-backs
> iommu/arm-smmu: Convert to probe/release_device() call-backs
> iommu/pamu: Convert to probe/release_device() call-backs
> iommu/s390: Convert to probe/release_device() call-backs
> iommu/virtio: Convert to probe/release_device() call-backs
> iommu/msm: Convert to probe/release_device() call-backs
> iommu/mediatek: Convert to probe/release_device() call-backs
> iommu/mediatek-v1 Convert to probe/release_device() call-backs
> iommu/qcom: Convert to probe/release_device() call-backs
> iommu/rockchip: Convert to probe/release_device() call-backs
> iommu/tegra: Convert to probe/release_device() call-backs
> iommu/renesas: Convert to probe/release_device() call-backs
> iommu/omap: Remove orphan_dev tracking
> iommu/omap: Convert to probe/release_device() call-backs
> iommu/exynos: Use first SYSMMU in controllers list for IOMMU core
> iommu/exynos: Convert to probe/release_device() call-backs
> iommu: Remove add_device()/remove_device() code-paths
> iommu: Unexport iommu_group_get_for_dev()
>
>Sai Praneeth Prakhya (1):
> iommu: Add def_domain_type() callback in iommu_ops
>
> drivers/iommu/amd_iommu.c | 97 ++++----
> drivers/iommu/amd_iommu_types.h | 1 -
> drivers/iommu/arm-smmu-v3.c | 38 +--
> drivers/iommu/arm-smmu.c | 39 ++--
> drivers/iommu/exynos-iommu.c | 24 +-
> drivers/iommu/fsl_pamu_domain.c | 22 +-
> drivers/iommu/intel-iommu.c | 68 +-----
> drivers/iommu/iommu.c | 393 +++++++++++++++++++++++++-------
> drivers/iommu/ipmmu-vmsa.c | 60 ++---
> drivers/iommu/msm_iommu.c | 34 +--
> drivers/iommu/mtk_iommu.c | 24 +-
> drivers/iommu/mtk_iommu_v1.c | 50 ++--
> drivers/iommu/omap-iommu.c | 99 ++------
> drivers/iommu/qcom_iommu.c | 24 +-
> drivers/iommu/rockchip-iommu.c | 26 +--
> drivers/iommu/s390-iommu.c | 22 +-
> drivers/iommu/tegra-gart.c | 24 +-
> drivers/iommu/tegra-smmu.c | 31 +--
> drivers/iommu/virtio-iommu.c | 41 +---
> include/linux/iommu.h | 21 +-
> 20 files changed, 533 insertions(+), 605 deletions(-)
>
>--
>2.17.1
>
>_______________________________________________
>iommu mailing list
>iommu@lists.linux-foundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
Hi Joerg,
With this patchset, I have an epyc system where if I boot with
iommu=nopt and force a dump I will see some io page faults for a nic
on the system. The vmcore is harvested and the system reboots. I
haven't reproduced it on other systems yet, but without the patchset I
don't see the io page faults during the kdump.
Regards,
Jerry
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH net-next v2] dt-bindings: net: rename the bindings document for MediaTek STAR EMAC
From: David Miller @ 2020-05-30 0:07 UTC (permalink / raw)
To: brgl
Cc: devicetree, stephane.leprovost, bgolaszewski, netdev,
linux-kernel, fparent, robh+dt, linux-mediatek, andrew.perepech,
pedro.tsai, matthias.bgg, kuba, linux-arm-kernel
In-Reply-To: <20200528135902.14041-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Thu, 28 May 2020 15:59:02 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The driver itself was renamed before getting merged into mainline, but
> the binding document kept the old name. This makes both names consistent.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - update the id field as well
Applied, thank you.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v4 00/17] Clean up "mediatek,larb" after adding device_link
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-------------
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
MediaTek IOMMU don't have its power-domain. When the consumer works,
it should enable the smi-larb's power which also need enable the smi-common's
power firstly.
Thus, Firstly, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
After adding the device_link, then "mediatek,larb" property can be removed.
the iommu consumer don't need call the mtk_smi_larb_get/put to enable
the power and clock of smi-larb and smi-common.
This patchset depends on v5.7-rc1 and several patchset. Mainly venc and MDP
adjust their flow, then this patchset can work successfully.
a) IOMMU depend on [1][2].
b) MDP depend on [3][4][5].
c) VENC depend on [6].
[1] iommu: Move iommu_group setup to IOMMU core code
https://lore.kernel.org/linux-iommu/20200429133712.31431-1-joro@8bytes.org/
[2] iommu/mediatek-v1: Fix a build warning for a unused variable 'data'
https://lore.kernel.org/linux-iommu/1589875064-662-1-git-send-email-yong.wu@mediatek.com/
[3] arm64: dts: mt8173: fix mdp aliases property name
https://lore.kernel.org/linux-mediatek/20200414030815.192104-1-hsinyi@chromium.org/
[4] MTK MDP driver cleanups to prep for futher work
https://lore.kernel.org/linux-mediatek/20200507102345.81849-1-eizan@chromium.org/
[5] Refactor MDP driver and add dummy component driver
https://lore.kernel.org/linux-mediatek/20200506084039.249977-1-eizan@chromium.org/
[6] media: mtk-vcodec: venc: support for MT8183
https://lore.kernel.org/linux-mediatek/20200520082723.96136-1-acourbot@chromium.org/
[1][2][3] have already been in lastest linux-next.
Change notes:
v4: base on v5.7-rc1.
1) Move drm PM patch before smi patchs.
2) Change builtin_platform_driver to module_platform_driver since we may need
build as module.
3) Rebase many patchset as above.
v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong.wu@mediatek.com/
1) rebase on v5.3-rc1 and the latest mt8183 patchset.
2) Use device_is_bound to check whether the driver is ready from Matthias.
3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the
reason in the commit message[3/14].
4) Add a display patch[12/14] into this series. otherwise it may affect
display HW fastlogo even though it don't happen in mt8183.
v2: http://lists.infradead.org/pipermail/linux-mediatek/2019-June/020440.html
1) rebase on v5.2-rc1.
2) Move adding device_link between the consumer and smi-larb into
iommu_add_device from Robin.
3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan.
4) Remove the shutdown callback in iommu.
v1: https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032387.html
Irui Wang (1):
arm64: dts: mt8173: Separate mtk-vcodec-enc node
Maoguang Meng (2):
media: dt-binding: mtk-vcodec: Separating mtk-vcodec encode node.
media: mtk-vcodec: separate mtk-vcodec-enc node.
Yong Wu (13):
dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW
iommu/mediatek: Add probe_defer for smi-larb
iommu/mediatek: Add device_link between the consumer and the larb
devices
memory: mtk-smi: Add device-link between smi-larb and smi-common
media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
media: mtk-mdp: Get rid of mtk_smi_larb_get/put
media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
drm/mediatek: Get rid of mtk_smi_larb_get/put
memory: mtk-smi: Get rid of mtk_smi_larb_get/put
iommu/mediatek: Use module_platform_driver
memory: mtk-smi: Use device_is_bound to check if smi-common is ready
arm: dts: mediatek: Get rid of mediatek,larb for MM nodes
arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes
Yongqiang Niu (1):
drm/mediatek: Add pm runtime support for ovl and rdma
.../bindings/display/mediatek/mediatek,disp.txt | 9 --
.../bindings/media/mediatek-jpeg-decoder.txt | 4 -
.../devicetree/bindings/media/mediatek-mdp.txt | 8 --
.../devicetree/bindings/media/mediatek-vcodec.txt | 58 +++++-----
arch/arm/boot/dts/mt2701.dtsi | 1 -
arch/arm/boot/dts/mt7623.dtsi | 1 -
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 72 +++++-------
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 21 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +-
drivers/iommu/mtk_iommu.c | 44 ++++---
drivers/iommu/mtk_iommu_v1.c | 39 +++++--
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 22 ----
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 44 +------
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
.../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 19 ---
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 13 +--
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 24 +++-
.../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 127 +++++++++------------
.../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 56 ---------
.../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h | 1 -
.../media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 +-
drivers/memory/mtk-smi.c | 41 +++----
include/soc/mediatek/smi.h | 20 ----
28 files changed, 246 insertions(+), 426 deletions(-)
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [PATCH v4 03/17] iommu/mediatek: Add probe_defer for smi-larb
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.
This is a preparing patch for adding device_link.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 8 +++++++-
drivers/iommu/mtk_iommu_v1.c | 7 ++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 2be96f1..7d8f3d0 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -643,6 +643,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
for (i = 0; i < larb_nr; i++) {
struct device_node *larbnode;
struct platform_device *plarbdev;
+ bool larbdev_is_bound = false;
u32 id;
larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
@@ -659,7 +660,12 @@ static int mtk_iommu_probe(struct platform_device *pdev)
id = i;
plarbdev = of_find_device_by_node(larbnode);
- if (!plarbdev) {
+ if (plarbdev) {
+ device_lock(&plarbdev->dev);
+ larbdev_is_bound = device_is_bound(&plarbdev->dev);
+ device_unlock(&plarbdev->dev);
+ }
+ if (!plarbdev || !larbdev_is_bound) {
of_node_put(larbnode);
return -EPROBE_DEFER;
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 1245e0c..02858a0 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -591,10 +591,15 @@ static int mtk_iommu_probe(struct platform_device *pdev)
plarbdev = of_find_device_by_node(larb_spec.np);
if (!plarbdev) {
+ bool larbdev_is_bound;
+
plarbdev = of_platform_device_create(
larb_spec.np, NULL,
platform_bus_type.dev_root);
- if (!plarbdev) {
+ device_lock(&plarbdev->dev);
+ larbdev_is_bound = device_is_bound(&plarbdev->dev);
+ device_unlock(&plarbdev->dev);
+ if (!plarbdev || !larbdev_is_bound) {
of_node_put(larb_spec.np);
return -EPROBE_DEFER;
}
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 04/17] iommu/mediatek: Add device_link between the consumer and the larb devices
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
MediaTek IOMMU don't have its power-domain. all the consumer connect
with smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-------------
| | ...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.
Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.
This patch adds device_link between the consumer and the larbs.
When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.
2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.
Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.
[1] http://lists.infradead.org/pipermail/linux-mediatek/2019-July/
021500.html
[2] https://lore.kernel.org/patchwork/patch/1086569/
Suggested-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 18 ++++++++++++++++++
drivers/iommu/mtk_iommu_v1.c | 20 +++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 7d8f3d0..5c3a6ba 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -445,22 +445,40 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_data *data;
+ struct device_link *link;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ /* Link the consumer device with the smi-larb device(supplier) */
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
return &data->iommu;
}
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ device_link_remove(dev, larbdev);
+
iommu_fwspec_free(dev);
}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 02858a0..26b6c79 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -422,7 +422,9 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
struct of_phandle_args iommu_spec;
struct of_phandle_iterator it;
struct mtk_iommu_data *data;
- int err;
+ struct device_link *link;
+ struct device *larbdev;
+ int err, larbid;
of_for_each_phandle(&it, err, dev->of_node, "iommus",
"#iommu-cells", -1) {
@@ -444,6 +446,14 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
data = dev_iommu_priv_get(dev);
+ /* Link the consumer device with the smi-larb device(supplier) */
+ larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ link = device_link_add(dev, larbdev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
+
return &data->iommu;
}
@@ -465,10 +475,18 @@ static void mtk_iommu_probe_finalize(struct device *dev)
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
+ struct device *larbdev;
+ unsigned int larbid;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+ larbdev = data->larb_imu[larbid].dev;
+ device_link_remove(dev, larbdev);
+
iommu_fwspec_free(dev);
}
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 05/17] memory: mtk-smi: Add device-link between smi-larb and smi-common
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
Normally, If the smi-larb HW need work, we should enable the smi-common
HW power and clock firstly.
This patch adds device-link between the smi-larb dev and the smi-common
dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
(smi-common-dev) will be called automatically.
Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
probe.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Suggested-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index a113e81..6cdefda 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -273,6 +273,7 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *smi_node;
struct platform_device *smi_pdev;
+ struct device_link *link;
larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
if (!larb)
@@ -312,6 +313,12 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
if (!platform_get_drvdata(smi_pdev))
return -EPROBE_DEFER;
larb->smi_common_dev = &smi_pdev->dev;
+ link = device_link_add(dev, larb->smi_common_dev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+ if (!link) {
+ dev_err(dev, "Unable to link smi-common dev\n");
+ return -ENODEV;
+ }
} else {
dev_err(dev, "Failed to get the smi_common device\n");
return -EINVAL;
@@ -324,6 +331,9 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
static int mtk_smi_larb_remove(struct platform_device *pdev)
{
+ struct mtk_smi_larb *larb = platform_get_drvdata(pdev);
+
+ device_link_remove(&pdev->dev, larb->smi_common_dev);
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &mtk_smi_larb_component_ops);
return 0;
@@ -335,17 +345,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
int ret;
- /* Power on smi-common. */
- ret = pm_runtime_get_sync(larb->smi_common_dev);
- if (ret < 0) {
- dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
- return ret;
- }
-
ret = mtk_smi_clk_enable(&larb->smi);
if (ret < 0) {
dev_err(dev, "Failed to enable clock(%d).\n", ret);
- pm_runtime_put_sync(larb->smi_common_dev);
return ret;
}
@@ -360,7 +362,6 @@ static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
mtk_smi_clk_disable(&larb->smi);
- pm_runtime_put_sync(larb->smi_common_dev);
return 0;
}
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 06/17] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
Rick Chang, ming-fan.chen, anan.sun, Robin Murphy, acourbot,
linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Rick Chang <rick.chang@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 22 ----------------------
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 --
2 files changed, 24 deletions(-)
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index f82a81a..21fba6f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -21,7 +21,6 @@
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-core.h>
#include <media/videobuf2-dma-contig.h>
-#include <soc/mediatek/smi.h>
#include "mtk_jpeg_hw.h"
#include "mtk_jpeg_core.h"
@@ -893,11 +892,6 @@ static int mtk_jpeg_queue_init(void *priv, struct vb2_queue *src_vq,
static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
{
- int ret;
-
- ret = mtk_smi_larb_get(jpeg->larb);
- if (ret)
- dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
clk_prepare_enable(jpeg->clk_jdec_smi);
clk_prepare_enable(jpeg->clk_jdec);
}
@@ -906,7 +900,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
clk_disable_unprepare(jpeg->clk_jdec);
clk_disable_unprepare(jpeg->clk_jdec_smi);
- mtk_smi_larb_put(jpeg->larb);
}
static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
@@ -1051,21 +1044,6 @@ static int mtk_jpeg_release(struct file *file)
static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
{
- struct device_node *node;
- struct platform_device *pdev;
-
- node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
- if (!node)
- return -EINVAL;
- pdev = of_find_device_by_node(node);
- if (WARN_ON(!pdev)) {
- of_node_put(node);
- return -EINVAL;
- }
- of_node_put(node);
-
- jpeg->larb = &pdev->dev;
-
jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
if (IS_ERR(jpeg->clk_jdec))
return PTR_ERR(jpeg->clk_jdec);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 999bd14..8579494 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -47,7 +47,6 @@ enum mtk_jpeg_ctx_state {
* @dec_reg_base: JPEG registers mapping
* @clk_jdec: JPEG hw working clock
* @clk_jdec_smi: JPEG SMI bus clock
- * @larb: SMI device
*/
struct mtk_jpeg_dev {
struct mutex lock;
@@ -61,7 +60,6 @@ struct mtk_jpeg_dev {
void __iomem *dec_reg_base;
struct clk *clk_jdec;
struct clk *clk_jdec_smi;
- struct device *larb;
};
/**
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 09/17] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel,
Tiffany Lin
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 19 ---------------
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 3 ---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 27 ----------------------
4 files changed, 50 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 36dfe3f..1d7d14d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
-#include <soc/mediatek/smi.h>
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
pm = &mtkdev->pm;
pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = &pdev->dev;
pdev = mtkdev->plat_dev;
pm->dev = &pdev->dev;
@@ -113,11 +100,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvdec);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
- goto error;
- }
return;
error:
@@ -130,7 +112,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *dec_clk = &pm->vdec_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvdec);
for (i = dec_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 52d1ce1..7d3966a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -190,10 +190,7 @@ struct mtk_vcodec_clk {
*/
struct mtk_vcodec_pm {
struct mtk_vcodec_clk vdec_clk;
- struct device *larbvdec;
-
struct mtk_vcodec_clk venc_clk;
- struct device *larbvenc;
struct device *dev;
struct mtk_vcodec_dev *mtkdev;
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 5301dca..18025f7 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -8,7 +8,6 @@
#include <media/v4l2-event.h>
#include <media/v4l2-mem2mem.h>
#include <media/videobuf2-dma-contig.h>
-#include <soc/mediatek/smi.h>
#include <linux/pm_runtime.h>
#include "mtk_vcodec_drv.h"
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
index 01c6a55..047919e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
@@ -8,44 +8,25 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
-#include <soc/mediatek/smi.h>
#include "mtk_vcodec_enc_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *enc_clk;
struct mtk_vcodec_clk_info *clk_info;
int ret = 0, i = 0;
- struct device *dev;
pdev = mtkdev->plat_dev;
pm = &mtkdev->pm;
memset(pm, 0, sizeof(struct mtk_vcodec_pm));
pm->mtkdev = mtkdev;
pm->dev = &pdev->dev;
- dev = &pdev->dev;
enc_clk = &pm->venc_clk;
- node = of_parse_phandle(dev->of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("no mediatek,larb found");
- return -ENODEV;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (!pdev) {
- mtk_v4l2_err("no mediatek,larb device found");
- return -ENODEV;
- }
- pm->larbvenc = &pdev->dev;
- pdev = mtkdev->plat_dev;
- pm->dev = &pdev->dev;
-
enc_clk->clk_num = of_property_count_strings(pdev->dev.of_node,
"clock-names");
if (enc_clk->clk_num > 0) {
@@ -93,13 +74,6 @@ void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm)
}
}
- ret = mtk_smi_larb_get(pm->larbvenc);
- if (ret) {
- mtk_v4l2_err("mtk_smi_larb_get larb3 fail %d", ret);
- goto clkerr;
- }
- return;
-
clkerr:
for (i -= 1; i >= 0; i--)
clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
@@ -110,7 +84,6 @@ void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm)
struct mtk_vcodec_clk *enc_clk = &pm->venc_clk;
int i = 0;
- mtk_smi_larb_put(pm->larbvenc);
for (i = enc_clk->clk_num - 1; i >= 0; i--)
clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
}
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 14/17] memory: mtk-smi: Use device_is_bound to check if smi-common is ready
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
smi-larb driver should run after smi-common, Use device_is_bound to confirm
whether smicommon driver is ready.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 19c3949..0f8cd50 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -296,8 +296,14 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
smi_pdev = of_find_device_by_node(smi_node);
of_node_put(smi_node);
if (smi_pdev) {
- if (!platform_get_drvdata(smi_pdev))
+ bool smicommon_is_bound;
+
+ device_lock(&smi_pdev->dev);
+ smicommon_is_bound = device_is_bound(&smi_pdev->dev);
+ device_unlock(&smi_pdev->dev);
+ if (!smicommon_is_bound)
return -EPROBE_DEFER;
+
larb->smi_common_dev = &smi_pdev->dev;
link = device_link_add(dev, larb->smi_common_dev,
DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 07/17] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: Minghsiu Tsai, Will Deacon, youlin.pei, Nicolas Boichat,
Evan Green, eizan, Matthias Kaehlcke, linux-arm-kernel,
devicetree, cui.zhang, Houlong Wei, Tomasz Figa, linux-mediatek,
ming-fan.chen, yong.wu, anan.sun, acourbot, srv_heupstream,
linux-kernel, chao.hao, iommu, Robin Murphy
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
CC: Houlong Wei <houlong.wei@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 44 +--------------------------
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 --
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 -
3 files changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 228c58f..388ae67 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -13,7 +13,6 @@
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
-#include <soc/mediatek/smi.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -58,18 +57,6 @@ void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
{
int i, err;
- if (comp->larb_dev) {
- err = mtk_smi_larb_get(comp->larb_dev);
- if (err) {
- enum mtk_mdp_comp_type comp_type =
- (enum mtk_mdp_comp_type)
- of_device_get_match_data(comp->dev);
- dev_err(comp->dev,
- "failed to get larb, err %d. type:%d\n",
- err, comp_type);
- }
- }
-
err = pm_runtime_get_sync(comp->dev);
if (err < 0)
dev_err(comp->dev,
@@ -97,9 +84,6 @@ void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
clk_disable_unprepare(comp->clk[i]);
}
- if (comp->larb_dev)
- mtk_smi_larb_put(comp->larb_dev);
-
pm_runtime_put_sync(comp->dev);
}
@@ -132,12 +116,10 @@ static void mtk_mdp_comp_unbind(struct device *dev, struct device *master,
int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
{
- struct device_node *larb_node;
- struct platform_device *larb_pdev;
- int i;
struct device_node *node = dev->of_node;
enum mtk_mdp_comp_type comp_type =
(enum mtk_mdp_comp_type)of_device_get_match_data(dev);
+ int i;
INIT_LIST_HEAD(&comp->node);
comp->dev = dev;
@@ -156,30 +138,6 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
break;
}
- /* Only DMA capable components need the LARB property */
- comp->larb_dev = NULL;
- if (comp_type != MTK_MDP_RDMA &&
- comp_type != MTK_MDP_WDMA &&
- comp_type != MTK_MDP_WROT)
- return 0;
-
- larb_node = of_parse_phandle(node, "mediatek,larb", 0);
- if (!larb_node) {
- dev_err(dev,
- "Missing mediadek,larb phandle in %pOF node\n", node);
- return -EINVAL;
- }
-
- larb_pdev = of_find_device_by_node(larb_node);
- if (!larb_pdev) {
- dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
- of_node_put(larb_node);
- return -EPROBE_DEFER;
- }
- of_node_put(larb_node);
-
- comp->larb_dev = &larb_pdev->dev;
-
return 0;
}
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index de158d3..355e226 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -11,13 +11,11 @@
* struct mtk_mdp_comp - the MDP's function component data
* @node: list node to track sibing MDP components
* @clk: clocks required for component
- * @larb_dev: SMI device required for component
* @dev: component's device
*/
struct mtk_mdp_comp {
struct list_head node;
struct clk *clk[2];
- struct device *larb_dev;
struct device *dev;
};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 133d107..bc5472d 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -18,7 +18,6 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/workqueue.h>
-#include <soc/mediatek/smi.h>
#include "mtk_mdp_comp.h"
#include "mtk_mdp_core.h"
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 13/17] iommu/mediatek: Use module_platform_driver
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
MediaTek IOMMU should wait for smi larb which need wait for the
power domain(mtk-scpsys.c) and the multimedia ccf, both are module
init. Thus, subsys_initcall for MediaTek IOMMU is not helpful.
Switch to module_platform_driver.
Correspondingly, add the module license information.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
for iommu v1: honghui's mail address is not valid now. I will be
responsible for that file too, So I add myself in it.
---
drivers/iommu/mtk_iommu.c | 18 ++++++------------
drivers/iommu/mtk_iommu_v1.c | 12 +++++++-----
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5c3a6ba..0740ca9 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -15,6 +15,7 @@
#include <linux/iommu.h>
#include <linux/iopoll.h>
#include <linux/list.h>
+#include <linux/module.h>
#include <linux/of_address.h>
#include <linux/of_iommu.h>
#include <linux/of_irq.h>
@@ -823,16 +824,9 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.pm = &mtk_iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init mtk_iommu_init(void)
-{
- int ret;
-
- ret = platform_driver_register(&mtk_iommu_driver);
- if (ret != 0)
- pr_err("Failed to register MTK IOMMU driver\n");
-
- return ret;
-}
-
-subsys_initcall(mtk_iommu_init)
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U implementations");
+MODULE_AUTHOR("Yong Wu <yong.wu@mediatek.com>");
+MODULE_ALIAS("platform:MediaTek-M4U");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 26b6c79..0852cb3 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -20,6 +20,7 @@
#include <linux/iommu.h>
#include <linux/iopoll.h>
#include <linux/list.h>
+#include <linux/module.h>
#include <linux/of_address.h>
#include <linux/of_iommu.h>
#include <linux/of_irq.h>
@@ -711,9 +712,10 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.pm = &mtk_iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init m4u_init(void)
-{
- return platform_driver_register(&mtk_iommu_driver);
-}
-subsys_initcall(m4u_init);
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U v1 implementations");
+MODULE_AUTHOR("Yong Wu <yong.wu@mediatek.com>");
+MODULE_AUTHOR("Honghui Zhang <honghui.zhang@mediatek.com>");
+MODULE_ALIAS("platform:MediaTek-M4U-v1");
+MODULE_LICENSE("GPL v2");
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 01/17] media: dt-binding: mtk-vcodec: Separating mtk-vcodec encode node.
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: Maoguang Meng, Will Deacon, youlin.pei, Irui Wang,
Nicolas Boichat, Evan Green, eizan, Matthias Kaehlcke,
linux-arm-kernel, devicetree, cui.zhang, Tomasz Figa,
linux-mediatek, Hsin-Yi Wang, ming-fan.chen, yong.wu, anan.sun,
acourbot, srv_heupstream, linux-kernel, chao.hao, iommu,
Robin Murphy
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
From: Maoguang Meng <maoguang.meng@mediatek.com>
Update binding document since the avc and vp8 hardware encoder in
mt8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to
"mediatek,mt8173-vcodec-vp8-enc" and "mediatek,mt8173-vcodec-avc-enc".
This is a preparing patch for smi cleaning up "mediatek,larb".
Signed-off-by: Maoguang Meng <maoguang.meng@mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
.../devicetree/bindings/media/mediatek-vcodec.txt | 58 ++++++++++++----------
1 file changed, 31 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8093335..1023740 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
supports high resolution encoding and decoding functionalities.
Required properties:
-- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
+- compatible : must be one of the following string:
+ "mediatek,mt8173-vcodec-vp8-enc" for mt8173 vp8 encoder.
+ "mediatek,mt8173-vcodec-avc-enc" for mt8173 avc encoder.
"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
- reg : Physical base address of the video codec registers and length of
@@ -13,10 +15,11 @@ Required properties:
- mediatek,larb : must contain the local arbiters in the current Socs.
- clocks : list of clock specifiers, corresponding to entries in
the clock-names property.
-- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
- "venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
- "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
- "venc_lt_sel", "vdec_bus_clk_src".
+- clock-names:
+ avc venc must contain "venc_sel";
+ vp8 venc must contain "venc_lt_sel";
+ decoder must contain "vcodecpll", "univpll_d2", "clk_cci400_sel",
+ "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", "vdec_bus_clk_src".
- iommus : should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -80,14 +83,10 @@ vcodec_dec: vcodec@16000000 {
assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>;
};
- vcodec_enc: vcodec@18002000 {
- compatible = "mediatek,mt8173-vcodec-enc";
- reg = <0 0x18002000 0 0x1000>, /*VENC_SYS*/
- <0 0x19002000 0 0x1000>; /*VENC_LT_SYS*/
- interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
- mediatek,larb = <&larb3>,
- <&larb5>;
+vcodec_enc: vcodec@18002000 {
+ compatible = "mediatek,mt8173-vcodec-avc-enc";
+ reg = <0 0x18002000 0 0x1000>;
+ interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
iommus = <&iommu M4U_PORT_VENC_RCPU>,
<&iommu M4U_PORT_VENC_REC>,
<&iommu M4U_PORT_VENC_BSDMA>,
@@ -98,8 +97,20 @@ vcodec_dec: vcodec@16000000 {
<&iommu M4U_PORT_VENC_REF_LUMA>,
<&iommu M4U_PORT_VENC_REF_CHROMA>,
<&iommu M4U_PORT_VENC_NBM_RDMA>,
- <&iommu M4U_PORT_VENC_NBM_WDMA>,
- <&iommu M4U_PORT_VENC_RCPU_SET2>,
+ <&iommu M4U_PORT_VENC_NBM_WDMA>;
+ mediatek,larb = <&larb3>;
+ mediatek,vpu = <&vpu>;
+ clocks = <&topckgen CLK_TOP_VENC_SEL>;
+ clock-names = "venc_sel";
+ assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
+ };
+
+vcodec_enc_lt: vcodec@19002000 {
+ compatible = "mediatek,mt8173-vcodec-vp8-enc";
+ reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
+ interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
<&iommu M4U_PORT_VENC_REC_FRM_SET2>,
<&iommu M4U_PORT_VENC_BSDMA_SET2>,
<&iommu M4U_PORT_VENC_SV_COMA_SET2>,
@@ -108,17 +119,10 @@ vcodec_dec: vcodec@16000000 {
<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+ mediatek,larb = <&larb5>;
mediatek,vpu = <&vpu>;
- clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
- <&topckgen CLK_TOP_VENC_SEL>,
- <&topckgen CLK_TOP_UNIVPLL1_D2>,
- <&topckgen CLK_TOP_VENC_LT_SEL>;
- clock-names = "venc_sel_src",
- "venc_sel",
- "venc_lt_sel_src",
- "venc_lt_sel";
- assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
- <&topckgen CLK_TOP_VENC_LT_SEL>;
- assigned-clock-parents = <&topckgen CLK_TOP_VENCPLL_D2>,
- <&topckgen CLK_TOP_UNIVPLL1_D2>;
+ clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
+ clock-names = "venc_lt_sel";
+ assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>;
};
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH v4 02/17] dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
From: Yong Wu @ 2020-05-30 8:10 UTC (permalink / raw)
To: Matthias Brugger, Joerg Roedel, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang, eizan,
srv_heupstream, chao.hao, Will Deacon, linux-kernel, Evan Green,
Tomasz Figa, iommu, Matthias Kaehlcke, linux-mediatek, yong.wu,
ming-fan.chen, anan.sun, Robin Murphy, acourbot, linux-arm-kernel
In-Reply-To: <1590826218-23653-1-git-send-email-yong.wu@mediatek.com>
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 9 ---------
.../devicetree/bindings/media/mediatek-jpeg-decoder.txt | 4 ----
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8 --------
Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 4 ----
4 files changed, 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index b91e709..c7e2eb8 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -60,8 +60,6 @@ Required properties (DMA function blocks):
"mediatek,<chip>-disp-rdma"
"mediatek,<chip>-disp-wdma"
the supported chips are mt2701 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as defined
- in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -82,7 +80,6 @@ ovl0: ovl@1400c000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
iommus = <&iommu M4U_PORT_DISP_OVL0>;
- mediatek,larb = <&larb0>;
};
ovl1: ovl@1400d000 {
@@ -92,7 +89,6 @@ ovl1: ovl@1400d000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL1>;
iommus = <&iommu M4U_PORT_DISP_OVL1>;
- mediatek,larb = <&larb4>;
};
rdma0: rdma@1400e000 {
@@ -102,7 +98,6 @@ rdma0: rdma@1400e000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
iommus = <&iommu M4U_PORT_DISP_RDMA0>;
- mediatek,larb = <&larb0>;
};
rdma1: rdma@1400f000 {
@@ -112,7 +107,6 @@ rdma1: rdma@1400f000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
iommus = <&iommu M4U_PORT_DISP_RDMA1>;
- mediatek,larb = <&larb4>;
};
rdma2: rdma@14010000 {
@@ -122,7 +116,6 @@ rdma2: rdma@14010000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA2>;
iommus = <&iommu M4U_PORT_DISP_RDMA2>;
- mediatek,larb = <&larb4>;
};
wdma0: wdma@14011000 {
@@ -132,7 +125,6 @@ wdma0: wdma@14011000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA0>;
iommus = <&iommu M4U_PORT_DISP_WDMA0>;
- mediatek,larb = <&larb0>;
};
wdma1: wdma@14012000 {
@@ -142,7 +134,6 @@ wdma1: wdma@14012000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA1>;
iommus = <&iommu M4U_PORT_DISP_WDMA1>;
- mediatek,larb = <&larb4>;
};
color0: color@14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index 044b119..7978f21 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -15,9 +15,6 @@ Required properties:
- clock-names: must contain "jpgdec-smi" and "jpgdec".
- power-domains: a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
-- mediatek,larb: must contain the local arbiters in the current Socs, see
- Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -32,7 +29,6 @@ Example:
clock-names = "jpgdec-smi",
"jpgdec";
power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
- mediatek,larb = <&larb2>;
iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index 0d03e3a..df69c5a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -27,9 +27,6 @@ Required properties (DMA function blocks, child node):
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
-- mediatek,larb: must contain the local arbiters in the current Socs, see
- Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- for details.
Example:
mdp_rdma0: rdma@14001000 {
@@ -40,7 +37,6 @@ Example:
<&mmsys CLK_MM_MUTEX_32K>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <&larb0>;
mediatek,vpu = <&vpu>;
};
@@ -51,7 +47,6 @@ Example:
<&mmsys CLK_MM_MUTEX_32K>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <&larb4>;
};
mdp_rsz0: rsz@14003000 {
@@ -81,7 +76,6 @@ Example:
clocks = <&mmsys CLK_MM_MDP_WDMA>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_WDMA>;
- mediatek,larb = <&larb0>;
};
mdp_wrot0: wrot@14007000 {
@@ -90,7 +84,6 @@ Example:
clocks = <&mmsys CLK_MM_MDP_WROT0>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_WROT0>;
- mediatek,larb = <&larb0>;
};
mdp_wrot1: wrot@14008000 {
@@ -99,5 +92,4 @@ Example:
clocks = <&mmsys CLK_MM_MDP_WROT1>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_WROT1>;
- mediatek,larb = <&larb4>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 1023740..50a27f2 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -12,7 +12,6 @@ Required properties:
- reg : Physical base address of the video codec registers and length of
memory mapped region.
- interrupts : interrupt number to the cpu.
-- mediatek,larb : must contain the local arbiters in the current Socs.
- clocks : list of clock specifiers, corresponding to entries in
the clock-names property.
- clock-names:
@@ -45,7 +44,6 @@ vcodec_dec: vcodec@16000000 {
<0 0x16027800 0 0x800>, /*VP8_VL*/
<0 0x16028400 0 0x400>; /*VP9_VD*/
interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>;
- mediatek,larb = <&larb1>;
iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
<&iommu M4U_PORT_HW_VDEC_PP_EXT>,
<&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
@@ -98,7 +96,6 @@ vcodec_enc: vcodec@18002000 {
<&iommu M4U_PORT_VENC_REF_CHROMA>,
<&iommu M4U_PORT_VENC_NBM_RDMA>,
<&iommu M4U_PORT_VENC_NBM_WDMA>;
- mediatek,larb = <&larb3>;
mediatek,vpu = <&vpu>;
clocks = <&topckgen CLK_TOP_VENC_SEL>;
clock-names = "venc_sel";
@@ -119,7 +116,6 @@ vcodec_enc_lt: vcodec@19002000 {
<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
- mediatek,larb = <&larb5>;
mediatek,vpu = <&vpu>;
clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
clock-names = "venc_lt_sel";
--
1.9.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox