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
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
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
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
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
>>
>> 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
- 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
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
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
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
>
[...]
>>>
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
[...]
>
>
> 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
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
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
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-
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
+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
>
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
>
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 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:
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
> ---
>
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 a
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
+ 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
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
eturn 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
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
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
gt; 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
yngier
> 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: Bjor
b
> 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
+ 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
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/drive
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
> ---
>
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
36 matches
Mail list logo