Re: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
On 03/01/14 00:12, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [140223 04:33]: ping x2! Thanks applying into omap-for-v3.15/dt finally. Thanks! Is it OK to remove the board-cm-*.c files for v3.15? Hmmm I thought we will have a transition release with both ways and similar functionality available... For this to happen, we need to extend the DT support to the stuff board-cm-t*.c files cover before removing them... We should be able to send additional patches in 3-5 weeks. Since rc4 is out a week ago, and rc5 is coming, we won't be able to prepare the extension in time for 3.15... So, can we postpone the board-cm-t*.c files removal to 3.16? Or does it make too much trouble for you? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
* Igor Grinberg grinb...@compulab.co.il [140302 06:19]: On 03/01/14 00:12, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [140223 04:33]: ping x2! Thanks applying into omap-for-v3.15/dt finally. Thanks! Is it OK to remove the board-cm-*.c files for v3.15? Hmmm I thought we will have a transition release with both ways and similar functionality available... For this to happen, we need to extend the DT support to the stuff board-cm-t*.c files cover before removing them... We should be able to send additional patches in 3-5 weeks. Since rc4 is out a week ago, and rc5 is coming, we won't be able to prepare the extension in time for 3.15... So, can we postpone the board-cm-t*.c files removal to 3.16? Or does it make too much trouble for you? OK that sounds good to me thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 9/9] arm: dts: am43x-gp-evm: Add matrix gpio keys.
Hi Sourav,
On 21/02/2014 15:28, Sourav Poddar wrote:
Hi Benoit,
On Tuesday 14 January 2014 07:51 PM, Benoit Cousson wrote:
Hi Felipe,
On 14/01/2014 14:14, Felipe Balbi wrote:
On Mon, Jan 13, 2014 at 10:13:13PM +0530, sourav wrote:
Benoit,
On Thursday 19 December 2013 06:03 PM, Sourav Poddar wrote:
Add gpio keys node for am43x gp evm.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 0dc248d..4eb72b8 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -13,6 +13,7 @@
#include am4372.dtsi
#includedt-bindings/pinctrl/am43xx.h
#includedt-bindings/pwm/pwm.h
+#includedt-bindings/gpio/gpio.h
/ {
model = TI AM437x GP EVM;
@@ -24,6 +25,26 @@
brightness-levels =0 51 53 56 62 75 101 152 255;
default-brightness-level =8;
};
+
+matrix_keypad: matrix_keypad@0 {
+compatible = gpio-matrix-keypad;
+debounce-delay-ms =5;
+col-scan-delay-us =2;
+
+row-gpios =gpio3 21 GPIO_ACTIVE_HIGH /* Bank3, pin21 */
+ gpio4 3 GPIO_ACTIVE_HIGH /* Bank4, pin3 */
+ gpio4 2 GPIO_ACTIVE_HIGH; /* Bank4, pin2 */
+
+col-gpios =gpio3 19 GPIO_ACTIVE_HIGH /* Bank3, pin19 */
+ gpio3 20 GPIO_ACTIVE_HIGH; /* Bank3, pin20 */
+
+linux,keymap =0x0201 /* P1 */
+0x00010202 /* P2 */
+0x0167 /* UP */
+0x0101006a /* RIGHT */
+0x0269 /* LEFT */
+0x0201006c; /* DOWN */
+};
};
am43xx_pinmux {
ping on this series, this series is lying for a while.
This series is based on your for_3.14 branch.
Benoit, do you need us to do anything else to get this merged ? Sourav
already rebased the patches as you requested back in December 19th.
Nope, I've just needed more BW. I'll apply it ASAP.
Thanks,
Benoit
Ping on this.
I've just applied them. Sorry for the delay,
Regards,
Benoit
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling
* Sørensen, Stefan stefan.soren...@spectralink.com [140301 02:02]: On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote: * Stefan Sørensen stefan.soren...@spectralink.com [140224 02:12]: Currently INTC interrupts are handled using handle_level_irq which will acknowledge the interrupt before running the handler. If a second interrupt is then asserted and this interrupt is disabled while running the first handler, the INTC will be brought into an inconsistent state. Hmm care to explain a bit more here if the second interrupt you're talking about is the same interrupt or any interrupt in the same interrupt bank? Is this limited to GPIO interrupts? I am seeing it with the cpsw driver on a custom board and on the beaglebone. When a tx irq is handled the cpsw irq handler disables both the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex traffic), this bug will trigger. Reproducing it is very simple, just hit a beaglebone with a flood ping and watch a function trace. OK so it's for the same interrupt. And that sounds like a good test :) Applying this patch I see a significant performance boost on duplex traffic. An iperf full duplex test gives a 50-100% increase in receive bandwidth - it now fully saturates a 100Mb interface, so the increase might be even larger with a gigabit interface. The reason I'm asking is because of the issues we've seen earlier with not flushing posted writes from the interrupt handlers. In those case the interrupt on the device gets acked too late without the read back call. I am not very familiar with the low level details of the irq handling, but am335x TRM states that a data synchronization barrier should be used after the ACK is posted to the INTC, and I don't see that anywhere in the code. Is this related? Well sort of, except DSB won't do it as it won't guarantee the write gets to the device on the bus. So a readback from the device is needed as only the order of reads and writes is guaranteed. A good sanity check would be to find the related interrupt handler(s) in the cpsw driver that do the write to the cpsw registers to ack interrupts. Then check if there's a readback in the cpsw interrupt handler(s) of some harmless cpsw register after acking the interrupt(s) and before doing return IRQ_HANDLED. If this fixes things without your patch, then we know it's a driver issue and there's no need to debug it further :) The missing flush of posted write usually shows up as a spurious interrupts with no status in the device, but depending on the driver code handling of spurious interrupts it may also have other side effects. I'm not too familiar with the cpsw driver so I can't do a test patch without digging into it further sorry. For similar examples, you may want to grep for flush posted write and OCP barrier in the kernel code. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] ARM: dts: omap3-gta04: Various devicetree updates
* Marek Belisko ma...@goldelico.com [140301 06:02]: This updated series fix issue with proper gta04 booting in 3.14 kernel and add various devices to devicetree. Changes from V1: - removed fixes which was merged to 3.14 already - add bma180 accelerometer + booting fix Marek Belisko (2): ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting ARM: dts: omap3-gta04: Add touchscreen properties NeilBrown (5): ARM: dts: omap3-gta04: Add support for magnetometer ARM: dts: omap3-gta04: Add twl4030 charger ARM: dts: omap3-gta04: Add basic sound support ARM: dts: omap3-gta04: Enable mmc2 for wifi ARM: dts: omap3-gta04: Add bma180 accelerometer arch/arm/boot/dts/omap3-gta04.dts | 53 +-- 1 file changed, 51 insertions(+), 2 deletions(-) Thanks for updating these, I'll take the first one into omap-for-v3.14/fixes and the rest into omap-for-v3.15/dt. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap3isp: Fix kerneldoc for _module_sync_is_stopping and isp_isr()
Hi Peter,
Thank you for the patch.
On Friday 28 February 2014 18:36:07 Peter Meerwald wrote:
use the correct name in the comment describing function
omap3isp_module_sync_is_stopping()
isp_isr() never returned IRQ_NONE, remove the comment saying so
Signed-off-by: Peter Meerwald pme...@pmeerw.net
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
and applied to my tree.
---
drivers/media/platform/omap3isp/isp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index 5807185..d60a4b7 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -588,9 +588,6 @@ static void isp_isr_sbl(struct isp_device *isp)
* @_isp: Pointer to the OMAP3 ISP device
*
* Handles the corresponding callback if plugged in.
- *
- * Returns IRQ_HANDLED when IRQ was correctly handled, or IRQ_NONE when the
- * IRQ wasn't handled.
*/
static irqreturn_t isp_isr(int irq, void *_isp)
{
@@ -1420,7 +1417,7 @@ int omap3isp_module_sync_idle(struct media_entity *me,
wait_queue_head_t *wait, }
/*
- * omap3isp_module_sync_is_stopped - Helper to verify if module was
stopping + * omap3isp_module_sync_is_stopping - Helper to verify if module
was stopping * @wait: ISP submodule's wait queue for streamoff/interrupt
synchronization * @stopping: flag which tells module wants to stop
*
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/5] add parallel NAND support for TI's new OMAPx and AMxx platforms
* Gupta, Pekon pe...@ti.com [140212 20:30]: Hi Benoit, Tony, From: Gupta, Pekon This patch-set adds and updates parallel NAND support on following TI platforms - AM335x (am335x-evm) - DRA7xx (dra7-evm - AM43xx (am43X-epos-evm) In addition, following OMAP2+/GPMC patch is also added in this series as it add checks DRA7xx and AM43xxx platforms for non-DT kernels. ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms Please let me know, if this patch-set is in acceptable state, Or should I rebase it against any specific branch at your side ? Thanks applying all except 4/5 into omap-for-v3.15/dt. Patch 4 should be just updated for the macros, I'll comment on that separately. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/5] ARM: dts: dra7: add support for parallel NAND flash
* Pekon Gupta pe...@ti.com [140205 05:31]:
From: Minal Shah minal.s...@ti.com
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,37 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+ * So NAND flash requires following switch settings:
+ * SW5.9 (GPMC_WPN) = LOW
+ * SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins =
+ 0x0 0x7 /* (PIN_INPUT | MUX_MODE0)
gpmc_ad0*/
+ 0x4 0x7 /* (PIN_INPUT | MUX_MODE0)
gpmc_ad1*/
...
Can you guys please update this one to use the macros in
arch/arm/boot/dts/include/dt-bindings/pinctrl/omap.h?
Preferrably the new DRA7XX_CORE_IOPAD and friends macros.
I've picked up the other patches in this series already.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] arm: dts: omap4+: Add DMM bindings
Hi Archit,
On 17/12/2013 11:02, Archit Taneja wrote:
Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 and DRA7x 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 andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
I've just applied your patch.
Thanks,
Benoit
---
Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
arch/arm/boot/dts/dra7.dtsi| 7 +++
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
4 files changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..8bd6d0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of
the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like
page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible: Should contain ti,omap4-dmm for OMAP4 family
+ Should contain ti,omap5-dmm for OMAP5 and DRA7x family
+- reg: Contains DMM register address range (base address and length)
+- interrupts: Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods: Name of the hwmod associated to DMM, which is typically dmm
+
+Example:
+
+dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ ti,hwmods = dmm;
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..c9bb006 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -425,6 +425,13 @@
ti,hwmods = wd_timer2;
};
+ dmm@4e00 {
+ compatible = ti,omap5-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
reg = 0x4807 0x100;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e0585..3c67b2f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -502,6 +502,13 @@
ti,hwmods = kbd;
};
+ dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@4c00 {
compatible = ti,emif-4d;
reg = 0x4c00 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad5..878f635 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -621,6 +621,13 @@
ti,hwmods = wd_timer2;
};
+ dmm@4e00 {
+ compatible = ti,omap5-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote: On 02/07/2014 04:49 PM, Bjorn Andersson wrote: It seems to be standard practice to pass the error value back to the consumer, so you should return ERR_PTR(ret); here instead of the NULL... I have modelled the return values in this function based on the return values in the existing hwspin_lock_request interfaces. I would need to change those functions as well. Ohad, Do you have any objections to the return code convention change? Unless strictly needed, I prefer we don't switch to the ERR_PTR code convention, as it reduces code readability and increases chances of user bugs. In our case, switching to ERR_PTR and friends seems only to optimize a few error paths, and I'm not sure it's a big win over simplicity. When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of initialization failed or device not yet probed; so that the client knows if it should fail or retry later. Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: Device Tree for 3.15
Hi Tony, Please pull the following commits for OMAP Device Tree for v3.15. Thanks, Benoît The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git tags/for_3.15/dts_signed for you to fetch changes up to 1a5fe3ca5ea192d4309dd61f3626b79ff38693c2: ARM: dts: omap4+: Add DMM bindings (2014-03-02 21:26:27 +0100) Add craneboard devices Add more N900 devices Add am43x-epos-evm and am437x-gp-evm devices Add OMAP4 DMM devices Archit Taneja (1): ARM: dts: omap4+: Add DMM bindings Darren Etheridge (1): pinctrl: am43xx: dt-bindings: add MUX_MODE8 Lokesh Vutla (1): ARM: dts: am437x-gp-evm: Add gp dts. Nishanth Menon (2): ARM: dts: Add basic devices for AM3517-craneboard ARM: dts: omap3430-sdp: add dip switch information for MMC operation Sebastian Reichel (6): ARM: dts: TWL4030: Add keypad node ARM: dts: OMAP3-N900: Add TWL4030 Keypad Matrix ARM: dts: OMAP3-N900: Add support for tsl2563 ARM: dts: OMAP3-N900: Add tpa6130a2 support ARM: dts: OMAP3-N900: Add isp1704 support ARM: dts: OMAP3-N900: Add bq24150a support Sourav Poddar (7): ARM: dts: am4372: Add pwm-cells property for ecap device. ARM: dts: am43x-epos-evm: Add pwm backlight support. ARM: dts: am43x-epos-evm: Add I2C2 data. ARM: dts: am43x-epos-evm: Add SPI data. ARM: dts: am437x-gp-evm: Add pwm backlight support. ARM: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++ Documentation/devicetree/bindings/arm/omap/omap.txt | 3 ++ arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/am3517-craneboard.dts | 174 +++ arch/arm/boot/dts/am4372.dtsi | 9 + arch/arm/boot/dts/am437x-gp-evm.dts | 100 + arch/arm/boot/dts/am43x-epos-evm.dts| 67 +++ arch/arm/boot/dts/dra7.dtsi | 7 arch/arm/boot/dts/omap3-n900.dts| 90 + arch/arm/boot/dts/omap3430-sdp.dts | 4 ++ arch/arm/boot/dts/omap4.dtsi| 7 arch/arm/boot/dts/omap5.dtsi| 7 arch/arm/boot/dts/twl4030.dtsi | 7 include/dt-bindings/pinctrl/am43xx.h| 1 + 14 files changed, 500 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt create mode 100644 arch/arm/boot/dts/am3517-craneboard.dts create mode 100644 arch/arm/boot/dts/am437x-gp-evm.dts -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.15
* Benoit Cousson bcous...@baylibre.com [140302 12:45]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.15. Thanks pulling into omap-for-v3.15/dt. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] two omap dt regression fixes for v3.14-rc4
The following changes since commit 4b41636878ee32d4c45a49de7749abca9721bd6a: ARM: OMAP3: Fix pinctrl interrupts for core2 (2014-02-27 15:35:48 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/fixes-dt-rc4 for you to fetch changes up to ae41a3030ce8901853b3cfd5e118a4b0288aa068: ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting (2014-03-02 09:44:45 -0800) Two omap3430 vs 3630 device tree regression fixes for issues booting 3430 based boards. Javier Martinez Canillas (1): ARM: dts: omap3-igep: fix boot fail due wrong compatible match Marek Belisko (1): ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting arch/arm/boot/dts/omap3-gta04.dts| 2 +- arch/arm/boot/dts/omap3-igep0020.dts | 2 +- arch/arm/boot/dts/omap3-igep0030.dts | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3/4] omap device tree changes for v3.15
* Tony Lindgren t...@atomide.com [140302 15:55]:
The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:
Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-signed
for you to fetch changes up to 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 -0800)
Device tree related changes for omaps with minor code
changes also to platform data quirks that are still needed
for some features.
FYI, this probably causes a minor overlapping additions conflict
with the recently merged fixes. My resolve below for reference.
Regards,
Tony
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@@ -172,21 -194,42 +196,58 @@@ static void __init am35xx_emac_reset(vo
omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); /* OCP barrier */
}
+static void __init nokia_n900_legacy_init(void)
+{
+ hsmmc2_internal_input_clk();
+
+ if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
+ if (IS_ENABLED(CONFIG_ARM_ERRATA_430973)) {
+ pr_info(RX-51: Enabling ARM errata 430973
workaround\n);
+ /* set IBE to 1 */
+ rx51_secure_update_aux_cr(BIT(6), 0);
+ } else {
+ pr_warning(RX-51: Not enabling ARM errata 430973
workaround\n);
+ pr_warning(Thumb binaries may crash randomly without
this workaround\n);
+ }
+ }
+}
++
+ static struct gpio cm_t3517_wlan_gpios[] __initdata = {
+ { 56, GPIOF_OUT_INIT_HIGH,wlan pwr },
+ { 4,GPIOF_OUT_INIT_HIGH,xcvr noe },
+ };
+
+ static void __init omap3_sbc_t3517_wifi_init(void)
+ {
+ int err = gpio_request_array(cm_t3517_wlan_gpios,
+ ARRAY_SIZE(cm_t3517_wlan_gpios));
+ if (err) {
+ pr_err(SBC-T3517: wl12xx gpios request failed: %d\n, err);
+ return;
+ }
+
+ gpio_export(cm_t3517_wlan_gpios[0].gpio, 0);
+ gpio_export(cm_t3517_wlan_gpios[1].gpio, 0);
+
+ msleep(100);
+ gpio_set_value(cm_t3517_wlan_gpios[1].gpio, 0);
+ }
+
+ static void __init omap3_sbc_t3517_legacy_init(void)
+ {
+ omap3_sbc_t3x_usb_hub_init(152, cm-t3517 usb hub);
+ omap3_sbc_t3x_usb_hub_init(98, sb-t35 usb hub);
+ am35xx_emac_reset();
+ hsmmc2_internal_input_clk();
+ omap3_sbc_t3517_wifi_init();
+ legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
+ omap_ads7846_init(1, 57, 0, NULL);
+ }
+
+ static void __init am3517_evm_legacy_init(void)
+ {
+ am35xx_emac_reset();
+ }
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_ARCH_OMAP4
@@@ -277,8 -319,10 +338,10 @@@ struct of_dev_auxdata omap_auxdata_look
*/
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
+ { compulab,omap3-sbc-t3517, omap3_sbc_t3517_legacy_init, },
+ { compulab,omap3-sbc-t3530, omap3_sbc_t3530_legacy_init, },
{ compulab,omap3-sbc-t3730, omap3_sbc_t3730_legacy_init, },
- { nokia,omap3-n900, hsmmc2_internal_input_clk, },
+ { nokia,omap3-n900, nokia_n900_legacy_init, },
{ nokia,omap3-n9, hsmmc2_internal_input_clk, },
{ nokia,omap3-n950, hsmmc2_internal_input_clk, },
{ isee,omap3-igep0020, omap3_igep0020_legacy_init, },
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm
On Fri, Feb 28, 2014 at 11:08:16AM +0100, Pavel Machek wrote: On Fri 2014-02-28 08:37:27, Jenny Tc wrote: On Thu, Feb 27, 2014 at 09:18:57PM +0100, Linus Walleij wrote: On Tue, Feb 4, 2014 at 6:12 AM, Jenny TC jenny...@intel.com wrote: +static inline bool __is_battery_full + (long volt, long cur, long iterm, unsigned long cv) Overall I wonder if you've run checkpatch on these patches, but why are you naming this one function with a double __underscore? Just is_battery_full_check() or something would work fine I guess? Just to convey that is_battery_full is a local function and not generic. You can find similar usage in power_supply_core.c (__power_supply_changed_work) and in other drivers. Isn't it advised to have __ prefixes? It is static; everybody sees it is local. __ prefix usually means something else. Agreed, I will remove the __ prefix in next patchset. Meanwhile I would appreciate if anyone could help me to understand what __ prefix really means. + u16 capacity; /* mAh */ + u16 voltage_max; /* mV */ + /* charge termination current */ + u16 chrg_term_mA; + /* Low battery level voltage */ + u16 low_batt_mV; + /* upper and lower temperature limits on discharging */ + s8 disch_temp_ul; /* Degree Celsius */ + s8 disch_temp_ll; /* Degree Celsius */ + /* number of temperature monitoring ranges */ + u16 temp_mon_ranges; + struct psy_ps_temp_chg_table temp_mon_range[BATT_TEMP_NR_RNG]; + /* lowest temperature supported */ + s8 temp_low_lim; +} __packed; Why packed, and convert to kerneldoc for this struct. Battery charging profile, may come from EEPROM/emmc which would be packed. Do you need to do endianness conversion, too? May/may not depending on the stored format. If needed, the endianess conversion should be done at driver level where the EEPROM/emmc reading happens. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote: Intent here is to allow drivers such as cpufreq-cpu0 to be reused on platforms such as TI's OMAP derivatives, and other SoCs which differ only by the sequence involved in voltage scale operations. So, this patch provides a framework for registering the underlying implementation of the SoC specific voltage change methodology. That bit is clear, what's very opaque from the code is how this is going to be accomplished. Overall the sequence takes place after this patch is as follows: a) voltage domain drivers such as those of TI or others register with voltage domain with devm_voltdm_register. b) cpufreq-cpu0/devfreq drivers: of_pm_voltdm_notifier_register(introduced as part of patch #1) to register notifiers around clk of interest. This request is linked to the specific voltage domain using phandle in device tree. c) when cpufreq-cpu0/devfreq does a clk_set_rate, the common clock framework triggers notifiers in voltage domain core which in turn, invokes the corresponding handlers for the voltage domain driver ensuring the right dvfs sequence specific to the SoC is triggered. So the first question I have here is what happens if multiple clocks need to be updated in lock step - if we're only triggering off clock notifiers that seems tricky. The other thing here is that the fact that your API is of_ suggests that it is in fact linked very srongly to DT - it'd be good to split out the layers to make sure things make sense standalone, the DT helpers are obviously good but the API should be able to stand separately. signature.asc Description: Digital signature
Re: [PATCH RFC 2/5] ASoC: tlv320aic31xx: Add codec driver to Makefile and Kconfig
On Wed, Feb 26, 2014 at 11:14:26AM +0200, Jyri Sarha wrote: --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -74,6 +74,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TLV320AIC23 if I2C select SND_SOC_TLV320AIC26 if SPI_MASTER select SND_SOC_TLV320AIC32X4 if I2C + select SND_SOC_TLV320AIC31XX if I2C select SND_SOC_TLV320AIC3X if I2C select SND_SOC_TPA6130A2 if I2C select SND_SOC_TLV320DAC33 if I2C Keep these files sorted and don't send the build infrastructure as a separate patch unless the driver as a whole is split into multiple patches - there is no value unless the driver is being built up over several patches, it just raises a review question on the driver patch. signature.asc Description: Digital signature
Re: [PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15
Tony, On 02/28/2014 05:00 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140228 12:46]: Hi Joerg, Tony, This is an updated series of the OMAP IOMMU DT adaptation intended for 3.15 merge window, addressing the comments from the v2 series. This series is rebased onto 3.14-rc4, and the only change to bindings is to drop the dma-window property. The first 7 patches in the series are in drivers/iommu, with the first 3 patches performing some cleanup. The DT bindings and adaptation are done in patches 4 and 5. Tony, Patches 8 through 13 are in arch/arm/mach-omap2 layer, so I am guessing these would have to go through your tree. Of these, patches 8 and 9 are cleanup fixes to get OMAP3 IVA MMU working, patches 10 11 are fixes required with DT-boot for OMAP3/4, patches 12 13 add the OMAP5 support. Are patches 8 to 13 OK to apply separately from the iommu patches or do they need to wait for the iommu patches to get merged first? Yeah, they don't have any direct dependencies. Patches 8, 9 and 12 are totally independent. Patches 10, 11 and 13 add the needed platform data or archdata to get the corresponding DT iommu devices functional by any users (OMAP3 ISP is the only user in kernel). The only remote dependency is the compatible string names used in the pdata-quirks. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 9/9] arm: dts: am43x-gp-evm: Add matrix gpio keys.
On Sunday 02 March 2014 11:00 PM, Benoit Cousson wrote:
Hi Sourav,
On 21/02/2014 15:28, Sourav Poddar wrote:
Hi Benoit,
On Tuesday 14 January 2014 07:51 PM, Benoit Cousson wrote:
Hi Felipe,
On 14/01/2014 14:14, Felipe Balbi wrote:
On Mon, Jan 13, 2014 at 10:13:13PM +0530, sourav wrote:
Benoit,
On Thursday 19 December 2013 06:03 PM, Sourav Poddar wrote:
Add gpio keys node for am43x gp evm.
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 0dc248d..4eb72b8 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -13,6 +13,7 @@
#include am4372.dtsi
#includedt-bindings/pinctrl/am43xx.h
#includedt-bindings/pwm/pwm.h
+#includedt-bindings/gpio/gpio.h
/ {
model = TI AM437x GP EVM;
@@ -24,6 +25,26 @@
brightness-levels =0 51 53 56 62 75 101 152 255;
default-brightness-level =8;
};
+
+matrix_keypad: matrix_keypad@0 {
+compatible = gpio-matrix-keypad;
+debounce-delay-ms =5;
+col-scan-delay-us =2;
+
+row-gpios =gpio3 21 GPIO_ACTIVE_HIGH /* Bank3, pin21 */
+ gpio4 3 GPIO_ACTIVE_HIGH /* Bank4, pin3 */
+ gpio4 2 GPIO_ACTIVE_HIGH; /* Bank4, pin2 */
+
+col-gpios =gpio3 19 GPIO_ACTIVE_HIGH /* Bank3, pin19 */
+ gpio3 20 GPIO_ACTIVE_HIGH; /* Bank3, pin20 */
+
+linux,keymap =0x0201 /* P1 */
+0x00010202 /* P2 */
+0x0167 /* UP */
+0x0101006a /* RIGHT */
+0x0269 /* LEFT */
+0x0201006c; /* DOWN */
+};
};
am43xx_pinmux {
ping on this series, this series is lying for a while.
This series is based on your for_3.14 branch.
Benoit, do you need us to do anything else to get this merged ? Sourav
already rebased the patches as you requested back in December 19th.
Nope, I've just needed more BW. I'll apply it ASAP.
Thanks,
Benoit
Ping on this.
I've just applied them. Sorry for the delay,
Regards,
Benoit
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 0/2] clock and HWMOD changes for USIM module
On 3/1/2014 3:29 AM, Tony Lindgren wrote: * Satish Patel satish.pa...@ti.com [140109 00:13]: On 1/6/2014 5:42 PM, Satish Patel wrote: Patch set includes clock and HWMOD entries for AM43x's USIM modoule. Note: I am in process of mainlining usim driver. Satish Patel (2): ARM: dts: AM43xx-clocks: Entries added for ti-usim ARM: OMAP: AM43xx: HWMOD changes added for ti-usim Tony, Can you pull in these patches if there are no comments? Would like to see acks from Benoit/Tero/Paul first. Benoit/Tero/Paul: Can you please review and ack this patch series, so that tony can pick it up. Thanks satish Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/5] ASoC: tlv320aic31xx: Add basic codec driver implementation
On Wed, Feb 26, 2014 at 11:14:25AM +0200, Jyri Sarha wrote:
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.
Always CC maintainers on patches please.
+static bool aic31xx_volatile(struct device *dev, unsigned int reg)
+{
+ if (aic31xx_precious(dev, reg) || aic31xx_real_volatile(dev, reg))
+ return true;
+
+ switch (reg) {
+ case AIC31XX_PAGECTL: /* regmap implementation requires this */
+ case AIC31XX_RESET: /* always clears after write */
+ return true;
+ }
+ return false;
+}
This is more complex than you need, just write a standalone volatile
function with some comments in it.
+static const struct regmap_range_cfg aic31xx_ranges[] = {
+ {
+ .name = codec-regmap,
Make this meaningful or omit it.
+#define AIC31XX_NUM_SUPPLIES 6
+static const char * const aic31xx_supply_names[] = {
Use the define in the array size to help check everything lines up.
+static const char * const ldac_in_text[] = {
+ off, Left Data, Right Data, Mono
+};
Off not off - be consistent both internally and with the general style.
+static const struct snd_kcontrol_new aic311x_snd_controls[] = {
+ SOC_DOUBLE_R(SP Driver Playback Switch, AIC31XX_SPLGAIN,
+ AIC31XX_SPRGAIN, 2, 1, 0),
SP?
+ if (!strcmp(w-name, DAC Left)) {
+ mask = AIC31XX_LDACPWRSTATUS_MASK;
There's no overlap with the enable bits? In general it would seem nicer
to have a switch based on the register bits used for the enable rather
than the tree of string comparisions but it's probably not that big a
deal overall.
+ dev_err(w-codec-dev, Unknown widget '%s' calling %s/n,
+ w-name, __func__);
+ return -1;
Return real error codes.
+ if (event == SND_SOC_DAPM_POST_PMU)
+ return aic31xx_wait_bits(aic31xx, reg, mask, mask, 5000, 100);
+ else if (event == SND_SOC_DAPM_POST_PMD)
+ return aic31xx_wait_bits(aic31xx, reg, mask, 0, 5000, 100);
switch.
+ SND_SOC_DAPM_DAC_E(DAC Right, DAC Right Input,
+AIC31XX_DACSETUP, 6, 0, aic31xx_dapm_power_event,
+SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
Don't use stream names, use DAPM to route from the AIF to the widgets.
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ break;
params_width().
+ AIC31XX_IFACE1_DATALEN_MASK,
+ data);
+
+ return aic31xx_setup_pll(codec, params);
This is going to mean that you have a symmetry constraint I think, if
you try to set up different rates for playback and capture presumably
things will break. Setting symmetric_rates will tell applications about
that.
+ case SND_SOC_DAIFMT_CBS_CFM:
+ case SND_SOC_DAIFMT_CBM_CFS:
+ case SND_SOC_DAIFMT_CBS_CFS:
+ dev_err(codec-dev, Unsupported DAI master/slave interface\n);
+ return -EINVAL;
+ default:
+ dev_alert(codec-dev, Invalid DAI master/slave interface\n);
+ return -EINVAL;
Just have a default.
+ for (i = 0; aic31xx_divs[i].mclk != freq; i++)
+ if (i == ARRAY_SIZE(aic31xx_divs)) {
+ dev_err(aic31xx-dev, %s: Unsupported frequency %d\n,
+ __func__, freq);
+ return -EINVAL;
+ }
Braces around the for () too please.
+static int aic31xx_set_power(struct snd_soc_codec *codec, int power)
+{
+ struct aic31xx_priv *aic31xx = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
+ dev_dbg(codec-dev, ## %s: %d - %d\n, __func__,
+ aic31xx-power, power);
+ if (aic31xx-power == power)
+ return 0;
This looks like you need sensible refcounting somewhere? Implementing
this as the standard PM operations may be sensible.
+ if (gpio_is_valid(aic31xx-pdata.gpio_reset)) {
+ gpio_set_value(aic31xx-pdata.gpio_reset, 1);
+ udelay(100);
+ }
+ snd_soc_write(codec, AIC31XX_RESET, 0x01);
+ udelay(100);
+ regcache_cache_only(aic31xx-regmap, false);
You should be coming out of cache only mode before you issue the reset
write. Is it not sensible to skip that if you have a physical reset
line?
+ snd_soc_write(codec, AIC31XX_RESET, 0x01);
+ regcache_cache_only(aic31xx-regmap, true);
+
+ if (gpio_is_valid(aic31xx-pdata.gpio_reset))
+ gpio_set_value(aic31xx-pdata.gpio_reset, 0);
Likewise here. Also if you do reset the CODEC then the dance you did
with the regulator notifiers becomes pointless - the goal with that is
to avoid the need to resync the cache if the CODEC
Re: [PATCH RFC 3/5] ASoC: tlv320aic31xx: Add DT binding document
On Wed, Feb 26, 2014 at 11:14:27AM +0200, Jyri Sarha wrote: +- ai31xx-micbias-vg - MicBias Voltage required. + 1 - MICBIAS output is powered to 2.0V, + 2 - MICBIAS output is powered to 2.5V, + 3 - MICBIAS output is connected to AVDD, + If this node is not mentioned or if the value is incorrect, then MicBias + is powered down. Please provide defines for these as part of the binding. It's not clear to me why leaving the micbias powered down is a sane default, it'll only be powered up if it's connected to something and used which doesn't seem altogether sane. I'd suggest picking 2.0V (the lowest voltage so least likely to cause damage). signature.asc Description: Digital signature
Re: [RFC PATCH v1 0/2] clock and HWMOD changes for USIM module
On 03/03/2014 08:09 AM, Satish Patel wrote: On 3/1/2014 3:29 AM, Tony Lindgren wrote: * Satish Patel satish.pa...@ti.com [140109 00:13]: On 1/6/2014 5:42 PM, Satish Patel wrote: Patch set includes clock and HWMOD entries for AM43x's USIM modoule. Note: I am in process of mainlining usim driver. Satish Patel (2): ARM: dts: AM43xx-clocks: Entries added for ti-usim ARM: OMAP: AM43xx: HWMOD changes added for ti-usim Tony, Can you pull in these patches if there are no comments? Would like to see acks from Benoit/Tero/Paul first. Benoit/Tero/Paul: Can you please review and ack this patch series, so that tony can pick it up. NAK, patch #1 is broken. Thanks satish Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/2] ARM: dts: AM43xx-clocks: Entries added for ti-usim
On 01/06/2014 02:12 PM, Satish Patel wrote:
Clock entries support for TI's USIM - Smart card controller of AM43xx platform
USIM controller has multiple sources for debounce and functional clock.Entry
for each source has been added.
This patch is using unsupported/old version of DT data layout for mux
and gate clocks, and as such does not work at all (probably causes a
hang during boot.) Please update against latest kernel.
Signed-off-by: Satish Patel satish.pa...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 34 ++
drivers/clk/ti/clk-43xx.c|4
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c127e7b..7ccfa75 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -420,6 +420,40 @@ wdt1_fck: wdt1_fck@44df422c {
bit-mask = 0x1;
};
+usim0_fck: usim0_fck@44df4254 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = sys_clkin_ck, dpll_core_m4_ck;
+ reg = 0x44df4254 0x4;
+ bit-mask = 0x1;
+};
+
+usim_dbck: usim_dbck@44df425c {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = clk_rc32k_ck, clk_32k_mosc_ck, clkdiv32k_ick;
+ reg = 0x44df425c 0x4;
+ bit-mask = 0x3;
+};
+
+usim0_opt_fck: usim0_opt_fck@44df8da8 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = usim0_fck;
+ reg = 0x44df8da8 0x4;
+ bit-shift = 8;
+ bit-mask = 0x1;
+};
+
+usim0_opt_fck32: usim0_opt_fck32@44df8da8 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = usim_dbck;
+ bit-shift = 9;
+ bit-mask = 0x1;
+ reg = 0x44df8da8 0x4;
+};
+
l3_gclk: l3_gclk {
#clock-cells = 0;
compatible = fixed-factor-clock;
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index ff3ad1b..8ed05f2 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -66,6 +66,10 @@ static struct omap_dt_clk am43xx_clks[] = {
DT_CLK(NULL, timer6_fck, timer6_fck),
DT_CLK(NULL, timer7_fck, timer7_fck),
DT_CLK(NULL, wdt1_fck, wdt1_fck),
+ DT_CLK(NULL, usim0_fck, usim0_fck),
+ DT_CLK(NULL, usim_dbck, usim_dbck),
+ DT_CLK(NULL, usim0_opt_fck, usim0_opt_fck),
+ DT_CLK(NULL, usim0_opt_fck32, usim0_opt_fck32),
Do you need to add these aliases? Please avoid if possible.
-Tero
DT_CLK(NULL, l3_gclk, l3_gclk),
DT_CLK(NULL, dpll_core_m4_div2_ck, dpll_core_m4_div2_ck),
DT_CLK(NULL, l4hs_gclk, l4hs_gclk),
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] v4l: ti-vpe: Allow usage of smaller images
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 atleast 16 bytes. Change the minimum supported dimensions to 32x32. This allows us to de-interlace qcif content. A smaller image size than 32x32 didn't make much sense, so stopped at this. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 915029b..3a610a6 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -49,8 +49,8 @@ #define VPE_MODULE_NAME vpe /* minimum and maximum frame sizes */ -#define MIN_W 128 -#define MIN_H 128 +#define MIN_W 32 +#define MIN_H 32 #define MAX_W 1920 #define MAX_H 1080 -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] v4l: ti-vpe: Fix some params in VPE data descriptors
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 be used to calculate the line stride, the original image width
should be used for that. We add a 'width' argument which gives the buffer
width in memory.
- frame_width and frame_height describe the complete width and height of the
client to which the channel is connected. If there are multiple channels
fetching data and providing to the same client, the above 2 arguments should
be the width and height of the region covered by all the channels. In the case
where there is only one channel providing pixel data to the client
(like in VPE), frame_width and frame_height should be the cropped width and
cropped height respectively. The calculation of these params is done in the
vpe driver now.
- start_h and start_v is also used in the case of multiple channels to describe
where each channel should start filling pixel data. We don't use this in VPE,
and pass 0s to the vpdma_add_in_dtd() helper.
- Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect
param is removed since cropping isn't possible for outbound data, and 'width'
is added to calculate the line stride.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 50 ++-
drivers/media/platform/ti-vpe/vpdma.h | 9 ---
drivers/media/platform/ti-vpe/vpe.c | 16 +++
3 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index 73dd38e..7248f16 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -614,8 +614,15 @@ static void dump_dtd(struct vpdma_dtd *dtd)
/*
* append an outbound data transfer descriptor to the given descriptor list,
* this sets up a 'client to memory' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * flags: VPDMA flags to configure some descriptor fileds
*/
-void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct v4l2_rect *c_rect,
+void vpdma_add_out_dtd(struct vpdma_desc_list *list, int width,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
enum vpdma_channel chan, u32 flags)
{
@@ -633,8 +640,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct
v4l2_rect *c_rect,
fmt-data_type == DATA_TYPE_C420)
depth = 8;
- stride = ALIGN((depth * c_rect-width) 3, VPDMA_STRIDE_ALIGN);
- dma_addr += (c_rect-left * depth) 3;
+ stride = ALIGN((depth * width) 3, VPDMA_STRIDE_ALIGN);
dtd = list-next;
WARN_ON((void *)(dtd + 1) (list-buf.addr + list-buf.size));
@@ -664,31 +670,48 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list,
struct v4l2_rect *c_rect,
/*
* append an inbound data transfer descriptor to the given descriptor list,
* this sets up a 'memory to client' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory(not the cropped width)
+ * @c_rect: crop params of input image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * field: top or bottom field info of the input image
+ * flags: VPDMA flags to configure some descriptor fileds
+ * frame_width/height: the complete width/height of the image presented to the
+ * client (this makes sense when multiple channels are
+ * connected to the same client, forming a larger frame)
+ * start_h, start_v: position where the given channel starts providing pixel
+ * data to the client (makes sense when multiple channels
+ * contribute to the client)
*/
-void vpdma_add_in_dtd(struct vpdma_desc_list *list, int frame_width,
- int frame_height, struct v4l2_rect *c_rect,
+void vpdma_add_in_dtd(struct vpdma_desc_list *list, int width,
+ const struct v4l2_rect *c_rect,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
- enum vpdma_channel chan, int field, u32 flags)
+ enum vpdma_channel chan, int field, u32 flags, int frame_width,
+ int frame_height, int start_h, int start_v)
{
int priority = 0;
int notify = 1;
int depth = fmt-depth;
int channel, next_chan;
+ struct v4l2_rect rect = *c_rect;
int stride;
- int height =
[PATCH 3/7] v4l: ti-vpe: Use video_device_release_empty
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 currently is the helper
video_device_release. This causes memory corruption, and leads to issues when
we try to re-insert the vpe module.
Use the video_device_release_empty helper function instead
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4243687..bb275f4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1998,7 +1998,7 @@ static struct video_device vpe_videodev = {
.fops = vpe_fops,
.ioctl_ops = vpe_ioctl_ops,
.minor = -1,
- .release= video_device_release,
+ .release= video_device_release_empty,
.vfl_dir= VFL_DIR_M2M,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] v4l: ti-vpe: register video device only when firmware is loaded
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. This function is
non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the
firmware is actually loaded when it returns.
We remove the device registration from vpe probe, and move it to a callback
provided by the vpe driver to the vpdma library, through vpdma_create().
The ready field in vpdma_data is no longer needed since we always have firmware
loaded before the device is registered.
A minor problem with this approach is that if the video_register_device
fails(which doesn't really happen), the vpe platform device would be registered.
however, there won't be any v4l2 device corresponding to it.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 8 +++--
drivers/media/platform/ti-vpe/vpdma.h | 7 +++--
drivers/media/platform/ti-vpe/vpe.c | 55 ---
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index e8175e7..73dd38e 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -781,7 +781,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
/* already initialized */
if (read_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
VPDMA_LIST_RDY_SHFT)) {
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
return;
}
@@ -811,7 +811,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
goto free_buf;
}
- vpdma-ready = true;
+ vpdma-cb(vpdma-pdev);
free_buf:
vpdma_unmap_desc_buf(vpdma, fw_dma_buf);
@@ -839,7 +839,8 @@ static int vpdma_load_firmware(struct vpdma_data *vpdma)
return 0;
}
-struct vpdma_data *vpdma_create(struct platform_device *pdev)
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev))
{
struct resource *res;
struct vpdma_data *vpdma;
@@ -854,6 +855,7 @@ struct vpdma_data *vpdma_create(struct platform_device
*pdev)
}
vpdma-pdev = pdev;
+ vpdma-cb = cb;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vpdma);
if (res == NULL) {
diff --git a/drivers/media/platform/ti-vpe/vpdma.h
b/drivers/media/platform/ti-vpe/vpdma.h
index cf40f11..bf5f8bb 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -35,8 +35,8 @@ struct vpdma_data {
struct platform_device *pdev;
- /* tells whether vpdma firmware is loaded or not */
- bool ready;
+ /* callback to VPE driver when the firmware is loaded */
+ void (*cb)(struct platform_device *pdev);
};
enum vpdma_data_format_type {
@@ -208,6 +208,7 @@ void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
void vpdma_dump_regs(struct vpdma_data *vpdma);
/* initialize vpdma, passed with VPE's platform device pointer */
-struct vpdma_data *vpdma_create(struct platform_device *pdev);
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev));
#endif
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 623e59e..4243687 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1815,11 +1815,6 @@ static int vpe_open(struct file *file)
vpe_dbg(dev, vpe_open\n);
- if (!dev-vpdma-ready) {
- vpe_err(dev, vpdma firmware not loaded\n);
- return -ENODEV;
- }
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -2037,10 +2032,40 @@ static void vpe_runtime_put(struct platform_device
*pdev)
WARN_ON(r 0 r != -ENOSYS);
}
+static void vpe_fw_cb(struct platform_device *pdev)
+{
+ struct vpe_dev *dev = platform_get_drvdata(pdev);
+ struct video_device *vfd;
+ int ret;
+
+ vfd = dev-vfd;
+ *vfd = vpe_videodev;
+ vfd-lock = dev-dev_mutex;
+ vfd-v4l2_dev = dev-v4l2_dev;
+
+ ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
+ if (ret) {
+ vpe_err(dev, Failed to register video device\n);
+
+ vpe_set_clock_enable(dev, 0);
+ vpe_runtime_put(pdev);
+ pm_runtime_disable(pdev-dev);
+ v4l2_m2m_release(dev-m2m_dev);
+ vb2_dma_contig_cleanup_ctx(dev-alloc_ctx);
+ v4l2_device_unregister(dev-v4l2_dev);
+
+ return;
+ }
+
+
[PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.
Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for this purpose.
Some standard crop parameter checks are done in __vpe_try_crop().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 6acdcd8..c6778f4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1585,6 +1585,98 @@ static int vpe_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return set_srcdst_params(ctx);
}
+static int __vpe_try_crop(struct vpe_ctx *ctx, struct v4l2_crop *cr)
+{
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ /* we don't support crop on capture plane */
+ if (cr-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ cr-c.top = cr-c.left = 0;
+ cr-c.width = q_data-width;
+ cr-c.height = q_data-height;
+ return 0;
+ }
+
+ if (cr-c.top 0 || cr-c.left 0) {
+ vpe_err(ctx-dev, negative values for top and left\n);
+ cr-c.top = cr-c.left = 0;
+ }
+
+ v4l_bound_align_image(cr-c.width, MIN_W, q_data-width, 1,
+ cr-c.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
+
+ /* adjust left/top if cropping rectangle is out of bounds */
+ if (cr-c.left + cr-c.width q_data-width)
+ cr-c.left = q_data-width - cr-c.width;
+ if (cr-c.top + cr-c.height q_data-height)
+ cr-c.top = q_data-height - cr-c.height;
+
+ return 0;
+}
+
+static int vpe_cropcap(struct file *file, void *priv, struct v4l2_cropcap *cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr-bounds.left = 0;
+ cr-bounds.top = 0;
+ cr-bounds.width = q_data-width;
+ cr-bounds.height = q_data-height;
+ cr-defrect = cr-bounds;
+
+ return 0;
+}
+
+static int vpe_g_crop(struct file *file, void *fh, struct v4l2_crop *cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr-c = q_data-c_rect;
+
+ return 0;
+}
+
+static int vpe_s_crop(struct file *file, void *priv,
+ const struct v4l2_crop *crop)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+ struct v4l2_crop cr = *crop;
+ int ret;
+
+ ret = __vpe_try_crop(ctx, cr);
+ if (ret)
+ return ret;
+
+ q_data = get_q_data(ctx, cr.type);
+
+ if ((q_data-c_rect.left == cr.c.left)
+ (q_data-c_rect.top == cr.c.top)
+ (q_data-c_rect.width == cr.c.width)
+ (q_data-c_rect.height == cr.c.height)) {
+ vpe_dbg(ctx-dev, requested crop values are already set\n);
+ return 0;
+ }
+
+ q_data-c_rect = cr.c;
+
+ return set_srcdst_params(ctx);
+}
+
static int vpe_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *reqbufs)
{
@@ -1672,6 +1764,10 @@ static const struct v4l2_ioctl_ops vpe_ioctl_ops = {
.vidioc_try_fmt_vid_out_mplane = vpe_try_fmt,
.vidioc_s_fmt_vid_out_mplane= vpe_s_fmt,
+ .vidioc_cropcap = vpe_cropcap,
+ .vidioc_g_crop = vpe_g_crop,
+ .vidioc_s_crop = vpe_s_crop,
+
.vidioc_reqbufs = vpe_reqbufs,
.vidioc_querybuf= vpe_querybuf,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] v4l: ti-vpe: Some VPE fixes and enhancements
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 v4l2 device. - Prevent the possibility of output m2m queue not having sufficient 'ready' buffers. - Some VPDMA data descriptor fields weren't understood correctly before. They are now used correctly. The rest of the patches add some minor features like DMA buf support and cropping. Reference branch: g...@github.com:boddob/linux.git vpe_for_315 Archit Taneja (7): v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs v4l: ti-vpe: register video device only when firmware is loaded v4l: ti-vpe: Use video_device_release_empty v4l: ti-vpe: Allow DMABUF buffer type support v4l: ti-vpe: Allow usage of smaller images v4l: ti-vpe: Fix some params in VPE data descriptors v4l: ti-vpe: Add crop support in VPE driver drivers/media/platform/ti-vpe/vpdma.c | 58 --- drivers/media/platform/ti-vpe/vpdma.h | 16 +-- drivers/media/platform/ti-vpe/vpe.c | 180 +++--- 3 files changed, 198 insertions(+), 56 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] v4l: ti-vpe: Allow DMABUF buffer type support
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 io_modes of the vb2 output and capture queues. This allows the driver to import dma shared buffers. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index bb275f4..915029b 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -1768,7 +1768,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(src_vq, 0, sizeof(*src_vq)); src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; - src_vq-io_modes = VB2_MMAP; + src_vq-io_modes = VB2_MMAP | VB2_DMABUF; src_vq-drv_priv = ctx; src_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); src_vq-ops = vpe_qops; @@ -1781,7 +1781,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(dst_vq, 0, sizeof(*dst_vq)); dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - dst_vq-io_modes = VB2_MMAP; + dst_vq-io_modes = VB2_MMAP | VB2_DMABUF; dst_vq-drv_priv = ctx; dst_vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); dst_vq-ops = vpe_qops; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs
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 ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/ti-vpe/vpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 1296c53..623e59e 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -887,6 +887,9 @@ static int job_ready(void *priv) if (v4l2_m2m_num_src_bufs_ready(ctx-m2m_ctx) needed) return 0; + if (v4l2_m2m_num_dst_bufs_ready(ctx-m2m_ctx) needed) + return 0; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi Archit!
On 03/03/2014 08:33 AM, Archit Taneja wrote:
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE,
or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.
Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for this purpose.
Some standard crop parameter checks are done in __vpe_try_crop().
Please use the selection ops instead: if you implement cropping with those then
you'll
support both the selection API and the old cropping API will be implemented by
the v4l2
core using the selection ops. Two for the price of one...
Regards,
Hans
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpe.c | 96
+
1 file changed, 96 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 6acdcd8..c6778f4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1585,6 +1585,98 @@ static int vpe_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return set_srcdst_params(ctx);
}
+static int __vpe_try_crop(struct vpe_ctx *ctx, struct v4l2_crop *cr)
+{
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ /* we don't support crop on capture plane */
+ if (cr-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ cr-c.top = cr-c.left = 0;
+ cr-c.width = q_data-width;
+ cr-c.height = q_data-height;
+ return 0;
+ }
+
+ if (cr-c.top 0 || cr-c.left 0) {
+ vpe_err(ctx-dev, negative values for top and left\n);
+ cr-c.top = cr-c.left = 0;
+ }
+
+ v4l_bound_align_image(cr-c.width, MIN_W, q_data-width, 1,
+ cr-c.height, MIN_H, q_data-height, H_ALIGN, S_ALIGN);
+
+ /* adjust left/top if cropping rectangle is out of bounds */
+ if (cr-c.left + cr-c.width q_data-width)
+ cr-c.left = q_data-width - cr-c.width;
+ if (cr-c.top + cr-c.height q_data-height)
+ cr-c.top = q_data-height - cr-c.height;
+
+ return 0;
+}
+
+static int vpe_cropcap(struct file *file, void *priv, struct v4l2_cropcap
*cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr-bounds.left = 0;
+ cr-bounds.top = 0;
+ cr-bounds.width = q_data-width;
+ cr-bounds.height = q_data-height;
+ cr-defrect = cr-bounds;
+
+ return 0;
+}
+
+static int vpe_g_crop(struct file *file, void *fh, struct v4l2_crop *cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr-type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr-c = q_data-c_rect;
+
+ return 0;
+}
+
+static int vpe_s_crop(struct file *file, void *priv,
+ const struct v4l2_crop *crop)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+ struct v4l2_crop cr = *crop;
+ int ret;
+
+ ret = __vpe_try_crop(ctx, cr);
+ if (ret)
+ return ret;
+
+ q_data = get_q_data(ctx, cr.type);
+
+ if ((q_data-c_rect.left == cr.c.left)
+ (q_data-c_rect.top == cr.c.top)
+ (q_data-c_rect.width == cr.c.width)
+ (q_data-c_rect.height == cr.c.height)) {
+ vpe_dbg(ctx-dev, requested crop values are already set\n);
+ return 0;
+ }
+
+ q_data-c_rect = cr.c;
+
+ return set_srcdst_params(ctx);
+}
+
static int vpe_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *reqbufs)
{
@@ -1672,6 +1764,10 @@ static const struct v4l2_ioctl_ops vpe_ioctl_ops = {
.vidioc_try_fmt_vid_out_mplane = vpe_try_fmt,
.vidioc_s_fmt_vid_out_mplane= vpe_s_fmt,
+ .vidioc_cropcap = vpe_cropcap,
+ .vidioc_g_crop = vpe_g_crop,
+ .vidioc_s_crop = vpe_s_crop,
+
.vidioc_reqbufs = vpe_reqbufs,
.vidioc_querybuf= vpe_querybuf,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
