Re: [PATCH v2] ARM: dts: add AM33XX EDMA support

[Joel Fernandes]

Hi Benoit,

On 08/26/2013 03:36 AM, Benoit Cousson wrote:
> - minus all the TI emails which are not working anymore :-(
> 
> I've just sent my previous email too soon...
> 
> Now the patch is different :-) I'll take that one.

Unfortunately this patch is still missing from your latest pull request:

Subject "[GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2"
  git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
tags/for_3.12/dts_signed  (commit 4843be165c10f9886c87eeb20acf19a3ddec6653)

Below is a scissor patch that cleanly applies on above branch.

Thanks,

-Joel

--->8
From: Matt Porter 
Subject: [PATCH] ARM: dts: add AM33XX EDMA support

Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt

v2 changes:
Drop DT entries that are non-hardware-description Joel Fernandes 
Discussion in [1].

v3 changes: Changed node name from "edma: edma@" to "edma: dma-controller@"
by Sebastian Andrzej Siewior 

[1] https://patchwork.kernel.org/patch/2226761/

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 arch/arm/boot/dts/am33xx.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5996d63..f5869ed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -101,6 +101,18 @@
reg = <0x4820 0x1000>;
};

+   edma: dma-controller@4900 {
+   compatible = "ti,edma3";
+   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+   reg =   <0x4900 0x1>,
+   <0x44e10f90 0x10>;
+   interrupts = <12 13 14>;
+   #dma-cells = <1>;
+   dma-channels = <64>;
+   ti,edma-regions = <4>;
+   ti,edma-slots = <256>;
+   };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
-- 
1.8.1.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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

Vaibhav Bedia  writes:

> On Tue, Aug 27, 2013 at 5:45 PM, Kevin Hilman  wrote:
> [...]
>>
>> Looking closer at this code as I'm trying to fully get my head around
>> all the IPC, I have some more comments.
>>
>> I think the split between pm33xx.c and the M3 driver is still confusing
>> here.  For example, am33xx_ping_wkup_m3(),
>> am33xx_m3_state_machine_reset() and the guts of am33xx_pm_begin() all
>> belong inside the M3 driver, along with all the wakeup_src stuff, which
>> is info coming from the M3.
>>
>> IOW, the communication with M3 should be abstracted from pm33xx by the
>> M3 driver (or possibly an eventual remoteproc/rpmsg implementation) with
>> a well defined API.  In this implementation, the interface is pretty
>> fuzzy and mixed between pm33xx.c and wkup_m3.c.
>>
>>
>
> The reason for the current split was to have the M3 driver just do the minimal
> that's needed to talk to get M3 and MPU talking. What made me do it this way
> was to attempt to address a previous comment on keeping options open for folks
> to use M3 for things other than PM stuff. The IPC stuff is how
> implementors of the
> firmware (anything other than the PM one that TI provides) want it to be.

IMO, there should actually be 3 levels. the SoC PM implementation
(pm33xx.c), the M3 driver where the protocol, state-machine, etc. are
handled, and the messaging layer.  In the current proposal, the last 2
are combined, but I'd really like to see a generalized messaging layer
that everyone else using an M3 coprocessor might use as well.  As
mentioned already, I think that should be rpmsg, but that still needs
some exploration.

