On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann wrote:
> On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
>> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
>>
>> > Right. As long as we always unmap the buffers from the IOMMU after they
>> > have stopped being in use, it's ver
On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote:
...
> As I said, AFAIK the trend is to get rid of ordering by initcalls and make
> sure that drivers can handle missing dependencies properly, even for
> "services" such as DMA, GPIO, clocks and so on, which after all are provided
> by normal dr
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
...
> No. Proper Linux drivers must support deferred probing mechanism and there
> should be no assumptions about probing orders. Using other initcall level
> than module_initcall for particular drivers is strongly discouraged.
That's true for "
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote:
...
>> Device driver is not only for the scholarship but also for the real use.
>
> Huh? I'm not sure what kind of comment is this.
I'm guessing Cho meant: "This isn't an academic exercise - I have a
real use case that requires reference countin
On Thu, Mar 13, 2014 at 10:13 PM, Cho KyongHo wrote:
> This commit introduces sysmmu_pte_t for page table entries and
> sysmmu_iova_t vor I/O virtual address that is manipulated by
> exynos-iommu driver. The purpose of the typedef is to remove
> dependencies to the driver code from the change of C
all and large page entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an unmapped area.
>
> Reviewed-by: Tomasz Figa
> Tested-by: Grant Grundler
> Signed-off-by: Cho KyongHo
On Wed, Aug 14, 2013 at 3:49 AM, Joerg Roedel wrote:
> On Thu, Aug 08, 2013 at 11:28:44AM -0700, Grant Grundler wrote:
>> I can't speak to the previous BUG_ON(). I believe the EADDRESSINUSE
>> failures could be either WARN_ON or BUG_ON. This condition is
>> clearly
Tomasz,
On Thu, Aug 8, 2013 at 6:54 AM, Tomasz Figa wrote:
...
>> + BUG_ON(lv1ent_section(sent));
>
> Is this condition really a critical one, to the point that the system
> should not continue execution?
>
...
>> if (lv1ent_page(sent)) {
>> - if (*pgcnt != NUM_LV2ENTRIES)
>
On Wed, Aug 7, 2013 at 5:07 AM, Cho KyongHo wrote:
...
>> I don't understand how this is possible. Can someone explain this
>> better in the IOMMU documentation please?
>
> System MMU is dedicated to a master H/W such as FIMD and FIMC.
Sory - Exynos 5250 documentation I have (confidential version
Hi Marek,
On Tue, Aug 6, 2013 at 6:17 AM, Marek Szyprowski
wrote:
...
> IMHO it is much better to have a simple driver, which binds to a single
> IOMMU controller and leave it to the driver whether to have a same virtual
> address
> space for all parts of FIMC-IS or MFC submodules/memory ports o
On Mon, Jul 29, 2013 at 2:18 AM, Cho KyongHo wrote:
...
>> > @@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent,
>> > phys_addr_t paddr, size_t size,
>> > int i;
>> > for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
>> > if (!lv2
On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo wrote:
> Signed-off-by: Cho KyongHo
> ---
> .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 103 +++
> arch/arm/boot/dts/exynos4.dtsi | 122
> arch/arm/boot/dts/exynos4210.dtsi | 25 ++
> arch
gt; initialized(enabled).
>
> Signed-off-by: Cho KyongHo
Reviewed-by: Grant Grundler
BTW, cscope doesn't find any callers of exynos_sysmmu_enable().
Want to submit another patch to remove it?
(Note I'm talking about exynos_sysmmu_enable() without "__" prefix).
che
mu_domain even though it is already attached to the same
> iommu_domain.
>
> Signed-off-by: Cho KyongHo
Reviewed-by: Grant Grundler
cheers,
grant
> ---
> drivers/iommu/exynos-iommu.c | 13 +++--
> 1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff -
On Fri, Jul 26, 2013 at 4:29 AM, Cho KyongHo wrote:
> This commit removes custom fault handler. The device drivers that
> need to register fault handler can register
> with iommu_set_fault_handler().
>
> Signed-off-by: Cho KyongHo
Reviewed-by: Grant Grundler
cheers
grant
&
On Fri, Jul 26, 2013 at 4:30 AM, Cho KyongHo wrote:
> Since acquiring read_lock is not more frequent than write_lock, it is
> not beneficial to use rwlock, this commit changes rwlock to spinlock.
>
> Signed-off-by: Cho KyongHo
Reviewed-by: Grant Grundler
cheers,
grant
> ---
&
On Fri, Jul 26, 2013 at 4:27 AM, Cho KyongHo wrote:
> This prevents allocating lv2 page table for the lv1 page table entry
> that already has 1MB page mapping. In addition some BUG_ON() is
> changed to WARN_ON().
>
> Signed-off-by: Cho KyongHo
Reviewed-by: Grant Grundler
In re
nmapped area.
>
> Signed-off-by: Cho KyongHo
Tested-by: Grant Grundler
I'm convinced this is a critical fix to apply. Any time we touch the
IOMMU Page Table, we need to flush so the change is immediately
visible to the IOMMU.
thanks,
grant
> ---
> drivers/iommu/exynos-iommu.c |
On Mon, Jul 15, 2013 at 4:21 AM, Cho KyongHo wrote:
...
>> Maybe you could add LV1TABLE_SIZE define and use it here (there is
>> already a LV2TABLE_SIZE define)?
>
> Yes. But, LV2TABLE_SIZE is used in more places than one.
> I do not feel that it is needed to define LV1TABLE_SIZE for the single li
On Mon, Jul 15, 2013 at 5:20 AM, Cho KyongHo wrote:
...
>> > Cho,
>> > Of the above patches, nearly all have been applied to chromeos-3.8
>> > (kernel-next git tree) by Doug Anderson and others.
>> >
>> > AFAICT, the only ones not applied are:
>> >[v7,3/9] iommu/exynos: fix page table maintena
On Fri, Jul 5, 2013 at 5:29 AM, Cho KyongHo wrote:
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
...
> Patch summary:
> [PATCH v7 1/9] iommu/exynos: do not include removed header
> [PATCH v7 2/9] io
t has fired, even if we're on an exynos device without any
> problems.
I agree. Can add:
Reviewed-by: Grant Grundler
thanks,
grant
>
> -Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
22 matches
Mail list logo
