On 10/21/2014 06:23 PM, Nishanth Menon wrote:
The final solution is to transition off to use 8250 driver and no
dependency on console structures and move away from omap-serial driver,
hence no major cleanups are done for this driver.
So the shiny new driver works for you, is this what you
Preload register is dumped twice for video overlays and mflag register
is not dumped for GFX.
Fix the register dump.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
The PLL settings are committed by setting GO bit, which is then cleared
by the HW when the settings have been taken into use.
The current PLL code handles this wrong: instead of waiting for the bit
to be cleared, it waits for the bit to be set. Usually, the bit is
always set, as the CPU has just
HDMI PLL's REGSD field is only set by the driver if the PLL's output
clock is over 1GHz. This is clearly an error, as REGSD should be set
always.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi_pll.c | 9 -
1 file changed, 4 insertions(+), 5
The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dispc.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.h
PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits
from 4 to 1. The bit 4 is 'reserved', so this probably should not cause
any issues, but it's better to fix it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/dsi.c | 2 +-
1 file
On Fri, Oct 10, 2014 at 01:07:27PM -0500, Felipe Balbi wrote:
On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
- /* clear pending irqs, and set 1/second periodic,
-* which we'll use instead of update irqs
+ /*
+* disable interrupts
+*
+* NOTE: ALARM2
On Wed, Oct 15, 2014 at 12:08:32PM -0500, Felipe Balbi wrote:
On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
BTW, how do you test this series ?
Set a 30 second wakealarm using the sysfs attribute of the rtc
On Sat, Oct 11, 2014 at 07:47:58PM -0500, Felipe Balbi wrote:
On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
Make sure to restore local
On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141011 02:42]:
On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
is this power-off feature RTC-only mode ?
Yes, I believe so, at least as long as RTC power is maintained. The
Hi,
On Tuesday 07 October 2014 03:49 PM, Vivek Gautam wrote:
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
On 10:03-20141022, Sebastian Andrzej Siewior wrote:
On 10/21/2014 06:23 PM, Nishanth Menon wrote:
The final solution is to transition off to use 8250 driver and no
dependency on console structures and move away from omap-serial driver,
hence no major cleanups are done for this driver
Increase the maximum number of consoles possible to 10 since DRA7 now
has the maximum number of consoles possible. without doing this, for
example, enabling DRA7 UART10 results in internal data structures and
console cannot match up and we endup with a crash as follows:
[1.903503] omap_uart
On Tue, Oct 21, 2014 at 04:28:27PM -0500, Suman Anna wrote:
I am looking to refresh this series for 3.19, and this is the only patch
that may need some changes. Please let me know what your preference is,
and I can rework this patch if needed. Either way,
the plan is to not have an OMAP IOMMU
* Johan Hovold jo...@kernel.org [141022 04:12]:
On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141011 02:42]:
On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
is this power-off feature RTC-only mode ?
Yes, I
On Wed, Oct 22, 2014 at 08:29:56AM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141022 04:12]:
On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141011 02:42]:
On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
* Johan Hovold jo...@kernel.org [141022 09:25]:
On Wed, Oct 22, 2014 at 08:29:56AM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141022 04:12]:
On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
* Johan Hovold jo...@kernel.org [141011 02:42]:
On Fri, Oct
Hi Joerg,
On 10/22/2014 08:29 AM, Joerg Roedel wrote:
On Tue, Oct 21, 2014 at 04:28:27PM -0500, Suman Anna wrote:
I am looking to refresh this series for 3.19, and this is the only patch
that may need some changes. Please let me know what your preference is,
and I can rework this patch if
The following functions were exported previously for usage by
the OMAP IOMMU debug module:
omap_iommu_dump_ctx()
omap_dump_tlb_entries()
omap_iopgtable_store_entry()
These functions need not be exported anymore as the OMAP IOMMU
debugfs code is integrated with the OMAP
Any debugfs access on an OMAP IOMMU that is not enabled (done during
attach) results in a bus error due to access of registers without
the clock or the reset enabled for the respective IOMMU. So, add a
check to make sure the IOMMU is enabled/attached by a client device.
This gracefully prints a
The function omap2_iommu_fault_isr() does an unnecessary
recomputation of the return value. The logic relies on
setting the same bit fields as the MMU fault error status
bits, so simplify this function and remove the unneeded
macros. These macros were originally exported to notify
MMU faults to
Remove the writeability on the 'pagetable' debugfs entry,
so that the mapping/unmapping into an OMAP IOMMU is only
limited to actual client devices/drivers at kernel-level.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
The permissions on the debugfs entry nr_tlb_entries should
have been octal, not decimal, so fix it.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu-debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The isr_priv field is a left-over from before the IOMMU API
adaptation, this was used to store the callback data. This is
no longer relevant, so remove it.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.h | 1 -
1
The omap2_iommu_save_ctx() and omap2_iommu_restore_ctx()
performs a sanity version check against a fixed value
that is correct only for OMAP2/OMAP3 IOMMUs. This fixed check
does not scale for all OMAP2+ IOMMUs and is not absolutely
required, so it has been removed.
Signed-off-by: Suman Anna
Hi,
This is an updated version of the OMAP IOMMU Cleanup Consolidation
patch series [1], rebased onto 3.18-rc1. The update addresses
comments on patch 12 [2] from the previous series, there are no
changes to any of the other patches.
The series is intended for the 3.19 merge window. A reference
The omap_iommu_save_ctx() and omap_iommu_restore_ctx() declarations
are defined in include/linux/omap-iommu.h and do not belong in the
internal drivers/iommu/omap-iommu.h header, so remove them.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
The .domain field in omap_iommu struct is set properly when the
OMAP IOMMU device is attached to, but is never reset properly
on detach. Reset this properly so that the OMAP IOMMU debugfs
logic can depend on this field before allowing the debugfs
operations.
Signed-off-by: Suman Anna
The function omap_iommu_arch_version() is not used anymore,
and is not required either, so remove it. The .version field
in struct iommu_functions that this function uses is also
removed, as it is not really an ops to retrieve a version and
there won't be any usage for this field either.
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
The OMAP IOMMU driver was originally designed as modules, and split
into a core module and a thin arch-specific module through the OMAP
arch-specific struct iommu_functions, to scale for both OMAP1 and
OMAP2+ IOMMU variants. The driver can only be built for OMAP2+
platforms currently, and also can
The exported functions omap_foreach_iommu_device() and
omap_iotlb_cr_to_e() have been deleted, as they are no
longer needed.
The function omap_foreach_iommu_device() is not required
after the consolidation of the OMAP IOMMU debug module,
and the function omap_iotlb_cr_to_e() is not required
after
The debugfs entry 'ver' to read the OMAP IOMMU version is
not much useful for developers, so it has been removed. The
same can be deduced from the register dump, provided by the
debugfs entry 'regs', REVISION register. This also allows us
to remove the omap_iommu_arch_revision() which is currently
The debugfs entry 'pagetable' that shows the page table entry
(PTE) data currently outputs only data that can be fit into a
page. Switch the entry to use the seq_file interface so that
it can show all the valid page table entries.
The patch also corrected the output for L2 entries, and prints
the
The dev_to_omap_iommu() is local to the OMAP IOMMU modules, and
need not be defined conditionally. The CONFIG_IOMMU_API dependency
check was added in the past to fix a compilation issue back when
the header resided in the arch/arm layers, and is no longer
needed.
While at this, fix the header
The refcount field in omap_iommu object is primarily used to check
if an IOMMU device has already been enabled, but this is already
implicit in the omap_iommu_attach_dev() which ensures that only
a single device can attach to an IOMMU. This field is redundant,
and so has been cleaned up.
Hi Suman,
Thank you for the patch.
On Wednesday 22 October 2014 17:22:30 Suman Anna wrote:
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel,
37 matches
Mail list logo