> The top level idea was to have the users of the firmware (PM in this case)
> decide what functionality they want when talking to M3. They are also free to
> decide the register bitfield layout and other IPC details.
>
> This was also a feeble attempt to keep things extensible for AM437x where
> in addition to the broken mailbox usage there's now a control module bit
> to trigger the interrupt to M3 (what's worse? pick one that you hate more ;)

Sounds like AM43xx is better.  If you have a control module bit to
trigger an interrupt, why do you need the mailbox at all?

> The AM437x PM routines could then just register different callbacks that
> are triggered when the M3 interrupts the MPU.
>
> Hope this clears up some of the confusion.

Thanks,

Kevin
--
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.12 take #2

[Benoit Cousson]

Hi Kevin & Olof,

Here is the updated version without the conflicting patch (ARM: dts: AM33XX: 
don't redefine OCP bus and device nodes) and with the signed tag.
There is still a small conflict with usb-next, but it is easily fixable, and 
already fixed by Stephen.

Thanks,
Benoit


The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:

  Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
tags/for_3.12/dts_signed

for you to fetch changes up to 4843be165c10f9886c87eeb20acf19a3ddec6653:

  ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies (2013-08-30 
21:33:13 +0200)


Add the minimal DTS support for DRA7xx based SoC core.
Add the initial support for N900 and gta04 phones.
Enable USB3 on OMAP5 evm board.
Do a lot of various cleanups.


Afzal Mohammed (2):
  ARM: dts: AM4372: cpu(s) node per latest binding
  ARM: dts: AM4372: add few nodes

Alexandre Belloni (1):
  ARM: dts: AM33XX: Add PMU support

Benoit Cousson (1):
  ARM: OMAP5: hwmod: add missing ocp2scp hwmod data

Felipe Balbi (4):
  ARM: OMAP5: dts: fix reg property size
  ARM: OMAP5: dts: fix ocp2scp DTS data
  ARM: OMAP5: dts: add palmas-usb node
  ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies

Javier Martinez Canillas (4):
  ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration
  ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs
  ARM: dts: omap3-igep0030: add mux conf for GPIO LED
  ARM: dts: AM33XX: use pinmux node defined in included file

Kishon Vijay Abraham I (1):
  ARM: dts: omap5-uevm: Split SMPS10 in two nodes

Lars Poeschel (1):
  ARM: dts: AM33xx: Correct gpio #interrupt-cells property

Lee Jones (7):
  ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
  ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
  ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
  ARM: dts: Remove '0x's from OMAP3 DTS file
  ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
  ARM: dts: Remove '0x's from OMAP4 DTS file
  ARM: dts: Remove '0x's from OMAP5 DTS file

Marek Belisko (1):
  ARM: dts: Add devicetree for gta04 board.

Pavel Machek (1):
  ARM: dts: N900: Add device tree

R Sricharan (1):
  ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board

Robert Nelson (1):
  ARM: dts: omap3-beagle-xm: fix string error in compatible property

Roger Quadros (1):
  ARM: dts: omap3-beagle: Make USB host pin naming consistent

Ruslan Bilovol (1):
  ARM: dts: twl6030: Move common configuration for OMAP4 boards in a 
separate dtsi file

 arch/arm/boot/dts/Makefile |   5 +-
 arch/arm/boot/dts/am335x-bone.dts  | 176 -
 arch/arm/boot/dts/am335x-evm.dts   | 254 ++---
 arch/arm/boot/dts/am335x-evmsk.dts | 258 ++---
 arch/arm/boot/dts/am33xx.dtsi  |  13 +-
 arch/arm/boot/dts/am4372.dtsi  | 347 +
 arch/arm/boot/dts/dra7-evm.dts | 140 +++
 arch/arm/boot/dts/dra7.dtsi| 575 +
 arch/arm/boot/dts/omap2420-h4.dts  |   6 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts  |   2 +-
 arch/arm/boot/dts/omap3-beagle.dts |  24 +-
 arch/arm/boot/dts/omap3-gta04.dts  | 168 +
 arch/arm/boot/dts/omap3-igep.dtsi  |   2 +
 arch/arm/boot/dts/omap3-igep0020.dts   |  19 +-
 arch/arm/boot/dts/omap3-igep0030.dts   |  17 +-
 arch/arm/boot/dts/omap3-n900.dts   |  92 +
 arch/arm/boot/dts/omap3.dtsi   |   2 +-
 arch/arm/boot/dts/omap3430-sdp.dts |  22 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi  |  21 +-
 arch/arm/boot/dts/omap4-sdp.dts|  21 +-
 arch/arm/boot/dts/omap4.dtsi   |   2 +-
 arch/arm/boot/dts/omap5-uevm.dts   |  25 +-
 arch/arm/boot/dts/omap5.dtsi   |  13 +-
 arch/arm/boot/dts/twl6030_omap4.dtsi   |  38 ++
 arch/arm/configs/omap2plus_defconfig   |   9 +
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  45 +++
 include/dt-bindings/pinctrl/dra.h  |  50 +++
 27 files changed, 1912 insertions(+), 434 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi
 create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
 create mode 100644 arch/arm/boot/dts/omap3-n900.dts
 create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi
 create mode 100644 include/dt-bindings/pinctrl/dra.h
--
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 1/1] arm: dts: am33xx: correcting dt node unit address for usb

[Kumar Gala]

On Aug 30, 2013, at 12:52 PM, Mugunthan V N wrote:

> DT node's unit address should be its own register offset address to make it a
> unique across the system. This patch corrects the incorrect USB entries with
> correct register offset for unit address.
> 
> Cc: Sebastian Andrzej Siewior 
> Cc: Felipe Balbi 
> Signed-off-by: Mugunthan V N 
> ---
> arch/arm/boot/dts/am33xx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index f9c5da9..e9b6775 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -346,7 +346,7 @@
>   ti,hwmods = "usb_otg_hs";
>   status = "disabled";
> 
> - ctrl_mod: control@44e1 {
> + ctrl_mod: control@44e10620 {
>   compatible = "ti,am335x-usb-ctrl-module";
>   reg = <0x44e10620 0x10
>   0x44e10648 0x4>;
> @@ -449,7 +449,7 @@
>   "tx14", "tx15";
>   };
> 
> - cppi41dma: dma-controller@07402000 {
> + cppi41dma: dma-controller@47402000 {

Why isn't the unit address 4740 ?

>   compatible = "ti,am3359-cppi41";
>   reg =  <0x4740 0x1000
>   0x47402000 0x1000
> -- 
> 1.8.4

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

--
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 01/13] ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4

[Vaibhav Bedia]

On Wed, Aug 21, 2013 at 3:13 AM, Rajendra Nayak  wrote:
[...]
>> +/**
>> + * omap4_cminst_clkdm_force_sleep - try to put a clockdomain to idle
>> + * @part: PRCM partition ID that the clockdomain registers exist in
>> + * @inst: CM instance register offset (*_INST macro)
>> + * @cdoffs: Clockdomain register offset (*_CDOFFS macro)
>> + *
>> + * Put a clockdomain referred to by (@part, @inst, @cdoffs) to idle,
>> + * forcing it to sleep.  No return value.
>> + */
>> +void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
>> +{
>> + _clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, part, inst, cdoffs);
>
> I guess this won't work on omap4/5 where some clockdomains do not support
> SW_SLEEP and only support HW_AUTO. We might need to have different clkdm
> operations for the different omap4 variants.
>
>

I am probably missing something here but doesn't omap4_clkdm_clk_disable() from
where this gets invoked have the appropriate flags in place already?
--
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/1] arm: dts: am33xx: correcting dt node unit address for usb

[Mugunthan V N]

DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.

Cc: Sebastian Andrzej Siewior 
Cc: Felipe Balbi 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am33xx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..e9b6775 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -346,7 +346,7 @@
ti,hwmods = "usb_otg_hs";
status = "disabled";
 
-   ctrl_mod: control@44e1 {
+   ctrl_mod: control@44e10620 {
compatible = "ti,am335x-usb-ctrl-module";
reg = <0x44e10620 0x10
0x44e10648 0x4>;
@@ -449,7 +449,7 @@
"tx14", "tx15";
};
 
-   cppi41dma: dma-controller@07402000 {
+   cppi41dma: dma-controller@47402000 {
compatible = "ti,am3359-cppi41";
reg =  <0x4740 0x1000
0x47402000 0x1000
-- 
1.8.4

--
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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support

[Vaibhav Bedia]

On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman  wrote:
[...]
>>>
>>> Maybe I'm getting confused, but the more you talk about the linux and
>>> the firmware doing the same code, the more I think the firmware is
>>> (trying) to do too much.  If this is going to be understandable (and
>>> maintainable), there needs to be a clean split of roles between the MPU
>>> and the M3.
>>>
>>
>> In the past i tried to keep the firmware as minimal as possible and pushed
>> back all efforts to push unnecessary stuff in there. Like Kevin, i too was of
>> the opinion that we need to do whatever's possible in the kernel.
>>
>> Sadly, things just got a point where it made much more sense (technically
>> as well as non-technically) to just put the low level stuff in the M3.
>>
>> 1. In addition to the Linux support, we have non-OS based code for AM335x
>> (and AM437x) which in the past just had to duplicate whatever was done
>> in the Linux. Being a different codebase the non-OS guys have their own
>> set of challenges and we had to at times sit through and debug issues in
>> one codebase while the other was working fine. Ideally these things should
>> never come up but sadly they do and we need to solve them.
>>
>> We also have people trying to implement this thing on different sort of
>> OS environments and they also end up debugging the same set of issues.
>>
>> With only a handful of folks able to spend time debugging issues 'do 
>> everything
>> in Linux and expect others to copy it' model doesn't scale up. Keeping
>> things in the
>> firmware with the code available online helps do away with the
>> 'developer scalability'
>> problem and if one looks at things differently enables code-reuse at
>> the same time.
>
> Yes, yes, this is the classic argument for a HAL, and making that case has 
> always
> gone over well in the kernel. ;)
>

If the carefully crafted C code with a bit of linker magic thrown in
works, that's great
but for anyone without the generic Linux code in general and the Linux community
to go to with queries will have a tough time getting it done. TI
non-OS code has been
implemented from scratch and one of the purposes is to keep things as simple
as possible for folks. I know it's all non-technical stuff and most
likely i am a bit
biased but just a different POV from someone who spent hours debugging
'this works
and that doesn't' kind of issues. Trying to wrap your head around
random s/w stacks
and figuring out what needs to be changed is not pretty IMHO :\

>> Moreover, when the code was finally moved to M3, AFAICT we had validated
>> all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT
>> control) that TI hardware guys could throw at us.Yes there could be stupid 
>> bugs
>> lurking in the code since it wasn't reviewed as much as i would have
>> liked but we
>> have something which proves the functionality to be used as the base.
>
> I don't follow the argument here.  You mean it was validated *before*
> moving it to the M3, or after?  Either way, I'm how that makes a case
> for moving it to the M3.  Surely if it was on the MPU, it would also
> have been validated, no?
>

At least i did all the validation without the VDD_CORE changes. The point i was
trying to make is that we are not trying to hide bugs in there, if
that's one of the
concerns. Just trying to make it simple (subjective, i know) for others to use.

>> 2. As has been already been pointed out by Russ, on AM335x this step needs
>> to be done very late in the suspend process (the last stage
>> actually).
>
> late, yes.  But *technically*, it can still be done from the MPU.
>
>> On the next SoC there are other complications related to security
>> which enforce this step must be done from the M3.
>
> Aha!  So far, the first technical reason I've seen.  Can you elaborate?
> Exactly which step has to be done from the M3, and why can't the MPU do
> it?  And could it be done more simply by putting *only* the parts needed
> on the M3 and not letting it snowball into a pile of stuff?
>

Sent out another mail for this.

Regards,
Vaibhav
--
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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi
 wrote:
> Hi
>
> On 07/02/2013 05:03 PM, Roger Quadros wrote:
>>
>> On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
>>> Hi Roger
>>>
>>> On 07/02/2013 04:42 PM, Roger Quadros wrote:
 On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
> Hi
>
>>

I'm working on PM consumption of other subsystem because it's a very
complex device.
Right now the pm consumption is sleep mode is 6mA just for (off mode disabled)

omap4 + LPDDR2 and TWL6032

I don't exactly know if they have updated the last bootloader but I think so.

I have tried to work on STP signal and re-enable it just before resume
but nothing change

Anyway my idea is the problem is releated on 18clk counter and an
invalid state of the
hw. I will try to implement save & restore register by hand instead
using the sar.

Michael


>>
>> When you said earlier that the problem doesn't happen when one of the 
>> ULPIs is used
>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>> case 2: port 2 only enabled.
>>
>> Did it work in both the cases?
>
> Yes, so I don't think could be a problem of ulpi pins and why this happen
> on both at the same time? Seems more connected to somenthing else.
>

 Right. Seems to be related to two things. OFF Mode and 2 ports being used 
 simultaneously.

 I'm not sure how to go about fixing this. How important is OFF Mode for 
 your application.
 Can you keep it always disabled?

>>
>>
>>>
>>> Right now I delivery without off mode. I will try to fix in long run the 
>>> usb and I think that it could be a good platform to test omap4 mainline.
>>>
>>
>> Yes, our aim is to get it working with mainline as well.
>>
>>> Last question:
>>> If one domain is in RET mode and not OFF mode what happen during SAR 
>>> restore in OFF mode?
>>>
>>
>> SAR restore will only happen when the Device enters OFF mode.
>>
>> Device OFF mode can only be reached when all voltage domains are switched 
>> OFF and that would depend
>> if all power domains entered OFF or not. Just a simplistic explanation. You 
>> can refer to chapter
>> "3.9.3 Device OFF State Management" in the TRM.
>
> What happen if we ask to go in off mode for all domains but one doesn't go in 
> off mode so the device
> will not go in off mode and the sar will not be used? How can work the 
> restore?
>
>>
>
> I have added a check of CM_RESTORE_ST. This register need to be clear before
> going in OFF mode and then show if the status of phase1 2a and 2b is 
> completed.
> So before proceed with system resume and after resetting OFF_MODE bit I have 
> tried to wait on this register,
> but without success.
>
> Michael
>
>> cheers,
>> -roger
>>
>
>
--
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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Vaibhav Bedia]

On Tue, Aug 27, 2013 at 5:45 PM, Kevin Hilman  wrote:
[...]
>
> Looking closer at this code as I'm trying to fully get my head around
> all the IPC, I have some more comments.
>
> I think the split between pm33xx.c and the M3 driver is still confusing
> here.  For example, am33xx_ping_wkup_m3(),
> am33xx_m3_state_machine_reset() and the guts of am33xx_pm_begin() all
> belong inside the M3 driver, along with all the wakeup_src stuff, which
> is info coming from the M3.
>
> IOW, the communication with M3 should be abstracted from pm33xx by the
> M3 driver (or possibly an eventual remoteproc/rpmsg implementation) with
> a well defined API.  In this implementation, the interface is pretty
> fuzzy and mixed between pm33xx.c and wkup_m3.c.
>
>

The reason for the current split was to have the M3 driver just do the minimal
that's needed to talk to get M3 and MPU talking. What made me do it this way
was to attempt to address a previous comment on keeping options open for folks
to use M3 for things other than PM stuff. The IPC stuff is how
implementors of the
firmware (anything other than the PM one that TI provides) want it to be.

The top level idea was to have the users of the firmware (PM in this case)
decide what functionality they want when talking to M3. They are also free to
decide the register bitfield layout and other IPC details.

This was also a feeble attempt to keep things extensible for AM437x where
in addition to the broken mailbox usage there's now a control module bit
to trigger the interrupt to M3 (what's worse? pick one that you hate more ;)
The AM437x PM routines could then just register different callbacks that
are triggered when the M3 interrupts the MPU.

Hope this clears up some of the confusion.

Regards,
Vaibhav
--
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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Vaibhav Bedia]

(picking up an old thread, again)

On Thu, Aug 8, 2013 at 7:04 PM, Kevin Hilman  wrote:
>
> I disagree here.  I'm a firmware minimalist, and hiding bugs like this
> in the firmware is wrong when Linux is otherwise managing these devices.
> It also imposes criteria on the firmware of future SoCs that doesn't
> belong there either.  IMO, the only stuff the firmware should do is what
> Linux *cannot* do.
>
> Remember, this only needs to happen when there isn't a driver for these
> devices.  Should we communicate to the firmware that the OS has no
> driver, so please enable the hack?  I think not.
>

Agreed on not hiding the bugs in the firmware. Moreover, M3 can't access
the IPs in PER domain which is where the bad modules are, so the h/w
doesn't support such hackery (+1 for the h/w after all the -1's that it gets ;)

[...]

>>> That being said, IMO, the kernel (specifically omap_device) should
>>> handle this, and it should be rather easy to do in the omap_device layer
>>> and keep the SoC suspend/resume core code simple and ignorant of these
>>> "quirks."
>>>
>>> AFAICT, there's no reason these quirks need to be dealt with immediatly
>>> on suspend.  A slight delay should be fine, as long as it's before the
>>> next suspend/idle attempt, right?
>>>
>>> Given that, what we need to do (and by we, I mean you) is to flag all
>>> broken IP blocks, and let omap_device handle them in a suspend/resume
>>> notifier (c.f. register_pm_notifier() and PM_POST_SUSPEND.)
>>
>> yes - that is the alternate that comes to mind.
>
> In the earlier reviews of this series (many months ago now), I
> complained about the presence of this device specific handling in the
> core MPU PM code.  I'm somewhat troubled by the fact that nobody explored
> alternatives that so easily come to mind.
>

My bad. I was thinking along those lines [1] but after the suggestion on
using the driver bound status i just went with that suggestion in the dumbest
possible manner.

Regards,
Vaibhav

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129676.html
--
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 v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support

[Kevin Hilman]

Russ Dill  writes:

> On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman  wrote:
>> Vaibhav Bedia  writes:
> [snip]
>>> Morevoer, all the suggestions on how to keep the code in Linux working
>>> around the complications due to the main memory not being accessible
>>> will need to be replicated on the non-Linux s/w stacks and that's just
>>> make it more difficult for them.
>>
>> The linux code has to be very self-contained (in assembler or C), so I'm
>> not sure how it's difficult to replicated in any other OS (or non-OS.)
>
> Let me pull on this thread a little bit. Would this involve defining a
> bunch of different sections for each arch so that I could do:
>
> void __sram_am33xx am33xx_some_pm_function(args)
> {
> }
>
> static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...};
>
> static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... };
>
> The sram push code could then push these sections into sram. There
> would then be a set of inlines or macros for converting addresses
> within these sections to SRAM addresses, maybe also inlines or macros
> for calling code that has been pushed into sram by wrapping the
> original function pointer. The macros or inlines that call SRAM code
> could perform the trampoline as well.

