[PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver

Marek Szyprowski m.szyprowski at samsung.com
Fri Apr 22 03:33:56 EDT 2011


On Thursday, April 21, 2011 4:19 PM Arnd Bergmann wrote:

> On Thursday 21 April 2011, Marek Szyprowski wrote:
> > > No, I think that would be much worse, it definitely destroys all kinds
> of
> > > assumptions that the core code makes about devices. However, I don't
> think
> > > it's much of a problem to just create two child devices and use them
> > > from the main driver, you don't really need to create a device_driver
> > > to bind to each of them.
> >
> > I must have missed something. Video codec is a platform device and struct
> > device pointer is gathered from it (&pdev->dev). How can I define child
> > devices and attach them to the platform device?
> There are a number of ways:
> * Do device_create() with &pdev->dev as the parent, inside of the
>   codec driver, with a new class you create for this purpose
> * Do device_register() for a device, in the same way
> * Create the additional platform devices in the platform code,
>   with their parents pointing to the code device, then
>   look for them using device_for_each_child in the driver

IMHO this will be the cleanest way. Thanks for the idea.

> * Create two codec devices in parallel and bind to both with your
>   driver, ideally splitting up the resources between the two
>   devices in a meaningful way.

Video codec has only standard 2 resources - ioregs and irq, so there
is not much left for such splitting.

> None of them are extremely nice, but it's not that hard either.
> You should probably prototype a few of these approaches to see
> which one is the least ugly one.

Ok. Today while iterating over the hardware requirements I noticed
one more thing. Our codec hardware has one more, odd requirement for
video buffers. The DMA addresses need to be aligned to 8KiB or 16KiB
(depending on buffer type). Do you have any idea how this can be
handled in a generic way?

Best regards
Marek Szyprowski
Samsung Poland R&D Center

More information about the linux-arm-kernel mailing list