Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM

[Ulf Hansson]

On 11 December 2014 at 09:26, Tomasz Figa tf...@chromium.org wrote:
 This patch modifies the rockchip-iommu driver to consider state of
 the power domain the IOMMU is located in. When the power domain
 is powered off, the IOMMU cannot be accessed and register programming
 must be deferred until the power domain becomes enabled.

 The solution implemented in this patch uses power domain notifications
 to perform necessary IOMMU initialization. Race with runtime PM core
 is avoided by protecting code accessing the hardware, including startup
 and shutdown functions, with a spinlock with a check for power state
 inside.

 Signed-off-by: Tomasz Figa tf...@chromium.org
 ---
  drivers/iommu/rockchip-iommu.c | 208 
 ++---
  1 file changed, 172 insertions(+), 36 deletions(-)

 diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
 index b2023af..9120655 100644
 --- a/drivers/iommu/rockchip-iommu.c
 +++ b/drivers/iommu/rockchip-iommu.c
 @@ -20,6 +20,8 @@
  #include linux/of.h
  #include linux/of_platform.h
  #include linux/platform_device.h
 +#include linux/pm_domain.h
 +#include linux/pm_runtime.h
  #include linux/slab.h
  #include linux/spinlock.h

 @@ -88,6 +90,9 @@ struct rk_iommu {
 int irq;
 struct list_head node; /* entry in rk_iommu_domain.iommus */
 struct iommu_domain *domain; /* domain to which iommu is attached */
 +   struct notifier_block genpd_nb;
 +   spinlock_t hw_lock; /* lock for register access */
 +   bool is_powered; /* power domain is on and register clock is enabled 
 */
  };

  static inline void rk_table_flush(u32 *va, unsigned int count)
 @@ -283,6 +288,9 @@ static void rk_iommu_zap_lines(struct rk_iommu *iommu, 
 dma_addr_t iova,
size_t size)
  {
 dma_addr_t iova_end = iova + size;
 +
 +   assert_spin_locked(iommu-hw_lock);
 +
 /*
  * TODO(djkurtz): Figure out when it is more efficient to shootdown 
 the
  * entire iotlb rather than iterate over individual iovas.
 @@ -293,11 +301,15 @@ static void rk_iommu_zap_lines(struct rk_iommu *iommu, 
 dma_addr_t iova,

  static bool rk_iommu_is_stall_active(struct rk_iommu *iommu)
  {
 +   assert_spin_locked(iommu-hw_lock);
 +
 return rk_iommu_read(iommu, RK_MMU_STATUS)  
 RK_MMU_STATUS_STALL_ACTIVE;
  }

  static bool rk_iommu_is_paging_enabled(struct rk_iommu *iommu)
  {
 +   assert_spin_locked(iommu-hw_lock);
 +
 return rk_iommu_read(iommu, RK_MMU_STATUS) 
  RK_MMU_STATUS_PAGING_ENABLED;
  }
 @@ -306,6 +318,8 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
  {
 int ret;

 +   assert_spin_locked(iommu-hw_lock);
 +
 if (rk_iommu_is_stall_active(iommu))
 return 0;

 @@ -327,6 +341,8 @@ static int rk_iommu_disable_stall(struct rk_iommu *iommu)
  {
 int ret;

 +   assert_spin_locked(iommu-hw_lock);
 +
 if (!rk_iommu_is_stall_active(iommu))
 return 0;

 @@ -344,6 +360,8 @@ static int rk_iommu_enable_paging(struct rk_iommu *iommu)
  {
 int ret;

 +   assert_spin_locked(iommu-hw_lock);
 +
 if (rk_iommu_is_paging_enabled(iommu))
 return 0;

 @@ -361,6 +379,8 @@ static int rk_iommu_disable_paging(struct rk_iommu *iommu)
  {
 int ret;

 +   assert_spin_locked(iommu-hw_lock);
 +
 if (!rk_iommu_is_paging_enabled(iommu))
 return 0;

 @@ -379,6 +399,8 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 int ret;
 u32 dte_addr;

 +   assert_spin_locked(iommu-hw_lock);
 +
 /*
  * Check if register DTE_ADDR is working by writing DTE_ADDR_DUMMY
  * and verifying that upper 5 nybbles are read back.
 @@ -401,6 +423,50 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 return ret;
  }

 +static int rk_iommu_startup(struct rk_iommu *iommu)
 +{
 +   struct iommu_domain *domain = iommu-domain;
 +   struct rk_iommu_domain *rk_domain;
 +   phys_addr_t dte_addr;
 +   int ret;
 +
 +   assert_spin_locked(iommu-hw_lock);
 +
 +   ret = rk_iommu_enable_stall(iommu);
 +   if (ret)
 +   return ret;
 +
 +   ret = rk_iommu_force_reset(iommu);
 +   if (ret)
 +   return ret;
 +
 +   rk_domain = domain-priv;
 +   dte_addr = virt_to_phys(rk_domain-dt);
 +   rk_iommu_write(iommu, RK_MMU_DTE_ADDR, dte_addr);
 +   rk_iommu_command(iommu, RK_MMU_CMD_ZAP_CACHE);
 +   rk_iommu_write(iommu, RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
 +
 +   ret = rk_iommu_enable_paging(iommu);
 +   if (ret)
 +   return ret;
 +
 +   rk_iommu_disable_stall(iommu);
 +
 +   return ret;
 +}
 +
 +static void rk_iommu_shutdown(struct rk_iommu *iommu)
 +{
 +   assert_spin_locked(iommu-hw_lock);
 +
 +   /* Ignore error while disabling, just keep going */
 +   

Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM

[Ulf Hansson]

On 11 December 2014 at 13:42, Tomasz Figa tf...@chromium.org wrote:
 Hi Ulf,

 On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 11 December 2014 at 09:26, Tomasz Figa tf...@chromium.org wrote:
 This patch modifies the rockchip-iommu driver to consider state of
 the power domain the IOMMU is located in. When the power domain
 is powered off, the IOMMU cannot be accessed and register programming
 must be deferred until the power domain becomes enabled.

 [snip]

 @@ -988,11 +1107,28 @@ static int rk_iommu_probe(struct platform_device 
 *pdev)
 return -ENXIO;
 }

 +   pm_runtime_no_callbacks(dev);
 +   pm_runtime_enable(dev);
 +
 +   /* Synchronize state of the domain with driver data. */
 +   pm_runtime_get_sync(dev);
 +   iommu-is_powered = true;

 Doesn't the runtime PM status reflect the value of is_powered, thus
 why do you need to have a copy of it? Could it perpahps be that you
 try to cope with the case when CONFIG_PM is unset?


 It's worth noting that this driver fully relies on status of other
 devices in the power domain the IOMMU is in and does not enforce the
 status on its own. So in general, as far as my understanding of PM
 runtime subsystem, the status of the IOMMU device will be always
 suspended, because nobody will call pm_runtime_get() on it (except the
 get and put pair in probe). So is_powered is here to track status of
 the domain, not the device. Feel free to suggest a better way, though.

I see, thanks for clarifying. I think it makes sense as is, I have no
better suggestion.

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 1/2] pm: Add PM domain notifications

[Ulf Hansson]

On 11 December 2014 at 14:54, Sylwester Nawrocki s.nawro...@samsung.com wrote:
 On 11/12/14 12:04, Tomasz Figa wrote:
 ...
  On 11/12/14 09:26, Tomasz Figa wrote:
   From: Sylwester Nawrocki s.nawro...@samsung.com
  
   This patch adds notifiers to the runtime PM/genpd subsystem. It is now
   possible to register a notifier, which will be called before and after
   the generic power domain subsystem calls the power domain's power_on
   and power_off callbacks.
  
   Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
   [tf...@chromium.org: rebased]
   Signed-off-by: Tomasz Figa tf...@chromium.org
 
  Not sure if you've noticed it, I posted an updated version of this patch
  recently [1]. The notifiers list is moved to struct generic_pm_domain
  there and it also allows to register a notifier for selected power domain
  by name.
 [snip]
  [1] http://www.spinics.net/lists/linux-samsung-soc/msg38549.html

 Ah, haven't noticed, sorry. The API using devices looks the same, so I
 guess we can simply have patch 2/2 of this series applied on top of
 your patch.

 Yes, that should work.

 By the way, look-up by name (presumably hardcoded somewhere?) sounds a
 bit strange to me. What was the reason for it to be added?

 Yes, that might not be a very elegant approach. We initially used it
 to implement power domain on/off sequence per specific domain and SoC,
 since it appeared resistant to generalize.  I.e. the control register
 write sequences are different per domain and per SoC (exynos).
 So we named the domains in the device tree in that way:

 pm_domains: pm-domains@10024000 {
 compatible = samsung,exynos4415-pd;
 reg-names = cam, tv, mfc, g3d,
 lcd0, isp0, isp1;
 reg = 0x10024000 0x20, 0x10024020 0x20,
   0x10024040 0x20, 0x10024060 0x20,
   0x10024080 0x20, 0x100240A0 0x20,
   0x100240E0 0x20;
 #power-domain-cells = 1;
 };

 and then, for example, in the exynos CMU_ISP{0, 1} (clock controller)
 driver registered for notification on isp0 and isp1 power domains
 (isp1 is a sub-domain of isp0 and the consumer devices are normally
 attached to isp1).

 We have been investigating if we could do without the notification
 at the clocks driver side, then the all SoC/power domain specific code
 would end up in the exynos power domain driver. But I'm afraid it's
 not going to work for all SoCs. Anyway lookup by name might be not
 needed.

Regarding lookup by name, let's please move away from those APIs. I
am planning to remove all name based API from the genpd API as soon as
I can.

If you need to fetch domains, this might help you:
http://www.spinics.net/lists/arm-kernel/msg383743.html

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM

[Ulf Hansson]