Well, I was thinking of something much dumber.

I was thinking about just _carefully_ writing a single, self-contained C
function, with all of its data on the stack (and consts as #defines).
Think of it is a step up in readability from straight assembly (which
was the stated reason for moving the code to the M3 in the first place.)

Kevin
--
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 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM

[Santosh Shilimkar]

On Friday 30 August 2013 10:39 AM, Kevin Hilman wrote:
> Rajendra Nayak  writes:
> 
>> On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
>>> Rajendra Nayak  writes:
>>>
 In order to handle errata I688, a page of sram was reserved by doing a
 static iotable map. Now that we use gen_pool to manage sram, we can
 completely remove all of these static mappings and use gen_pool_alloc()
 to get the one page of sram space needed to implement errata I688.

 Suggested-by: Sekhar Nori 
 Signed-off-by: Rajendra Nayak 
>>>
>>> [...]
>>>
 @@ -71,6 +72,21 @@ void omap_bus_sync(void)
  }
  EXPORT_SYMBOL(omap_bus_sync);
  
 +static int __init omap4_sram_init(void)
 +{
 +  struct device_node *np;
 +  struct gen_pool *sram_pool;
 +
 +  np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
 +  if (!np)
 +  pr_warn("%s:Unable to allocate sram needed to handle errata 
 I688\n",
 +   __func__);
 +  sram_pool = of_get_named_gen_pool(np, "sram", 0);
>>>
>>> I haven't actually tested this, but if there is no 'sram' property 
>>> defined...
>>>   
 +  sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
>>>
>>> ... does this still behave properly?
>>
>> I guess not :(
>> of_get_named_gen_pool() ends up returning NULL, but passing NULL to 
>> gen_pool_alloc()
>> crashes. Will fix with the additional check for non-NULL sram_pool, thanks.
> 
> OK, that's what I suspected.  Thanks for checking/testing.
> 
I miss-understood your comment initially. Now re-reading it, its clear now.

Regards,
Santosh

--
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 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM

[Kevin Hilman]

Rajendra Nayak  writes:

> On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
>> Rajendra Nayak  writes:
>> 
>>> In order to handle errata I688, a page of sram was reserved by doing a
>>> static iotable map. Now that we use gen_pool to manage sram, we can
>>> completely remove all of these static mappings and use gen_pool_alloc()
>>> to get the one page of sram space needed to implement errata I688.
>>>
>>> Suggested-by: Sekhar Nori 
>>> Signed-off-by: Rajendra Nayak 
>> 
>> [...]
>> 
>>> @@ -71,6 +72,21 @@ void omap_bus_sync(void)
>>>  }
>>>  EXPORT_SYMBOL(omap_bus_sync);
>>>  
>>> +static int __init omap4_sram_init(void)
>>> +{
>>> +   struct device_node *np;
>>> +   struct gen_pool *sram_pool;
>>> +
>>> +   np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
>>> +   if (!np)
>>> +   pr_warn("%s:Unable to allocate sram needed to handle errata 
>>> I688\n",
>>> +__func__);
>>> +   sram_pool = of_get_named_gen_pool(np, "sram", 0);
>> 
>> I haven't actually tested this, but if there is no 'sram' property defined...
>>   
>>> +   sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
>> 
>> ... does this still behave properly?
>
> I guess not :(
> of_get_named_gen_pool() ends up returning NULL, but passing NULL to 
> gen_pool_alloc()
> crashes. Will fix with the additional check for non-NULL sram_pool, thanks.

OK, that's what I suspected.  Thanks for checking/testing.

Kevin
--
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 02/10] cpufreq: OMAP: Add SMP support for OMAP4+

[Santosh Shilimkar]

> From: Viresh Kumar mailto:viresh.ku...@linaro.org>>
> Date: Wed, 21 Aug 2013 19:05:05 +0530
> Subject: [PATCH] cpufreq: omap: use cpufreq_generic_init() routine
> 
> Use generic cpufreq_generic_init() routine instead of replicating the same 
> code
> here.
> 
> This also rearranges the code a bit to make it more sensible. Also removes 
> some
> unnecessary checks.
> 
> Signed-off-by: Viresh Kumar  >
> ---
>  drivers/cpufreq/omap-cpufreq.c | 41 +++--
>  1 file changed, 11 insertions(+), 30 deletions(-)
>
I haven't tested it but looks straightforward so..
Acked-by: Santosh Shilimkar 

--
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 v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver

[Hans Verkuil]

On Fri 30 August 2013 12:05:11 Archit Taneja wrote:
> Hi,
> 
> On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote:
> > On 08/30/2013 08:47 AM, Archit Taneja wrote:
> >> On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
> >>> On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
>  VPE is a block which consists of a single memory to memory path which can
>  perform chrominance up/down sampling, de-interlacing, scaling, and color 
>  space
>  conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
>  interleaved video formats.
> 
>  We create a mem2mem driver based primarily on the mem2mem-testdev 
>  example.
>  The de-interlacer, scaler and color space converter are all bypassed for 
>  now
>  to keep the driver simple. Chroma up/down sampler blocks are 
>  implemented, so
>  conversion beteen different YUV formats is possible.
> 
>  Each mem2mem context allocates a buffer for VPE MMR values which it will 
>  use
>  when it gets access to the VPE HW via the mem2mem queue, it also 
>  allocates
>  a VPDMA descriptor list to which configuration and data descriptors are 
>  added.
> 
>  Based on the information received via v4l2 ioctls for the source and
>  destination queues, the driver configures the values for the MMRs, and 
>  stores
>  them in the buffer. There are also some VPDMA parameters like frame 
>  start and
>  line mode which needs to be configured, these are configured by direct 
>  register
>  writes via the VPDMA helper functions.
> 
>  The driver's device_run() mem2mem op will add each descriptor based on 
>  how the
>  source and destination queues are set up for the given ctx, once the 
>  list is
>  prepared, it's submitted to VPDMA, these descriptors when parsed by 
>  VPDMA will
>  upload MMR registers, start DMA of video buffers on the various input 
>  and output
>  clients/ports.
> 
> 
> 
> >>
>  +}
>  +
>  +#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1000)
> >>>
> >>> Reserve a control range for this driver in 
> >>> include/uapi/linux/v4l2-controls.h.
> >>> Similar to the ones already defined there.
> >>>
> >>> That will ensure that controls for this driver have unique IDs.
> >>
> >> Thanks, I took this from the mem2mem-testdev driver, a test driver
> >> doesn't need to worry about this I suppose.
> >>
> >> I had a query regarding this. I am planning to add a capture driver in
> >> the future for a similar IP which can share some of the control IDs with
> >> VPE. Is it possible for 2 different drivers to share the IDs?
> >
> > Certainly. There are three levels of controls:
> >
> > 1) Standard controls: can be used by any driver and are documented in the 
> > spec.
> > 2) IP-specific controls: controls specific for a commonly used IP.
> > These can be used by any driver containing that IP and are documented 
> > as well
> > in the spec. Good examples are the MFC and CX2341x MPEG controls.
> > 3) Driver-specific controls: these are specific to a driver and do not have 
> > to be
> > documented in the spec, only in the header/source specifying them. A 
> > range
> > of controls needs to be assigned to such a driver in v4l2-dv-controls.h.
> >
> > In your case it looks like the controls would fall into category 2.
> 
> For 2), by commonly used IP, do you mean a commonly used class of IPs 
> like MPEG decoder, FM and camera? Or do you mean a specific vendor IP 
> like say a camera subsystem found on different SoCs.

