On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Tiffany Lin
> Signed-off-by
On Mon, Dec 31, 2018 at 8:53 PM Yong Wu wrote:
>
> After adding device_link between the IOMMU consumer and smi,
> the mediatek,larb is unnecessary now.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
Reviewed-by: Evan Green
___
iommu mailing list
i
On Mon, Dec 31, 2018 at 8:53 PM Yong Wu wrote:
>
> After adding device_link between the iommu consumer and smi-larb,
> the pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. we can get rid of mtk_smi_larb_get/put.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
I
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the drm device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: CK Hu
> CC: Philipp Zabel
> S
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the mdp device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Minghsiu Tsai
> Signed-off-by:
On Mon, Dec 31, 2018 at 8:53 PM Yong Wu wrote:
>
> After adding device_link between the IOMMU consumer and smi,
> the mediatek,larb is unnecessary now.
>
> CC: Matthias Brugger
> Signed-off-by: Yong Wu
Reviewed-by: Evan Green
___
iommu mailing list
i
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link
> automatically on consumer/supplier driver unbind", that means we should
> remove whole the device_link when there is no this driver no matter what
> the ref_count of the link is.
>
> CC
On Mon, Dec 31, 2018 at 8:53 PM Yong Wu wrote:
>
> MediaTek IOMMU should wait for smi larb which need wait for the
> power domain(mtk-scpsys.c) and the multimedia ccf who both are
> module init. Thus, subsys_initcall for MediaTek IOMMU is not helpful.
> Switch to builtin_platform_driver.
>
> Meanw
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> MediaTek IOMMU don't have its power-domain. all the consumer connect
> with smi-larb, then connect with smi-common.
>
> M4U
> |
> smi-common
> |
> -
> | |...
> | |
> larb1 lar
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> Normally, If the smi-larb HW need work, we should enable the smi-common
> HW power and clock firstly.
> This patch adds device-link between the smi-larb dev and the smi-common
> dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sy
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> MediaTek IOMMU has already added device_link between the consumer
> and smi-larb device. If the jpg device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Rick Chang
> Signed-off-by: Yong W
On Mon, Dec 31, 2018 at 8:51 PM Yong Wu wrote:
>
> After adding device_link between the consumer with the smi-larbs,
> if the consumer call its owner pm_runtime_get(_sync), the
> pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. Thus, the consumer don't need the prop
On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote:
>
> The iommu consumer should use device_link to connect with the
> smi-larb(supplier). then the smi-larb should run before the iommu
> consumer. Here we delay the iommu driver until the smi driver is
> ready, then all the iommu consumer always is aft
From: Tianyu Lan Sent: Friday, February 22, 2019
4:12 AM
>
> On the bare metal, enabling X2APIC mode requires interrupt remapping
> function which helps to deliver irq to cpu with 32-bit APIC ID.
> Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> MSI protocol already sup
Hi Eric,
On Mon, Feb 18, 2019 at 02:55:00PM +0100, Eric Auger wrote:
> This patch registers a fault handler which records faults in
> a circular buffer and then signals an eventfd. This buffer is
> exposed within the fault region.
>
> Signed-off-by: Eric Auger
> ---
> drivers/vfio/pci/vfio_pci.
Hi Jean,
On 15.01.2019 13:19, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.9 [1].
>
> This is a simple rebase onto Linux v5.0-rc2. We now use the
> dev_iommu_fwspec_get() helper introduced in v5.0 instead of accessing
> dev->iommu_fwspec, but there
Hi Vincent,
On 2/25/19 3:22 PM, Vincent Stehlé wrote:
> Hi Eric,
>
> On Mon, Feb 18, 2019 at 02:55:00PM +0100, Eric Auger wrote:
>> This patch registers a fault handler which records faults in
>> a circular buffer and then signals an eventfd. This buffer is
>> exposed within the fault region.
>>
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 Mon, Feb 25, 2019 at 07:12:16PM +0800, Dave Young wrote:
> If we move to high as default, it will allocate 160M high + 256M low. It
We won't move to high by default - we will *fall* back to high if the
default allocation fails.
> To make the process less fragile maybe we can remove the 896M li
On 02/25/19 at 12:00pm, Joerg Roedel wrote:
> On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote:
> > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > > The current default of 256MB was found by experiments on a bigger
> > > number of machines, to create a reasonable d
On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote:
> On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > The current default of 256MB was found by experiments on a bigger
> > number of machines, to create a reasonable default that is at least
> > likely to be sufficient
On Sun, Feb 24, 2019 at 09:25:18PM +0800, Pingfan Liu wrote:
> Maybe I misunderstood you, but does "requested range failed" mean that
> user specify the range? If yes, then it should be the duty of user as
> you said later, not the duty of kernel"
No, it should say that it selected a different ran
22 matches
Mail list logo
