Ping. Any objections? Thanks
On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko ma...@goldelico.com wrote:
Following series add support to tsc2007 touchscreen driver for
pre-calibration,
flipping and rotation. Added bindings are documented and used in gta04 device
tree.
Marek Belisko (3):
On Tue, Oct 7, 2014 at 8:43 PM, PERIER Romain romain.per...@gmail.com wrote:
This is not the final location, I have no idea exactly where I might
put this helper function. This is why I ask you your opinion (and
also, this is why that's a proposal)
2014-10-07 21:45 GMT+02:00 Romain Perier
On Fri, Oct 10, 2014 at 12:47:08PM +0100, Grant Likely wrote:
This is an extremely simple wrapper. It may be best to simply make it
a static inline. It is also generic enough that I don't have a problem
with it living in include/linux/of.h; but of_regulator.h would be fine
too.
I think of.h
What I'm more concerned about is the semantics of the property. What
do the generic code paths gain by standardizing this property? Is it
expected that
We really need to come up with a standard property for this and document
it rather than continuing to add individual device specific
Hi Grant,
Am Freitag, 10. Oktober 2014, 12:47:08 schrieb Grant Likely:
What I'm more concerned about is the semantics of the property. What
do the generic code paths gain by standardizing this property? Is it
expected that
[seems to be missing some text in the original mail]
We currently see
Hi,
Seems like MPU DVFS does not scale the voltages currently with DT boot,
due to missing mapping between regulator - VCVP. Fixed this by adding
support for platform data in the TWL regulator DT case + adding platform
data quirk for the same.
Tested on omap3-beagle by measuring the MPU voltage
Device tree based boot does not currently support DVFS voltage scaling,
as the VC/VP mapping is broken. This patch adds support to provide
platform data in the device tree boot case also, basically to pass the
function pointers to the vc/vp core for voltage changes.
Signed-off-by: Tero Kristo
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.
Signed-off-by: Tero Kristo t-kri...@ti.com
To: Liam Girdwood lgirdw...@gmail.com
To:
On 10/10/2014 04:40 PM, Tero Kristo wrote:
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.
Signed-off-by: Tero Kristo
On 16:40-20141010, Tero Kristo wrote:
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.
Signed-off-by: Tero Kristo t-kri...@ti.com
On Fri, Oct 10, 2014 at 04:43:42PM +0300, Tero Kristo wrote:
On 10/10/2014 04:40 PM, Tero Kristo wrote:
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for
On Thu, Oct 09, 2014 at 04:07:15PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
alright, it's pretty
This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Liam Girdwood lgirdw...@gmail.com
Cc:
Device tree based boot does not currently support DVFS voltage scaling,
as the VC/VP mapping is broken. This patch adds support to provide
platform data in the device tree boot case also, basically to pass the
function pointers to the vc/vp core for voltage changes.
Signed-off-by: Tero Kristo
Hi,
Seems like MPU DVFS does not scale the voltages currently with DT boot,
due to missing mapping between regulator - VCVP. Fixed this by adding
support for platform data in the TWL regulator DT case + adding platform
data quirk for the same. This same already works in the legacy boot, the
This patchset adds following improvements for the ti-vpe driver.
* Support SEQ_TB format for interlaced buffers
Some of the video decoders generate interlaced content in SEQ_TB format
Y top, T bottom in one plane and UV top, UV bottom in another
* Improve multi instance latency
From: Archit Taneja arc...@ti.com
For n input fields, the VPE de-interlacer creates n - 2 progressive frames.
To support this, we use line average mode of de-interlacer for the first 2
input fields to generate 2 progressive frames. We then revert back to the
preferred EDI method, and create n -
The data_offset in v4l2_planes structure will help us point to the start of
data content for that particular plane. This may be useful when a single
buffer contains the data for different planes e.g. Y planes of two fields in
the same buffer. With this, user space can pass queue top field and
Current VPE driver does not start the job untill all the buffers for
a transaction are not queued. When running in multiple context, this might
increase the processing latency.
Alternate solution would be to try to continue the same context as long as
buffers for the transaction are ready; else
The video source can generate the data in the SEQ_TB buffer format.
In the case of TI SoC, the IVA_HD can generate the interlaced content in
the SEQ_TB buffer format. This is the format where the top and bottom field
data can be contained in a single buffer. For example, for NV12, interlaced
On Fri, Oct 10, 2014 at 12:47:06AM +0300, Aaro Koskinen wrote:
Hi,
On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
What GCC version are you using?
4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
find_get_entry() crashes with 0x involved
On Fri, Oct 10, 2014 at 08:57:43AM -0500, Felipe Balbi wrote:
On Thu, Oct 09, 2014 at 04:07:15PM -0500, Felipe Balbi wrote:
Hi,
On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
On Thu, Oct 09, 2014 at
* Tero Kristo t-kri...@ti.com [141010 06:41]:
Device tree based boot does not currently support DVFS voltage scaling,
as the VC/VP mapping is broken. This patch adds support to provide
platform data in the device tree boot case also, basically to pass the
function pointers to the vc/vp core
On 10/10/2014 08:00 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [141010 06:41]:
Device tree based boot does not currently support DVFS voltage scaling,
as the VC/VP mapping is broken. This patch adds support to provide
platform data in the device tree boot case also, basically to
HI,
On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
This series fixes a few issues with the omap rtc-driver, cleans up a bit
and finally adds support for the PMIC control feature found in some
revisions of this RTC IP block.
Ultimately, this allows for powering off the
On Thu, Oct 09, 2014 at 09:06:23PM +0200, Johan Hovold wrote:
Make sure not to reset the clock-source configuration when enabling the
32kHz clock mux.
Until the clock source can be configured through device tree we must not
overwrite settings made by the bootloader (e.g. clock-source
On Thu, Oct 09, 2014 at 09:06:24PM +0200, Johan Hovold wrote:
The platform device must be registered as wakeup capable before
registering the class device, or the wakealarm attribute will not be
created.
Also make sure to unregister the wakeup source on probe errors.
Fixes: 1d2e2b65d098
On Thu, Oct 09, 2014 at 09:06:25PM +0200, Johan Hovold wrote:
Make sure not to register the class device until after it has been
configured and interrupt handlers registered at probe.
Currently, the device is not fully configured (e.g. 24-hour mode) when
the class device is registered,
On Thu, Oct 09, 2014 at 09:06:27PM +0200, Johan Hovold wrote:
Remove redundant debug message.
The corresponding error has already been logged by rtc core.
Signed-off-by: Johan Hovold jo...@kernel.org
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/rtc/rtc-omap.c | 6 ++
1 file
On Thu, Oct 09, 2014 at 09:06:26PM +0200, Johan Hovold wrote:
Remove register-base define, which is no longer used.
Signed-off-by: Johan Hovold jo...@kernel.org
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/rtc/rtc-omap.c | 2 --
1 file changed, 2 deletions(-)
diff --git
On Thu, Oct 09, 2014 at 09:06:28PM +0200, Johan Hovold wrote:
Use dev_info and dev_dbg rather than pr_info and pr_debug.
Signed-off-by: Johan Hovold jo...@kernel.org
thanks!
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/rtc/rtc-omap.c | 19 +--
1 file changed, 9
On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
Some legacy RTC IP revisions has a power-up reset flag in the status
register that later revisions lack.
As this flag is always read back as set on later revisions (or is
overloaded with a different flag), make sure to only clear
On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
Some legacy RTC IP revisions has a power-up reset flag in the status
register that later revisions lack.
As this flag is always read back as set on later revisions
Hi,
On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
Make sure to restore local irq state when reading the timer/calendar
(TC) registers, so that omap_rtc_read_time() can be called with
interrupts disabled.
Signed-off-by: Johan Hovold jo...@kernel.org
---
Hi,
On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
@@ -124,11 +138,18 @@
*/
#define OMAP_RTC_HAS_POWER_UP_RESET BIT(3)
+/*
+ * Some RTC IP revisions can control an external PMIC via the pmic_power_en
+ * pin.
+ */
+#define OMAP_RTC_HAS_PMIC_MODE BIT(4)
On Thu, Oct 09, 2014 at 09:06:32PM +0200, Johan Hovold wrote:
The ALARM interrupt must not be disabled during shutdown in order to be
able to power up the system using an RTC alarm.
Signed-off-by: Johan Hovold jo...@kernel.org
nicely done!
Reviewed-by: Felipe Balbi ba...@ti.com
---
On Thu, Oct 09, 2014 at 09:06:34PM +0200, Johan Hovold wrote:
Configure the RTC as system-power controller, which allows the system to
be powered off as well as woken up again on subsequent RTC alarms.
Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
maintain RTC power.
On Thu, Oct 09, 2014 at 09:06:33PM +0200, Johan Hovold wrote:
Enable am33xx specific RTC features (e.g. PMIC control) by adding
ti,am3352-rtc to the compatible property of the rtc node.
Signed-off-by: Johan Hovold jo...@kernel.org
Reviewed-by: Felipe Balbi ba...@ti.com
---
The TPS65217C used on the boneblack defaults to 1.5v on startup for dcdc1_reg.
While 1.35v ddr3 memory is actually used. This was discovered by a user during
a schematic review of his beaglebone-black clone, a u-boot patch will also also
be submitted.
Signed-off-by: Robert Nelson
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x 3
are affected, as well as 4.9.0.
We
On 10/10/2014 09:44 PM, Nathan Lynch wrote:
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x
On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)
Looking at http://gcc.gnu.org/PR58854 it
42 matches
Mail list logo