I mean a specific vendor IP found on different SoCs. So different drivers
would have to support the same IP.

> I think the controls in my case are very specific to the VPE and VIP 
> IPs. These 2 IPs have some components like scaler, color space 
> converter, chrominance up/downsampler in common. The controls will be 
> specific to how these components behave. For example, a control can tell 
> what value of frequency of Luminance peaking the scaler needs to 
> perform. I don't think all scalers would provide Luma peaking. This 
> holds for other controls too.
> 
> So if I understood your explanation correctly, I think 3) might make 
> more sense.

That might be a good starting point. It is not uncommon that controls
migrate from being custom controls to more standardized controls when
other devices appear using the same IP. Or sometimes what seemed like a
HW specific feature turns out to be available on other hardware from
other vendors as well.

> 
> >
> >> Also, I noticed in the header that most drivers reserve space for 16
> >> IDs. The current driver just has one, but there will be more custom ones
> >> in the future. Is it fine if I reserve 16 for this driver too?
> >
> > Sure, that's no problem. Make sure you reserve enough space for future
> > expansion, i.e. IDs are cheap, so no need to be conservative when defining
> > the range.
> 
> T

[PATCH v2 3/3] gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done

[George Cherian]

For pcf857x driver if the initial state is not set properly (proper
n_latch is not passed), we get bad irq prints on console.
We get this only for the first interrupt and doesnot repeat for further
interrupts unles and until there are other gpio pins which are not flipping
continously.

following prints are seen on console.

[   40.983924] irq 0, desc: ce004080, depth: 1, count: 0, unhandled: 0
[   40.990511] ->handle_irq():  c00aa538, handle_bad_irq+0x0/0x260
[   40.996768] ->irq_data.chip(): c080b6ec, no_irq_chip+0x0/0x60
[   41.002842] ->action():   (null)
[   41.006242]IRQ_NOPROBE set
[   41.009465]  IRQ_NOREQUEST set

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/dra7-evm.dts |  4 ++--
 drivers/gpio/gpio-pcf857x.c| 22 +++---
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 39b44bc..00fb0df 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,7 +50,7 @@
gpio20: pcf8575@20 {
compatible = "ti,pcf8575";
reg = <0x20>;
-   n_latch = <0x4000>;
+   n_latch = <0x>;
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&gpio6>;
@@ -62,7 +62,7 @@
gpio21: pcf8575@21 {
compatible = "ti,pcf8575";
reg = <0x21>;
-   n_latch = <0x1408>;
+   /*n_latch = <0x1408>;*/
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&gpio20>;
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4890e97..578d93f 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -93,6 +93,7 @@ struct pcf857x {
unsignedout;/* software latch */
unsignedstatus; /* current status */
int irq;/* real irq number */
+   unsignedirq_mapped; /* mapped gpio irqs */
 
int (*write)(struct i2c_client *client, unsigned data);
int (*read)(struct i2c_client *client);
@@ -185,8 +186,13 @@ static void pcf857x_set(struct gpio_chip *chip, unsigned 
offset, int value)
 static int pcf857x_to_irq(struct gpio_chip *chip, unsigned offset)
 {
struct pcf857x *gpio = container_of(chip, struct pcf857x, chip);
+   int ret;
 
-   return irq_create_mapping(gpio->irq_domain, offset);
+   ret = irq_create_mapping(gpio->irq_domain, offset);
+   if (ret > 0)
+   gpio->irq_mapped |= (1 << offset);
+
+   return ret;
 }
 
 static irqreturn_t pcf857x_irq(int irq, void *data)
@@ -198,7 +204,12 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
 
spin_lock_irqsave(&gpio->slock, flags);
 
-   change = gpio->status ^ status;
+   /*
+* call the interrupt handler iff gpio is used as
+* interrupt source, just to avoid bad irqs
+*/
+
+   change = ((gpio->status ^ status) & gpio->irq_mapped);
for_each_set_bit(i, &change, gpio->chip.ngpio)
generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
gpio->status = status;
@@ -211,9 +222,14 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
 static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
 irq_hw_number_t hw)
 {
+   struct pcf857x *gpio = domain->host_data;
+
irq_set_chip_and_handler(virq,
 &dummy_irq_chip,
 handle_level_irq);
+   set_irq_flags(virq, IRQF_VALID);
+   gpio->irq_mapped |= (1 << hw);
+
return 0;
 }
 
@@ -236,7 +252,7 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
gpio->irq_domain = irq_domain_add_linear(client->dev.of_node,
 gpio->chip.ngpio,
 &pcf857x_irq_domain_ops,
-NULL);
+gpio);
if (!gpio->irq_domain)
goto fail;
 
-- 
1.8.1.4

--
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 v2 1/3] gpio: pcf857x: change to devm_request_threaded_irq

[George Cherian]

Remove the request_irq and use devm_request_threaded_irq
also cleanup free_irq. devm_* takes care of that.

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/dra7-evm.dts |  2 +-
 drivers/gpio/gpio-pcf857x.c| 28 
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8b0738a..39b44bc 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -65,7 +65,7 @@
n_latch = <0x1408>;
gpio-controller;
#gpio-cells = <2>;
-   interrupt-parent = <&pcf_20>;
+   interrupt-parent = <&gpio20>;
interrupts = <14 2>;
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 947cff4..4d0d28c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -191,6 +191,25 @@ static int pcf857x_to_irq(struct gpio_chip *chip, unsigned 
offset)
return irq_create_mapping(gpio->irq_domain, offset);
 }
 
