Another step towards generic IOMMU support on OMAP: eliminating
the public omap-specific find_iommu_device API.
Instead, we now bind iommu clients with their respective iommu device
using a private iommu member which is added to ARM's dev_archdata.
With this in hand, generic IOMMU API users will
Add a private iommu pointer to the ARM-specific arch data in the
device struct, which will be used to attach iommu-specific data
to devices which require iommu support.
Different iommu implementations (on different platforms) will attach
different types of data to this pointer, so 'void *' is curr
Make it possible to set an iommu private archdata before a newly-created
omap device is registered.
Binding iommu client devices with their respective iommu data this way
is needed so the generic IOMMU API can later be used without employing
any omap-specific IOMMU plumbing.
This patch just crude
Declare an omap iommu private struct, which binds an iommu user
to its iommu device. This struct should be placed at the iommu user's
dev_archdata so generic IOMMU API can be used without having to
utilize omap-specific plumbing anymore.
While at it, provide an accessor method to ease the retrieva
Eliminate the public omap_find_iommu_device() method, and don't
expect clients to provide the omap_iommu handle anymore.
Instead, OMAP's iommu driver should now utilize dev_archdata's private iommu
extension to be able to access the required iommu information.
Update omap3isp appropriately.
Sign
Bind OMAP3's isp device to the isp's dedicated iommu, by setting
the device's archdata iommu member.
This way omap3isp will be able to use the generic IOMMU API without
having to call any omap-specific binding method.
Signed-off-by: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: Laurent Pinchart
---
ar
On Wed, Sep 21, 2011 at 11:06:41AM +0200, Laurent Pinchart wrote:
> Hi Deepthy,
Hi,
(Dropped most of people and lists from cc. I don't think Andrew Morton, for
example, has immediate interest towards this topic. Feel free to prome me
wrong.)
> On Wednesday 21 September 2011 07:32:44 Ravi, Deepth
On Sat, Sep 24, 2011 at 1:18 PM, Paul Walmsley wrote:
> On Fri, 23 Sep 2011, J, KEERTHY wrote:
>
>> On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley wrote:
>> >
>> > On Thu, 22 Sep 2011, Keerthy wrote:
>> >
>> >> @@ -0,0 +1,175 @@
>> >> +/*
>> >> + * OMAP system control module header file
>> >> +
Hi,
On Wednesday 21 September 2011 04:15 PM, Taneja, Archit wrote:
Hi,
On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.
Hi Benoit,
On Saturday 24 September 2011 01:53 AM, Benoit Cousson wrote:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
The current approach is an interm
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values i
On Tue, 2011-09-20 at 11:18 +0300, Tomi Valkeinen wrote:
> Hi Tony,
>
> Here is a bunch of board file patches related to DSS. They have all been sent
> for review earlier, and are currently in my tree. Some of them depend on DSS
> driver changes, so I'd like to keep them there to avoid compilation
This set includes patches which do the following:
- Fix crash if a we call dssdev->driver->update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Fix a small bug in omap_vout_isr()
- Remove some redundant code in om
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout->buffer_size, this isn't correct as
vout->buffer_size is later set to the size requested i
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja
---
drivers/media/vid
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
su
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update mode
Remove the code in omap_vout_probe() which calls display->driver->update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by
18 matches
Mail list logo