On 11 December 2014 at 16:31, Kevin Hilman khil...@kernel.org wrote:
 [+ Laurent Pinchart]

 Tomasz Figa tf...@chromium.org writes:

 On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson ulf.hans...@linaro.org wrote:

 [...]

 @@ -988,11 +1107,28 @@ static int rk_iommu_probe(struct platform_device 
 *pdev)
 return -ENXIO;
 }

 +   pm_runtime_no_callbacks(dev);
 +   pm_runtime_enable(dev);
 +
 +   /* Synchronize state of the domain with driver data. */
 +   pm_runtime_get_sync(dev);
 +   iommu-is_powered = true;

 Doesn't the runtime PM status reflect the value of is_powered, thus
 why do you need to have a copy of it? Could it perpahps be that you
 try to cope with the case when CONFIG_PM is unset?


 It's worth noting that this driver fully relies on status of other
 devices in the power domain the IOMMU is in and does not enforce the
 status on its own. So in general, as far as my understanding of PM
 runtime subsystem, the status of the IOMMU device will be always
 suspended, because nobody will call pm_runtime_get() on it (except the
 get and put pair in probe). So is_powered is here to track status of
 the domain, not the device. Feel free to suggest a better way, though.

 I still don't like these notifiers.  I think they add ways to bypass
 having proper runtime PM implemented for devices/subsystems.

I do agree, but I haven't found another good solution to the problem.


 From a high-level, the IOMMU is just another device inside the PM
 domain, so ideally it should be doing it's own _get() and _put() calls
 so the PM domain code would just do the right thing without the need for
 notifiers.

As I understand it, the IOMMU (or for other similar cases) shouldn't
be doing any get() and put() at all because there are no IO API to
serve request from.

In principle we could consider these kind devices as parent devices
to those other devices that needs them. Then runtime PM core would
take care of things for us, right!?

Now, I am not so sure using the parent approach is actually viable,
since it will likely have other complications, but I haven't
thoroughly thought it though yet.


 No knowing a lot about the IOMMU API, I'm guessing the reason you're not
 doing that is because the IOMMU API currently doesn't have an easy way
 to keep track of *active* users so it's not obvious where to put those
 _get and _put calls.  If that doesn't exist, perhaps a simple
 iommu_get() and iommu_put() API needs to be introduced (which inside the
 IOMMU core would just do runtime PM calls) so that users of the IOMMU
 could inform the subsystem that the IOMMU is needed and it should not be
 powered off.

 I Cc'd Laurent because I know he's thought about this before from the
 IOMMU side, and not sure if he came up with a solution.

Cool, let's see then.

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

[Ulf Hansson]

On 26 May 2016 at 06:05, Yangbo Lu  wrote:
> Hi Uffe,
>
> Could we merge this patchset? ...
> It has been a long time to wait for Arnd's response...
>
> Thanks a lot.
>
>

As we are still in the merge window I won't queue anything but fixes.
Let's give Arnd another week or so to respond.

Kind regards
Uffe

> Best regards,
> Yangbo Lu
>
>
>> -Original Message-
>> From: Yangbo Lu
>> Sent: Friday, May 20, 2016 2:06 PM
>> To: 'Scott Wood'; Arnd Bergmann; linux-arm-ker...@lists.infradead.org
>> Cc: linuxppc-...@lists.ozlabs.org; Mark Rutland;
>> devicet...@vger.kernel.org; ulf.hans...@linaro.org; Russell King; Bhupesh
>> Sharma; net...@vger.kernel.org; Joerg Roedel; Kumar Gala; linux-
>> m...@vger.kernel.org; linux-ker...@vger.kernel.org; Yang-Leo Li;
>> iommu@lists.linux-foundation.org; Rob Herring; linux-...@vger.kernel.org;
>> Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-...@vger.kernel.org;
>> Qiang Zhao
>> Subject: RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-
>> R1.0-R2.0
>>
>> Hi Arnd,
>>
>> Any comments?
>> Please reply when you see the email since we want this eSDHC issue to be
>> fixed soon.
>>
>> All the patches are Freescale-specific and is to fix the eSDHC driver.
>> Could we let them merged first if you were talking about a new way of
>> abstracting getting SoC version.
>>
>>
>> Thanks :)
>>
>>
>> Best regards,
>> Yangbo Lu
>>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v7, 0/5] Fix eSDHC host version register bug

[Ulf Hansson]

>>
>> I was about to queue this for next, when I noticed that checkpatch is
>> complaining/warning lots about these patches. Can you please a round of
>> checkpatch and fix what makes sense.
>>
>> Kind regards
>> Uffe
>
> [Lu Yangbo-B47093] Sorry about this, Uffe...

No worries!

> Should I ignore the warnings that update MAINTAINERS?

drivers/soc/fsl/guts.c isn't part of the MAINTAINERS file, it should be.

I also realize that the FREESCALE QUICC ENGINE LIBRARY section
drivers/soc/fsl/qe/* also need an active maintainer, as it's currently
orphan.

Perhaps we should have create a new section for drivers/soc/fsl/*
instead that covers all of the above? Maybe you or Scott are
interested to pick it up?

I also noted that, "include/linux/fsl/" isn't present in MAINTAINERS,
please add that as well.

> Regarding the 'undocumented' warning, I will added a patch updates doc before 
> all the patches, Ok?

Yes, good!

>
> Thanks a lot :)
>

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

[Ulf Hansson]

- decreasing the cc list significantly

On 1 April 2016 at 05:07, Yangbo Lu  wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
> a common header file. It has been used for mpc85xx and it will
> be used for ARM-based SoC as well.
>
> Signed-off-by: Yangbo Lu 
> Acked-by: Wolfram Sang 
> ---
> Changes for v2:
> - None
> Changes for v3:
> - None
> Changes for v4:
> - None
> Changes for v5:
> - Changed to Move mpc85xx.h to include/linux/fsl/
> - Adjusted '#include ' position in file
> Changes for v6:
> - None
> Changes for v7:
> - Added 'Acked-by: Wolfram Sang' for I2C part
> - Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
> ---
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
>  drivers/clk/clk-qoriq.c   | 3 +--
>  drivers/i2c/busses/i2c-mpc.c  | 2 +-
>  drivers/iommu/fsl_pamu.c  | 3 +--

Hi Joerg,

Could you have a look at the iommu parts here and provide your ack if
you like it.

I intend to queue this for 4.7 via my mmc tree, unless you see issues with that.

Kind regards
Uffe

>  drivers/net/ethernet/freescale/gianfar.c  | 2 +-
>  arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
>  6 files changed, 7 insertions(+), 9 deletions(-)
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 462aed9..2b0284e 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -13,13 +13,13 @@
>   *
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>
>  _GLOBAL(__e500_icache_setup)
> mfspr   r0, SPRN_L1CSR1
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 7bc1c45..fc7f722 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1148,8 +1149,6 @@ bad_args:
>  }
>
>  #ifdef CONFIG_PPC
> -#include 
> -
>  static const u32 a4510_svrs[] __initconst = {
> (SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
> (SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index 48ecffe..600704c 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -27,9 +27,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
> -#include 
>  #include 
>
>  #define DRV_NAME "mpc-i2c"
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index a34355f..af8fb27 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -21,11 +21,10 @@
>  #include "fsl_pamu.h"
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> -#include 
> -
>  /* define indexes for each operation mapping scenario */
>  #define OMI_QMAN0x00
>  #define OMI_FMAN0x01
> diff --git a/drivers/net/ethernet/freescale/gianfar.c 
> b/drivers/net/ethernet/freescale/gianfar.c
> index d2f917a..2224b10 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -86,11 +86,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #ifdef CONFIG_PPC
>  #include 
> -#include 
>  #endif
>  #include 
>  #include 
> diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
> similarity index 97%
> rename from arch/powerpc/include/asm/mpc85xx.h
> rename to include/linux/fsl/svr.h
> index 213f3a8..8d13836 100644
> --- a/arch/powerpc/include/asm/mpc85xx.h
> +++ b/include/linux/fsl/svr.h
> @@ -9,8 +9,8 @@
>   * (at your option) any later version.
>   */
>
> -#ifndef __ASM_PPC_MPC85XX_H
> -#define __ASM_PPC_MPC85XX_H
> +#ifndef FSL_SVR_H
> +#define FSL_SVR_H
>
>  #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
>  #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
> --
> 2.1.0.27.g96db324
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v7, 0/5] Fix eSDHC host version register bug

[Ulf Hansson]

On 1 April 2016 at 05:07, Yangbo Lu  wrote:
> This patchset is used to fix a host version register bug in the 
> T4240-R1.0-R2.0
> eSDHC controller. To get the SoC version and revision, it's needed to add the
> GUTS driver to access the global utilities registers.
>
> So, the first three patches are to add the GUTS driver.
> The following two patches are to enable GUTS driver support to get SVR in 
> eSDHC
> driver and fix host version for T4240.
>
> Yangbo Lu (5):
>   ARM64: dts: ls2080a: add device configuration node
>   soc: fsl: add GUTS driver for QorIQ platforms
>   dt: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 ++
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  23 
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|   8 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 119 
> +
>  include/linux/fsl/guts.h   |  98 -
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  15 files changed, 219 insertions(+), 58 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/guts.c
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>

I was about to queue this for next, when I noticed that checkpatch is
complaining/warning lots about these patches. Can you please a round
of checkpatch and fix what makes sense.

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v9, 6/7] MAINTAINERS: add entry for Freescale SoC driver

[Ulf Hansson]

On 4 May 2016 at 05:24, Yangbo Lu  wrote:
> Add maintainer entry for Freescale SoC driver including
> the QE library and the GUTS driver now. Also add maintainer
> for QE library.
>
> Signed-off-by: Yangbo Lu 

So I need an ack from Scott and Qiang for this one, then I intend to
queue up the series.

Kind regards
Uffe