+static irqreturn_t pcf857x_irq(int irq, void *data)
+{
+   struct pcf857x  *gpio = data;
+   unsigned long change, i, status, flags;
+
+   status = gpio->read(gpio->client);
+
+   spin_lock_irqsave(&gpio->slock, flags);
+
+   change = gpio->status ^ status;
+   for_each_set_bit(i, &change, gpio->chip.ngpio)
+   generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
+   gpio->status = status;
+
+   spin_unlock_irqrestore(&gpio->slock, flags);
+
+   return IRQ_HANDLED;
+}
+
 static void pcf857x_irq_demux_work(struct work_struct *work)
 {
struct pcf857x *gpio = container_of(work,
@@ -241,8 +260,6 @@ static void pcf857x_irq_domain_cleanup(struct pcf857x *gpio)
if (gpio->irq_domain)
irq_domain_remove(gpio->irq_domain);
 
-   if (gpio->irq)
-   free_irq(gpio->irq, gpio);
 }
 
 static int pcf857x_irq_domain_init(struct pcf857x *gpio,
@@ -258,8 +275,11 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
 
/* enable real irq */
-   status = request_irq(client->irq, pcf857x_irq_demux, 0,
-dev_name(&client->dev), gpio);
+   status = devm_request_threaded_irq(&client->dev, client->irq,
+   NULL, pcf857x_irq, IRQF_ONESHOT |
+   IRQF_TRIGGER_FALLING,
+   dev_name(&client->dev), gpio);
+
if (status)
goto fail;
 
-- 
1.8.1.4

--
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 v2 2/3] gpio: pcf857x: remove the irq_demux_work

[George Cherian]

Now that we are using devm_request_threaded_irq no need for
irq_demux_work. Remove all its references.

Signed-off-by: George Cherian 
---
 drivers/gpio/gpio-pcf857x.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 4d0d28c..4890e97 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 
 
 static const struct i2c_device_id pcf857x_id[] = {
@@ -89,7 +88,6 @@ struct pcf857x {
struct gpio_chipchip;
struct i2c_client   *client;
struct mutexlock;   /* protect 'out' */
-   struct work_struct  work;   /* irq demux work */
struct irq_domain   *irq_domain;/* for irq demux  */
spinlock_t  slock;  /* protect irq demux */
unsignedout;/* software latch */
@@ -210,38 +208,6 @@ static irqreturn_t pcf857x_irq(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static void pcf857x_irq_demux_work(struct work_struct *work)
-{
-   struct pcf857x *gpio = container_of(work,
-  struct pcf857x,
-  work);
-   unsigned long change, i, status, flags;
-
-   status = gpio->read(gpio->client);
-
-   spin_lock_irqsave(&gpio->slock, flags);
-
-   change = gpio->status ^ status;
-   for_each_set_bit(i, &change, gpio->chip.ngpio)
-   generic_handle_irq(irq_find_mapping(gpio->irq_domain, i));
-   gpio->status = status;
-
-   spin_unlock_irqrestore(&gpio->slock, flags);
-}
-
-static irqreturn_t pcf857x_irq_demux(int irq, void *data)
-{
-   struct pcf857x  *gpio = data;
-
-   /*
-* pcf857x can't read/write data here,
-* since i2c data access might go to sleep.
-*/
-   schedule_work(&gpio->work);
-
-   return IRQ_HANDLED;
-}
-
 static int pcf857x_irq_domain_map(struct irq_domain *domain, unsigned int virq,
 irq_hw_number_t hw)
 {
@@ -284,7 +250,6 @@ static int pcf857x_irq_domain_init(struct pcf857x *gpio,
goto fail;
 
/* enable gpio_to_irq() */
-   INIT_WORK(&gpio->work, pcf857x_irq_demux_work);
gpio->chip.to_irq   = pcf857x_to_irq;
gpio->irq   = client->irq;
 
-- 
1.8.1.4

--
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 v2 0/3] cleanup of gpio_pcf857x.c

[George Cherian]

This patch series
- removes the irq_demux_work
- Uses devm_request_threaded_irq
- Call the user handler iff gpio_to_irq is done.

v1 --> v2 
Split v1 to 3 patches

George Cherian (3):
  gpio: pcf857x: change to  devm_request_threaded_irq
  gpio: pcf857x: remove the irq_demux_work
  gpio: pcf857x: call the gpio user  handler  iff gpio_to_irq is done

 arch/arm/boot/dts/dra7-evm.dts |  6 ++---
 drivers/gpio/gpio-pcf857x.c| 51 +-
 2 files changed, 29 insertions(+), 28 deletions(-)

-- 
1.8.1.4

--
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 v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver

[Archit Taneja]

Hi,

On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote:

On 08/30/2013 08:47 AM, Archit Taneja wrote:

On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:

On Thu 29 August 2013 14:32:49 Archit Taneja wrote:

VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.

We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.

Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.

Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.

The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.







+}
+
+#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)


Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.

That will ensure that controls for this driver have unique IDs.


Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.

I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?


Certainly. There are three levels of controls:

1) Standard controls: can be used by any driver and are documented in the spec.
2) IP-specific controls: controls specific for a commonly used IP.
These can be used by any driver containing that IP and are documented as 
well
in the spec. Good examples are the MFC and CX2341x MPEG controls.
3) Driver-specific controls: these are specific to a driver and do not have to 
be
documented in the spec, only in the header/source specifying them. A range
of controls needs to be assigned to such a driver in v4l2-dv-controls.h.

In your case it looks like the controls would fall into category 2.


For 2), by commonly used IP, do you mean a commonly used class of IPs 
like MPEG decoder, FM and camera? Or do you mean a specific vendor IP 
like say a camera subsystem found on different SoCs.


I think the controls in my case are very specific to the VPE and VIP 
IPs. These 2 IPs have some components like scaler, color space 
converter, chrominance up/downsampler in common. The controls will be 
specific to how these components behave. For example, a control can tell 
what value of frequency of Luminance peaking the scaler needs to 
perform. I don't think all scalers would provide Luma peaking. This 
holds for other controls too.


So if I understood your explanation correctly, I think 3) might make 
more sense.





Also, I noticed in the header that most drivers reserve space for 16
IDs. The current driver just has one, but there will be more custom ones
in the future. Is it fine if I reserve 16 for this driver too?


Sure, that's no problem. Make sure you reserve enough space for future
expansion, i.e. IDs are cheap, so no need to be conservative when defining
the range.


Thanks for the clarification.

Archit

--
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 00/22] OMAPDSS: DT support

[Tomi Valkeinen]

On 13/08/13 10:54, Tony Lindgren wrote:
> * Tomi Valkeinen  [130809 01:46]:
>>
>> So as is evident, I have things in my mind that should be improved. Maybe
>> the most important question for short term future is:
>>
>> Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us
>> some proper testing of the related code, and would also allow us to remove
>> the related hacks (which don't even work quite right). However, I have no
>> idea yet when the unstable DSS bindings would turn stable.
>>
>> If we shouldn't add the bindings as unstable, when should the bindings be
>> added? Wait until CDF is in the mainline, and use that?
> 
> I don't think we should add any temporary bindings as it's going to be
> a pain to support those in the long run. I suggest you initially just
> stick to established bindings for the basic hardware IO address and
> interrupts etc, then those should still be valid with the generic panel
> bindings later on.

I don't understand what does it matter if the bindings are temporary, or
basic established bindings. In both cases the DT data needs to be
changed when the CDF is taken into use.

Well, one difference is that the temporary bindings would give us
working display, but having only basic bindings would not. So I don't
see any reason to add only the basic bindings. Or how would it work?

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 3/3] ARM: OMAP4+: Remove static iotable mappings for SRAM

[Rajendra Nayak]

On Thursday 29 August 2013 10:50 PM, Kevin Hilman wrote:
> Rajendra Nayak  writes:
> 
>> In order to handle errata I688, a page of sram was reserved by doing a
>> static iotable map. Now that we use gen_pool to manage sram, we can
>> completely remove all of these static mappings and use gen_pool_alloc()
>> to get the one page of sram space needed to implement errata I688.
>>
>> Suggested-by: Sekhar Nori 
>> Signed-off-by: Rajendra Nayak 
> 
> [...]
> 
>> @@ -71,6 +72,21 @@ void omap_bus_sync(void)
>>  }
>>  EXPORT_SYMBOL(omap_bus_sync);
>>  
>> +static int __init omap4_sram_init(void)
>> +{
>> +struct device_node *np;
>> +struct gen_pool *sram_pool;
>> +
>> +np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
>> +if (!np)
>> +pr_warn("%s:Unable to allocate sram needed to handle errata 
>> I688\n",
>> + __func__);
>> +sram_pool = of_get_named_gen_pool(np, "sram", 0);
> 
> I haven't actually tested this, but if there is no 'sram' property defined...
>   
>> +sram_sync = (void *)gen_pool_alloc(sram_pool, PAGE_SIZE);
> 
> ... does this still behave properly?

I guess not :(
of_get_named_gen_pool() ends up returning NULL, but passing NULL to 
gen_pool_alloc()
crashes. Will fix with the additional check for non-NULL sram_pool, thanks.

regards,
Rajendra
> 
>> +return 0;
>> +}
> 
> Kevin
> 

--
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 1/3] crypto: omap-des: Add omap-des driver for OMAP4/AM43xx

[Rajendra Nayak]

[]..

> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#ifdef DEBUG
> +#define prn(num) printk(#num "=%d\n", num)
> +#define prx(num) printk(#num "=%x\n", num)
> +#else
> +#define prn(num) do { } while (0)
> +#define prx(num)  do { } while (0)
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DST_MAXBURST 2
> +
> +#define DES_BLOCK_WORDS  (DES_BLOCK_SIZE >> 2)
> +
> +#define _calc_walked(inout) (dd->inout##_walk.offset - 
> dd->inout##_sg->offset)
> +
> +#define DES_REG_KEY(dd, x)   ((dd)->pdata->key_ofs - \
> + ((x ^ 0x01) * 0x04))
> +
> +#define DES_REG_IV(dd, x)((dd)->pdata->iv_ofs + ((x) * 0x04))
> +
> +#define DES_REG_CTRL(dd) ((dd)->pdata->ctrl_ofs)
> +#define DES_REG_CTRL_CBC (1 << 4)
> +#define DES_REG_CTRL_TDES(1 << 3)
> +#define DES_REG_CTRL_DIRECTION   (1 << 2)
> +#define DES_REG_CTRL_INPUT_READY (1 << 1)
> +#define DES_REG_CTRL_OUTPUT_READY(1 << 0)

Why not use bitops like you have done below.

> +
> +#define DES_REG_DATA_N(dd, x)((dd)->pdata->data_ofs + ((x) * 
> 0x04))
> +
> +#define DES_REG_REV(dd)  ((dd)->pdata->rev_ofs)
> +
> +#define DES_REG_MASK(dd) ((dd)->pdata->mask_ofs)
> +
> +#define DES_REG_LENGTH_N(x)  (0x24 + ((x) * 0x04))
> +
> +#define DES_REG_IRQ_STATUS(dd) ((dd)->pdata->irq_status_ofs)
> +#define DES_REG_IRQ_ENABLE(dd) ((dd)->pdata->irq_enable_ofs)
> +#define DES_REG_IRQ_DATA_INBIT(1)
> +#define DES_REG_IRQ_DATA_OUT   BIT(2)
> +
> +#define FLAGS_MODE_MASK  0x000f
> +#define FLAGS_ENCRYPTBIT(0)
> +#define FLAGS_CBCBIT(1)
> +#define FLAGS_INIT   BIT(4)
> +#define FLAGS_BUSY   BIT(6)
> +

[]..

> +struct omap_des_pdata {
> + struct omap_des_algs_info   *algs_info;
> + unsigned intalgs_info_size;
> +
> + void(*trigger)(struct omap_des_dev *dd, int length);

Is this really used? How does a DT platform pass function pointers?

> +
> + u32 key_ofs;
> + u32 iv_ofs;
> + u32 ctrl_ofs;
> + u32 data_ofs;
> + u32 rev_ofs;
> + u32 mask_ofs;
> + u32 irq_enable_ofs;
> + u32 irq_status_ofs;
> +
> + u32 dma_enable_in;
> + u32 dma_enable_out;
> + u32 dma_start;
> +
> + u32 major_mask;
> + u32 major_shift;
> + u32 minor_mask;
> + u32 minor_shift;
> +};
> +
> +struct omap_des_dev {
> + struct list_headlist;
> + unsigned long   phys_base;
> + void __iomem*io_base;
> + struct omap_des_ctx *ctx;
> + struct device   *dev;
> + unsigned long   flags;
> + int err;
> +
> + /* spinlock used for queues */
> + spinlock_t  lock;
> + struct crypto_queue queue;
> +
> + struct tasklet_struct   done_task;
> + struct tasklet_struct   queue_task;
> +
> + struct ablkcipher_request   *req;
> + /*
> +  * total is used by PIO mode for book keeping so introduce
> +  * variable total_save as need it to calc page_order
> +  */
> + size_t  total;
> + size_t  total_save;
> +
> + struct scatterlist  *in_sg;
> + struct scatterlist  *out_sg;
> +
> + /* Buffers for copying for unaligned cases */
> + struct scatterlist  in_sgl;
> + struct scatterlist  out_sgl;
> + struct scatterlist  *orig_out;
> + int sgs_copied;
> +
> + struct scatter_walk in_walk;
> + struct scatter_walk out_walk;
> + int dma_in;
> + struct dma_chan *dma_lch_in;
> + int dma_out;
> + struct dma_chan *dma_lch_out;
> + int in_sg_len;
> + int out_sg_len;
> + int pio_only;
> + const struct omap_des_pdata *pdata;
> +};
> +
> +/* keep registered devices data here */
> +static LIST_HEAD(dev_list);
> +static DEFINE_SPINLOCK(list_lock);
> +

[]..

