On 03/10/2014 07:03 PM, Tony Lindgren wrote:
* Florian Vaussard florian.vauss...@epfl.ch [140310 08:17]:
On 03/10/2014 11:30 AM, Roger Quadros wrote:
If you don't use the OMAP3x30_CORE2_IOPAD() macro then these definitions
can fit in omap3-overo-base.dtsi.
The offsets will be taken care of
There are some unused registers in twl4030 at I2C address 0x49 and function
twl4030_49_nop_reg() is used to check accessibility of that registers. These
registers are written in decimal format but the values are correct in
hexadecimal format. (It can be checked few lines above the patched code
There are some unused registers in twl4030 at I2C address 0x49 and function
twl4030_49_nop_reg() is used to check accessibility of that registers. These
registers are written in decimal format but the values are correct in
hexadecimal format. (It can be checked few lines above the patched code
Hi,
On 15/10/13 10:04, Archit Taneja wrote:
Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.
Add documentation for the DMM bindings.
Originally worked on by Andy Gross andy...@gmail.com
Cc: Andy Gross
On Tuesday 11 March 2014 12:45 PM, Tomi Valkeinen wrote:
Hi,
On 15/10/13 10:04, Archit Taneja wrote:
Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.
Add documentation for the DMM bindings.
Originally worked on by Andy
On 03/10/2014 08:12 PM, Tomas Novotny wrote:
There are some unused registers in twl4030 at I2C address 0x49 and function
twl4030_49_nop_reg() is used to check accessibility of that registers. These
registers are written in decimal format but the values are correct in
hexadecimal format. (It
This patch set mainly consists of minor fixes for the VPE driver. These fixes
ensure the following:
- The VPE module can be inserted and removed successively.
- Make sure that smaller resolutions like qcif work correctly.
- Prevent race condition between firmware loading and an open call to the
VPE has a ctrl parameter which decides how many mem to mem transactions the
active job from the job queue can perform.
The driver's job_ready() made sure that the number of ready source buffers are
sufficient for the job to execute successfully. But it didn't make sure if
there are sufficient
The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
wasn't done in the driver and hence was breaking compliance. Update the bus_info
parameter accordingly.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 3 ++-
1 file changed, 2
The minimum width and height for VPE input/output was kept as 128 pixels. VPE
doesn't have a constraint on the image height, it requires the image width to
be at least 16 bytes.
Change the minimum supported dimensions to 32x32. This allows us to de-interlace
qcif content. A smaller image size
vpe fops(vpe_open in particular) should be called only when VPDMA firmware
is loaded. File operations on the video device are possible the moment it is
registered.
Currently, we register the video device for VPE at driver probe, after calling
a vpdma helper to initialize VPDMA and load firmware.
Zero out the reserved formats in v4l2_pix_format_mplane and
v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
through TRY_FMT ioctl.
This ensures that the user doesn't interpret the non-zero fields as some data
passed by the driver, and ensures compliance.
The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
type buffers for the case where the captured output is progressive.
Set the field to V4L2_FIELD_NONE for the completed destination buffers when
the captured output is progressive.
For OUTPUT type buffers, a queued
The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.
Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
they are dequed.
Signed-off-by: Archit Taneja arc...@ti.com
---
The vpe output and capture queues are initially configured to default values in
vpe_open(). A G_FMT before any S_FMTs will result in these values being
populated.
The colorspace and bytesperline parameter of this initial configuration are
incorrect. This breaks compliance when as we get
querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be
V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers).
For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the
Rename the memory block resource vpe_csc to csc since it also exists within
the VIP IP block. This would make the name more generic, and both VPE and VIP DT
nodes in the future can use it.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/csc.c | 2 +-
1 file changed,
The video_device struct is currently embedded in the driver data struct vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.
The v4l2 core, however, manages the removal of the vfd region, through the
video_device's .release() op, which
Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:
- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect-width
shouldn't
For OMAP and DRA7x, we generally allocate video and graphics buffers through
omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed
contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by
other drivers in the video pipeline.
Add VB2_DMABUF flag to the
Hi!
You still miss some wovels here. Sometimes it imakes it unlear:
chrg is charge? charger?
chrgr means charger, chrg means charge. Isn't it used consistently?. Can fix
it if
it's really annoying. Please suggest.
Well... with all the missing letters, it is not clear if letter is
Hi Lee,
On 02/27/2014 04:18 PM, Roger Quadros wrote:
Hi,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these for -next.
Lee,
I've folded
Hi,
2014-03-05 17:33 GMT+01:00 Tony Lindgren t...@atomide.com:
* Andreas Fenkart afenk...@gmail.com [140305 00:30]:
Hi,
2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com:
The wake-irq is needed for omaps with wake-up path and also
when doing GPIO remuxing. So the wake-up
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO
Resend of v8, with Chris Ball on cc and following changes.
v9
- extended comment about why wake-irq is needed
- drop double '(' ')' around card_detect_irq
- drop final '.' in in subject line of patch
v8
- rebased on top of Tony Lindgrent...@atomide.com changes
- improved changelog describing
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the
On 03/10/2014 05:13 PM, Florian Vaussard wrote:
Hi Roger,
On 03/10/2014 11:30 AM, Roger Quadros wrote:
Hi Florian,
On 03/07/2014 09:22 PM, Florian Vaussard wrote:
Add the High-Speed USB PHY.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index
On 03/07/2014 09:22 PM, Florian Vaussard wrote:
Add the High-Speed USB PHY.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Roger Quadros rog...@ti.com
cheers,
-roger
---
arch/arm/boot/dts/omap3-overo-base.dtsi | 44
On 10/03/14 17:41, Tony Lindgren wrote:
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is
On Mon, Mar 10, 2014 at 01:41:14PM +0200, Jyri Sarha wrote:
Since RFC:
- fixed commit msg typo
- added include/sound/soc.h changes too
The sematics of bitclock-master and frame-master DT parameters
should depend on whether they are found from a cpu-dai or codec
sub-node.
-
This commit adds a bare bones driver support for TLV320AIC31XX family
audio codecs. The driver adds basic stereo playback trough headphone
and speaker outputs and mono capture trough microphone inputs.
The driver is currently missing support at least for mini DSP features
and jack detection. I
Hi,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these for -next.
Lee,
I've folded some platform data dependent patches with
On 03/11/14 09:33, Archit Taneja wrote:
For OMAP and DRA7x, we generally allocate video and graphics buffers through
omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed
contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by
other drivers in the video
On 03/11/14 09:33, Archit Taneja wrote:
The minimum width and height for VPE input/output was kept as 128 pixels. VPE
doesn't have a constraint on the image height, it requires the image width to
be at least 16 bytes.
Change the minimum supported dimensions to 32x32. This allows us to
On 03/11/14 09:33, Archit Taneja wrote:
The video_device struct is currently embedded in the driver data struct
vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.
The v4l2 core, however, manages the removal of the vfd region,
On 03/11/2014 02:02 PM, Lee Jones wrote:
Hi,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these for -next.
Lee,
I've folded some platform data
The LIS33DE accelerometer is used on several Gumstix expansion boards,
thus add the DT node to omap3-overo-common-peripherals.dtsi.
For the boards that do not have the accelerometer (like Tobi), mark the
status as disabled.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
Hi,
This series adds the support for 5 new expansion boards from Gumstix:
- Palo43
- Gallop43
- Chestnut43
- Alto35
- Summit
The 1st patch is a preparatory work, in order to factorize some
peripherals that are common to most Gumstix expansion boards. Patch 2
adds the support for an accelerometer
Gallop43 is an expansion board for Gumstix Overo products.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-overo-gallop43-common.dtsi | 57 ++
Chestnut43 is an expansion board for Gumstix Overo products.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/Makefile | 2 +
.../boot/dts/omap3-overo-chestnut43-common.dtsi| 69 ++
Gumstix expansion boards share a couple of peripherals:
- uart3 is used for the console
- AT24C01 EEPROM on i2c3
Use this file for overo-tobi.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
.../boot/dts/omap3-overo-common-peripherals.dtsi | 50 ++
Alto35 is an expansion board for Gumstix Overo products.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-overo-alto35-common.dtsi | 77
arch/arm/boot/dts/omap3-overo-alto35.dts
Summit is an expansion board for Gumstix Overo products.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/Makefile | 2 ++
arch/arm/boot/dts/omap3-overo-storm-summit.dts | 30 +++
Palo43 is an expansion board for Gumstix Overo products.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/omap3-overo-palo43-common.dtsi | 53
arch/arm/boot/dts/omap3-overo-palo43.dts
Hi Archit,
A few small comments below...
On 03/11/14 09:33, Archit Taneja wrote:
Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only for the output of VPE(or
On 03/11/14 09:33, Archit Taneja wrote:
querycap currently returns V4L2_CAP_VIDEO_M2M as a capability, this should be
V4L2_CAP_VIDEO_M2M_MPLANE instead, as the driver supports multiplanar formats.
Signed-off-by: Archit Taneja arc...@ti.com
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
On 03/11/14 09:33, Archit Taneja wrote:
The bus_info parameter in v4l2_capabilities expects a 'platform_' prefix. This
wasn't done in the driver and hence was breaking compliance. Update the
bus_info
parameter accordingly.
Signed-off-by: Archit Taneja arc...@ti.com
Reviewed-by: Hans
On 03/11/14 09:33, Archit Taneja wrote:
The vpe output and capture queues are initially configured to default values
in
vpe_open(). A G_FMT before any S_FMTs will result in these values being
populated.
The colorspace and bytesperline parameter of this initial configuration are
incorrect.
On 03/11/14 09:33, Archit Taneja wrote:
Zero out the reserved formats in v4l2_pix_format_mplane and
v4l2_plane_pix_format members of the returned v4l2_format pointer when passed
through TRY_FMT ioctl.
This ensures that the user doesn't interpret the non-zero fields as some data
passed by
On 03/11/14 09:33, Archit Taneja wrote:
The vpe driver wasn't setting the correct field parameter for dequed CAPTURE
type buffers for the case where the captured output is progressive.
Set the field to V4L2_FIELD_NONE for the completed destination buffers when
the captured output is
On 03/11/14 09:33, Archit Taneja wrote:
The dequed CAPTURE_MPLANE type buffers don't contain the flags that the
originally queued OUTPUT_MPLANE type buffers have. This breaks compliance.
Copy the source v4l2_buffer flags to the destination v4l2_buffer flags before
they are dequed.
Summit and Tobi expansion boards have a HDMI connector with a TFP410
encoder. Add a common include file for this configuration, and then
use it for Summit and Tobi.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo-common-dvi.dtsi| 109
Alto35 expansion board has a ZIF connector for a 3.5'' LCD.
Add a common include file for this configuration, and use it
on Alto35.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo-alto35-common.dtsi | 1 +
Chestnut43, Gallop43 and Palo43 expansion boards have a ZIF connector
for a 4.3'' LCD.Add a common include file for this configuration, and
use it on relevant expansion boards.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
.../boot/dts/omap3-overo-chestnut43-common.dtsi| 1 +
Hi,
This series enables the DVI / LCD graphics present on some of
the Overo expansion boards.
DVI output:
- Tobi
- Summit
LCD (3.5''):
- Alto35
LCD (4.3''):
- Chestnut43
- Palo43
- Gallop43
I tested on Tobi, Alto35 and Gallop43 using both OMAP35xx and OMAP36xx
Overo boards.
This series
Tony,
On Monday 10 March 2014 10:06 PM, Tony Lindgren wrote:
* Olof Johansson o...@lixom.net [140308 23:36]:
On Sun, Mar 02, 2014 at 03:14:49PM -0800, Tony Lindgren wrote:
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13
On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:
Hi Archit,
A few small comments below...
On 03/11/14 09:33, Archit Taneja wrote:
Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense
only
On 03/11/14 13:46, Archit Taneja wrote:
On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:
Hi Archit,
A few small comments below...
On 03/11/14 09:33, Archit Taneja wrote:
Add selection ioctl ops. For VPE, cropping makes sense only for the input to
VPE(or
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these for -next.
Lee,
I've folded some platform data dependent patches with mfd patches
On Tuesday 11 March 2014 06:19 PM, Hans Verkuil wrote:
On 03/11/14 13:46, Archit Taneja wrote:
On Tuesday 11 March 2014 05:51 PM, Hans Verkuil wrote:
Hi Archit,
A few small comments below...
On 03/11/14 09:33, Archit Taneja wrote:
snip
Yes. If for no other reason that I plan on adding
On 03/11/2014 03:07 PM, Lee Jones wrote:
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these for -next.
Lee,
I've folded some platform data
* Roger Quadros rog...@ti.com [140311 06:13]:
On 03/11/2014 03:07 PM, Lee Jones wrote:
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It also does some cleanup with respect to DT clock binding
for the mfd/omap-usb-host driver.
Please queue these
* Tomi Valkeinen tomi.valkei...@ti.com [140311 03:19]:
On 10/03/14 17:41, Tony Lindgren wrote:
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break
* Andreas Fenkart afenk...@gmail.com [140311 02:45]:
Hi,
2014-03-05 17:33 GMT+01:00 Tony Lindgren t...@atomide.com:
* Andreas Fenkart afenk...@gmail.com [140305 00:30]:
Hi,
2014-02-27 22:33 GMT+01:00 Tony Lindgren t...@atomide.com:
The wake-irq is needed for omaps with wake-up
On Fri, Mar 07, 2014 at 09:58:36AM -0800, Tony Lindgren wrote:
The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84:
Merge tag 'for_3.15/dts_signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into
omap-for-v3.15/dt (2014-03-02 14:22:03
Hi Paul,
On 03/05/2014 06:24 PM, Suman Anna wrote:
Hi Paul, Benoit,
This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support
patches that are under arch/arm. The series just assimilates patches 8
through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and
all
Hi Jyri
Since RFC:
- fixed commit msg typo
- added include/sound/soc.h changes too
The sematics of bitclock-master and frame-master DT parameters
should depend on whether they are found from a cpu-dai or codec
sub-node.
- bitclock-master in cpu-dai node means Codec-Bitclock-Slave
-
Hi Mark, Jyri
Since RFC:
- fixed commit msg typo
- added include/sound/soc.h changes too
The sematics of bitclock-master and frame-master DT parameters
should depend on whether they are found from a cpu-dai or codec
sub-node.
- bitclock-master in cpu-dai node means
Hi Tony,
On 3/7/2014 5:26 PM, George Cherian wrote:
The patch series adds USB dt nodes for am43xx epos and gp evm
Boot tested with Benoit's for_3.15 + following patches
https://patchwork.kernel.org/patch/3600821/
https://patchwork.kernel.org/patch/3600831/
On Wed, Mar 12, 2014 at 9:13 AM, Kuninori Morimoto
kuninori.morimoto...@gmail.com wrote:
Hi Jyri
Since RFC:
- fixed commit msg typo
- added include/sound/soc.h changes too
The sematics of bitclock-master and frame-master DT parameters
should depend on whether they are found from a
72 matches
Mail list logo