> ---
> Changes for v8:
> - Added this patch
> Changes for v9:
> - Added linux-arm mail list
> - Removed GUTS driver entry
> ---
>  MAINTAINERS | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42e65d1..ce91db7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4622,9 +4622,18 @@ F:   drivers/net/ethernet/freescale/fec_ptp.c
>  F: drivers/net/ethernet/freescale/fec.h
>  F: Documentation/devicetree/bindings/net/fsl-fec.txt
>
> +FREESCALE SOC DRIVER
> +M: Scott Wood 
> +L: linuxppc-...@lists.ozlabs.org
> +L: linux-arm-ker...@lists.infradead.org
> +S: Maintained
> +F: drivers/soc/fsl/
> +F: include/linux/fsl/
> +
>  FREESCALE QUICC ENGINE LIBRARY
> +M: Qiang Zhao 
>  L: linuxppc-...@lists.ozlabs.org
> -S: Orphan
> +S: Maintained
>  F: drivers/soc/fsl/qe/
>  F: include/soc/fsl/*qe*.h
>  F: include/soc/fsl/*ucc*.h
> --
> 2.1.0.27.g96db324
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [v11, 7/8] base: soc: introduce soc_device_match() interface

[Ulf Hansson]

On 6 September 2016 at 10:28, Yangbo Lu  wrote:
> We keep running into cases where device drivers want to know the exact
> version of the a SoC they are currently running on. In the past, this has
> usually been done through a vendor specific API that can be called by a
> driver, or by directly accessing some kind of version register that is
> not part of the device itself but that belongs to a global register area
> of the chip.
>
> Common reasons for doing this include:
>
> - A machine is not using devicetree or similar for passing data about
>   on-chip devices, but just announces their presence using boot-time
>   platform devices, and the machine code itself does not care about the
>   revision.
>
> - There is existing firmware or boot loaders with existing DT binaries
>   with generic compatible strings that do not identify the particular
>   revision of each device, but the driver knows which SoC revisions
>   include which part.
>
> - A prerelease version of a chip has some quirks and we are using the same
>   version of the bootloader and the DT blob on both the prerelease and the
>   final version. An update of the DT binding seems inappropriate because
>   that would involve maintaining multiple copies of the dts and/or
>   bootloader.
>
> This patch introduces the soc_device_match() interface that is meant to
> work like of_match_node() but instead of identifying the version of a
> device, it identifies the SoC itself using a vendor-agnostic interface.
>
> Unlike of_match_node(), we do not do an exact string compare but instead
> use glob_match() to allow wildcards in strings.

Overall, this change make sense to me, although some minor comment below.

>
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v11:
> - Added this patch for soc match
> ---
>  drivers/base/Kconfig|  1 +
>  drivers/base/soc.c  | 61 
> +
>  include/linux/sys_soc.h |  3 +++
>  3 files changed, 65 insertions(+)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 98504ec..f1591ad2 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
>
>  config SOC_BUS
> bool
> +   select GLOB
>
>  source "drivers/base/regmap/Kconfig"
>
> diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> index 75b98aa..5c4e84a 100644
> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static DEFINE_IDA(soc_ida);
>
> @@ -168,3 +169,63 @@ static void __exit soc_bus_unregister(void)
> bus_unregister(_bus_type);
>  }
>  module_exit(soc_bus_unregister);
> +
> +static int soc_device_match_one(struct device *dev, void *arg)
> +{
> +   struct soc_device *soc_dev = container_of(dev, struct soc_device, 
> dev);
> +   const struct soc_device_attribute *match = arg;
> +
> +   if (match->machine &&
> +   !glob_match(match->machine, soc_dev->attr->machine))
> +   return 0;
> +
> +   if (match->family &&
> +   !glob_match(match->family, soc_dev->attr->family))
> +   return 0;
> +
> +   if (match->revision &&
> +   !glob_match(match->revision, soc_dev->attr->revision))
> +   return 0;
> +
> +   if (match->soc_id &&
> +   !glob_match(match->soc_id, soc_dev->attr->soc_id))
> +   return 0;
> +
> +   return 1;
> +}
> +
> +/*
> + * soc_device_match - identify the SoC in the machine
> + * @matches: zero-terminated array of possible matches

Perhaps also express the constraint on the matching entries. As you
need at least one of the ->machine(), ->family(), ->revision() or
->soc_id() callbacks implemented, right!?

> + *
> + * returns the first matching entry of the argument array, or NULL
> + * if none of them match.
> + *
> + * This function is meant as a helper in place of of_match_node()
> + * in cases where either no device tree is available or the information
> + * in a device node is insufficient to identify a particular variant
> + * by its compatible strings or other properties. For new devices,
> + * the DT binding should always provide unique compatible strings
> + * that allow the use of of_match_node() instead.
> + *
> + * The calling function can use the .data entry of the
> + * soc_device_attribute to pass a structure or function pointer for
> + * each entry.

I don't get the use case behind this, could you elaborate?

Perhaps we should postpone adding the .data entry until we actually
see a need for it?

> + */
> +const struct soc_device_attribute *soc_device_match(
> +   const struct soc_device_attribute *matches)
> +{
> +   struct device *dev;
> +   int ret;
> +
> +   for (ret = 0; ret == 0; matches++) {

This loop looks a bit weird and unsafe.

1) Perhaps using a while loop makes this more readable?
2) As this is an 

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[Ulf Hansson]

[...]

>>>
 To solve this problem, I was thinking we could convert to use the
 asynchronous pm_runtime_get() API, when trying to runtime resume the
 device from atomic contexts.
>>>
>>> I'm not sure if this will work for DMA engine devices. If I understand
>>> correctly some client's of DMA engine device might rely on the DMA
>>> engine being configured and operational after queuing a request and
>>> they might lock up if the DMA engine device activation if postponed
>>> because of async runtime pm activation.
>>
>> I didn't know about this. If you have an example from the top of your
>> head, could you perhaps point me to it?
>
>
> No, I don't have any example. This is just my fear that there might be some
> hardware which works this way. I can imagine a driver, which queue dma
> engine
> request and then triggers 'start' command to its hw block. HW blocks usually
> uses some additional signal lines for DMA, so the HW block might check if
> all
> needed signals from DMA engine HW are ready. If not it will fail to start
> avoid lockup of starting without DMA engine HW being ready.

Well, I think this reasoning makes lots of sense! Clearly we wouldn't
be able to guarantee that there's isn't a glitch in an undefined HW
behaviour.

I will drop my suggested approach and try out another one.

>
> However I don't have much experience with DMA engine and drivers. I only
> helped in adding DMA engine support to Samsung UART driver and in the
> hardware manual there is information about additional lines between DMA
> controller and UART module, which are used in the DMA mode.

Thanks for sharing your experience!

Now, I should allow you to get back to the original review! :-)

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[Ulf Hansson]

[...]

>
>
> There are some similarities between IOMMU and DMA engine devices (serial
> drivers are imho completely different case). Both hw blocks do their work
> on behalf of some other hardware block, which I will call master device.
> DMA engine performs some DMA transaction on master's device request, while
> IOMMU usually sits between system memory and master's device memory
> interface, remapping addresses of each DMA transaction according to its
> configuration and provided mapping tables (master device has some kind
> of internal DMA controller and performs DMA transactions on their own).
> IOMMU is usually used for a) mapping physically discontinuous memory into
> contiguous DMA addresses and b) isolating devices, so they can access
> only memory, which is dedicated or allocated for them.
>
> DMA engine devices provide explicit API for their master's device drivers,
> while IOMMU drivers are usually hidden behind DMA-mapping API (for most
> use cases, although it would be possible for master's device driver to
> call IOMMU API directly and some GPU/DRM drivers do that).
>
> However from runtime pm perspective the DMA engine and IOMMU devices are
> a bit different.
>
> DMA engine drivers have well defined start and end of operation (queuing
> dma request and irq from hw about having it finished). During that time
> the device has to be runtime active all the time. The problem with using
> current implementation of runtime pm is the fact that both start and end
> of operation can be triggered from atomic context, what is not really
> suitable for runtime pm. So the problem is mainly about API
> incompatibility and lack of something like dma_engine_prepare()/unprepare()
> (as an analogy to clocks api).

That's also a viable option. Although, DMA clients would then need to
invoke such APIs from non-atomic contexts. Typically that would be
from client driver's runtime PM callbacks.

Me personally would rather avoid such solution, as it would sprinkle
lots of drivers to deal with this. Although, perhaps this is the only
option that actually works.

>
> In case of IOMMU the main problem is determining weather IOMMU controller
> has to be activated. There is no calls in IOMMU and DMA-mapping API, which
> would bracket all DMA transactions performed by the master device. Someone
> proposed to keep IOMMU runtime active when there exist at least one
> mapping created by the IOMMU/DMA-mapping layers. This however does not
> cover all the cases. In case of our IOMMU, when it is disabled or runtime
> suspended, it enters "pass-thought" mode, so master device can still
> perform DMA operations with identity mappings (so DMA address equals to
> physical memory address). Till now Exynos IOMMU called pm_runtime_get()
> on attaching to the iommu domain (what happens during initialization of
> dma-mapping structures for given master device) and kept it active all
> the time.
>
> This patch series tries to address Exynos IOMMU runtime pm issue by forcing
> IOMMU controller to follow runtime pm status of its master device. This way
> we ensure that anytime when master's device is runtime activated, the iommu
> will be also active and master device won't be able to bypass during its
> DMA transactions mappings created by the IOMMU layer.
>
> Quite long answer, but I hope I managed to give you a bit more background
> on this topic.

Yes, indeed. Thank you for taking the time to respond!

>
>> As we know, using the pm_runtime_irq_safe() option comes with some
>> limitations, such as the runtime PM callbacks is not allowed to sleep.
>> For a PM domain (genpd) that is attached to the device, this also
>> means it must not be powered off.
>
>
> Right, if possible I would like to avoid using pm_runtime_irq_safe()
> option, because it is really impractical.
>
>> To solve this problem, I was thinking we could convert to use the
>> asynchronous pm_runtime_get() API, when trying to runtime resume the
>> device from atomic contexts.
>
>
> I'm not sure if this will work for DMA engine devices. If I understand
> correctly some client's of DMA engine device might rely on the DMA
> engine being configured and operational after queuing a request and
> they might lock up if the DMA engine device activation if postponed
> because of async runtime pm activation.