> +
> +static int omap_des_crypt_dma_start(struct omap_des_dev *dd)
> +{
> + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(
> + crypto_ablkcipher_reqtfm(dd->req));
> + int err;
> +
> + pr_debug("total: %d\n", dd->total);
> +
> + if (!dd->pio_only) {
> + err = dma_map_sg(dd->d

Re: omap: panda rcu stall on 3.10.1

[jean-philippe francois]

2013/8/30 Christian Hoffmann :
>
>> This also went to: linaro-ker...@lists.linaro.org
>
> Hi,
>
> current linaro kernel on 13.07 (3.10.1.0-1-linaro-omap) shows stack below.
> System is generally quite unstable. Light usage (postfix+dovecot...)
>
> Full dmesg here:
> https://dl.dropboxusercontent.com/u/21820416/rcu.stall.panda
>
Hi,

Does it happen when run with nohlt in the kernel command line ?

> Rgds,
> Chris
>
> [ 4538.880432] INFO: rcu_sched detected stalls on CPUs/tasks: { 1}
> (detected by 0, t=2103 jiffies, g=1649, c=1648, q=18)
> [ 4538.891723] Backtrace for cpu 0 (current):
> [ 4538.891723] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.891754] [] (unwind_backtrace+0x1/0x9c) from
> [] (show_stack+0x11/0x14)
> [ 4538.891815] [] (show_stack+0x11/0x14) from []
> (smp_send_all_cpu_backtrace+0x49/0x98)
> [ 4538.891815] [] (smp_send_all_cpu_backtrace+0x49/0x98) from
> [] (rcu_check_callbacks+0x439/0x4ac)
> [ 4538.891815] [] (rcu_check_callbacks+0x439/0x4ac) from
> [] (update_process_times+0x2d/0x4c)
> [ 4538.891876] [] (update_process_times+0x2d/0x4c) from
> [] (tick_sched_handle+0x35/0x40)
> [ 4538.891906] [] (tick_sched_handle+0x35/0x40) from
> [] (tick_sched_timer+0x31/0x54)
> [ 4538.891937] [] (tick_sched_timer+0x31/0x54) from
> [] (__run_hrtimer+0x5b/0x138)
> [ 4538.891937] [] (__run_hrtimer+0x5b/0x138) from []
> (hrtimer_interrupt+0xdb/0x22c)
> [ 4538.891967] [] (hrtimer_interrupt+0xdb/0x22c) from
> [] (twd_handler+0x1b/0x28)
> [ 4538.891998] [] (twd_handler+0x1b/0x28) from []
> (handle_percpu_devid_irq+0x4d/0xac)
> [ 4538.891998] [] (handle_percpu_devid_irq+0x4d/0xac) from
> [] (generic_handle_irq+0x19/0x24)
> [ 4538.892028] [] (generic_handle_irq+0x19/0x24) from
> [] (handle_IRQ+0x29/0x68)
> [ 4538.892059] [] (handle_IRQ+0x29/0x68) from []
> (gic_handle_irq+0x27/0x50)
> [ 4538.892059] [] (gic_handle_irq+0x27/0x50) from []
> (__irq_svc+0x3b/0x5c)
> [ 4538.892059] Exception stack(0xc06e3f68 to 0xc06e3fb0)
> [ 4538.892059] 3f60:     
>  c06e2000 c075f130
> [ 4538.892120] 3f80: c06e2000 c075ea93 c075f130 c06ea594 c045c2e0
> c06e2000 c0fe5908 c06e3fb0
> [ 4538.892120] 3fa0: c007bab1 c0058b48 400f0133 
> [ 4538.892120] [] (__irq_svc+0x3b/0x5c) from []
> (cpu_startup_entry+0xbc/0x164)
> [ 4538.892120] [] (cpu_startup_entry+0xbc/0x164) from
> [] (start_kernel+0x251/0x2ac)
> [ 4538.892120]
> [ 4538.892120] sending IPI to all other CPUs:
> [ 4538.892211] IPI backtrace for cpu 1
> [ 4538.892211]
> [ 4538.892242] CPU: 1 PID: 2064 Comm: clamd Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.892242] task: edb09500 ti: ec91e000 task.ti: ec91e000
> [ 4538.892272] PC is at 0xb6e2f0d4
> [ 4538.892272] LR is at 0xb6eeec01
> [ 4538.892272] pc : []lr : []psr: 000f0130
> [ 4538.892272] sp : be8b472c  ip : 62323337  fp : 684a
> [ 4538.892303] r10: 0084d750  r9 : 0200  r8 : e86d6a2f
> [ 4538.892303] r7 : 0a0a0a0a  r6 : 69393e32  r5 : 0080bf24  r4 : 0080bf28
> [ 4538.892333] r3 : 81010100  r2 : 6438  r1 : 000a  r0 : 0080bf24
> [ 4538.892333] Flags: nzcv  IRQs on  FIQs on  Mode USER_32  ISA Thumb
> Segment user
> [ 4538.892333] Control: 50c5387d  Table: acbd404a  DAC: 
> [ 4538.892364]
> [ 4538.892364] R8: 0xe86d69af:
> [ 4538.892364] 69ac  6a6f7254 412e6e61 746e6567 3939332d 00303934
> b1aa3270 2506 47a83ca7
> [ 4538.892395] 69cc  e4ebc453 91ad979e 23363f8b fd49d9d0 773b48ba
> ad58f7d3 04c351eb 96e4414f
> [ 4538.892395] 69ec  7e1a3ac7 f39072a5 e362cedb b119b3e0 b595375e
> b2137762 b19f99a8 b10dc638
> [ 4538.892395] 6a0c  1806 2e6e6957 6a6f7254 412e6e61 746e6567
> 3939332d 00303534 b23ade28
> [ 4538.892395] 6a2c  1806 2e6e6957 6a6f7254 462e6e61 61656b61
> 37342d76 00373131 ac58376e
> [ 4538.892395] 6a4c  72542e6e 6e616a6f 3434382e 35313336 3e55c600
> 412e6eb2 72617764 61472e65
> [ 4538.892517] 6a6c  6176656d 2d65636e 34393132 55b20037 1604b173
> 2e6e6957 6a6f7254 462e6e61
> [ 4538.892547] 6a8c  61656b61 37342d76 00343131 b652e2c0 72542e6e
> 6e616a6f 7075532e 756a7265
> [ 4538.892547] 6aac  322d6e61 fb003731 15b23a2b 2e6e6957 6a6f7254
> 412e6e61 746e6567 3939332d
> [ 4538.892547] CPU: 1 PID: 2064 Comm: clamd Not tainted
> 3.10.1.0-1-linaro-omap #1ubuntu1~ci+130723003933-Ubuntu
> [ 4538.892547] [] (unwind_backtrace+0x1/0x9c) from
> [] (show_stack+0x11/0x14)
> [ 4538.892639] [] (show_stack+0x11/0x14) from []
> (handle_IPI+0xd5/0x158)
> [ 4538.892669] [] (handle_IPI+0xd5/0x158) from []
> (gic_handle_irq+0x4b/0x50)
> [ 4538.892669] [] (gic_handle_irq+0x4b/0x50) from []
> (__irq_usr+0x49/0x60)
> [ 4538.892700] Exception stack(0xec91ffb0 to 0xec91fff8)
> [ 4538.892700] ffa0: 0080bf24
> 000a 6438 81010100
> [ 4538.892730] ffc0: 0080bf28 0080bf24 69393e32 0a0a0a0a e86d6a2f
> 0200 0084d750 684a
> [ 4538.892730] ffe0: 62323337 be8b472c b6eeec01 b6e2f0d4 000f0130 
>
>
> --
> To unsubs

Re: [PATCH] omap2: panel-generic: Added panel parameters for ortus-com37h3m05dtc/99dtc and sharp-lq070y3dg3b.

[Tomi Valkeinen]

On 29/08/13 15:35, Marek Belisko wrote:
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 
> ---
>  drivers/video/omap2/displays/panel-generic-dpi.c | 53 
> 
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
> b/drivers/video/omap2/displays/panel-generic-dpi.c
> index bebebd4..d573291 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -107,6 +107,33 @@ static struct panel_config generic_dpi_panels[] = {
>   .name   = "sharp_ls",
>   },

The drivers in drivers/video/omap2/displays/ are on their way out, and
will probably be removed for 3.12. Please look at the new one at
drivers/video/omap2/displays-new/panel-dpi.c.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO

[Chanwoo Choi]

Hi George,

In addition, I add answer about that device driver control gpio pin directly.

On 08/30/2013 03:15 PM, George Cherian wrote:
> Hi Chanwoo,
> 
> On 8/30/2013 5:41 AM, Chanwoo Choi wrote:
>> Hi George,
>>
>> On 08/29/2013 10:45 PM, George Cherian wrote:
>>> Hi Chanwoo,
>>>
>>>
>>> On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
>>> [big snip ]
>> I tested various development board based on Samsung Exynos series SoC.
>> Although some gpio of Exynos series SoC set high state(non zero, 1) as 
>> default value,
>> this gpio state could mean off state, disconnected or un-powered state 
>> according to gpio.
>> Of course, above explanation about specific gpio don't include all gpios.
>> This is meaning that there is possibility.
> okay then how about adding a flag for inverted logic too.  something like 
> this
>
> if(of_property_read_bool(np,"inverted_gpio))
>   gpio_usbvid->gpio_inv = 1;
> And always check on this before deciding?
>>> Is this fine ?
>> OK.
>> But, as Stephen commented on other mail, you should use proper DT helper 
>> function.
> okay
 Second,
 gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" 
 cable state at same time
 in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think 
 that other extcon devices
 would not control both "USB-HOST" and "USB" cable state at same time.

 Other extcon devices would support either "USB-HOST" or "USB" cable.
>>> The driver has 2 configurations.
>>> 1) supports implementations with both VBUS and ID pin are routed via 
>>> gpio's for swicthing roles(compatible  gpio-usb-vid).
>> As you explained about case 1, it is only used on dra7x SoC.
> No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via 
> gpio.
>> Other SoC could not wish to control both "USB-HOST" and "USB" cable at 
>> same time.
>>> I could'nt actually parse this. You meant since the id_irq_handler handles 
>>> both USB and USB-HOST cable
>>> its not proper?
>> It's not proper in general case. The generic driver must guarantee all of 
>> extcon device using gpio.
>> As far as I know, the generic driver cannot direclty control gpio pin and 
>> get value from gpio pin.
>> Almost device driver including in kernel/drivers control gpio pin on 
>> specific device driver
>> instead of generic driver.
> But without reading the gpio value how can we set the cable states?

hmm. I mentioned above my answer as following:
>> As far as I know, the generic driver cannot direclty control gpio 
pin and get value from gpio pin.
>> Almost device driver including in kernel/drivers control gpio pin on 
specific device driver
Because your extcon driver directly control gpio pin so I think your extcon 
driver isn't generic.

for this driver the assumption is the dedicated gpio
> is always DIR_IN and in the driver we just read the value.

What is DIR_IN?

 I need your answer about above my opinion for other SoC.
>>> So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
>>>
>>> static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
>>> {
>>>  int id_current, vbus_current;
>>>
>>>  id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
>>>  if (!!id_current == ID_FLOAT)
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
>>>  else
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
>>>
>>>  vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
>>>   if (!!vbus_current == VBUS_ON)
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
>>>  else
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
>>> }
>>>
>>> and the irq handlers like this
>>>
>>> static irqreturn_t id_irq_handler(int irq, void *data)
>>> {
>>>  struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
>>>  int id_current;
>>>
>>>  id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
>>>  if (id_current == ID_GND)
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", 
>>> true);
>>>  else
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", 
>>> false);
>>>  return IRQ_HANDLED;
>>> }
>>>
>>> static irqreturn_t vbus_irq_handler(int irq, void *data)
>>> {
>>>  struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
>>>  int vbus_current;
>>>
>>>  vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
>>>  if (vbus_current == VBUS_OFF)
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
>>>  else
>>>  extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
>>>
>>>  return IRQ_HANDLED;
>>> }
>> I know your intention dividing interrupt handler for each cable.
>> But I don

Re: [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver

[Hans Verkuil]

On 08/30/2013 08:47 AM, Archit Taneja wrote:
> On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
>> On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
>>> VPE is a block which consists of a single memory to memory path which can
>>> perform chrominance up/down sampling, de-interlacing, scaling, and color 
>>> space
>>> conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
>>> interleaved video formats.
>>>
>>> We create a mem2mem driver based primarily on the mem2mem-testdev example.
>>> The de-interlacer, scaler and color space converter are all bypassed for now
>>> to keep the driver simple. Chroma up/down sampler blocks are implemented, so
>>> conversion beteen different YUV formats is possible.
>>>
>>> Each mem2mem context allocates a buffer for VPE MMR values which it will use
>>> when it gets access to the VPE HW via the mem2mem queue, it also allocates
>>> a VPDMA descriptor list to which configuration and data descriptors are 
>>> added.
>>>
>>> Based on the information received via v4l2 ioctls for the source and
>>> destination queues, the driver configures the values for the MMRs, and 
>>> stores
>>> them in the buffer. There are also some VPDMA parameters like frame start 
>>> and
>>> line mode which needs to be configured, these are configured by direct 
>>> register
>>> writes via the VPDMA helper functions.
>>>
>>> The driver's device_run() mem2mem op will add each descriptor based on how 
>>> the
>>> source and destination queues are set up for the given ctx, once the list is
>>> prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA 
>>> will
>>> upload MMR registers, start DMA of video buffers on the various input and 
>>> output
>>> clients/ports.
>>>
>>> When the list is parsed completely(and the DMAs on all the output ports 
>>> done),
>>> an interrupt is generated which we use to notify that the source and 
>>> destination
>>> buffers are done.
>>>
>>> The rest of the driver is quite similar to other mem2mem drivers, we use the
>>> multiplane v4l2 ioctls as the HW support coplanar formats.
>>>
>>> Signed-off-by: Archit Taneja 
>>
>> Thanks for the patch. Just a few small comments below...
>>
>>> ---
>>>   drivers/media/platform/Kconfig   |   16 +
>>>   drivers/media/platform/Makefile  |2 +
>>>   drivers/media/platform/ti-vpe/Makefile   |5 +
>>>   drivers/media/platform/ti-vpe/vpe.c  | 1740 
>>> ++
>>>   drivers/media/platform/ti-vpe/vpe_regs.h |  496 +
>>>   5 files changed, 2259 insertions(+)
>>>   create mode 100644 drivers/media/platform/ti-vpe/Makefile
>>>   create mode 100644 drivers/media/platform/ti-vpe/vpe.c
>>>   create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
>>>
>>> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
>>> b/drivers/media/platform/ti-vpe/vpe.c
>>> new file mode 100644
>>> index 000..85b0880
>>> --- /dev/null
>>> +++ b/drivers/media/platform/ti-vpe/vpe.c
>>
>> 
>>
>>> +static int vpe_enum_fmt(struct file *file, void *priv,
>>> +   struct v4l2_fmtdesc *f)
>>> +{
>>> +   if (V4L2_TYPE_IS_OUTPUT(f->type))
>>> +   return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
>>> +   else
>>
>> The line above isn't necessary.
> 
> Oh right, thanks for spotting that.
> 
>>
>>> +   return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
>>> +}
>>> +
> 
> 
>>> +
>>> +   pix->field = V4L2_FIELD_NONE;
>>> +
>>> +   v4l_bound_align_image(&pix->width, MIN_W, MAX_W, W_ALIGN,
>>> + &pix->height, MIN_H, MAX_H, H_ALIGN,
>>> + S_ALIGN);
>>> +
>>> +   pix->num_planes = fmt->coplanar ? 2 : 1;
>>> +   pix->pixelformat = fmt->fourcc;
>>> +   pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
>>> +   V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
>>
>> pix->priv should be set to NULL as well.
> 
> I'll fix this.
> 
> 
> 
>>> +}
>>> +
>>> +#define V4L2_CID_TRANS_NUM_BUFS(V4L2_CID_USER_BASE + 0x1000)
>>
>> Reserve a control range for this driver in 
>> include/uapi/linux/v4l2-controls.h.
>> Similar to the ones already defined there.
>>
>> That will ensure that controls for this driver have unique IDs.
> 
> Thanks, I took this from the mem2mem-testdev driver, a test driver 
> doesn't need to worry about this I suppose.
> 
> I had a query regarding this. I am planning to add a capture driver in 
> the future for a similar IP which can share some of the control IDs with 
> VPE. Is it possible for 2 different drivers to share the IDs?

Certainly. There are three levels of controls:

1) Standard controls: can be used by any driver and are documented in the spec.
2) IP-specific controls: controls specific for a commonly used IP.
   These can be used by any driver containing that IP and are documented as well
   in the spec. Good examples are the MFC and CX2341x MPEG controls.
3) Driver-specific controls: these are specific to a driver and do not have to 
be
   documented in the s

Fwd: Re: current panda omap kernel stacks

[Christian Hoffmann]

Hi,

please see the current issues I found on panda running 
3.10.1.0-1-linaro-omap


https://dl.dropboxusercontent.com/u/21820416/panda.syslog.gz
https://dl.dropboxusercontent.com/u/21820416/panda-dmesg

System is generally very unstable.

RCU stall sent in different thread

Chris


 Original Message 
Subject:Re: current panda omap kernel stacks
Date:   Tue, 27 Aug 2013 21:11:12 +0200
From:   Christian Hoffmann 
To: linaro-ker...@lists.linaro.org



Forgot to attach syslog here:
https://dl.dropboxusercontent.com/u/21820416/panda.syslog.gz


On Tue, Aug 27, 2013 at 9:09 PM, Christian Hoffmann
mailto:chrmhoffm...@gmail.com>> wrote:

Sorry to reply to myself, but after a while the panda doesn't reply
any more over network and the syslog has lots of entries like this one:

Aug 27 13:00:38 panda kernel: [87136.303894] []
(__schedule_bug+0x39/0x50) from [] (__schedule+0x51f/0x5c4)
Aug 27 13:00:38 panda kernel: [87136.303924] []
(__schedule+0x51f/0x5c4) from []
(schedule_preempt_disabled+0xf/0x10)
Aug 27 13:00:38 panda kernel: [87136.303924] []
(schedule_preempt_disabled+0xf/0x10) from []
(cpu_startup_entry+0x12f/0x164)
Aug 27 13:00:38 panda kernel: [87136.303955] []
(cpu_startup_entry+0x12f/0x164) from [<80448ea9>] (0x80448ea9)
Aug 27 13:00:38 panda kernel: [87136.307403] BUG: scheduling while
atomic: swapper/1/0/0x
Aug 27 13:00:38 panda kernel: [87136.313781] Modules linked in:
snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040
snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi
snd_pcm snd_page_alloc snd_timer snd soundcore gator
Aug 27 13:00:38 panda kernel: [87136.313842] CPU: 1 PID: 0 Comm:
swapper/1 Tainted: GW3.10.1.0-1-linaro-omap
#1ubuntu1~ci+130723003933-Ubuntu
Aug 27 13:00:38 panda kernel: [87136.313842] []
(unwind_backtrace+0x1/0x9c) from [] (show_stack+0x11/0x14)
Aug 27 13:00:38 panda kernel: [87136.313873] []
(show_stack+0x11/0x14) from [] (__schedule_bug+0x39/0x50)
Aug 27 13:00:38 panda kernel: [87136.313903] []
(__schedule_bug+0x39/0x50) from [] (__schedule+0x51f/0x5c4)
Aug 27 13:00:38 panda kernel: [87136.313934] []
(__schedule+0x51f/0x5c4) from []
(schedule_preempt_disabled+0xf/0x10)
Aug 27 13:00:38 panda kernel: [87136.313934] []
(schedule_preempt_disabled+0xf/0x10) from []
(cpu_startup_entry+0x12f/0x164)
Aug 27 13:00:38 panda kernel: [87136.313964] []
(cpu_startup_entry+0x12f/0x164) from [<80448ea9>] (0x80448ea9)
Aug 27 13:00:38 panda kernel: [87136.317382] BUG: scheduling while
atomic: swapper/1/0/0x
Aug 27 13:00:38 panda kernel: [87136.323760] Modules linked in:
snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040
snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi
snd_pcm snd_page_alloc snd_timer snd soundcore gator
Aug 27 13:00:38 panda kernel: [87136.323822] CPU: 1 PID: 0 Comm:
swapper/1 Tainted: GW3.10.1.0-1-linaro-omap
#1ubuntu1~ci+130723003933-Ubuntu
Aug 27 13:00:38 panda kernel: [87136.323822] []
(unwind_backtrace+0x1/0x9c) from [] (show_stack+0x11/0x14)
Aug 27 13:00:38 panda kernel: [87136.323822] []
(show_stack+0x11/0x14) from [] (__schedule_bug+0x39/0x50)
Aug 27 13:00:38 panda kernel: [87136.323883] []
(__schedule_bug+0x39/0x50) from [] (__schedule+0x51f/0x5c4)
Aug 27 13:00:38 panda kernel: [87136.323913] []
(__schedule+0x51f/0x5c4) from []
(schedule_preempt_disabled+0xf/0x10)
Aug 27 13:00:38 panda kernel: [87136.323913] []
(schedule_preempt_disabled+0xf/0x10) from []
(cpu_startup_entry+0x12f/0x164)
Aug 27 13:00:38 panda kernel: [87136.323944] []
(cpu_startup_entry+0x12f/0x164) from [<80448ea9>] (0x80448ea9)
Aug 27 13:00:38 panda kernel: [87136.327392] BUG: scheduling while
atomic: swapper/1/0/0x
Aug 27 13:00:38 panda kernel: [87136.333770] Modules linked in:
snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040
snd_soc_omap snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi
snd_pcm snd_page_alloc snd_timer snd soundcore gator

Rgds,
Chris


On Tue, Aug 27, 2013 at 8:50 AM, Christian Hoffmann
mailto:chrmhoffm...@gmail.com>> wrote:

Hi,

running the current panda linaro kernel 3.10.1.0-1-linaro-omap
from linaro release 13.07, I run into a few kernel stacks.

Eg.:

[33222.473022] [ cut here ]
[33222.473052] WARNING: at
/build/buildd/linux-linaro-omap-3.10.1-3.10.1.0/kernel/timer.c:1122
call_timer_fn+0x81/0xb0()
[33222.473083] timer: process_timeout+0x1/0xc preempt leak:
0100 -> 
[33222.473083] Modules linked in: snd_soc_omap_abe_twl6040
snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap
snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd