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 --g
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 inser
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/devic
+ 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 exte
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
> C
ars-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
>
---
> 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 Hanss
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 fo
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
infor
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
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
+ 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 exa
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
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
>
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
> eve
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,
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: Th
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
> ---
> dri
+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
> re
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 i
ff-by: Geert Uytterhoeven
> Reviewed-by: Mark Brown
> Acked-by: Robin Murphy
> Acked-by: Ulf Hansson
Thanks, applied for next!
Kind regrds
Uffe
> ---
> v3:
> - Add Acked-by,
> - Rebase to v4.17-rc1,
>
> v2:
> - Add Reviewed-by, Acked-by,
> - Dr
ff-by: Geert Uytterhoeven
> Reviewed-by: Mark Brown
> Acked-by: Robin Murphy
Acked-by: Ulf Hansson
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/mmc/host/Kconfig | 10 ++
> 1 file changed,
me Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
>
> --
> 2.1.0.27.g96db324
>
Thanks, applied on my mmc tree for next!
I noticed that some DT compatibles weren't documented, according to
checkpatch. Please fix that asap!
Kind regards
Ulf Hansson
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
[...]
>>>
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
[...]
>
>
> 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
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 be
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 acc
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 rega
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
>>
>> 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
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 ar
- 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
On 11 December 2014 at 16:31, Kevin Hilman wrote:
> [+ Laurent Pinchart]
>
> Tomasz Figa writes:
>
>> On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson wrote:
>
> [...]
>
>>>> @@ -988,11 +1107,28 @@ static int rk_iommu_probe(struct platform_device
>>
On 11 December 2014 at 14:54, Sylwester Nawrocki wrote:
> On 11/12/14 12:04, Tomasz Figa wrote:
> ...
>>> > On 11/12/14 09:26, Tomasz Figa wrote:
> > From: Sylwester Nawrocki
> >
> > This patch adds notifiers to the runtime PM/genpd subsystem. It is now
> > possible to registe
On 11 December 2014 at 13:42, Tomasz Figa wrote:
> Hi Ulf,
>
> On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson wrote:
>> On 11 December 2014 at 09:26, Tomasz Figa wrote:
>>> This patch modifies the rockchip-iommu driver to consider state of
>>> the power domain
On 11 December 2014 at 09:26, Tomasz Figa 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
37 matches
Mail list logo