I didn't know about this. If you have an example from the top of your
head, could you perhaps point me to it?

[...]

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[Ulf Hansson]

On 13 September 2016 at 14:49, Marek Szyprowski
 wrote:
> This patch uses recently introduced device links to track the runtime pm
> state of the master's device. This way each SYSMMU controller is runtime
> activated when its master's device is active and can save/restore its state
> instead of being enabled all the time. This way SYSMMU controllers no
> longer prevents respective power domains to be turned off when master's
> device is not used.

Apologize for not reviewing earlier and if you find my
questions/suggestions being silly. You may ignore them, if you don't
think they deserves a proper answer. :-)

I am not so familiar with the IOMMU subsystem, but I am wondering
whether the issue you are solving, is similar to what can be observed
for DMA and serial drivers. And of course also for other IOMMU
drivers.

In general the DMA/serial drivers requires to use the
pm_runtime_irq_safe() option, to be able to easily deploy runtime PM
support (of course there are some other workarounds as well).

As we know, using the pm_runtime_irq_safe() option comes with some
limitations, such as the runtime PM callbacks is not allowed to sleep.
For a PM domain (genpd) that is attached to the device, this also
means it must not be powered off.

To solve this problem, I was thinking we could convert to use the
asynchronous pm_runtime_get() API, when trying to runtime resume the
device from atomic contexts.

Of course when it turns out that the device isn't yet runtime resumed
immediately after calling pm_runtime_get(), the request needs to be
put on a request queue to be managed shortly after instead. Doing it
like this, would remove the need to use the pm_runtime_irq_safe()
option.

I realize that such change needs to be implemented in common code for
IOMMU drivers, if at all possible.

Anyway, I hope you at least get the idea and I just wanted to mention
that I have been exploring this option for DMA and serial drivers.

Kind regards
Uffe

>
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/iommu/exynos-iommu.c | 225 
> ++-
>  1 file changed, 94 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index b0fa4d432e71..34717a0b1902 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -206,6 +206,7 @@ static const struct sysmmu_fault_info sysmmu_v5_faults[] 
> = {
>  struct exynos_iommu_owner {
> struct list_head controllers;   /* list of sysmmu_drvdata.owner_node 
> */
> struct iommu_domain *domain;/* domain this device is attached */
> +   struct mutex rpm_lock;  /* for runtime pm of all sysmmus */
>  };
>
>  /*
> @@ -237,8 +238,8 @@ struct sysmmu_drvdata {
> struct clk *aclk;   /* SYSMMU's aclk clock */
> struct clk *pclk;   /* SYSMMU's pclk clock */
> struct clk *clk_master; /* master's device clock */
> -   int activations;/* number of calls to sysmmu_enable */
> spinlock_t lock;/* lock for modyfying state */
> +   int active; /* current status */
> struct exynos_iommu_domain *domain; /* domain we belong to */
> struct list_head domain_node;   /* node for domain clients list */
> struct list_head owner_node;/* node for owner controllers list */
> @@ -251,25 +252,6 @@ static struct exynos_iommu_domain 
> *to_exynos_domain(struct iommu_domain *dom)
> return container_of(dom, struct exynos_iommu_domain, domain);
>  }
>
> -static bool set_sysmmu_active(struct sysmmu_drvdata *data)
> -{
> -   /* return true if the System MMU was not active previously
> -  and it needs to be initialized */
> -   return ++data->activations == 1;
> -}
> -
> -static bool set_sysmmu_inactive(struct sysmmu_drvdata *data)
> -{
> -   /* return true if the System MMU is needed to be disabled */
> -   BUG_ON(data->activations < 1);
> -   return --data->activations == 0;
> -}
> -
> -static bool is_sysmmu_active(struct sysmmu_drvdata *data)
> -{
> -   return data->activations > 0;
> -}
> -
>  static void sysmmu_unblock(struct sysmmu_drvdata *data)
>  {
> writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
> @@ -389,7 +371,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
> unsigned short reg_status, reg_clear;
> int ret = -ENOSYS;
>
> -   WARN_ON(!is_sysmmu_active(data));
> +   WARN_ON(!data->active);
>
> if (MMU_MAJ_VER(data->version) < 5) {
> reg_status = REG_INT_STATUS;
> @@ -435,40 +417,19 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void 
> *dev_id)
> return IRQ_HANDLED;
>  }
>
> -static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
> +static void __sysmmu_disable(struct sysmmu_drvdata *data)
>  {
> +   unsigned long flags;
> +
> 

Re: [v12, 0/8] Fix eSDHC host version register bug

[Ulf Hansson]

On 21 September 2016 at 08:57, Yangbo Lu  wrote:
> This patchset is used to fix a host version register bug in the 
> T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only 
> available
> method left now. This v11 patchset introduces the soc_device_match interface 
> in
> soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
>   base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
>   dt: bindings: update Freescale DCFG compatible
>   ARM64: dts: ls2080a: add device configuration node
>   dt: bindings: move guts devicetree doc out of powerpc directory
>   powerpc/fsl: move mpc85xx.h to include/linux/fsl
>   soc: fsl: add GUTS driver for QorIQ platforms
>   MAINTAINERS: add entry for Freescale SoC drivers
>   mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
>  Documentation/devicetree/bindings/arm/fsl.txt  |   6 +-
>  .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
>  MAINTAINERS|  11 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 +
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
>  arch/powerpc/sysdev/fsl_pci.c  |   2 +-
>  drivers/base/Kconfig   |   1 +
>  drivers/base/soc.c |  66 ++
>  drivers/clk/clk-qoriq.c|   3 +-
>  drivers/i2c/busses/i2c-mpc.c   |   2 +-
>  drivers/iommu/fsl_pamu.c   |   3 +-
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/sdhci-of-esdhc.c  |  20 ++
>  drivers/net/ethernet/freescale/gianfar.c   |   2 +-
>  drivers/soc/Kconfig|   2 +-
>  drivers/soc/fsl/Kconfig|  19 ++
>  drivers/soc/fsl/Makefile   |   1 +
>  drivers/soc/fsl/guts.c | 257 
> +
>  include/linux/fsl/guts.h   | 125 ++
>  .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
>  include/linux/sys_soc.h|   3 +
>  21 files changed, 478 insertions(+), 61 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/guts.c
>  rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>

This looks good to me! I am not sure which tree you want this to be
picked up through, but unless no other volunteers I can take it
through my mmc tree.

Although, before considering to apply, I need an ack from Scott/Arnd
for the guts driver in patch 5/8 and I need an ack from Greg for patch
7/8, where the soc_device_match() interface is added (seems like you
didn't add him on cc/to).

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

[Ulf Hansson]

On 17 April 2018 at 19:49, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> Reviewed-by: Mark Brown <broo...@kernel.org>
> Acked-by: Robin Murphy <robin.mur...@arm.com>
> Acked-by: Ulf Hansson <ulf.hans...@linaro.org>

Thanks, applied for next!

Kind regrds
Uffe

> ---
> v3:
>   - Add Acked-by,
>   - Rebase to v4.17-rc1,
>
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/mmc/host/Kconfig | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 9589f9c9046f14b1..3978d0418958bf6b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
> tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller 
> support"
> depends on ARCH_MESON || COMPILE_TEST
> depends on COMMON_CLK
> -   depends on HAS_DMA
> depends on OF
> help
>   This selects support for the SD/MMC Host Controller on
> @@ -401,7 +400,6 @@ config MMC_OMAP
>
>  config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
> help
>   This selects the TI OMAP High Speed Multimedia card Interface.
> @@ -511,7 +509,6 @@ config MMC_DAVINCI
>
>  config MMC_GOLDFISH
> tristate "goldfish qemu Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on GOLDFISH || COMPILE_TEST
> help
>   This selects the Goldfish Multimedia card Interface emulation
> @@ -605,7 +602,7 @@ config MMC_SDHI
>
>  config MMC_SDHI_SYS_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if (SUPERH || ARM)
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
>  config MMC_SDHI_INTERNAL_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using on-chip bus 
> mastering"
> depends on ARM64 || COMPILE_TEST
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if ARM64
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
>
>  config MMC_DW
> tristate "Synopsys DesignWare Memory Card Interface"
> -   depends on HAS_DMA
> depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
> help
>   This selects support for the Synopsys DesignWare Mobile Storage IP
> @@ -748,7 +744,6 @@ config MMC_DW_ZX
>
>  config MMC_SH_MMCIF
> tristate "SuperH Internal MMCIF support"
> -   depends on HAS_DMA
> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> help
>   This selects the MMC Host Interface controller (MMCIF) found in 
> various
> @@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
>  config MMC_BCM2835
> tristate "Broadcom BCM2835 SDHOST MMC Controller support"
> depends on ARCH_BCM2835 || COMPILE_TEST
> -   depends on HAS_DMA
> help
>   This selects the BCM2835 SDHOST MMC controller. If you have
>   a BCM2835 platform with SD or MMC devices, say Y or M here.
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency

[Ulf Hansson]

On 16 March 2018 at 14:51, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> Reviewed-by: Mark Brown <broo...@kernel.org>
> Acked-by: Robin Murphy <robin.mur...@arm.com>

Acked-by: Ulf Hansson <ulf.hans...@linaro.org>

> ---
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Drop RFC state,
>   - Split per subsystem.
> ---
>  drivers/mmc/host/Kconfig | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 620c2d90a646f387..f6d43348b4a3e5d4 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
> tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller 
> support"
> depends on ARCH_MESON || COMPILE_TEST
> depends on COMMON_CLK
> -   depends on HAS_DMA
> depends on OF
> help
>   This selects support for the SD/MMC Host Controller on
> @@ -401,7 +400,6 @@ config MMC_OMAP
>
>  config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
> help
>   This selects the TI OMAP High Speed Multimedia card Interface.
> @@ -511,7 +509,6 @@ config MMC_DAVINCI
>
>  config MMC_GOLDFISH
> tristate "goldfish qemu Multimedia Card Interface support"
> -   depends on HAS_DMA
> depends on GOLDFISH || COMPILE_TEST
> help
>   This selects the Goldfish Multimedia card Interface emulation
> @@ -605,7 +602,7 @@ config MMC_SDHI
>
>  config MMC_SDHI_SYS_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if (SUPERH || ARM)
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
>  config MMC_SDHI_INTERNAL_DMAC
> tristate "DMA for SDHI SD/SDIO controllers using on-chip bus 
> mastering"
> depends on ARM64 || COMPILE_TEST
> -   depends on MMC_SDHI && HAS_DMA
> +   depends on MMC_SDHI
> default MMC_SDHI if ARM64
> help
>   This provides DMA support for SDHI SD/SDIO controllers
> @@ -688,7 +685,6 @@ config MMC_CAVIUM_THUNDERX
>
>  config MMC_DW
> tristate "Synopsys DesignWare Memory Card Interface"
> -   depends on HAS_DMA
> depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
> help
>   This selects support for the Synopsys DesignWare Mobile Storage IP
> @@ -758,7 +754,6 @@ config MMC_DW_ZX
>
>  config MMC_SH_MMCIF
> tristate "SuperH Internal MMCIF support"
> -   depends on HAS_DMA
> depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> help
>   This selects the MMC Host Interface controller (MMCIF) found in 
> various
> @@ -878,7 +873,6 @@ config MMC_TOSHIBA_PCI
>  config MMC_BCM2835
> tristate "Broadcom BCM2835 SDHOST MMC Controller support"
> depends on ARCH_BCM2835 || COMPILE_TEST
> -   depends on HAS_DMA
> help
>   This selects the BCM2835 SDHOST MMC controller. If you have
>   a BCM2835 platform with SD or MMC devices, say Y or M here.
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops

[Ulf Hansson]

On 30 August 2018 at 16:45, Vivek Gautam  wrote:
> From: Sricharan R 
>
> The smmu needs to be functional only when the respective
> master's using it are active. The device_link feature
> helps to track such functional dependencies, so that the
> iommu gets powered when the master device enables itself
> using pm_runtime. So by adapting the smmu driver for
> runtime pm, above said dependency can be addressed.
>
> This patch adds the pm runtime/sleep callbacks to the
> driver and also the functions to parse the smmu clocks
> from DT and enable them in resume/suspend.
>
> Also, while we enable the runtime pm add a pm sleep suspend
> callback that pushes devices to low power state by turning
> the clocks off in a system sleep.
> Also add corresponding clock enable path in resume callback.
>
> Signed-off-by: Sricharan R 
> Signed-off-by: Archit Taneja 
> [vivek: rework for clock and pm ops]
> Signed-off-by: Vivek Gautam 
> Reviewed-by: Tomasz Figa 
> Tested-by: Srinivas Kandagatla 
> ---
>  drivers/iommu/arm-smmu.c | 77 
> ++--
>  1 file changed, 74 insertions(+), 3 deletions(-)
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c

[...]

> -static int __maybe_unused arm_smmu_pm_resume(struct device *dev)
> +static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
>  {
> struct arm_smmu_device *smmu = dev_get_drvdata(dev);
> +   int ret;
> +
> +   ret = clk_bulk_enable(smmu->num_clks, smmu->clks);
> +   if (ret)
> +   return ret;
>
> arm_smmu_device_reset(smmu);
> +
> return 0;
>  }
>
> -static SIMPLE_DEV_PM_OPS(arm_smmu_pm_ops, NULL, arm_smmu_pm_resume);
> +static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
> +{
> +   struct arm_smmu_device *smmu = dev_get_drvdata(dev);
> +
> +   clk_bulk_disable(smmu->num_clks, smmu->clks);
> +
> +   return 0;
> +}
> +
> +static int __maybe_unused arm_smmu_pm_resume(struct device *dev)
> +{
> +   if (pm_runtime_suspended(dev))
> +   return 0;

Looks like you should be able use pm_runtime_force_resume(), instead
of using this local trick. Unless I am missing something, of course.

In other words, just assign the system sleep callbacks for resume, to
pm_runtime_force_resume(). And vice verse for the system suspend
callbacks, pm_runtime_force_suspend(), of course.

> +
> +   return arm_smmu_runtime_resume(dev);
> +}
> +
> +static int __maybe_unused arm_smmu_pm_suspend(struct device *dev)
> +{
> +   if (pm_runtime_suspended(dev))
> +   return 0;
> +
> +   return arm_smmu_runtime_suspend(dev);
> +}
> +
> +static const struct dev_pm_ops arm_smmu_pm_ops = {
> +   SET_SYSTEM_SLEEP_PM_OPS(arm_smmu_pm_suspend, arm_smmu_pm_resume)

I am wondering if using the ->suspend|resume() callback is really
"late/early" enough in the device suspend phase?

Others is using the noirq phase and some is even using the syscore
ops. Of course it depends on the behavior of the consumers of iommu
device, and I guess not everyone is using device links, which for sure
improves things in this regards as well.

> +   SET_RUNTIME_PM_OPS(arm_smmu_runtime_suspend,
> +  arm_smmu_runtime_resume, NULL)
> +};
>
>  static struct platform_driver arm_smmu_driver = {
> .driver = {
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>

BTW, apologize for very late review comments.

Besides the above comments, the series looks good to me.

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: remove block layer bounce buffering for MMC

[Ulf Hansson]

+Linus Walleij (recently made a cleanup of the mmc bounce buffering code).

On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig  wrote:
>
> Hi everyone,
>
> this series converts the remaining MMC host drivers to properly kmap the
> scatterlist entries it does PIO operations on, and then goes on to
> remove the usage of block layer bounce buffering (which I plan to remove
> eventually) from the MMC layer.
>
> As a bonus I've converted various drivers to the proper scatterlist
> helpers so that at least in theory they are ready for chained
> scatterlists.
>
> All the changes are compile tested only as I don't have any of the
> hardware, so a careful review would be appreciated.

Thanks for posting this. I will have a look as soon as I can, but
first needs to catch up with things since the holidays.

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: remove block layer bounce buffering for MMC v2

[Ulf Hansson]

On Tue, 12 Feb 2019 at 08:25, Christoph Hellwig  wrote:
>
> Hi everyone,
>
> this series converts the remaining MMC host drivers to properly kmap the
> scatterlist entries it does PIO operations on, and then goes on to
> remove the usage of block layer bounce buffering (which I plan to remove
> eventually) from the MMC layer.
>
> As a bonus I've converted various drivers to the proper scatterlist
> helpers so that at least in theory they are ready for chained
> scatterlists.
>
> All the changes are compile tested only as I don't have any of the
> hardware, so a careful review would be appreciated.
>
> Changes since v1:
>  - fix a missing kunmap_atomic in mvsdio
>  - fix a stray whitespace in s3cmci
>  - add new sg_kmap_atomic and sg_kunmap_atomic helpers
>  - set the DMA and block layer dma boundary
>  - use pointer arithmetics to reduce the amount of changes in
>various drivers
>

This looks good to me, however the lack of feedback/tests worries me a
bit. So, unless you think it's a bad idea, I intend to apply this when
v5.1 rc1 is out, which allows a lengthy test period in linux-next.

Make sense?

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: remove block layer bounce buffering for MMC v2

[Ulf Hansson]

On Fri, 8 Mar 2019 at 10:18, Christoph Hellwig  wrote:
>
> On Mon, Feb 25, 2019 at 02:54:13PM +0100, Ulf Hansson wrote:
> > This looks good to me, however the lack of feedback/tests worries me a
> > bit. So, unless you think it's a bad idea, I intend to apply this when
> > v5.1 rc1 is out, which allows a lengthy test period in linux-next.
>
> Please don't rush to merge this.  Based on a talk to some folks I
> have an idea for a sg iterator that can hide the kmapping from
> the drivers, which should allow for some less scary driver code and
> clean this up a bit further.

Okay, I see. Thanks for letting me know!

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 05/11] mmc: s3cmci: handle highmem pages

[Ulf Hansson]

On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig  wrote:
>
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
>
> Signed-off-by: Christoph Hellwig 

Nitpick: This one have some trailing whitespace errors, which git
complains about when I apply it.

No need to re-spin due to this, I can fix it  up.

Kind regards
Uffe

> ---
>  drivers/mmc/host/s3cmci.c | 107 +++---
>  drivers/mmc/host/s3cmci.h |   3 +-
>  2 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index 10f5219b3b40..1be84426c817 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -317,26 +318,17 @@ static void s3cmci_check_sdio_irq(struct s3cmci_host 
> *host)
> }
>  }
>
> -static inline int get_data_buffer(struct s3cmci_host *host,
> - u32 *bytes, u32 **pointer)
> +static inline int get_data_buffer(struct s3cmci_host *host)
>  {
> -   struct scatterlist *sg;
> -
> -   if (host->pio_active == XFER_NONE)
> -   return -EINVAL;
> -
> -   if ((!host->mrq) || (!host->mrq->data))
> -   return -EINVAL;
> -
> if (host->pio_sgptr >= host->mrq->data->sg_len) {
> dbg(host, dbg_debug, "no more buffers (%i/%i)\n",
>   host->pio_sgptr, host->mrq->data->sg_len);
> return -EBUSY;
> }
> -   sg = >mrq->data->sg[host->pio_sgptr];
> +   host->cur_sg = >mrq->data->sg[host->pio_sgptr];
>
> -   *bytes = sg->length;
> -   *pointer = sg_virt(sg);
> +   host->pio_bytes = host->cur_sg->length;
> +   host->pio_offset = host->cur_sg->offset;
>
> host->pio_sgptr++;
>
> @@ -422,11 +414,16 @@ static void s3cmci_disable_irq(struct s3cmci_host 
> *host, bool transfer)
>
>  static void do_pio_read(struct s3cmci_host *host)
>  {
> -   int res;
> u32 fifo;
> u32 *ptr;
> u32 fifo_words;
> void __iomem *from_ptr;
> +   void *buf;
> +
> +   if (host->pio_active == XFER_NONE)
> +   goto done;
> +   if (!host->mrq || !host->mrq->data)
> +   goto done;
>
> /* write real prescaler to host, it might be set slow to fix */
> writel(host->prescaler, host->base + S3C2410_SDIPRE);
> @@ -435,20 +432,12 @@ static void do_pio_read(struct s3cmci_host *host)
>
> while ((fifo = fifo_count(host))) {
> if (!host->pio_bytes) {
> -   res = get_data_buffer(host, >pio_bytes,
> - >pio_ptr);
> -   if (res) {
> -   host->pio_active = XFER_NONE;
> -   host->complete_what = COMPLETION_FINALIZE;
> -
> -   dbg(host, dbg_pio, "pio_read(): "
> -   "complete (no more data).\n");
> -   return;
> -   }
> +   if (get_data_buffer(host) < 0)
> +   goto done;
>
> dbg(host, dbg_pio,
> -   "pio_read(): new target: [%i]@[%p]\n",
> -   host->pio_bytes, host->pio_ptr);
> +   "pio_read(): new target: [%i]@[%zu]\n",
> +   host->pio_bytes, host->pio_offset);
> }
>
> dbg(host, dbg_pio,
> @@ -470,63 +459,65 @@ static void do_pio_read(struct s3cmci_host *host)
> host->pio_count += fifo;
>
> fifo_words = fifo >> 2;
> -   ptr = host->pio_ptr;
> -   while (fifo_words--)
> +
> +   buf = (kmap_atomic(sg_page(host->cur_sg)) + host->pio_offset);
> +   ptr = buf;
> +   while (fifo_words--) {
> *ptr++ = readl(from_ptr);
> -   host->pio_ptr = ptr;
> +   host->pio_offset += 4;
> +   }
>
> if (fifo & 3) {
> u32 n = fifo & 3;
> u32 data = readl(from_ptr);
> -   u8 *p = (u8 *)host->pio_ptr;
> +   u8 *p = (u8 *)ptr;
>
> while (n--) {
> *p++ = data;
> data >>= 8;
> +   host->pio_offset++;
> }
> }
> +   kunmap_atomic(buf);
> }
>
> if (!host->pio_bytes) {
> -   res = get_data_buffer(host, >pio_bytes, >pio_ptr);
> -   if (res) {
> -   dbg(host, dbg_pio,
> -  

Re: [PATCH 07/11] mmc: mvsdio: handle highmem pages

[Ulf Hansson]

On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig  wrote:
>
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/mmc/host/mvsdio.c | 48 +++
>  1 file changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
> index e22bbff89c8d..545e370d6dae 100644
> --- a/drivers/mmc/host/mvsdio.c
> +++ b/drivers/mmc/host/mvsdio.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -42,7 +43,8 @@ struct mvsd_host {
> unsigned int intr_en;
> unsigned int ctrl;
> unsigned int pio_size;
> -   void *pio_ptr;
> +   struct scatterlist *pio_sg;
> +   unsigned int pio_offset; /* offset in words into the segment */
> unsigned int sg_frags;
> unsigned int ns_per_clk;
> unsigned int clock;
> @@ -96,9 +98,9 @@ static int mvsd_setup_data(struct mvsd_host *host, struct 
> mmc_data *data)
> if (tmout_index > MVSD_HOST_CTRL_TMOUT_MAX)
> tmout_index = MVSD_HOST_CTRL_TMOUT_MAX;
>
> -   dev_dbg(host->dev, "data %s at 0x%08x: blocks=%d blksz=%d tmout=%u 
> (%d)\n",
> +   dev_dbg(host->dev, "data %s at 0x%08llx: blocks=%d blksz=%d tmout=%u 
> (%d)\n",
> (data->flags & MMC_DATA_READ) ? "read" : "write",
> -   (u32)sg_virt(data->sg), data->blocks, data->blksz,
> +   (u64)sg_phys(data->sg), data->blocks, data->blksz,
> tmout, tmout_index);
>
> host->ctrl &= ~MVSD_HOST_CTRL_TMOUT_MASK;
> @@ -118,10 +120,11 @@ static int mvsd_setup_data(struct mvsd_host *host, 
> struct mmc_data *data)
>  * boundary.
>  */
> host->pio_size = data->blocks * data->blksz;
> -   host->pio_ptr = sg_virt(data->sg);
> +   host->pio_sg = data->sg;
> +   host->pio_offset = data->sg->offset / 2;
> if (!nodma)
> -   dev_dbg(host->dev, "fallback to PIO for data at 0x%p 
> size %d\n",
> -   host->pio_ptr, host->pio_size);
> +   dev_dbg(host->dev, "fallback to PIO for data at 0x%x 
> size %d\n",
> +   host->pio_offset, host->pio_size);
> return 1;
> } else {
> dma_addr_t phys_addr;
> @@ -291,8 +294,9 @@ static u32 mvsd_finish_data(struct mvsd_host *host, 
> struct mmc_data *data,
>  {
> void __iomem *iobase = host->base;
>
> -   if (host->pio_ptr) {
> -   host->pio_ptr = NULL;
> +   if (host->pio_sg) {
> +   host->pio_sg = NULL;
> +   host->pio_offset = 0;
> host->pio_size = 0;
> } else {
> dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->sg_frags,
> @@ -376,11 +380,12 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
> if (host->pio_size &&
> (intr_status & host->intr_en &
>  (MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W))) {
> -   u16 *p = host->pio_ptr;
> +   u16 *p = kmap_atomic(sg_page(host->pio_sg));

Seems like a corresponding kunmap_atomic() is missing somewhere.

> +   unsigned int o = host->pio_offset;
> int s = host->pio_size;
> while (s >= 32 && (intr_status & MVSD_NOR_RX_FIFO_8W)) {
> -   readsw(iobase + MVSD_FIFO, p, 16);
> -   p += 16;
> +   readsw(iobase + MVSD_FIFO, p + o, 16);
> +   o += 16;
> s -= 32;
> intr_status = mvsd_read(MVSD_NOR_INTR_STATUS);
> }
> @@ -391,8 +396,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
>  */
> if (s <= 32) {
> while (s >= 4 && (intr_status & MVSD_NOR_RX_READY)) {
> -   put_unaligned(mvsd_read(MVSD_FIFO), p++);
> -   put_unaligned(mvsd_read(MVSD_FIFO), p++);
> +   put_unaligned(mvsd_read(MVSD_FIFO), p + o);
> +   o++;
> +   put_unaligned(mvsd_read(MVSD_FIFO), p + o);
> +   o++;
> s -= 4;
> intr_status = mvsd_read(MVSD_NOR_INTR_STATUS);
> }
> @@ -400,7 +407,7 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
> u16 val[2] = {0, 0};
> val[0] = mvsd_read(MVSD_FIFO);
> val[1] = mvsd_read(MVSD_FIFO);
> -   memcpy(p, ((void *)) + 4 - s, s);
> +  

Re: [PATCH 05/11] mmc: s3cmci: handle highmem pages

[Ulf Hansson]

On Wed, 30 Jan 2019 at 09:04, Christoph Hellwig  wrote:
>
> On Wed, Jan 30, 2019 at 08:57:47AM +0100, Ulf Hansson wrote:
> > On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig  wrote:
> > >
> > > Instead of setting up a kernel pointer to track the current PIO address,
> > > track the offset in the current page, and do an atomic kmap for the page
> > > while doing the actual PIO operations.
> > >
> > > Signed-off-by: Christoph Hellwig 
> >
> > Nitpick: This one have some trailing whitespace errors, which git
> > complains about when I apply it.
> >
> > No need to re-spin due to this, I can fix it  up.
>
> I'll need to respin to limit the segment size to a page anyway, so I
> will take this into account as well for v2.

Okay!

FYI, I have no further comment on the series, it looks okay to me!

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing

[Ulf Hansson]

Hi Christoph,

On Thu, 11 Apr 2019 at 09:10, Christoph Hellwig  wrote:
>
> Just like we do for all other block drivers.  Especially as the limit
> imposed at the moment might be way to pessimistic for iommus.

I would appreciate some information in the changelog, as it's quite
unclear of what this change really means.

>
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/mmc/core/queue.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..eb9c0692062c 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -354,18 +354,15 @@ static const struct blk_mq_ops mmc_mq_ops = {
>  static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
>  {
> struct mmc_host *host = card->host;
> -   u64 limit = BLK_BOUNCE_HIGH;
> unsigned block_size = 512;
>
> -   if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
> -   limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
> -
> blk_queue_flag_set(QUEUE_FLAG_NONROT, mq->queue);
> blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> if (mmc_can_erase(card))
> mmc_queue_setup_discard(mq->queue, card);
>
> -   blk_queue_bounce_limit(mq->queue, limit);
> +   if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> +   blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);

So this means we are not going to set a bounce limit for the queue, in
case we have a dma mask.

Why isn't that needed no more? Whats has changed?

> blk_queue_max_hw_sectors(mq->queue,
> min(host->max_blk_count, host->max_req_size / 512));
> blk_queue_max_segments(mq->queue, host->max_segs);
> --
> 2.20.1
>

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] driver: core: Allow subsystems to continue deferring probe

[Ulf Hansson]

+ Rob

On Wed, 5 Jun 2019 at 16:23, Thierry Reding  wrote:
>
> From: Thierry Reding 
>
> Some subsystems, such as pinctrl, allow continuing to defer probe
> indefinitely. This is useful for devices that depend on resources
> provided by devices that are only probed after the init stage.
>
> One example of this can be seen on Tegra, where the DPAUX hardware
> contains pinmuxing controls for pins that it shares with an I2C
> controller. The I2C controller is typically used for communication
> with a monitor over HDMI (DDC). However, other instances of the I2C
> controller are used to access system critical components, such as a
> PMIC. The I2C controller driver will therefore usually be a builtin
> driver, whereas the DPAUX driver is part of the display driver that
> is loaded from a module to avoid bloating the kernel image with all
> of the DRM/KMS subsystem.
>
> In this particular case the pins used by this I2C/DDC controller
> become accessible very late in the boot process. However, since the
> controller is only used in conjunction with display, that's not an
> issue.
>
> Unfortunately the driver core currently outputs a warning message
> when a device fails to get the pinctrl before the end of the init
> stage. That can be confusing for the user because it may sound like
> an unwanted error occurred, whereas it's really an expected and
> harmless situation.
>
> In order to eliminate this warning, this patch allows callers of the
> driver_deferred_probe_check_state() helper to specify that they want
> to continue deferring probe, regardless of whether we're past the
> init stage or not. All of the callers of that function are updated
> for the new signature, but only the pinctrl subsystem passes a true
> value in the new persist parameter if appropriate.
>
> Signed-off-by: Thierry Reding 

Overall this looks good to me. I guess Greg prefers a separate
function, which sets a flag for the device to switch to this new
behavior. That seems like a reasonable change to make and avoids
changing calls to driver_deferred_probe_check_state().

Kind regards
Uffe

> ---
>  drivers/base/dd.c| 17 -
>  drivers/base/power/domain.c  |  2 +-
>  drivers/iommu/of_iommu.c |  2 +-
>  drivers/pinctrl/devicetree.c | 10 ++
>  include/linux/device.h   |  2 +-
>  5 files changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 0df9b4461766..25ffbadf4187 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -238,23 +238,30 @@ __setup("deferred_probe_timeout=", 
> deferred_probe_timeout_setup);
>  /**
>   * driver_deferred_probe_check_state() - Check deferred probe state
>   * @dev: device to check
> + * @persist: Boolean flag indicating whether drivers should keep trying to
> + *   probe after built-in drivers have had a chance to probe. This is useful
> + *   for built-in drivers that rely on resources provided by modular drivers.
>   *
>   * Returns -ENODEV if init is done and all built-in drivers have had a chance
> - * to probe (i.e. initcalls are done), -ETIMEDOUT if deferred probe debug
> - * timeout has expired, or -EPROBE_DEFER if none of those conditions are met.
> + * to probe (i.e. initcalls are done) and unless persist is set, -ETIMEDOUT 
> if
> + * deferred probe debug timeout has expired, or -EPROBE_DEFER if none of 
> those
> + * conditions are met.
>   *
>   * Drivers or subsystems can opt-in to calling this function instead of 
> directly
>   * returning -EPROBE_DEFER.
>   */
> -int driver_deferred_probe_check_state(struct device *dev)
> +int driver_deferred_probe_check_state(struct device *dev, bool persist)
>  {
> if (initcalls_done) {
> if (!deferred_probe_timeout) {
> dev_WARN(dev, "deferred probe timeout, ignoring 
> dependency");
> return -ETIMEDOUT;
> }
> -   dev_warn(dev, "ignoring dependency for device, assuming no 
> driver");
> -   return -ENODEV;
> +
> +   if (!persist) {
> +   dev_warn(dev, "ignoring dependency for device, 
> assuming no driver");
> +   return -ENODEV;
> +   }
> }
> return -EPROBE_DEFER;
>  }
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 33c30c1e6a30..effa5276a773 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2423,7 +2423,7 @@ static int __genpd_dev_pm_attach(struct device *dev, 
> struct device *base_dev,
> mutex_unlock(_list_lock);
> dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
> __func__, PTR_ERR(pd));
> -   return driver_deferred_probe_check_state(base_dev);
> +   return driver_deferred_probe_check_state(base_dev, false);
> }
>
> dev_dbg(dev, "adding to PM domain %s\n", pd->name);
> diff --git 

Re: [RFC PATCH v7 0/5] treewide: improve R-Car SDHI performance

[Ulf Hansson]

On Mon, 1 Jul 2019 at 10:32, Christoph Hellwig  wrote:
>
> Any comments from the block, iommu and mmc maintainers?  I'd be happy
> to queue this up in the dma-mapping tree, but I'll need some ACKs
> for that fast.  Alternatively I can just queue up the DMA API bits,
> leaving the rest for the next merge window, but would drag things
> out far too long IMHO.

Apologize for the delay, the mmc parts looks good to me. If not too
late, feel free to pick it up.

Otherwise, let's do it for the next cycle.

Kind regards
Uffe

Re: [RFC PATCH v7 5/5] mmc: queue: Use bigger segments if DMA MAP layer can merge the segments

[Ulf Hansson]

On Mon, 24 Jun 2019 at 08:24, Christoph Hellwig  wrote:
>
> On Thu, Jun 20, 2019 at 05:50:10PM +0900, Yoshihiro Shimoda wrote:
> > When the max_segs of a mmc host is smaller than 512, the mmc
> > subsystem tries to use 512 segments if DMA MAP layer can merge
> > the segments, and then the mmc subsystem exposes such information
> > to the block layer by using blk_queue_can_use_dma_map_merging().
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  drivers/mmc/core/queue.c | 35 ---
> >  include/linux/mmc/host.h |  1 +
> >  2 files changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> > index 92900a0..ab0ecc6 100644
> > --- a/drivers/mmc/core/queue.c
> > +++ b/drivers/mmc/core/queue.c
> > @@ -24,6 +24,8 @@
> >  #include "card.h"
> >  #include "host.h"
> >
> > +#define MMC_DMA_MAP_MERGE_SEGMENTS   512
> > +
> >  static inline bool mmc_cqe_dcmd_busy(struct mmc_queue *mq)
> >  {
> >   /* Allow only 1 DCMD at a time */
> > @@ -196,6 +198,12 @@ static void mmc_queue_setup_discard(struct 
> > request_queue *q,
> >   blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
> >  }
> >
> > +static unsigned int mmc_get_max_segments(struct mmc_host *host)
> > +{
> > + return host->can_dma_map_merge ? MMC_DMA_MAP_MERGE_SEGMENTS :
> > +  host->max_segs;
>
> I personally don't like superflous use of ? : if an if would be more
> obvious:
>
> if (host->can_dma_map_merge)
> return MMC_DMA_MAP_MERGE_SEGMENTS;
> return host->max_segs;
>
> but that is really just a nitpick and for the mmc maintainer to decide.

I have no strong opinions, both formats are used in mmc code, so I am
fine as is.

>
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing

[Ulf Hansson]

On Tue, 25 Jun 2019 at 11:21, Christoph Hellwig  wrote:
>
> Just like we do for all other block drivers.  Especially as the limit
> imposed at the moment might be way to pessimistic for iommus.
>
> Signed-off-by: Christoph Hellwig 

>From your earlier reply, I decided to fold in the following
information to the changelog, as to clarify things a bit:

"This also means we are not going to set a bounce limit for the queue, in
case we have a dma mask. On most architectures it was never needed, the
major hold out was x86-32 with PAE, but that has been fixed by now."

Please tell, if you want me to change something.

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/core/queue.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 3557d5c51141..e327f80ebe70 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -350,18 +350,15 @@ static const struct blk_mq_ops mmc_mq_ops = {
>  static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
>  {
> struct mmc_host *host = card->host;
> -   u64 limit = BLK_BOUNCE_HIGH;
> unsigned block_size = 512;
>
> -   if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
> -   limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
> -
> blk_queue_flag_set(QUEUE_FLAG_NONROT, mq->queue);
> blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> if (mmc_can_erase(card))
> mmc_queue_setup_discard(mq->queue, card);
>
> -   blk_queue_bounce_limit(mq->queue, limit);
> +   if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> +   blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
> blk_queue_max_hw_sectors(mq->queue,
> min(host->max_blk_count, host->max_req_size / 512));
> blk_queue_max_segments(mq->queue, host->max_segs);
> --
> 2.20.1
>

Re: [PATCH 2/2] dma-mapping: remove dma_max_pfn

[Ulf Hansson]

On Tue, 25 Jun 2019 at 11:21, Christoph Hellwig  wrote:
>
> These days the DMA mapping code must bounce buffer for any not supported
> address, and if they driver needs to optimize for natively supported
> ranged it should use dma_get_required_mask.
>
> Signed-off-by: Christoph Hellwig 

Applied for next, by amending the changelog according to suggestions
from Marc, thanks!

I also decided to consider to the reply from Marc (with the changes
made) as an ack, so added a tag for that.

If there are any objections, from anyone, please tell now.

Kind regards
Uffe


> ---
>  arch/arm/include/asm/dma-mapping.h | 7 ---
>  include/linux/dma-mapping.h| 7 ---
>  2 files changed, 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h 
> b/arch/arm/include/asm/dma-mapping.h
> index 03ba90ffc0f8..7e0486ad1318 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -89,13 +89,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
> void *addr)
>  }
>  #endif
>
> -/* The ARM override for dma_max_pfn() */
> -static inline unsigned long dma_max_pfn(struct device *dev)
> -{
> -   return dma_to_pfn(dev, *dev->dma_mask);
> -}
> -#define dma_max_pfn(dev) dma_max_pfn(dev)
> -
>  /* do not use this function in a driver */
>  static inline bool is_device_dma_coherent(struct device *dev)
>  {
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 6309a721394b..8d13e28a8e07 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -729,13 +729,6 @@ static inline int dma_set_seg_boundary(struct device 
> *dev, unsigned long mask)
> return -EIO;
>  }
>
> -#ifndef dma_max_pfn
> -static inline unsigned long dma_max_pfn(struct device *dev)
> -{
> -   return (*dev->dma_mask >> PAGE_SHIFT) + dev->dma_pfn_offset;
> -}
> -#endif
> -
>  static inline int dma_get_cache_alignment(void)
>  {
>  #ifdef ARCH_DMA_MINALIGN
> --
> 2.20.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 0/6] ACPI / utils: add new helper for HID/UID match

[Ulf Hansson]

On Tue, 1 Oct 2019 at 16:27, Andy Shevchenko
 wrote:
>
> There are few users outside of ACPI realm that re-introduce a custom
> solution to match ACPI device against HID/UID. Add a generic helper for
> them.
>
> The series is supposed to go via linux-pm tree.
>
> In v3:
> - correct logic in sdhci-acpi for qcom devices (Adrian)
> - add Mika's Ack
>
> In v2:
> - add patch 2 due to latent issue in the header (lkp)
> - get rid of match_hid_uid() completely in patch 6
>
> Andy Shevchenko (6):
>   ACPI / utils: Describe function parameters in kernel-doc
>   ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI
>   ACPI / utils: Introduce acpi_dev_hid_uid_match() helper
>   ACPI / LPSS: Switch to use acpi_dev_hid_uid_match()
>   mmc: sdhci-acpi: Switch to use acpi_dev_hid_uid_match()
>   iommu/amd: Switch to use acpi_dev_hid_uid_match()
>
>  drivers/acpi/acpi_lpss.c  | 21 +++
>  drivers/acpi/utils.c  | 32 +++
>  drivers/iommu/amd_iommu.c | 30 -
>  drivers/mmc/host/sdhci-acpi.c | 49 ---
>  include/acpi/acpi_bus.h   |  8 +++---
>  include/linux/acpi.h  |  6 +
>  6 files changed, 67 insertions(+), 79 deletions(-)
>
> --
> 2.23.0
>

I guess Rafael intend to pick this up for v5.5?

In any case, for the mmc patch, feel free to add:

Acked-by: Ulf Hansson 

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

[Ulf Hansson]

On Tue, 15 Jun 2021 at 21:15, Rob Herring  wrote:
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
>
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.
>
> Cc: Jens Axboe 
> Cc: Stephen Boyd 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Vinod Koul 
> Cc: Bartosz Golaszewski 
> Cc: Kamal Dasu 
> Cc: Jonathan Cameron 
> Cc: Lars-Peter Clausen 
> Cc: Thomas Gleixner 
> Cc: Marc Zyngier 
> Cc: Joerg Roedel 
> Cc: Jassi Brar 
> Cc: Mauro Carvalho Chehab 
> Cc: Krzysztof Kozlowski 
> Cc: Ulf Hansson 
> Cc: Jakub Kicinski 
> Cc: Wolfgang Grandegger 
> Cc: Marc Kleine-Budde 
> Cc: Andrew Lunn 
> Cc: Vivien Didelot 
> Cc: Vladimir Oltean 
> Cc: Bjorn Helgaas 
> Cc: Kishon Vijay Abraham I 
> Cc: Linus Walleij 
> Cc: "Uwe Kleine-König" 
> Cc: Lee Jones 
> Cc: Ohad Ben-Cohen 
> Cc: Mathieu Poirier 
> Cc: Philipp Zabel 
> Cc: Paul Walmsley 
> Cc: Palmer Dabbelt 
> Cc: Albert Ou 
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: Greg Kroah-Hartman 
> Cc: Mark Brown 
> Cc: Zhang Rui 
> Cc: Daniel Lezcano 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Signed-off-by: Rob Herring 

Acked-by: Ulf Hansson  # for MMC

[...]

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dt-bindings: Improve phandle-array schemas

[Ulf Hansson]

On Wed, 19 Jan 2022 at 02:50, Rob Herring  wrote:
>
> The 'phandle-array' type is a bit ambiguous. It can be either just an
> array of phandles or an array of phandles plus args. Many schemas for
> phandle-array properties aren't clear in the schema which case applies
> though the description usually describes it.
>
> The array of phandles case boils down to needing:
>
> items:
>   maxItems: 1
>
> The phandle plus args cases should typically take this form:
>
> items:
>   - items:
>   - description: A phandle
>   - description: 1st arg cell
>   - description: 2nd arg cell
>
> With this change, some examples need updating so that the bracketing of
> property values matches the schema.
>
> Cc: Damien Le Moal 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: Chun-Kuang Hu 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: Vinod Koul 
> Cc: Georgi Djakov 
> Cc: Thomas Gleixner 
> Cc: Marc Zyngier 
> Cc: Joerg Roedel 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Pavel Machek 
> Cc: Mauro Carvalho Chehab 
> Cc: Krzysztof Kozlowski 
> Cc: Jakub Kicinski 
> Cc: Wolfgang Grandegger 
> Cc: Marc Kleine-Budde 
> Cc: Andrew Lunn 
> Cc: Vivien Didelot 
> Cc: Florian Fainelli 
> Cc: Vladimir Oltean 
> Cc: Kalle Valo 
> Cc: Viresh Kumar 
> Cc: Stephen Boyd 
> Cc: Kishon Vijay Abraham I 
> Cc: Linus Walleij 
> Cc: "Rafael J. Wysocki" 
> Cc: Kevin Hilman 
> Cc: Ulf Hansson 
> Cc: Sebastian Reichel 
> Cc: Mark Brown 
> Cc: Mathieu Poirier 
> Cc: Daniel Lezcano 
> Cc: Zhang Rui 
> Cc: Greg Kroah-Hartman 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Sudeep Holla 
> Cc: Geert Uytterhoeven 
> Cc: linux-...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: dmaeng...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-l...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-remotep...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---

For CPUs and PM domains:

Acked-by: Ulf Hansson 

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 2/7] dt-bindings: mmc: sdhci-msm: Document the SDX65 compatible

[Ulf Hansson]

+ Shaik, Bhupesh


On Mon, 11 Apr 2022 at 11:50, Rohit Agarwal  wrote:
>
> The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
> document the compatible with "qcom,sdhci-msm-v5" as the fallback.
>
> Signed-off-by: Rohit Agarwal 

As stated in a couple of other threads for patches extending these
bindings, I would really like to see the binding being converted to
the yaml format first.

It seems like Bhupesh is working on the conversion [1]. If not, please
help him to get this done.

Kind regards
Uffe

[1]
https://www.spinics.net/lists/linux-arm-msm/msg107809.html

> ---
>  Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt 
> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> index 6216ed7..e7dec8a 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> @@ -25,6 +25,7 @@ Required properties:
> "qcom,sc7280-sdhci", "qcom,sdhci-msm-v5";
> "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5"
> "qcom,sdx55-sdhci", "qcom,sdhci-msm-v5";
> +   "qcom,sdx65-sdhci", "qcom,sdhci-msm-v5";
> "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5"
> NOTE that some old device tree files may be floating around that only
> have the string "qcom,sdhci-msm-v4" without the SoC compatible string
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

[Ulf Hansson]

On Wed, 1 Jun 2022 at 09:07, Saravana Kannan  wrote:
>
> Now that fw_devlink=on by default and fw_devlink supports
> "power-domains" property, the execution will never get to the point
> where driver_deferred_probe_check_state() is called before the supplier
> has probed successfully or before deferred probe timeout has expired.
>
> So, delete the call and replace it with -ENODEV.

With fw_devlink=on by default - does that mean that the parameter
can't be changed?

Or perhaps the point is that we don't want to go back, but rather drop
the fw_devlink parameter altogether when moving forward?

>
> Signed-off-by: Saravana Kannan 

Just a minor nitpick below. Nevertheless, feel free to add:

Reviewed-by: Ulf Hansson 

> ---
>  drivers/base/power/domain.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 739e52cd4aba..3e86772d5fac 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2730,7 +2730,7 @@ static int __genpd_dev_pm_attach(struct device *dev, 
> struct device *base_dev,
> mutex_unlock(_list_lock);
> dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
> __func__, PTR_ERR(pd));
> -   return driver_deferred_probe_check_state(base_dev);

Adding a brief comment about why -EPROBE_DEFER doesn't make sense
here, would be nice.

> +   return -ENODEV;
> }
>
> dev_dbg(dev, "adding to PM domain %s\n", pd->name);
> --
> 2.36.1.255.ge46751e96f-goog
>

Kind regards
Uffe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/4] dt-bindings: mmc: sdhci-msm: Document the SDX65 compatible

[Ulf Hansson]

On Mon, 2 May 2022 at 10:38, Rohit Agarwal  wrote:
>
> The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
> document the compatible with "qcom,sdhci-msm-v5" as the fallback.
>
> Signed-off-by: Rohit Agarwal 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  Documentation/devicetree/bindings/mmc/sdhci-msm.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml 
> b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
> index da42a88..e423633 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
> @@ -33,6 +33,7 @@ properties:
>- qcom,sdm630-sdhci
>- qcom,sdm845-sdhci
>- qcom,sdx55-sdhci
> +  - qcom,sdx65-sdhci
>- qcom,sm6125-sdhci
>- qcom,sm6350-sdhci
>- qcom,sm8150-sdhci
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/4] mmc: host/sdhci-msm: Add compatible string check for sdx65

[Ulf Hansson]

On Mon, 2 May 2022 at 10:38, Rohit Agarwal  wrote:
>
> Add sdx65 SoC specific compatible string check inside qcom
> 'sdhci-msm' controller driver.
>
> Signed-off-by: Rohit Agarwal 

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-msm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index fd8b4a9..65661ad 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2453,6 +2453,7 @@ static const struct of_device_id sdhci_msm_dt_match[] = 
> {
>  */
> {.compatible = "qcom,qcs404-sdhci", .data = _msm_v5_var},
> {.compatible = "qcom,sdx55-sdhci",  .data = _msm_v5_var},
> +   {.compatible = "qcom,sdx65-sdhci",  .data = _msm_v5_var},
> {.compatible = "qcom,sdm630-sdhci", .data = _msm_v5_var},
> {.compatible = "qcom,sm6125-sdhci", .data = _msm_v5_var},
> {.compatible = "qcom,sm6350-sdhci", .data = _msm_v5_var},
> --
> 2.7.4
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu