Re: iss: camera interface omap5
* H. Nikolaus Schaller [191004 16:27]: > Hi Tony, > > > Am 04.10.2019 um 18:11 schrieb Tony Lindgren : > > > > * H. Nikolaus Schaller [191004 07:25]: > >> Hi Tony, > >> is there a similar node for omap5 comparable to this for omap4: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4.dtsi?h=v5.4-rc1#n176 > > (I just noticed there seems to be a missing empty line between 216 and 217) > > > > > Not sure if it's the same interface as on omap4, but at > > least TRM has "8.1.3.1 ISS Instance Summary" at 0x5200. > > Ok. > > IMHO there was a patch where someone got it working a while ago so it is > likely the same: > > https://e2e.ti.com/support/interface/f/138/t/647460 > > Now I wonder how it can be updated to current target-module style. > > Is it correct to do it similar to omap4 and replace > > /* No child device binding, driver in staging */ > > by a child node that is compatible to "ti,omap4-iss". > And there define a reg record like in the example on e2e? > I.e. split into sysc registers for the target-module@5200 > and driver specific registers in the child node? Yeah something like that. Michael Alwright has a patch at [0] with improvments for the iss staging driver to get it working. Have you seen that one? > Regarding clocks they likely have to stay with the target-module@5200 > node, right? I think it should be just something like this for the target-module (on top of Michael's changes): clocks = <&iss_clkctrl OMAP4_ISS_CLKCTRL 0>; clock-names = "fck"; Then in the child node: clocks = <&iss_clkctrl OMAP4_ISS_CLKCTRL 8>; clock-names = "ctrlclk"; > And what about the dma nodes? Also keep in the target-module@5200? Those should be all in the child iss driver(s). In general, it sounds like the iss is a private interconnect with a control module for clocks etc, so doing it as multiple device drivers probably makes sense. Regards, Tony [0] https://github.com/allsey87/meta-builderbot/blob/master/recipes-kernel/linux/linux-stable-4.16/0008-omap4iss-Fix-multiple-bugs-and-use-device-tree.patch
Re: [PATCH RFC] DT support for omap4-iss
Hi, * Sakari Ailus [190628 11:05]: > Hi Michael, > > On Mon, Aug 10, 2015 at 05:16:30PM +0200, Michael Allwright wrote: > > Hi All, > > > > The following PRELIMINARY patch adds DT support to the OMAP4 ISS. It > > also fixes some problems a have found along the way. It is tightly > > modelled after the omap3-isp media platform driver. This patch is a > > work in progress as I would like feedback. It contains debugging > > messages that need to be removed, as well as disgusting abuses of the > > C language as required (i.e. clk_core_fake and clk_fake). > > We'd like to restart the effort adding DT support for this driver. Would > you be able to, if not address the comments, at least resend your old patch > with your Signed-off-by: line so we could make use of what you've already > done? I think this email no longer works for Michael? Adding another one from commit at [0] below. Michael, care to email that patch to the lists with your Signed-off-by so Sakari can use it? Or at least reply with your Signed-off-by to this thread :) Regards, Tony [0] https://github.com/allsey87/meta-builderbot/blob/master/recipes-kernel/linux/linux-stable-4.16/0008-omap4iss-Fix-multiple-bugs-and-use-device-tree.patch
Re: [PATCH] mach-omap2/devices.c: set dma mask
* Hans Verkuil [190812 12:50]:
> On 7/30/19 8:17 AM, Hans Verkuil wrote:
> > The dma_mask and coherent_dma_mask values were never set.
> >
> > This prevented the media omap_vout driver from loading successfully.
> >
> > Tested on a Pandaboard and Beagle XM board.
> >
> > Signed-off-by: Hans Verkuil
>
> Tony, can you pick this up? Or give an Ack so that it can be merged via
> the media subsystem if you prefer?
Sorry for the delays on this one. Please just merge
it via via the media susbsystem since you need it:
Acked-by: Tony Lindgren
> > ---
> > arch/arm/mach-omap2/devices.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index cc0d08dad141..5a2e198e7db1 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -43,11 +44,17 @@ static struct resource omap_vout_resource[2] = {
> > };
> > #endif
> >
> > +static u64 omap_vout_dma_mask = DMA_BIT_MASK(32);
> > +
> > static struct platform_device omap_vout_device = {
> > .name = "omap_vout",
> > .num_resources = ARRAY_SIZE(omap_vout_resource),
> > .resource = &omap_vout_resource[0],
> > .id = -1,
> > + .dev= {
> > + .dma_mask = &omap_vout_dma_mask,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + },
> > };
> >
> > int __init omap_init_vout(void)
> >
>
Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
* Adam Ford [181222 20:36]: > As much as I'd like to see the ti-st kim stuff go, I am not able to > load the Bluetooth on the Torpedo board (wl1283). The hooks on a > different, wl18xx and 127x board work fine. I am not sure if there is > anything different about the wl1283, but I don't have any other boards > other than the Logic PD Torpedo kit. Do you have any wl1283 boards to > test? I'd like to see this BT timeout stuff resolved before we dump > the ti-st kim stuff, otherwise, I'll forever be porting drivers. :-( Sebastian and I both tested this with droid 4, which has wl1283. So it's probably some missing GPIO/regulator/pinconf stuff that the pdata-quirks.c does for you. Maybe try adding back also the pdata-quirks.c code and see if that helps? Regards, Tony
Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
* Sebastian Reichel [181222 02:48]: > On Fri, Dec 21, 2018 at 10:02:05AM -0800, Tony Lindgren wrote: > > Hmm so looks like nothing to configure for the clocks or > > CPCAP_BIT_ST_L_TIMESLOT bits for cap for the EXT? So the > > wl12xx audio is wired directly to cpcap EXT then and not a > > TDM slot on the mcbsp huh? > > For FM radio it's directly wired to EXT with no DAI being required. > I think that EXT is only used by FM radio and not by bluetooth. BT > seems to use TDM. OK then it sounds like we just need a diff -u of the cpcap regs from Android with cpcaprw --all before and after using a bluetooth headset during a voice call to configure it for voice calls for the TDM. I think snd-soc-motmd just needs the voice output specified in the mixer in addition to the cpcap configuration. I don't think have any bluetooth audio gear though, maybe somebody using a headset can post the diff. Regards, Tony
Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
* Sebastian Reichel [181221 01:18]: > The new code has been tested on the Motorola Droid 4. For testing the audio > should be configured to route Ext to Speaker or Headphone. Then you need to > plug headphone, since its cable is used as antenna. For testing there is a > 'radio' utility packages in Debian. When you start the utility you need to > specify a frequency, since initial get_frequency returns an error: Nice, good to see that ti-st kim stuff gone :) I gave this a quick try using fmtools.git and fmscan works just fine. No luck yet with fm though, it gives VIDIOC_G_CTRL: Not a tty error somehow so maybe I'm missing some options, patch below for omap2plus_defconfig. Hmm so looks like nothing to configure for the clocks or CPCAP_BIT_ST_L_TIMESLOT bits for cap for the EXT? So the wl12xx audio is wired directly to cpcap EXT then and not a TDM slot on the mcbsp huh? > Merry Christmas! Same to you! Tony 8< >From tony Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Fri, 21 Dec 2018 07:57:09 -0800 Subject: [PATCH] ARM: omap2plus_defconfig: Add RADIO_WL128X as a loadable module This allows using the FM radio in the wl12xx chips after modprobe fm_drv using radio from xawt, or fmtools. Note that the firmware placed into /lib/firmware/ti-connectivity directory: fm_rx_ch8_1283.2.bts fmc_ch8_1283.2.bts Signed-off-by: Tony Lindgren --- arch/arm/configs/omap2plus_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -126,6 +126,7 @@ CONFIG_AF_RXRPC=m CONFIG_RXKAD=y CONFIG_CFG80211=m CONFIG_MAC80211=m +CONFIG_RFKILL=m CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMA_CMA=y @@ -343,12 +344,14 @@ CONFIG_IR_GPIO_TX=m CONFIG_IR_PWM_TX=m CONFIG_MEDIA_SUPPORT=m CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_RADIO_SUPPORT=y CONFIG_MEDIA_CEC_SUPPORT=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_OMAP3=m CONFIG_CEC_PLATFORM_DRIVERS=y +CONFIG_RADIO_WL128X=m # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set CONFIG_VIDEO_TVP5150=m CONFIG_DRM=m -- 2.19.2
Re: [PATCH] am335x-boneblack-common.dtsi: add cec support
* Hans Verkuil [180924 04:06]: > Add CEC support to the tda998x. > > Signed-off-by: Hans Verkuil > --- > Note: this relies on this gpio patch series: > > https://www.spinics.net/lists/linux-gpio/msg32401.html > > and this follow-up gpio patch: > > https://www.spinics.net/lists/linux-gpio/msg32551.html > > that will appear in 4.20. > > Tested with my BeagleBone Black board. OK great applying into omap-for-v4.20/dt thanks. Tony
Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data
* Wolfram Sang [180419 20:02]: > This header only contains platform_data. Move it to the proper directory. Acked-by: Tony Lindgren
Re: [BUG] musb: broken isochronous transfer at TI AM335x platform
* Matwey V. Kornilov [180215 17:55]: > [] 7.219456 d= 0.000997 [181.0 + 3.667] [ 3] IN : 4.5 > [T ] 7.219459 d= 0.03 [181.0 + 7.083] [800] DATA0: 53 da ... > [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5 > [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: 13 36 ... > [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5 > [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00 > [] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5 > [] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00 > > Please note, that the time moment "7.221456" has missed IN request > packet which must be sent out every 1ms in this low-speed USB case. > Then, all incoming packets became empty ones. Such moments coincide > with frame discarding in pwc driver. Well sounds like you may be able to fix it since you have a test case for it :) > Even though IN sending is usually handled by USB host hardware, it is > not fully true for MUSB. Every IN is triggered by musb kernel driver > (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and > musb_ep_program()) since auto IN is not used. Rather complicated logic > is incorporated to decide whether IN packet has to be sent. First, > musb_host_packet_rx() handles IN sending when current URB is not > completed (i.e. current URB has another packet which has to be > received next). Second, musb_advance_schedule() (via musb_start_urb()) > handles the case when current URB is completed but there is another > URB pending. It seems that there is a hardware logic to fire IN packet > in a way to have exactly 1ms between two consequent INs. So, > MUSB_RXCSR_H_REQPKT is considered as IN requesting flag. Yeah this is a known issue with musb, there is not much ISO support currently really. The regression should be fixed though. Sorry I don't have much ideas on how to improve things here. One way might be to attempt to split the large musb functions into smaller functions and see if that then allows finer grained control. Just to try to come up with some new ideas.. Maybe there's some way to swap the hardware EP config dynamically and have some packets mostly preconfigured and waiting to be triggered? Regards, Tony
Re: [Patch 4/6] dt-bindings: media: ti-vpe: Document VPE driver
* Rob Herring [171019 14:07]:
> On Wed, Oct 18, 2017 at 8:02 AM, Benoit Parrot wrote:
> >> > +Example:
> >> > + vpe {
> >> > + compatible = "ti,vpe";
> >> > + ti,hwmods = "vpe";
> >> > + clocks = <&dpll_core_h23x2_ck>;
> >> > + clock-names = "fck";
> >> > + reg = <0x489d 0x120>,
> >> > + <0x489d0300 0x20>,
> >> > + <0x489d0400 0x20>,
> >> > + <0x489d0500 0x20>,
> >> > + <0x489d0600 0x3c>,
> >> > + <0x489d0700 0x80>,
> >>
> >> Is there other stuff between these regions?
> >
> > No, they listed separately because each sub-region/module is
> > individually mapped and accessed using a starting 0 offset.
>
> So you are going to use 48KB of virtual memory to map 2KB of
> registers? Because each ioremap uses 8KB (1 page plus 1 guard page)
> last time i looked (which has been a while).
>
> But it's your platform.
We should have cached regions for all interconnects so this should
not be a problem. Worth checking that the areas are listed in
dra7xx_io_desc[] and for other SoCs too to avoid this issue.
Regards,
Tony
Re: [Patch 5/6] ARM: DRA7: hwmod: Add VPE nodes
* Benoit Parrot [171013 11:06]:
> Tony Lindgren wrote on Fri [2017-Oct-13 10:05:13 -0700]:
> > * Benoit Parrot [171012 12:28]:
> > > +static struct omap_hwmod_class_sysconfig dra7xx_vpe_sysc = {
> > > + .sysc_offs = 0x0010,
> > > + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> > > + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> > > +MSTANDBY_FORCE | MSTANDBY_NO |
> > > +MSTANDBY_SMART),
> > > + .sysc_fields= &omap_hwmod_sysc_type2,
> > > +};
> >
> > I think checkpatch.pl --strict would complain about unnecessary
> > parentheses, might as well check the whole series while at it.
>
> I actually ran the whole series through "checkpatch.pl --strict"
> before posting. And other then the usual MAINTAINER file needing
> update warning for the binding patch it no other warning or error.
>
> Based on the rest of the file I believe the parentheses around those
> flags are at least consistent.
OK fine thanks for checking.
> Now, would the .rev_offs comment also apply here?
I don't think it has it, you might want to dump out the value
at offset 0 and see if it contains anything.
Regards,
Tony
Re: [Patch 3/6] ARM: OMAP: DRA7xx: Make CAM clock domain SWSUP only
* Benoit Parrot [171013 11:01]: > Tony Lindgren wrote on Fri [2017-Oct-13 10:01:13 -0700]: > > * Benoit Parrot [171012 12:29]: > > > HWSUP on this domain is only working when VIP1 probes. > > > If only VIP2 on DRA74x or CAL on DRA72x probes the domain does > > > not get enabled. This might indicates an issue in the HW Auto > > > state-machine for this domain. > > > > > > Work around is to set the CAM domain to use SWSUP only. > > > > Hmm this you might get fixed automatically by configuring the > > parent interconnect target module to use "ti,sysc-omap4" and > > adding VIP1 and VIP2 as children to it. > > > > The reason why I suspect it will fix the issue is because > > with the parent being "ti,sysc-omap4" with "ti,hwmods" being > > in that parent node too, you automatically get PM runtime > > refcounting keep the parent active for either child. > > > > Maybe give it a try against today's Linux next and see for > > example how it was done for musb: > > > > https://patchwork.kernel.org/patch/9978783/ > > > > Just use "ti,sysc-omap2" for type1 and "ti,sysc-omap4" > > for type2. > > Hmm interesting, I'll give that a try and if it fixes it. OK great. Note that you need to manually apply "[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()" on today's next and make sure CONFIG_DRM and CONFIG_DRM_KMS_HELPER are built-in and not modules if using them. Regards, Tony
Re: [Patch 5/6] ARM: DRA7: hwmod: Add VPE nodes
* Benoit Parrot [171012 12:28]:
> +static struct omap_hwmod_class_sysconfig dra7xx_vpe_sysc = {
> + .sysc_offs = 0x0010,
> + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +MSTANDBY_FORCE | MSTANDBY_NO |
> +MSTANDBY_SMART),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
I think checkpatch.pl --strict would complain about unnecessary
parentheses, might as well check the whole series while at it.
Regards,
Tony
Re: [Patch 3/6] ARM: OMAP: DRA7xx: Make CAM clock domain SWSUP only
* Benoit Parrot [171012 12:29]: > HWSUP on this domain is only working when VIP1 probes. > If only VIP2 on DRA74x or CAL on DRA72x probes the domain does > not get enabled. This might indicates an issue in the HW Auto > state-machine for this domain. > > Work around is to set the CAM domain to use SWSUP only. Hmm this you might get fixed automatically by configuring the parent interconnect target module to use "ti,sysc-omap4" and adding VIP1 and VIP2 as children to it. The reason why I suspect it will fix the issue is because with the parent being "ti,sysc-omap4" with "ti,hwmods" being in that parent node too, you automatically get PM runtime refcounting keep the parent active for either child. Maybe give it a try against today's Linux next and see for example how it was done for musb: https://patchwork.kernel.org/patch/9978783/ Just use "ti,sysc-omap2" for type1 and "ti,sysc-omap4" for type2. Regards, Tony
Re: [Patch 2/6] ARM: DRA7: hwmod: Add CAL nodes
* Benoit Parrot [171012 12:28]:
> This patch adds the required hwmod nodes to support the Camera
> Adaptation Layer (CAL) for the DRA72 family of devices.
...
> +static struct omap_hwmod_class_sysconfig dra7xx_cal_sysc = {
> + .sysc_offs = 0x0010,
Also has .rev_offs at 0 so please add that too.
Regards,
Tony
Re: [Patch 1/6] ARM: dts: DRA72: Add CAL dtsi node
* Benoit Parrot [171012 12:29]:
> This patch adds the required dtsi node to support the Camera
> Adaptation Layer (CAL) for the DRA72 family of devices.
>
> - Added CAL entry in dra72x.dtsi.
>
> Signed-off-by: Benoit Parrot
> ---
> arch/arm/boot/dts/dra72x.dtsi | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
> index 67107605fb4c..d0ba4f238084 100644
> --- a/arch/arm/boot/dts/dra72x.dtsi
> +++ b/arch/arm/boot/dts/dra72x.dtsi
> @@ -17,6 +17,37 @@
> interrupt-parent = <&wakeupgen>;
> interrupts = ;
> };
> +
> + ocp {
> + cal: cal@4845b000 {
> + compatible = "ti,dra72-cal";
> + ti,hwmods = "cal";
> + reg = <0x4845B000 0x400>,
> + <0x4845B800 0x40>,
> + <0x4845B900 0x40>,
> + <0x4A002e94 0x4>;
Care to fix the cAmelcasing here? All lower case hex is pretty much the
standard with linux, so might as well lower case them all while at it.
Regards,
Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Jyri Sarha [170627 02:47]: > There is no real volume on HDMI audio output as it is a digital > interface, but it should be possible to provide some volume control > using TV's volume trough CEC. OK great! Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Hans Verkuil [170627 02:27]: > On 27/06/17 11:14, Tony Lindgren wrote: > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > > HDMI audio volume level on devices implementing it? Or am I too > > optimistic? :) > > I'm not quite sure what you mean. Do you want CEC to change the volume on the > TV, or use the TV's remote to change the volume of the HDMI audio output of > the > omap4? I'm hoping to change audio volume on a USB+HDMI lapdock from omap4. > Anyway, either is supported, but it requires a userspace implementation. > > Although TV remote control messages will be mapped to an input device, and if > those are hooked up to the alsa audio volume, then this already works. OK great thanks, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Hans Verkuil [170627 01:39]: > On 26/06/17 13:07, Tony Lindgren wrote: > > Tomi, > > > > * Tomi Valkeinen [170428 04:15]: > >> On 14/04/17 13:25, Hans Verkuil wrote: > >>> From: Hans Verkuil > >>> > >>> The CEC pin was always pulled up, making it impossible to use it. > > ... > > > >> Tony, can you queue this? It's safe to apply separately from the rest of > >> the HDMI CEC work. > > > > So the dts changes are merged now but what's the status of the CEC driver > > changes? Were there some issues as I don't see them in next? > > Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the > omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago) > this was still pending review. OK thanks for the update. Adding Jyri to Cc, hopefully the CEC support allows also setting the HDMI audio volume level on devices implementing it? Or am I too optimistic? :) > Tomi, any updates on this? It would be nice to get this in for 4.14. Yeah seems like we have real mainline kernel user needs for this one. Regards, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
Tomi, * Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil > > > > The CEC pin was always pulled up, making it impossible to use it. ... > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. So the dts changes are merged now but what's the status of the CEC driver changes? Were there some issues as I don't see them in next? Regards, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Tony Lindgren [170428 11:57]: > The pull seems to be enabled in the Android kernel too: > > # rwmem -s16 0x4a10009a > 0x4a10009a = 0x0118 > > So needs to be tested, what's the simplest test to check the CEC? So on droid 4, with the internal pull enabled cec-ctl -m does not show anything. With the internal pull disabled, cec-ctl -m produces the following with a lapdock: Initial Event: State Change: PA: 1.0.0.0, LA mask: 0x4000 Event: State Change: PA: f.f.f.f, LA mask: 0x Event: State Change: PA: 1.0.0.0, LA mask: 0x Transmitted by Specific to Specific (14 to 14): CEC_MSG_POLL Tx, Not Acknowledged (4), Max Retries Event: State Change: PA: 1.0.0.0, LA mask: 0x4000 Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_FEATURES (0xa6): cec-version: version-2-0 (0x06) all-device-types: switch (0x04) rc-profile: tv-profile-none (0x00) dev-features: 0 (0x00) Transmitted by Specific to all (14 to 15): CEC_MSG_REPORT_PHYSICAL_ADDR (0x84): phys-addr: 1.0.0.0 prim-devtype: processor (0x07) And looking at the ifixit.com board picture, there seems to be a IP4791CZ12 chip on droid 4. And it's docs seem to hint it has a pull in the IP4791CZ12. So yeah my guess is the cec internal pull should be disabled on all omap4 devices with HDMI. I'll send a follow-up patch for that. > Hmm I wonder if disabling the internal pull also allows removing > the "regulator-always-on" hack for hdmi_regulator there? Without > regulator-always-on I noticed that HDMI panel resolutions are not > detected. This I can test easily.. The regulator-fixed is still needed, I think this GPIO regulator powers the IP4791CZ12 which has no control channel. Not sure if we should still have encoder-ip4791cz12.c driver for it just to manage the regulator? Regards, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Sebastian Reichel [170428 11:29]: > Hi, > > On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > > * Tomi Valkeinen [170428 04:15]: > > > On 14/04/17 13:25, Hans Verkuil wrote: > > > > From: Hans Verkuil > > > > > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > > > > > Change to PIN_INPUT so it can be used by the new CEC support. > > ... > > > > > Reviewed-by: Tomi Valkeinen > > > > > > Tony, can you queue this? It's safe to apply separately from the rest of > > > the HDMI CEC work. > > > > Sure will do. > > I guess the same patch should be applied to Droid 4? I guess it depends if there is an external pull or not. If there's an external pull, the internal pull needs to be disabled as otherwise the resistors are parallel and pull value is much lower than intended. Looks like on droid 4 we have: $ grep 09a /sys/kernel/debug/pinctrl/4a100040.pinmux/pins pin 45 (PIN45) 4a10009a 0118 pinctrl-single $ grep PULL_ENA ./include/dt-bindings/pinctrl/omap.h #define PULL_ENA(1 << 3) ... So bit 3 is set and internal pull is enabled in pinmux_dss_hdmi_pins for droid 4 also. The pull seems to be enabled in the Android kernel too: # rwmem -s16 0x4a10009a 0x4a10009a = 0x0118 So needs to be tested, what's the simplest test to check the CEC? Hmm I wonder if disabling the internal pull also allows removing the "regulator-always-on" hack for hdmi_regulator there? Without regulator-always-on I noticed that HDMI panel resolutions are not detected. This I can test easily.. Regards, Tony
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > Change to PIN_INPUT so it can be used by the new CEC support. ... > Reviewed-by: Tomi Valkeinen > > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. Sure will do. Thanks, Tony
Re: [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c
* Thomas Gleixner [170227 08:20]: > On Mon, 27 Feb 2017, Tony Lindgren wrote: > > * Ingo Molnar [170227 07:44]: > > > Because it's not the requirement that hurts primarily, but the resulting > > > non-determinism and the sporadic crashes. Which can be solved by making > > > the race > > > deterministic via the debug facility. > > > > > > If the IRQ handler crashed the moment it was first written by the driver > > > author > > > we'd never see these problems. > > > > Just in case this is PM related.. Maybe the spurious interrupt is pending > > from earlier? This could be caused by glitches on the lines with runtime PM, > > or a pending interrupt during suspend/resume. In that case > > IRQ_DISABLE_UNLAZY > > might provide more clues if the problem goes away. > > It's not PM related. That's just silly hardware. At the moment when you > enable some magic bit in the control register, which is required to probe > the version, the fricking thing spits out a spurious interrupt despite the > interrupt enable bit in the same control register being still disabled. Of > course we cannot install an interrupt handler before having probed the > version and setup other stuff, except we add magic 'if (!initialized)' > crappola into the handler and lose the ability to install version dependent > handlers afterwards. OK and presumably no -EPROBE_DEFER happening either. > Wonderful crap that, isn't it? Sounds broken.. Regards, Tony
Re: [WARNING: A/V UNSCANNABLE][Merge tag 'media/v4.11-1' of git] ff58d005cd: BUG: unable to handle kernel NULL pointer dereference at 0000039c
* Ingo Molnar [170227 07:44]:
>
> * Thomas Gleixner wrote:
>
> > The pending interrupt issue happens, at least on my test boxen, mostly on
> > the 'legacy' interrupts (0 - 15). But even the IOAPIC interrupts >=16
> > happen occasionally.
> >
> >
> > - Spurious interrupts on IRQ7, which are triggered by IRQ 0 (PIT/HPET). On
> >one of the affected machines this stops when the interrupt system is
> >switched to interrupt remapping !?!?!?
> >
> > - Spurious interrupts on various interrupt lines, which are triggered by
> >IOAPIC interrupts >= IRQ16. That's a known issue on quite some chipsets
> >that the legacy PCI interrupt (which is used when IOAPIC is disabled) is
> >triggered when the IOAPIC >=16 interrupt fires.
> >
> > - Spurious interrupt caused by driver probing itself. I.e. the driver
> >probing code causes an interrupt issued from the device
> >inadvertently. That happens even on IRQ >= 16.
This sounds a lot like what we saw few weeks ago with dwc3. See commit
12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler in
probe"). It was caused by runtime PM and -EPROBE_DEFER, see the description
Grygorii wrote up in that commit.
> >This problem might be handled by the device driver code itself, but
> >that's going to be ugly. See below.
>
> That's pretty colorful behavior...
>
> > We can try to sample more data from the machines of affected users, but I
> > doubt
> > that it will give us more information than confirming that we really have
> > to
> > deal with all that hardware wreckage out there in some way or the other.
>
> BTW., instead of trying to avoid the scenario, wow about moving in the other
> direction: making CONFIG_DEBUG_SHIRQ=y unconditional property in the IRQ core
> code
> starting from v4.12 or so, i.e. requiring device driver IRQ handlers to
> handle the
> invocation of IRQ handlers at pretty much any moment. (We could also extend
> it a
> bit, such as invoking IRQ handlers early after suspend/resume wakeup.)
>
> Because it's not the requirement that hurts primarily, but the resulting
> non-determinism and the sporadic crashes. Which can be solved by making the
> race
> deterministic via the debug facility.
>
> If the IRQ handler crashed the moment it was first written by the driver
> author
> we'd never see these problems.
Just in case this is PM related.. Maybe the spurious interrupt is pending
from earlier? This could be caused by glitches on the lines with runtime PM,
or a pending interrupt during suspend/resume. In that case IRQ_DISABLE_UNLAZY
might provide more clues if the problem goes away.
Regards,
Tony
Re: [PATCHv6] support for AD5820 camera auto-focus coil
* Pali Rohár [161214 05:38]: > On Monday 08 August 2016 23:41:32 Pavel Machek wrote: > > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote: > > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote: > > > > This adds support for AD5820 autofocus coil, found for example in > > > > Nokia N900 smartphone. > > > > > > Thanks, Pavel! > > > > > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get > > > something better in the future, we'll switch to that then. > > > > > > I've applied this to ad5820 branch in my tree. > > > > Thanks. If I understands things correctly, both DTS patch and this > > patch are waiting in your tree, so we should be good to go for 4.9 > > (unless some unexpected problems surface)? > > > > Best regards, > > Pavel > > Was DTS patch merged into 4.9? At least I do not see updated that dts > file omap3-n900.dts in linus tree... If it's not in current mainline or next, it's off my radar so sounds like I've somehow missed it and needs resending.. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] support for AD5820 camera auto-focus coil
* Pavel Machek [161104 00:45]: > Hi! > > > > > I have to admit I mostly use an N9. > > > > > > Well, if you compare that to development on PC, I prefer PC. > > > > > > Even arm development boards are usually easier, as they don't need too > > > complex userspace, and do have working serial ports. > > > > > > But I do have a serial adapter for N900 now (thanks, sre), so my main > > > problem now is that N900 takes a lot of time to boot into usable > > > state. > > > > Yeah... I just upgraded my Debian installation (armel over NFS) a few major > > numbers and I find it a lot slower than it used to do. I presume that's > > mostly because of systemd... > > I'm not sure if systemd is to blame. (I'm booting into full GUI...) > > And yes, I noticed the slowdown in Debian 7 -> 8 transition, so I'm > basically staying at Debian 7 as far as I can. Maybe it's the armel vs armhf causing the slowdown? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes
* Tony Lindgren [160622 21:47]: > * Ivaylo Dimitrov [160622 12:25]: > > ir-rx51 is a driver for Nokia N900 IR transmitter. The current series > > fixes the remaining problems in the driver: > > Thanks for updating these. > > Trierry, care to ack the PWM patch? > > Mauro, do you want me to set up an immutable branch with all > these against v4.7-rc1 that we can all merge as needed? > > If you want to set up the branch instead, please feel free > to add my ack. OK so no comments from Mauro, so I've applied these with Thierry's ack and pushed out into omap-for-v4.8/legacy branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 1/5] ir-rx51: Fix build after multiarch changes broke it
* Ivaylo Dimitrov [160627 11:22]: > On 23.06.2016 20:48, Pali Rohár wrote: > > On Wednesday 22 June 2016 21:22:17 Ivaylo Dimitrov wrote: > > > The ir-rx51 driver for n900 has been disabled since the multiarch > > > changes as plat include directory no longer is SoC specific. > > > > > > Let's fix it with minimal changes to pass the dmtimer calls in > > > pdata. Then the following changes can be done while things can > > > be tested to be working for each change: > > > > > > 1. Change the non-pwm dmtimer to use just hrtimer if possible > > > > > > 2. Change the pwm dmtimer to use Linux PWM API with the new > > > drivers/pwm/pwm-omap-dmtimer.c and remove the direct calls > > > to dmtimer functions > > > > > > 3. Parse configuration from device tree and drop the pdata > > > > > > Note compilation of this depends on the previous patch > > > "ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51". > > > > I think that this extensive description is not needed for commit > > message. Just for email discussion. > > > > I guess Tony can strip the description a bit before applying. OK I'll leave out the last paragraph as that already got merged earlier. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes
* Ivaylo Dimitrov [160622 12:25]: > ir-rx51 is a driver for Nokia N900 IR transmitter. The current series > fixes the remaining problems in the driver: Thanks for updating these. Trierry, care to ack the PWM patch? Mauro, do you want me to set up an immutable branch with all these against v4.7-rc1 that we can all merge as needed? If you want to set up the branch instead, please feel free to add my ack. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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 0/3] media: an attempt to refresh omap1_camera driver
* Hans Verkuil [160617 00:07]: > Hi Janusz, > > On 06/16/2016 07:21 PM, Janusz Krzysztofik wrote: > > As requested by media subsystem maintainers, here is an attempt to > > convert the omap1_camera driver to the vb2 framework. Also, conversion > > to the dmaengine framework, long awaited by ARM/OMAP maintainers, is > > done. Janusz, thanks for updating to the dmaengine :) > > Next, I'm going to approach removal of soc-camera dependency. Please > > let me know how much time I have for that, i.e., when the soc-camera > > framework is going to be depreciated. > > Well, it is already deprecated (i.e. new drivers cannot use it), but it won't > be removed any time soon. There are still drivers depending on it, and some > aren't easy to rewrite. > > I have to say that it is totally unexpected to see that this omap1 driver is > still > used. In fact, we've already merged a patch that removed it for the upcoming > 4.8 kernel. Based on this new development I'll revert that for the omap1 > driver. > > Out of curiosity: is supporting the Amstrad Delta something you do as a hobby > or are there other reasons? Hmm if that IP old phone works fine with mainline kernel, why not keep using it? :) > A final note: once you've managed to drop the soc-camera dependency you should > run the v4l2-compliance test over the video node > (https://git.linuxtv.org/v4l-utils.git/). > > If that passes without failures, then this driver is in good shape and can be > moved out of staging again. Sounds good to me also, thanks guys. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.
* Ivaylo Dimitrov [160613 12:01]: > Hi, > > On 13.06.2016 10:10, Tony Lindgren wrote: > > * Ivaylo Dimitrov [160610 14:23]: > > > > > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > > > > > OK. And I just applied the related dts changes. Please repost the driver > > > > changes and DT binding doc with Rob's ack to the driver maintainers to > > > > apply. > > > > > > > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > > > > > Shall I do anything else? > > > > Probably good idea to repost just the driver changes to the > > subsystem maintainers. With v4.7 out any pre v4.7 patchsets > > easily get forgotten. > > > > Sorry for the maybe stupid question, but does this mean that I should send > separate patches instead of series? Or the series without what you've > already applied? Always leave out the patches that have been already applied. Otherwise people will get confused. Just mention it in the cover letter saying "patch xyz has been already applied into foo tree, these patches are safe to apply separately into bar tree" or something similar :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.
* Tony Lindgren [160613 00:10]: > * Ivaylo Dimitrov [160610 14:23]: > > > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > > > OK. And I just applied the related dts changes. Please repost the driver > > > changes and DT binding doc with Rob's ack to the driver maintainers to > > > apply. > > > > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > > > Shall I do anything else? > > Probably good idea to repost just the driver changes to the > subsystem maintainers. With v4.7 out any pre v4.7 patchsets > easily get forgotten. Heh s/v4.7/v4.6/ :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.
* Ivaylo Dimitrov [160610 14:23]: > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > OK. And I just applied the related dts changes. Please repost the driver > > changes and DT binding doc with Rob's ack to the driver maintainers to > > apply. > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > Shall I do anything else? Probably good idea to repost just the driver changes to the subsystem maintainers. With v4.7 out any pre v4.7 patchsets easily get forgotten. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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 6/6] ARM: dts: n900: enable lirc-rx51 driver
* Ivaylo Dimitrov [160516 12:36]: > Add the needed DT data to enable IR TX driver Applying this patch into omap-for-v4.8/dt instead of the earlier version. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.
* Ivaylo Dimitrov [160509 13:52]: > Hi, > > On 9.05.2016 22:36, Tony Lindgren wrote: > > * Ivaylo Dimitrov [160507 08:24]: > > > once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() > > > and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime > > > functions again before omap_dm_timer_stop is called(). Otherwise PM > > > runtime > > > functions called in omap_dm_timer_enable/disable lead to long and unneeded > > > delays. > > > > > > Fix that by implementing an "enabled" counter, so the PM runtime functions > > > get called only when really needed. > > > > > > Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. > > > > Well, I just tested again, with the $subject patch reverted and > contradictory to my own words, it worked just fine. I believe the reason is > that I did hrtimer "migration" after I did the $subject patch. I was > thinking the reason for the slow transmission was PWM dmtimer, but now it > turns out it has been the "pulse" dmtimer. So, I think the $subject patch > should be dropped. > > > We should use pm_runtime for the refcounting though and call PM runtime > > unconditionally. Can you try to follow the standard PM runtime usage > > like this: > > > > It works without that, but on the other hand, I finally have some reference > on how PM runtime API should be called :). OK. And I just applied the related dts changes. Please repost the driver changes and DT binding doc with Rob's ack to the driver maintainers to apply. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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] ARM: dts: n900: enable lirc-rx51 driver
* Ivaylo Dimitrov [160507 08:24]: > Add the needed DT data to enable IR TX driver Applying this patch into omap-for-v4.8/dt thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.
* Ivaylo Dimitrov [160507 08:24]: > once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() > and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime > functions again before omap_dm_timer_stop is called(). Otherwise PM runtime > functions called in omap_dm_timer_enable/disable lead to long and unneeded > delays. > > Fix that by implementing an "enabled" counter, so the PM runtime functions > get called only when really needed. > > Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. We should use pm_runtime for the refcounting though and call PM runtime unconditionally. Can you try to follow the standard PM runtime usage like this: init: pm_runtime_use_autosuspend(&timer->pdev->dev); pm_runtime_set_autosuspend_delay(&timer->pdev->dev, 200); pm_runtime_enable(&timer->pdev->dev); ... enable: pm_runtime_get_sync(&timer->pdev->dev); ... disable: pm_runtime_mark_last_busy(&timer->pdev->dev); pm_runtime_put_autosuspend(&timer->pdev->dev); ... exit: pm_runtime_dont_use_autosuspend(&timer->pdev->dev); pm_runtime_put_sync(&timer->pdev->dev); pm_runtime_disable(&timer->pdev->dev); No idea what the timeout should be, maybe less than 200 ms. Also we need to test that off idle still works with timer1, that might need special handling. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix ir-rx51 by using PWM pdata
* Ivaylo Dimitrov [160430 10:53]:
> Hi,
>
> On 29.04.2016 00:27, Tony Lindgren wrote:
> >* Ivaylo Dimitrov [160428 14:21]:
> >>
> >>I didn't test legacy boot, as I don't really see any value of doing it now
> >>the end of the legacy boot is near, the driver does not function correctly,
> >>however the patchset at least allows for the driver to be build and we have
> >>something to improve on. And I am going to send a patch that fixes the
> >>problem with omap_dm_timer_request_specific(). So, for both patches, you may
> >>add:
> >>
> >>Tested-by: Ivaylo Dimitrov
> >
> >OK thanks.
> >
> >Mauro, do the driver changes look OK to you?
> >
> >If so, I could queue the driver too for v4.7 because of the
> >dependency with your ack. Or I can provide you an immutable
> >branch with just the pdata changes against v4.6-rc1 if you
> >prefer that.
> >
Mauro, I've applied the pdata patch only into my omap-for-v4.7/legacy branch.
Feel free to merge immutable commit against v4.6-rc1 which is 8453c5cafd32
("ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51") to your tree
also for v4.7 if you decide to apply the ir-rx51 driver changes. Else we need
to wait for v4.7-rc1 :)
> In the meanwhile I was able to make the driver functional (on top of the
> $subject series) - for that purpose I had to fix dmtimer.c - it turns out
> that PM runtime get()/put() is called in almost every function exported by
> dmtimer, which in turn slows down IR transmission to 4-5s instead of 0.5s. I
> also replaced GPT9 dmtimer with PWM framework API (pwm-omap-dmtimer needs a
> patch) and implemented some DT support.
>
> Now, how shall I proceed with those - wait for the $subject series to be
> accepted or post the patches now?
Best to do incremental patches on what was posted to avoid confusion.
> Tony, I was unable to find the tree on kernel.org your patches are in. Which
> tree to use to base my patches on?
The pdata changes are in Linux next with omap-for-v4.7/legacy, the driver
changes I have not committed into any upstream going tree. Seems like
Mauro can take it after merging in commit 8453c5cafd32.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix ir-rx51 by using PWM pdata
* Ivaylo Dimitrov [160428 14:21]: > > I didn't test legacy boot, as I don't really see any value of doing it now > the end of the legacy boot is near, the driver does not function correctly, > however the patchset at least allows for the driver to be build and we have > something to improve on. And I am going to send a patch that fixes the > problem with omap_dm_timer_request_specific(). So, for both patches, you may > add: > > Tested-by: Ivaylo Dimitrov OK thanks. Mauro, do the driver changes look OK to you? If so, I could queue the driver too for v4.7 because of the dependency with your ack. Or I can provide you an immutable branch with just the pdata changes against v4.6-rc1 if you prefer that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] ir-rx51: Fix build after multiarch changes broke it
* Ivaylo Dimitrov [160428 13:44]: > Хи, > > On 28.04.2016 23:22, Tony Lindgren wrote: > >* Ivaylo Dimitrov [160428 12:39]: > >>On 27.04.2016 02:51, Tony Lindgren wrote: > >> > >>omap_dm_timer_request_specific always fails with message "Please use > >>omap_dm_timer_request_by_cap/node()" with DT boot. > >> > >>I hacked the code to use omap_dm_timer_request_by_cap(OMAP_TIMER_HAS_PWM) > >>and it seems to use the correct timer (IR LED blinks, checked with the > >>camera of Samsung S4 mini), but it doesn't actually control either of the TV > >>sets here. The same SW(pierogi) controls them when device is booted to stock > >>kernel. However, this seems another problem not related to the patch. > > > >OK thanks for testing, I'll apply the pdata patch then. > > > >I assume you'll post a separate fix for the request_by_cap > >driver change? > > > > Well, it was a hack, it just happens that the first matched timer is GPT9, I > think we should aim for a proper solution (request_by_node()). > > Shall I prepare a patch that gets the timer from the DT? Sounds good to me! Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] ir-rx51: Fix build after multiarch changes broke it
* Ivaylo Dimitrov [160428 12:39]: > On 27.04.2016 02:51, Tony Lindgren wrote: > > omap_dm_timer_request_specific always fails with message "Please use > omap_dm_timer_request_by_cap/node()" with DT boot. > > I hacked the code to use omap_dm_timer_request_by_cap(OMAP_TIMER_HAS_PWM) > and it seems to use the correct timer (IR LED blinks, checked with the > camera of Samsung S4 mini), but it doesn't actually control either of the TV > sets here. The same SW(pierogi) controls them when device is booted to stock > kernel. However, this seems another problem not related to the patch. OK thanks for testing, I'll apply the pdata patch then. I assume you'll post a separate fix for the request_by_cap driver change? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix ir-rx51 by using PWM pdata
Hi all, Here are minimal fixes to get ir-rx51 going again. Then further fixes can be done as noted in the second patch. Regards, Tony Tony Lindgren (2): ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51 [media] ir-rx51: Fix build after multiarch changes broke it arch/arm/mach-omap2/board-rx51-peripherals.c | 35 - arch/arm/mach-omap2/pdata-quirks.c | 33 - drivers/media/rc/Kconfig | 2 +- drivers/media/rc/ir-rx51.c | 99 ++ include/linux/platform_data/media/ir-rx51.h| 1 + include/linux/platform_data/pwm_omap_dmtimer.h | 21 ++ 6 files changed, 141 insertions(+), 50 deletions(-) -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51
Before we start removing omap3 legacy booting support, let's make n900
DT booting behave the same way for ir-rx51 as the legacy booting does.
For now, we need to pass pdata to the ir-rx51 driver. This means that
the n900 tree can move to using DT based booting without having to carry
all the legacy platform data with it when it gets dropped from the mainline
tree.
Note that the ir-rx51 driver is currently disabled because of the
dependency to !ARCH_MULTIPLATFORM. This will get sorted out later
with the help of drivers/pwm/pwm-omap-dmtimer.c. But first we need
to add chained IRQ support to dmtimer code to avoid introducing new
custom frameworks.
So let's just pass the necessary dmtimer functions to ir-rx51 so we
can get it working in the following patch.
Cc: Neil Armstrong
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 35 --
arch/arm/mach-omap2/pdata-quirks.c | 33 +++-
include/linux/platform_data/media/ir-rx51.h| 1 +
include/linux/platform_data/pwm_omap_dmtimer.h | 21
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index da174c0..4c35ffd 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#include
#include "common.h"
@@ -47,9 +49,8 @@
#include
-#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include
#include
-#endif
#include "mux.h"
#include "omap-pm.h"
@@ -1212,10 +1213,40 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
+ .request_by_node = omap_dm_timer_request_by_node,
+ .request_specific = omap_dm_timer_request_specific,
+ .request = omap_dm_timer_request,
+ .set_source = omap_dm_timer_set_source,
+ .get_irq = omap_dm_timer_get_irq,
+ .set_int_enable = omap_dm_timer_set_int_enable,
+ .set_int_disable = omap_dm_timer_set_int_disable,
+ .free = omap_dm_timer_free,
+ .enable = omap_dm_timer_enable,
+ .disable = omap_dm_timer_disable,
+ .get_fclk = omap_dm_timer_get_fclk,
+ .start = omap_dm_timer_start,
+ .stop = omap_dm_timer_stop,
+ .set_load = omap_dm_timer_set_load,
+ .set_match = omap_dm_timer_set_match,
+ .set_pwm = omap_dm_timer_set_pwm,
+ .set_prescaler = omap_dm_timer_set_prescaler,
+ .read_counter = omap_dm_timer_read_counter,
+ .write_counter = omap_dm_timer_write_counter,
+ .read_status = omap_dm_timer_read_status,
+ .write_status = omap_dm_timer_write_status,
+};
+#endif
+
#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
static struct lirc_rx51_platform_data rx51_lirc_data = {
.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
.pwm_timer = 9, /* Use GPT 9 for CIR */
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+ .dmtimer = &pwm_dmtimer_pdata,
+#endif
+
};
static struct platform_device rx51_lirc_device = {
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index cfaf45f..b36f0bd 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "common.h"
@@ -32,6 +33,7 @@
#include "dss-common.h"
#include "control.h"
#include "omap_device.h"
+#include "omap-pm.h"
#include "omap-secure.h"
#include "soc.h"
#include "hsmmc.h"
@@ -271,6 +273,8 @@ static struct platform_device omap3_rom_rng_device = {
},
};
+static struct platform_device rx51_lirc_device;
+
static void __init nokia_n900_legacy_init(void)
{
hsmmc2_internal_input_clk();
@@ -291,6 +295,8 @@ static void __init nokia_n900_legacy_init(void)
platform_device_register(&omap3_rom_rng_device);
}
+
+ platform_device_register(&rx51_lirc_device);
}
static void __init omap3_tao3530_legacy_init(void)
@@ -458,8 +464,14 @@ void omap_auxdata_legacy_init(struct device *dev)
/* Dual mode timer PWM callbacks platdata */
#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
-struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
+static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
.request_by_node = omap_dm_timer_request_by_node,
+ .request_specific = omap_dm_timer_request_specific,
+ .request = omap_dm_timer_request,
+ .set_source = omap_dm_timer_set_source,
+ .get_irq = omap_dm_timer_get_irq,
+ .set_int_enable = omap_dm_timer_set_int_enable,
+ .set_int_disable = omap_dm_timer_s
[PATCH 2/2] [media] ir-rx51: Fix build after multiarch changes broke it
The ir-rx51 driver for n900 has been disabled since the multiarch
changes as plat include directory no longer is SoC specific.
Let's fix it with minimal changes to pass the dmtimer calls in
pdata. Then the following changes can be done while things can
be tested to be working for each change:
1. Change the non-pwm dmtimer to use just hrtimer if possible
2. Change the pwm dmtimer to use Linux PWM API with the new
drivers/pwm/pwm-omap-dmtimer.c and remove the direct calls
to dmtimer functions
3. Parse configuration from device tree and drop the pdata
Note compilation of this depends on the previous patch
"ARM: OMAP2+: Add more functions to pwm pdata for ir-rx51".
Cc: Mauro Carvalho Chehab
Cc: Neil Armstrong
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren
---
drivers/media/rc/Kconfig | 2 +-
drivers/media/rc/ir-rx51.c | 99 +-
2 files changed, 54 insertions(+), 47 deletions(-)
Can you guys please test this still works? I've only been able
to test that it compiles/loads/unloads as my n900 in in a rack.
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index bd4d685..370e16e 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -336,7 +336,7 @@ config IR_TTUSBIR
config IR_RX51
tristate "Nokia N900 IR transmitter diode"
- depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC &&
!ARCH_MULTIPLATFORM
+ depends on OMAP_DM_TIMER && PWM_OMAP_DMTIMER && ARCH_OMAP2PLUS && LIRC
---help---
Say Y or M here if you want to enable support for the IR
transmitter diode built in the Nokia N900 (RX51) device.
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 4e1711a..da839c3 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -19,6 +19,7 @@
*
*/
+#include
#include
#include
#include
@@ -26,11 +27,9 @@
#include
#include
-#include
-#include
-
#include
#include
+#include
#include
#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE | \
@@ -44,8 +43,9 @@
#define TIMER_MAX_VALUE 0x
struct lirc_rx51 {
- struct omap_dm_timer *pwm_timer;
- struct omap_dm_timer *pulse_timer;
+ pwm_omap_dmtimer *pwm_timer;
+ pwm_omap_dmtimer *pulse_timer;
+ struct pwm_omap_dmtimer_pdata *dmtimer;
struct device*dev;
struct lirc_rx51_platform_data *pdata;
wait_queue_head_t wqueue;
@@ -63,14 +63,14 @@ struct lirc_rx51 {
static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
{
- omap_dm_timer_set_pwm(lirc_rx51->pwm_timer, 0, 1,
- OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE);
+ lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
+ PWM_OMAP_DMTIMER_TRIGGER_OVERFLOW_AND_COMPARE);
}
static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
{
- omap_dm_timer_set_pwm(lirc_rx51->pwm_timer, 0, 1,
- OMAP_TIMER_TRIGGER_NONE);
+ lirc_rx51->dmtimer->set_pwm(lirc_rx51->pwm_timer, 0, 1,
+ PWM_OMAP_DMTIMER_TRIGGER_NONE);
}
static int init_timing_params(struct lirc_rx51 *lirc_rx51)
@@ -79,12 +79,12 @@ static int init_timing_params(struct lirc_rx51 *lirc_rx51)
load = -(lirc_rx51->fclk_khz * 1000 / lirc_rx51->freq);
match = -(lirc_rx51->duty_cycle * -load / 100);
- omap_dm_timer_set_load(lirc_rx51->pwm_timer, 1, load);
- omap_dm_timer_set_match(lirc_rx51->pwm_timer, 1, match);
- omap_dm_timer_write_counter(lirc_rx51->pwm_timer, TIMER_MAX_VALUE - 2);
- omap_dm_timer_start(lirc_rx51->pwm_timer);
- omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
- omap_dm_timer_start(lirc_rx51->pulse_timer);
+ lirc_rx51->dmtimer->set_load(lirc_rx51->pwm_timer, 1, load);
+ lirc_rx51->dmtimer->set_match(lirc_rx51->pwm_timer, 1, match);
+ lirc_rx51->dmtimer->write_counter(lirc_rx51->pwm_timer, TIMER_MAX_VALUE
- 2);
+ lirc_rx51->dmtimer->start(lirc_rx51->pwm_timer);
+ lirc_rx51->dmtimer->set_int_enable(lirc_rx51->pulse_timer, 0);
+ lirc_rx51->dmtimer->start(lirc_rx51->pulse_timer);
lirc_rx51->match = 0;
@@ -100,15 +100,15 @@ static int pulse_timer_set_timeout(struct lirc_rx51
*lirc_rx51, int usec)
BUG_ON(usec < 0);
if (lirc_rx51->match == 0)
- counter = omap_dm_timer_read_counter(lirc_rx51->pulse_timer);
+ counter =
lirc_rx51->dmtimer->read_counter(lirc_rx51->pulse_timer);
else
counter = lirc_rx51->match;
counter += (u32)(lirc_rx51->fclk_khz * usec / (1000));
- omap_dm_timer_set_match(lirc_rx51->pulse_
Re: tvp5150 regression after commit 9f924169c035
* Javier Martinez Canillas [160415 09:50]: > On 04/15/2016 10:58 AM, Tony Lindgren wrote: > > If you block PM runtime for I2C, then it blocks deeper idle states > > for the whole device. Note that you can disable off mode during idle > > Thanks again for this clarification. > > > and suspend with: > > > > # echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > I see thought that enable_off_mode is 0 by default when booting the board: > > # cat /sys/kernel/debug/pm_debug/enable_off_mode > 0 OK so you're not hitting off mode then. > So if I understood your explanation correctly, that means that the glitch > should not happen for the GPIO pins since the machine doesn't enter into > deeper idle states that could cause the glitch from erratum 1.158? Correct. But you could still have a dependency to some other device driver that stays active if I2C keeps the whole system from hitting retention mode during idle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tvp5150 regression after commit 9f924169c035
* Javier Martinez Canillas [160414 17:00]: > On 04/14/2016 11:12 AM, Tony Lindgren wrote: > > Is this with omap3 and does tvp5150 have a reset GPIO pin? > > Yes, it's a DM3730 (OMAP3) and yes the tvp5150 (actually it's a tvp5151) has > a reset pin that has to be toggled, along with a power-down pin for the chip > to be in an operative state before accessing the I2C registers. That is the > power/reset sequence I mentioned before. > > > If so, you could be hitting the GPIO errata where a glitch can happen > > when restoring the GPIO state coming back from off mode in idle. This > > happes for GPIO pins that are not in GPIO bank1 and have an external > > pull down resistor on the line. > > > > The GPIO lines connected to these pins are: > > GPIO126 (bank4 pin 30) -> tvp5150 power-down pin > GPIO167 (bank6 pin 7) -> tvp5150 reset pin > > Neither are in GPIO bank1 so they could be affected by the errata you > mention but there isn't external pull down (or up) resistors on these > lines AFAICT by looking at the board schematics. I've added to the cc > list to other people that are familiar with the board in case I missed > something. > > > The short term workaround is to mux the reset pin to use the internal > > pulls by using PIN_INPUT_PULLUP | MUX_MODE7, or depending on the direction, > > PIN_INPUT_PULLDOWN | MUX_MODE7. > > I guess you meant MUX_MODE4 here since the pin has to be in GPIO mode? No, the glitch affects the GPIO mode, so that's why direction + pull + safe mode is needed. > Also, I wonder how the issue could be related to the GPIO controller > since is when enabling runtime PM for the I2C controller that things > fail. IOW, disabling runtime PM for the I2C adapter shouldn't make > things to work if the problem was caused by the mentioned GPIO errata. If you block PM runtime for I2C, then it blocks deeper idle states for the whole device. Note that you can disable off mode during idle and suspend with: # echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > In any case, I've tried to use the internal pulls as you suggested but > that didn't solve the issue. OK. Just to be sure.. Did you use the safe mode mux option instead of the GPIO mux option? Note that in some cases the internal pull is not strong enough to keep the reset line up if there's an external pull down resistor. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tvp5150 regression after commit 9f924169c035
Hi, * Javier Martinez Canillas [160414 07:28]: > Hello Wofram, > > On 04/14/2016 10:19 AM, Wolfram Sang wrote: > > > >> Yes, I also wonder why I'm the only one facing this issue... maybe no one > >> else is using the tvp5150 driver on an OMAP board with mainline? > > > > I wonder why it only affects tvp5150. I don't see the connection yet. > > > > Yes, me neither. All other I2C devices are working properly on this board. > > The only thing I can think, is that the tvp5150 needs a reset sequence in > order to be operative. It basically toggles two pins in the chip, this is > done in tvp5150_init() [0] and is needed before accessing I2C registers. > > Maybe runtime pm has an effect on this and the chip is not reset correctly? Is this with omap3 and does tvp5150 have a reset GPIO pin? If so, you could be hitting the GPIO errata where a glitch can happen when restoring the GPIO state coming back from off mode in idle. This happes for GPIO pins that are not in GPIO bank1 and have an external pull down resistor on the line. The short term workaround is to mux the reset pin to use the internal pulls by using PIN_INPUT_PULLUP | MUX_MODE7, or depending on the direction, PIN_INPUT_PULLDOWN | MUX_MODE7. The long term workaround is tho have gpio-omap.c do this dynamically with pinctrl-single.c using gpio-ranges, but that's going to take a while.. You can search for erratum 1.158 for more info. Regards, Tony > [0]: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/media/i2c/tvp5150.c#n1311 -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
* Tony Lindgren [150914 09:37]: > * Suman Anna [150914 09:33]: > > Hi Tony, > > > > On 09/03/2015 05:34 PM, Suman Anna wrote: > > > Hi Sakari, > > > > > > On 07/16/2015 07:58 AM, Tony Lindgren wrote: > > >> * Laurent Pinchart [150716 05:57]: > > >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation > > >>> from C code. > > >> > > >> Please feel to queue this along with the second patch in this series, > > >> this should not cause any merge conflicts: > > >> > > >> Acked-by: Tony Lindgren > > > > > > Just wondering if you have already queued this, I see the v4l changes in > > > linux-next, but not this patch. Also, can you confirm if this series is > > > making it into 4.3? > > > > > > > This patch is not in 4.3-rc1, can you pick this up for the next merge > > window? I am gonna send out some additional cleanup patches (removing > > legacy mailbox and iommu pieces) on top on this patch. The second patch > > in this series did make it. > > OK tagging this one for next, will apply once I'm done with fixes. Applying into omap-for-v4.4/cleanup finally thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
* Suman Anna [150914 09:33]: > Hi Tony, > > On 09/03/2015 05:34 PM, Suman Anna wrote: > > Hi Sakari, > > > > On 07/16/2015 07:58 AM, Tony Lindgren wrote: > >> * Laurent Pinchart [150716 05:57]: > >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation > >>> from C code. > >> > >> Please feel to queue this along with the second patch in this series, > >> this should not cause any merge conflicts: > >> > >> Acked-by: Tony Lindgren > > > > Just wondering if you have already queued this, I see the v4l changes in > > linux-next, but not this patch. Also, can you confirm if this series is > > making it into 4.3? > > > > This patch is not in 4.3-rc1, can you pick this up for the next merge > window? I am gonna send out some additional cleanup patches (removing > legacy mailbox and iommu pieces) on top on this patch. The second patch > in this series did make it. OK tagging this one for next, will apply once I'm done with fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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] DT support for omap4-iss
* Michael Allwright [150811 10:16]:
> On 11 August 2015 at 13:16, Tony Lindgren wrote:
> > * Michael Allwright [150810 08:19]:
> >> +
> >> +/*
> >> +We need a better solution for this
> >> +*/
> >> +#include <../arch/arm/mach-omap2/omap-pm.h>
> >
> > Please let's not do things like this, I end up having to deal with
> > all these eventually :(
> >
> >> +static void iss_set_constraints(struct iss_device *iss, bool enable)
> >> +{
> >> +if (!iss)
> >> +return;
> >> +
> >> +/* FIXME: Look for something more precise as a good throughtput limit
> >> */
> >> +omap_pm_set_min_bus_tput(iss->dev, OCP_INITIATOR_AGENT,
> >> + enable ? 80 : -1);
> >> +}
> >> +
> >> +static struct iss_platform_data iss_dummy_pdata = {
> >> +.set_constraints = iss_set_constraints,
> >> +};
> >
> > If this is one time setting, you could do it based on the
> > compatible string using arch/arm/mach-omap2/pdata-quirks.c.
> >
> > If you need to toggle it, you could populate a function pointer
> > in pdata-quirks.c. Those are easy to fix once there is some Linux
> > generic API available :)
> >
> > Regards,
> >
> > Tony
>
> Hi Tony,
>
> Thanks for the suggestion, I'll move that function into
> pdata-quirks.c. Please read on, I really need some help regarding the
> following error, I lost 8-9 hours on this today.
>
> [ 141.612609] omap4iss 5200.iss: CSI2: CSI2_96M_FCLK reset timeout!
>
> This comes from the function: int omap4iss_csi2_reset(struct
> iss_csi2_device *csi2) in iss_csi2.c. I have found that bit 29 in
> REGISTER1 belonging to the CSI2A registers, isn't becoming high after
> doing the reset on kernel 4.1.4. However it does come high in 3.17.
> This bit is a flag indicating that the reset on the CSI2_96M_FCLK is
> complete.
>
> 3.17
> [ 43.399658] omap4-iss 5200.iss: REGISTER1 = 0x
> [ 43.405456] omap4-iss 5200.iss: REGISTER1 = 0xe002e10e
>
> 4.1.4
> [ 210.331909] omap4iss 5200.iss: REGISTER1 = 0x
> [ 210.338470] omap4iss 5200.iss: REGISTER1 = 0xc002e10e
> [ 210.342609] omap4iss 5200.iss: CSI2: CSI2_96M_FCLK reset timeout!
>
> Note: the transition from 0x to 0xc002e10e would seem to
> indicate that the operation completed, just not successfully...
>
> I have spent the day sampling at different points in the code,
> checking the contents of all the registers belonging to the ISS and
> CSI PHY to conclude that there are no differences between the two
> instances of the driver running on 3.17 and 4.1.4. Using the internal
> __clk_is_enabled from clk-provider.h I also checked that the muxes
> responsible for providing the clocks to the module were enabled
> before, during and after the reset. I have also confirmed the
> identical issue also occurs on a different board.
>
> I suspect someone has broken something in the hwmods, or PRCM data
> structures. Although I have not yet been able to find any relevant
> differences in the source files that I have searched through.
>
> Any suggestions regarding where I should continue to look for this
> issue are welcome. Unfortunately if I can't get some support on this
> soon, I will have to abandon working on this patch.
Sorry I'm a bit behind on emails.. If this is still an issue you
may be able to git bisect it with an additional camera patches. Of
course assuming your camera patches apply and work over a larger
set of kernel versions :) If it does not work, you might be able
to create a minimal test patch for git bisect that just tests the
CSI2_96M_FCLK on boot.
Of course it might make sense to test that with recent main kernel
revisions first before git bisect.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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] DT support for omap4-iss
* Michael Allwright [150810 08:19]:
> +
> +/*
> +We need a better solution for this
> +*/
> +#include <../arch/arm/mach-omap2/omap-pm.h>
Please let's not do things like this, I end up having to deal with
all these eventually :(
> +static void iss_set_constraints(struct iss_device *iss, bool enable)
> +{
> +if (!iss)
> +return;
> +
> +/* FIXME: Look for something more precise as a good throughtput limit */
> +omap_pm_set_min_bus_tput(iss->dev, OCP_INITIATOR_AGENT,
> + enable ? 80 : -1);
> +}
> +
> +static struct iss_platform_data iss_dummy_pdata = {
> +.set_constraints = iss_set_constraints,
> +};
If this is one time setting, you could do it based on the
compatible string using arch/arm/mach-omap2/pdata-quirks.c.
If you need to toggle it, you could populate a function pointer
in pdata-quirks.c. Those are easy to fix once there is some Linux
generic API available :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
* Laurent Pinchart [150716 05:57]: > The OMAP3 ISP is now fully supported in DT, remove its instantiation > from C code. Please feel to queue this along with the second patch in this series, this should not cause any merge conflicts: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] v4l: omap4iss: DT bindings development
* Michael Allwright [150602 01:41]: > Hi Everyone, > > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I > am unable to capture any data in my test setup. As detailed below, it > seems that everything has been configured correctly however I never > get any interrupts from the ISS unless I do something drastic like > removing one of the wires from the clock differential pair which > results in constant complex IO error interrupts from CSIA until I > restore the physical connection. > > My test setup includes a OV6540 sensor camera module (MIPI) from > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards > forming an interconnect between the two. The sensor is connected to > CSI21 on the OMAP4 using a clock lane (on position 1, default > polarity) and a single data lane (on position 2, default polarity), > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds > to 19.2MHz when asked for 24MHz). > > The relevant parts of my device tree can be seen here: > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually > somewhat unclear what effect stating the ti,hwmod="iss" parameter has. > Does anything else need to be done here? As far as I can tell I think > all clocks and power has been switched on. I do make two function > calls to the PM API in the ISS probe function, i.e.: > > pm_runtime_enable(&pdev->dev); > r = pm_runtime_get_sync(&pdev->dev); The ti,hwmod = "iss" hooks up the device with the PM runtime, see omap_hwmod_44xx_data.c for "iss". > Regarding my debugging, this is what I have checked so far > > * Changing the pixel rate of the sensor - this lead me to discover a > possible bug in iss.c or perhaps my ov5640 driver, as the > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this > by copying what Laurent has done in the OMAP3ISP driver which now > works. > * As I only have a 100MHz scope, I had to slow down the camera > significantly (MIPI clock => 10-12MHz range) to verify that I was > getting reasonable output from the sensor (i.e. signals that were > characteristic of CSI2/MIPI). I checked the calculations and made sure > these updated values came across via the V4L2_CID_PIXEL_RATE control > and ended up in the THS_TERM and THS_SETTLE fields of register 0. > * Using the omapconf tool, I have manually and one by one pulled up > the CSI2 pins and verified multiple times all connections to the > sensor module and have even manually tried swapping the DP/DN pairs in > case they were still somehow backwards despite previous testing > * Verified that the interrupt service routine is called by generating > a test interrupt HS_VS from inside the ISS i.e. > > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x0002 > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x0002 > > * Verified that the default CMA region is being used, it ends up in > the ping-pong resisters of the ISS. > > Additional information: > > * Initialisation of pipe line and stream commands: > > media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]' > media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0 > [UYVY 640x480]' > yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy > > * Output from OMAPCONF tool is in the second part of: > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 > > Anyway, at this point, I'm almost completely out of ideas on how to > move forwards so any suggestions, criticisms or help of any nature > would be appreciated! Usually it's pinmuxing or some regulator or clock not enabled. Or incorrect hwmod sysc and syss configuration for iss that prevents enabling it properly. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
* Peter Ujfalusi [150526 06:28]:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channels. In case of error, return the error code we received including
> -EPROBE_DEFER
>
> Signed-off-by: Peter Ujfalusi
> CC: Greg Kroah-Hartman
> ---
> drivers/tty/serial/8250/8250_dma.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_dma.c
> b/drivers/tty/serial/8250/8250_dma.c
> index 21d01a491405..a617eca4e97d 100644
> --- a/drivers/tty/serial/8250/8250_dma.c
> +++ b/drivers/tty/serial/8250/8250_dma.c
> @@ -182,21 +182,19 @@ int serial8250_request_dma(struct uart_8250_port *p)
> dma_cap_set(DMA_SLAVE, mask);
>
> /* Get a channel for RX */
> - dma->rxchan = dma_request_slave_channel_compat(mask,
> -dma->fn, dma->rx_param,
> -p->port.dev, "rx");
> - if (!dma->rxchan)
> - return -ENODEV;
> + dma->rxchan = dma_request_slave_channel_compat_reason(mask, dma->fn,
> + dma->rx_param, p->port.dev, "rx");
> + if (IS_ERR(dma->rxchan))
> + return PTR_ERR(dma->rxchan);
>
> dmaengine_slave_config(dma->rxchan, &dma->rxconf);
>
> /* Get a channel for TX */
> - dma->txchan = dma_request_slave_channel_compat(mask,
> -dma->fn, dma->tx_param,
> -p->port.dev, "tx");
> - if (!dma->txchan) {
> + dma->txchan = dma_request_slave_channel_compat_reason(mask, dma->fn,
> + dma->tx_param, p->port.dev, "tx");
> + if (IS_ERR(dma->txchan)) {
> dma_release_channel(dma->rxchan);
> - return -ENODEV;
> + return PTR_ERR(dma->txchan);
> }
>
> dmaengine_slave_config(dma->txchan, &dma->txconf);
In general the drivers need to work just fine also without DMA.
Does this handle the case properly where no DMA channel is configured
for the driver in the dts file?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] ARM: omap2: use clkdev_add_alias()
* Russell King [150403 10:14]:
> When creating aliases of existing clkdev clocks, use clkdev_add_alias()
> isntead of open coding the lookup and clk_lookup creation.
>
> Signed-off-by: Russell King
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/omap_device.c | 24 +---
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
> index be9541e18650..521c32e7778e 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -47,7 +47,7 @@ static void _add_clkdev(struct omap_device *od, const char
> *clk_alias,
> const char *clk_name)
> {
> struct clk *r;
> - struct clk_lookup *l;
> + int rc;
>
> if (!clk_alias || !clk_name)
> return;
> @@ -62,21 +62,15 @@ static void _add_clkdev(struct omap_device *od, const
> char *clk_alias,
> return;
> }
>
> - r = clk_get(NULL, clk_name);
> - if (IS_ERR(r)) {
> - dev_err(&od->pdev->dev,
> - "clk_get for %s failed\n", clk_name);
> - return;
> + rc = clk_add_alias(clk_alias, dev_name(&od->pdev->dev), clk_name, NULL);
> + if (rc) {
> + if (rc == -ENODEV || rc == -ENOMEM)
> + dev_err(&od->pdev->dev,
> + "clkdev_alloc for %s failed\n", clk_alias);
> + else
> + dev_err(&od->pdev->dev,
> + "clk_get for %s failed\n", clk_name);
> }
> -
> - l = clkdev_alloc(r, clk_alias, dev_name(&od->pdev->dev));
> - if (!l) {
> - dev_err(&od->pdev->dev,
> - "clkdev_alloc for %s failed\n", clk_alias);
> - return;
> - }
> -
> - clkdev_add(l);
> }
>
> /**
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: omap2: use clkdev_create()
* Russell King [150403 10:14]: > Rather than open coding the clkdev allocation, initialisation and > addition, use the clkdev_create() helper. > > Signed-off-by: Russell King Acked-by: Tony Lindgren > --- > arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 12 ++-- > 1 file changed, 2 insertions(+), 10 deletions(-) > > diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c > b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c > index 85e0b0c06718..b64d717bfab6 100644 > --- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c > +++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c > @@ -232,14 +232,12 @@ void omap2xxx_clkt_vps_init(void) > struct clk_hw_omap *hw = NULL; > struct clk *clk; > const char *parent_name = "mpu_ck"; > - struct clk_lookup *lookup = NULL; > > omap2xxx_clkt_vps_late_init(); > omap2xxx_clkt_vps_check_bootloader_rates(); > > hw = kzalloc(sizeof(*hw), GFP_KERNEL); > - lookup = kzalloc(sizeof(*lookup), GFP_KERNEL); > - if (!hw || !lookup) > + if (!hw) > goto cleanup; > init.name = "virt_prcm_set"; > init.ops = &virt_prcm_set_ops; > @@ -249,15 +247,9 @@ void omap2xxx_clkt_vps_init(void) > hw->hw.init = &init; > > clk = clk_register(NULL, &hw->hw); > - > - lookup->dev_id = NULL; > - lookup->con_id = "cpufreq_ck"; > - lookup->clk = clk; > - > - clkdev_add(lookup); > + clkdev_create(clk, "cpufreq_ck", NULL); > return; > cleanup: > kfree(hw); > - kfree(lookup); > } > #endif > -- > 1.8.3.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h
* Russell King [150403 10:13]: > clk_add_alias() is provided by clkdev, and is not part of the clk API. > Howver, it is prototyped in two locations: linux/clkdev.h and > linux/clk.h. This is a mess. Get rid of the redundant and unnecessary > version in linux/clk.h. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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 06/15] omap3isp: Refactor device configuration structs for Device Tree
* Sakari Ailus [150325 16:00]:
> Make omap3isp configuration data structures more suitable for consumption by
> the DT by separating the I2C bus information of all the sub-devices in a
> group and the ISP bus information from each other. The ISP bus information
> is made a pointer instead of being directly embedded in the struct.
>
> In the case of the DT only the sensor specific information on the ISP bus
> configuration is retained. The structs are renamed to reflect that.
>
> After this change the structs needed to describe device configuration can be
> allocated and accessed separately without those needed only in the case of
> platform data. The platform data related structs can be later removed once
> the support for platform data can be removed.
>
> Signed-off-by: Sakari Ailus
> Acked-by: Laurent Pinchart
> Cc: Igor Grinberg
> Acked-by: Igor Grinberg (for cm-t35)
There arch/arm/mach-omap2 changes here are OK to merge along with
the driver changes:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 57 +++---
> drivers/media/platform/omap3isp/isp.c | 86
> +--
> drivers/media/platform/omap3isp/isp.h |2 +-
> drivers/media/platform/omap3isp/ispccdc.c | 26
> drivers/media/platform/omap3isp/ispccp2.c | 22 +++
> drivers/media/platform/omap3isp/ispcsi2.c |8 +--
> drivers/media/platform/omap3isp/ispcsiphy.c | 21 ---
> include/media/omap3isp.h| 34 +--
> 8 files changed, 119 insertions(+), 137 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index 91738a1..b5dfbc1 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -492,51 +492,36 @@ static struct twl4030_platform_data cm_t35_twldata = {
> #include
> #include "devices.h"
>
> -static struct i2c_board_info cm_t35_isp_i2c_boardinfo[] = {
> +static struct isp_platform_subdev cm_t35_isp_subdevs[] = {
> {
> - I2C_BOARD_INFO("mt9t001", 0x5d),
> - },
> - {
> - I2C_BOARD_INFO("tvp5150", 0x5c),
> - },
> -};
> -
> -static struct isp_subdev_i2c_board_info cm_t35_isp_primary_subdevs[] = {
> - {
> - .board_info = &cm_t35_isp_i2c_boardinfo[0],
> - .i2c_adapter_id = 3,
> - },
> - { NULL, 0, },
> -};
> -
> -static struct isp_subdev_i2c_board_info cm_t35_isp_secondary_subdevs[] = {
> - {
> - .board_info = &cm_t35_isp_i2c_boardinfo[1],
> + .board_info = &(struct i2c_board_info){
> + I2C_BOARD_INFO("mt9t001", 0x5d)
> + },
> .i2c_adapter_id = 3,
> - },
> - { NULL, 0, },
> -};
> -
> -static struct isp_v4l2_subdevs_group cm_t35_isp_subdevs[] = {
> - {
> - .subdevs = cm_t35_isp_primary_subdevs,
> - .interface = ISP_INTERFACE_PARALLEL,
> - .bus = {
> - .parallel = {
> - .clk_pol = 1,
> + .bus = &(struct isp_bus_cfg){
> + .interface = ISP_INTERFACE_PARALLEL,
> + .bus = {
> + .parallel = {
> + .clk_pol = 1,
> + },
> },
> },
> },
> {
> - .subdevs = cm_t35_isp_secondary_subdevs,
> - .interface = ISP_INTERFACE_PARALLEL,
> - .bus = {
> - .parallel = {
> - .clk_pol = 0,
> + .board_info = &(struct i2c_board_info){
> + I2C_BOARD_INFO("tvp5150", 0x5c),
> + },
> + .i2c_adapter_id = 3,
> + .bus = &(struct isp_bus_cfg){
> + .interface = ISP_INTERFACE_PARALLEL,
> + .bus = {
> + .parallel = {
> + .clk_pol = 0,
> + },
> },
> },
> },
> - { NULL, 0, },
> + { 0 },
> };
>
> static struct isp_platform_data cm_t35_isp_pdata = {
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c
> index 537377b..1b5c6df 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -447,7 +447,7 @@ static void isp_core_init(struct isp_device *isp, int
> idle)
> */
> void omap3isp_config
Re: [PATCH v2 0/3] OMAP 3 ISP (and N9/N950 primary camera support) dts changes
* Sakari Ailus [150318 16:51]: > Hi folks, > > Since v1, I've rebased the set on Tero Kristo's PRCM / SCM cleanup patchset > here: > > http://www.spinics.net/lists/linux-omap/msg116949.html> > > v1 can be found here: > > http://www.spinics.net/lists/linux-omap/msg116753.html> > > Changes since v1: > > - Fixed phy reference (number to name) in the example, > > - Dropped the first patch. This is already done by Tero's patch "ARM: dts: > omap3: merge control module features under scrm node". Applying these into omap-for-v4.1/dt thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 18/18] omap3isp: Deprecate platform data support
* Sebastian Reichel [150313 02:41]: > Hi, > > [+CC Tony] > > On Sat, Mar 07, 2015 at 11:41:15PM +0200, Sakari Ailus wrote: > > Print a warning when the driver is used with platform data. Existing > > platform data user should move to DT now. > > I guess this should become a more visible warning on OMAP SoC level, > since platform data based boot will be deprecated completly. Yeah. We should need platform data in addition to device tree data in only very few cases. Basically only when there's some arch specific callback function that needs to be passed to the driver. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 11/18] omap3isp: Replace many MMIO regions by two
* Laurent Pinchart [150307 15:43]:
> Hi Sakari,
>
> Thank you for the patch.
>
> (CC'ing linux-omap and Tony)
>
> On Saturday 07 March 2015 23:41:08 Sakari Ailus wrote:
> > The omap3isp MMIO register block is contiguous in the MMIO register space
> > apart from the fact that the ISP IOMMU register block is in the middle of
> > the area. Ioremap it at two occasions, and keep the rest of the layout of
> > the register space internal to the omap3isp driver.
> >
> > Signed-off-by: Sakari Ailus
>
> Acked-by: Laurent Pinchart
>
> > ---
> > arch/arm/mach-omap2/devices.c | 66 +--
> > arch/arm/mach-omap2/omap34xx.h| 36 +--
>
> Once again you might be asked to split this. However, it would be pretty
> painful, so it would be nice if we could merge everything through the Linux
> media tree. You will need an ack from Tony.
These changes look fine to me and should not conflict with anything
I'm planning to queue, so please feel free to take them along with
the other isp changes:
Acked-by: Tony Lindgren
> > drivers/media/platform/omap3isp/isp.c | 113 --
> > drivers/media/platform/omap3isp/isp.h |4 +-
> > 4 files changed, 66 insertions(+), 153 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index e945957..990338f 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -74,72 +74,12 @@ omap_postcore_initcall(omap3_l3_init);
> > static struct resource omap3isp_resources[] = {
> > {
> > .start = OMAP3430_ISP_BASE,
> > - .end= OMAP3430_ISP_END,
> > + .end= OMAP3430_ISP_BASE + 0x12fc,
> > .flags = IORESOURCE_MEM,
> > },
> > {
> > - .start = OMAP3430_ISP_CCP2_BASE,
> > - .end= OMAP3430_ISP_CCP2_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_CCDC_BASE,
> > - .end= OMAP3430_ISP_CCDC_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_HIST_BASE,
> > - .end= OMAP3430_ISP_HIST_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_H3A_BASE,
> > - .end= OMAP3430_ISP_H3A_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_PREV_BASE,
> > - .end= OMAP3430_ISP_PREV_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_RESZ_BASE,
> > - .end= OMAP3430_ISP_RESZ_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_SBL_BASE,
> > - .end= OMAP3430_ISP_SBL_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_CSI2A_REGS1_BASE,
> > - .end= OMAP3430_ISP_CSI2A_REGS1_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3430_ISP_CSIPHY2_BASE,
> > - .end= OMAP3430_ISP_CSIPHY2_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3630_ISP_CSI2A_REGS2_BASE,
> > - .end= OMAP3630_ISP_CSI2A_REGS2_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3630_ISP_CSI2C_REGS1_BASE,
> > - .end= OMAP3630_ISP_CSI2C_REGS1_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3630_ISP_CSIPHY1_BASE,
> > - .end= OMAP3630_ISP_CSIPHY1_END,
> > - .flags = IORESOURCE_MEM,
> > - },
> > - {
> > - .start = OMAP3630_ISP_CSI2C_REGS2_BASE,
> > - .end= OMAP3630_ISP_CSI2C_REGS2_END,
> > + .start = OMAP3430_ISP_BASE2,
> > + .end= OMAP3430_ISP_BASE2 + 0x0600,
> > .flags = IORESO
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
* Sakari Ailus [150307 15:44]:
> Hi Laurent,
>
> On Sun, Mar 08, 2015 at 01:34:17AM +0200, Laurent Pinchart wrote:
> > Hi Sakari,
> >
> > Thank you for the patch.
> >
> > (CC'ing linux-omap and Tony)
>
> Thanks.
>
> > On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
> > > The syscon register isn't part of the ISP, use it through the syscom
> > > driver
> > > regmap instead. The syscom block is considered to be from 343x on ISP
> > > revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
> > >
> > > Signed-off-by: Sakari Ailus
> > > ---
> > > arch/arm/boot/dts/omap3.dtsi|2 +-
> > > arch/arm/mach-omap2/devices.c | 10 --
> > > drivers/media/platform/omap3isp/isp.c | 19 +++
> > > drivers/media/platform/omap3isp/isp.h | 19 +--
> > > drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
> >
> > You might be asked to split the patch into two, let's see what Tony says.
> >
> > > 5 files changed, 42 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> > > index 01b7111..fe0b293 100644
> > > --- a/arch/arm/boot/dts/omap3.dtsi
> > > +++ b/arch/arm/boot/dts/omap3.dtsi
> > > @@ -183,7 +183,7 @@
> > >
> > > omap3_scm_general: tisyscon@48002270 {
> > > compatible = "syscon";
> > > - reg = <0x48002270 0x2f0>;
> > > + reg = <0x48002270 0x2f4>;
> > > };
> > >
> > > pbias_regulator: pbias_regulator {
Can you please send the above dts change separately as a fix describing
what goes wrong? Let's get that out of the way for the -rc, otherwise
we're going to probably get conflicts with Tero's dts changes.
> > > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > > index 1afb50d..e945957 100644
> > > --- a/arch/arm/mach-omap2/devices.c
> > > +++ b/arch/arm/mach-omap2/devices.c
> > > @@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
> > > .flags = IORESOURCE_MEM,
> > > },
> > > {
> > > - .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
> > > - .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
> > > + 3,
> > > - .flags = IORESOURCE_MEM,
> > > - },
> > > - {
> > > - .start = OMAP343X_CTRL_BASE +
> > > OMAP3630_CONTROL_CAMERA_PHY_CTRL,
> > > - .end= OMAP343X_CTRL_BASE +
> > > OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
> > > - .flags = IORESOURCE_MEM,
> > > - },
> > > - {
> > > .start = 24 + OMAP_INTC_START,
> > > .flags = IORESOURCE_IRQ,
> > > }
Looks good to me, teel free to merge this part along with the other
isp changes:
Acked-by: Tony Lindgren
> > > diff --git a/drivers/media/platform/omap3isp/isp.c
> > > b/drivers/media/platform/omap3isp/isp.c index 68d7edfc..4ff4bbd 100644
> > > --- a/drivers/media/platform/omap3isp/isp.c
> > > +++ b/drivers/media/platform/omap3isp/isp.c
> > > @@ -51,6 +51,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> > > 1 << OMAP3_ISP_IOMEM_RESZ |
> > > 1 << OMAP3_ISP_IOMEM_SBL |
> > > 1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
> > > -1 << OMAP3_ISP_IOMEM_CSIPHY2 |
> > > -1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> > > +1 << OMAP3_ISP_IOMEM_CSIPHY2,
> > > + .syscon_offset = 0xdc,
> > > + .phy_type = ISP_PHY_TYPE_3430,
> > > },
> > > {
> > > .isp_rev = ISP_REVISION_15_0,
> > > @@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
> > > 1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
> > > 1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
> > > 1 << OMAP3_ISP_IOMEM_CSIPHY1 |
> > > -1
Re: [PATCH 10/10] ARM: omap2: use clkdev_add_alias()
* Russell King [150302 09:10]: > When creating aliases of existing clkdev clocks, use clkdev_add_alias() > isntead of open coding the lookup and clk_lookup creation. Gave this series a quick try but I get these build errors: arch/arm/mach-omap2/omap_device.c: In function ‘_add_clkdev’: arch/arm/mach-omap2/omap_device.c:65:58: warning: passing argument 3 of ‘clk_add_alias’ discards ‘const’ qualifier from pointer target type rc = clk_add_alias(clk_alias, dev_name(&od->pdev->dev), clk_name, NULL); ^ In file included from arch/arm/mach-omap2/omap_device.c:34:0: include/linux/clkdev.h:44:5: note: expected ‘char *’ but argument is of type ‘const char *’ int clk_add_alias(const char *, const char *, char *, struct device *); ^ drivers/clk/clkdev.c:298:16: error: expected declaration specifiers or ‘...’ before ‘(’ token vclkdev_create((struct clk *clk, const char *con_id, const char *dev_fmt, ^ drivers/clk/clkdev.c:322:92: error: storage class specified for parameter ‘__crc_clkdev_alloc’ EXPORT_SYMBOL(clkdev_alloc); ^ drivers/clk/clkdev.c:322:1: warning: ‘weak’ attribute ignored [-Wattributes] EXPORT_SYMBOL(clkdev_alloc); ^ drivers/clk/clkdev.c:322:1: warning: ‘externally_visible’ attribute ignored [-Wattributes] drivers/clk/clkdev.c:322:161: error: storage class specified for parameter ‘__kcrctab_clkdev_alloc’ EXPORT_SYMBOL(clkdev_alloc); ^ drivers/clk/clkdev.c:322:1: warning: ‘__used__’ attribute ignored [-Wattributes] EXPORT_SYMBOL(clkdev_alloc); ^ drivers/clk/clkdev.c:322:161: error: section attribute not allowed for ‘__kcrctab_clkdev_alloc’ EXPORT_SYMBOL(clkdev_alloc); ^ drivers/clk/clkdev.c:322:279: error: expected ‘;’, ‘,’ or ‘)’ before ‘=’ token EXPORT_SYMBOL(clkdev_alloc); drivers/clk/clkdev.c:274:1: warning: ‘vclkdev_alloc’ defined but not used [-Wunused-function] vclkdev_alloc(struct clk *clk, const char *con_id, const char *dev_fmt, Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] adp1653: Add device tree bindings for LED controller
* Pali Rohár [141117 07:03]: > On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: > > > > There's nothing stopping us from initializing the camera code > > from pdata-quirks.c for now to keep it working. Certainly the > > binding should be added to the driver, but that removes a > > dependency to the legacy booting mode if things are otherwise > > working. > > Tony, legacy board code for n900 is not in mainline tree. And > that omap3 camera subsystem for n900 is broken since 3.5 > kernel... (both Front and Back camera on n900 show only green > picture). I'm still seeing the legacy board code for n900 in mainline tree :) It's deprecated, but still there. Are you maybe talking about some other piece of platform_data that's no longer in the mainline kernel? No idea what might be wrong with the camera though. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] adp1653: Add device tree bindings for LED controller
* Pavel Machek [141117 02:17]: > On Mon 2014-11-17 11:09:45, Pali Rohár wrote: > > On Monday 17 November 2014 11:05:19 Pavel Machek wrote: > > > Hi! > > > > > > On Mon 2014-11-17 09:43:19, Pali Rohár wrote: > > > > On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: > > > > > For device tree people: Yes, I know I'll have to create > > > > > file in documentation, but does the binding below look > > > > > acceptable? > > > > > > > > > > I'll clean up driver code a bit more, remove the printks. > > > > > Anything else obviously wrong? > > > > > > > > I think that this patch is probably not good and specially > > > > not for n900. adp1653 should be registered throw omap3 isp > > > > camera subsystem which does not have DT support yet. > > > > > > Can you explain? > > > > > > adp1653 is independend device on i2c bus, and we have kernel > > > driver for it (unlike rest of n900 camera system). Just now > > > it is unusable due to lack of DT binding. It has two > > > functions, LED light and a camera flash; yes, the second one > > > should be integrated to the rest of camera system, but that > > > is not yet merged. That should not prevent us from merging DT > > > support for the flash, so that this part can be > > > tested/maintained. > > > > > > > Ok. When ISP camera subsystem has DT support somebody will modify > > n900 DT to add camera flash from adp1653 to ISP... I believe it > > will not be hard. > > Exactly. And yes, I'd like to get complete camera support for n900 > merged. But first step is "make sure existing support does not break". There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/2] mach-omap2: remove deprecated VIDEO_OMAP2 support
* Hans Verkuil [141114 01:25]:
> From: Hans Verkuil
>
> The omap2 camera driver has been deprecated for a year and is now
> going to be removed. It is unmaintained and it uses an internal API
> that has long since been superseded by a much better API. Worse, that
> internal API has been abused by out-of-kernel trees (i.MX6).
>
> In addition, Sakari stated that these drivers have never been in a
> usable state in the mainline kernel due to missing platform data.
>
> Signed-off-by: Hans Verkuil
> Cc: Sakari Ailus
> Cc: David Cohen
This applies with fuzz to what I have queued but should not
cause merge conflicts and should be safe to merge along with
other camera related patches:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/devices.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 324f02b..1b623a0 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -101,28 +101,6 @@ static int __init omap4_l3_init(void)
> }
> omap_postcore_initcall(omap4_l3_init);
>
> -#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> -
> -static struct resource omap2cam_resources[] = {
> - {
> - .start = OMAP24XX_CAMERA_BASE,
> - .end= OMAP24XX_CAMERA_BASE + 0xfff,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 24 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - }
> -};
> -
> -static struct platform_device omap2cam_device = {
> - .name = "omap24xxcam",
> - .id = -1,
> - .num_resources = ARRAY_SIZE(omap2cam_resources),
> - .resource = omap2cam_resources,
> -};
> -#endif
> -
> #if defined(CONFIG_IOMMU_API)
>
> #include
> @@ -245,14 +223,6 @@ int omap3_init_camera(struct isp_platform_data *pdata)
>
> #endif
>
> -static inline void omap_init_camera(void)
> -{
> -#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> - if (cpu_is_omap24xx())
> - platform_device_register(&omap2cam_device);
> -#endif
> -}
> -
> #if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
> static inline void __init omap_init_mbox(void)
> {
> @@ -431,7 +401,6 @@ static int __init omap2_init_devices(void)
>* in alphabetical order so they're easier to sort through.
>*/
> omap_init_audio();
> - omap_init_camera();
> /* If dtb is there, the devices will be created dynamically */
> if (!of_have_populated_dt()) {
> omap_init_mbox();
> --
> 2.1.1
>
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/4] [media] si4713 DT binding
* Sebastian Reichel [141110 12:36]: > Hi, > > This is the third revision of the si4713 radio transmitter DT support > patchset needed for the Nokia N900. > > Changes since PATCHv2: > * Dropped patches 1-4, which have been accepted > * Patch 1 has been updated according to Sakari's comments > * Patch 3-4 are unchanged > > Apart from that you marked Patch 2 as not applicable last time [0]. > Normally the DT binding documentation is taken by the subsystem > maintainer together with the driver changes. You can see the details > in Documentation/devicetree/bindings/submitting-patches.txt > > For Patch 3 feedback from Tony is needed. I think the simplest solution > would be to merge it via the media tree (assuming, that the boardcode > is not yet removed in 3.19). Yes just acked it thanks. Tony > [0] https://patchwork.linuxtv.org/patch/26506/ > > -- Sebastian > > Sebastian Reichel (4): > [media] si4713: add device tree support > [media] si4713: add DT binding documentation > ARM: OMAP2: RX-51: update si4713 platform data > [media] si4713: cleanup platform data > > Documentation/devicetree/bindings/media/si4713.txt | 30 ++ > arch/arm/mach-omap2/board-rx51-peripherals.c | 69 > ++ > drivers/media/radio/si4713/radio-platform-si4713.c | 28 ++--- > drivers/media/radio/si4713/si4713.c| 31 +- > drivers/media/radio/si4713/si4713.h| 6 ++ > include/media/radio-si4713.h | 30 -- > include/media/si4713.h | 4 +- > 7 files changed, 103 insertions(+), 95 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/si4713.txt > delete mode 100644 include/media/radio-si4713.h > > -- > 2.1.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/4] ARM: OMAP2: RX-51: update si4713 platform data
* Sebastian Reichel [141110 12:37]:
> This updates platform data related to Si4713, which
> has been updated to be compatible with DT interface.
>
> Signed-off-by: Sebastian Reichel
Please feel free to merge this one along with the
other camera patches, this should not conflict with
anything in the linux-omap tree:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 69
> +---
> 1 file changed, 31 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index ddfc8df..ec2e410 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -38,7 +39,6 @@
>
> #include
> #include
> -#include
> #include
> #include
>
> @@ -760,46 +760,17 @@ static struct regulator_init_data rx51_vintdig = {
> },
> };
>
> -static const char * const si4713_supply_names[] = {
> - "vio",
> - "vdd",
> -};
> -
> -static struct si4713_platform_data rx51_si4713_i2c_data __initdata_or_module
> = {
> - .supplies = ARRAY_SIZE(si4713_supply_names),
> - .supply_names = si4713_supply_names,
> - .gpio_reset = RX51_FMTX_RESET_GPIO,
> -};
> -
> -static struct i2c_board_info rx51_si4713_board_info __initdata_or_module = {
> - I2C_BOARD_INFO("si4713", SI4713_I2C_ADDR_BUSEN_HIGH),
> - .platform_data = &rx51_si4713_i2c_data,
> -};
> -
> -static struct radio_si4713_platform_data rx51_si4713_data
> __initdata_or_module = {
> - .i2c_bus= 2,
> - .subdev_board_info = &rx51_si4713_board_info,
> -};
> -
> -static struct platform_device rx51_si4713_dev __initdata_or_module = {
> - .name = "radio-si4713",
> - .id = -1,
> - .dev= {
> - .platform_data = &rx51_si4713_data,
> +static struct gpiod_lookup_table rx51_fmtx_gpios_table = {
> + .dev_id = "2-0063",
> + .table = {
> + GPIO_LOOKUP("gpio.6", 3, "reset", GPIO_ACTIVE_HIGH), /* 163 */
> + { },
> },
> };
>
> -static __init void rx51_init_si4713(void)
> +static __init void rx51_gpio_init(void)
> {
> - int err;
> -
> - err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, "si4713 irq");
> - if (err) {
> - printk(KERN_ERR "Cannot request si4713 irq gpio. %d\n", err);
> - return;
> - }
> - rx51_si4713_board_info.irq = gpio_to_irq(RX51_FMTX_IRQ);
> - platform_device_register(&rx51_si4713_dev);
> + gpiod_add_lookup_table(&rx51_fmtx_gpios_table);
> }
>
> static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
> @@ -1029,7 +1000,17 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
> .gpio_reset = 60,
> };
>
> +static struct si4713_platform_data rx51_si4713_platform_data = {
> + .is_platform_device = true
> +};
> +
> static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[]
> = {
> +#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> + {
> + I2C_BOARD_INFO("si4713", 0x63),
> + .platform_data = &rx51_si4713_platform_data,
> + },
> +#endif
> {
> I2C_BOARD_INFO("tlv320aic3x", 0x18),
> .platform_data = &rx51_aic3x_data,
> @@ -1070,6 +1051,10 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_3[] = {
>
> static int __init rx51_i2c_init(void)
> {
> +#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> + int err;
> +#endif
> +
> if ((system_rev >= SYSTEM_REV_S_USES_VAUX3 && system_rev < 0x100) ||
> system_rev >= SYSTEM_REV_B_USES_VAUX3) {
> rx51_twldata.vaux3 = &rx51_vaux3_mmc;
> @@ -1087,6 +1072,14 @@ static int __init rx51_i2c_init(void)
> rx51_twldata.vdac->constraints.name = "VDAC";
>
> omap_pmic_init(1, 2200, "twl5030", 7 + OMAP_INTC_START, &rx51_twldata);
> +#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> + err = gpio_request_one(RX51_FMTX_IRQ, GPIOF_DIR_IN, "si4713 irq");
> + if (err) {
> + printk(KERN_ERR "Cannot request si4713 irq gpio. %d\n", err);
> + return err;
> + }
> + rx51
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
* Mauro Carvalho Chehab [140909 17:52]: > Em Tue, 09 Sep 2014 12:36:54 -0300 > Mauro Carvalho Chehab escreveu: > > > Em Tue, 9 Sep 2014 15:41:58 +0100 > > Russell King - ARM Linux escreveu: > > > > > On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: > > > > We want to be able to COMPILE_TEST the omap1_camera driver. > > > > It compiles fine, but it fails linkediting: > > > > > > > > ERROR: "omap_stop_dma" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_start_dma" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_dma_link_lch" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_set_dma_dest_burst_mode" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_set_dma_src_params" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_request_dma" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_set_dma_transfer_params" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_set_dma_dest_params" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > ERROR: "omap_free_dma" > > > > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! > > > > > > > > So, add some stub functions to avoid it. > > > > > > The real answer to this is to find someone who still uses it, and convert > > > it to the DMA engine API. If there's no users, the driver might as well > > > be killed off. > > > > Hmm... it seems that there are still several drivers still relying on > > the functions declared at: omap-dma.h: > > > > $ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if > > (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l > > arch/arm/mach-omap1/pm.c > > arch/arm/mach-omap2/pm24xx.c > > arch/arm/plat-omap/dma.c > > drivers/dma/omap-dma.c > > drivers/media/platform/omap/omap_vout_vrfb.c > > drivers/media/platform/omap3isp/isphist.c > > drivers/media/platform/soc_camera/omap1_camera.c > > drivers/mtd/onenand/omap2.c > > drivers/usb/gadget/udc/omap_udc.c > > drivers/usb/musb/tusb6010_omap.c > > drivers/video/fbdev/omap/omapfb_main.c > > include/linux/omap-dma.h > > > > Perhaps we can remove the header and mark all the above as BROKEN. No, not quite yet. That would currently cause major issues for omap2 and omap3. > > If nobody fixes, we can strip all of them from the Kernel. > > Are all the functions declared at omap-dma.h part of the > old DMA API that should be deprecated? For the drivers yes. For the platform code, there are few functions needed, that's at least omap_dma_global_context_save() and omap_dma_global_context_restore(). But those can be in a local header file in arch/arm/plat-omap/include/plat. > If so, it seems that the OMAP2 and OMAP3 also depends on this > thing, as all the PM code for OMAP depends on the functions > declared inside omap-dma.h, and marking them as BROKEN > causes compilation to failure: > > arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents': > :(.text+0x798): undefined reference to `omap3_restore_3630' > :(.text+0x7a8): undefined reference to `omap3_restore' > :(.text+0x7ac): undefined reference to `omap3_restore_es3' > arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context': > :(.text+0x925c): undefined reference to `omap_push_sram_idle' > arch/arm/mach-omap2/built-in.o: In function `option_set': > :(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable' > arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set': > :(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state' > arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get': > :(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state' > arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm': > :(.text+0xc7ec): undefined reference to `omap_sram_idle' > :(.text+0xc848): undefined reference to `pm34xx_errata' > arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late': > :(.init.text+0xf64): undefined reference to `omap2_pm_init' > arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late': > :(.init.text+0x1024): undefined reference to `omap2_pm_init' > arch/arm/mach-omap2/built-in.o: In function `omap3_init_late': > :(.init.text+0x1248): undefined reference to `omap3_pm_init' > arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late': > :(.init.text+0x1264): undefined reference to `omap3_pm_init' > arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late': > :(.init.text+0x1280): undefined reference to `omap3_pm_init' > arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late': > :(.init.text+0x129c): undefined reference to `omap3_pm_init' > arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late': > :(.init.text+0x12b8): undefined
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
* Nishanth Menon [140909 07:40]:
> +linux-omap, tony
> -Balaji
>
> On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
> > We want to be able to COMPILE_TEST the omap1_camera driver.
> > It compiles fine, but it fails linkediting:
> >
> > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko]
> > undefined!
> > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko]
> > undefined!
> > ERROR: "omap_dma_link_lch"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_burst_mode"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_src_params"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_request_dma"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_transfer_params"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_params"
> > [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko]
> > undefined!
> >
> > So, add some stub functions to avoid it.
How about just remove that old driver? I doubt it works, and I'm
almost certain nobody has actually tried to use it for many
years. At least I'm not aware of any hardware supported in the
mainline kernel with it. And we're moving things to dma engine
API anyways.
Regards,
Tony
> > Reported-by: Stephen Rothwell
> > Signed-off-by: Mauro Carvalho Chehab
> >
> > diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> > index 6f06f8bc612c..7c8bfdd90a33 100644
> > --- a/include/linux/omap-dma.h
> > +++ b/include/linux/omap-dma.h
> > @@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
> > extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
> >
> > extern void omap_set_dma_priority(int lch, int dst_port, int priority);
> > -extern int omap_request_dma(int dev_id, const char *dev_name,
> > - void (*callback)(int lch, u16 ch_status, void *data),
> > - void *data, int *dma_ch);
> > extern void omap_enable_dma_irq(int ch, u16 irq_bits);
> > extern void omap_disable_dma_irq(int ch, u16 irq_bits);
> > -extern void omap_free_dma(int ch);
> > -extern void omap_start_dma(int lch);
> > -extern void omap_stop_dma(int lch);
> > -extern void omap_set_dma_transfer_params(int lch, int data_type,
> > -int elem_count, int frame_count,
> > -int sync_mode,
> > -int dma_trigger, int src_or_dst_synch);
> > extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
> > u32 color);
> > extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode
> > mode);
> > extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
> > mode);
> >
> > -extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> > - unsigned long src_start,
> > - int src_ei, int src_fi);
> > extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
> > extern void omap_set_dma_src_data_pack(int lch, int enable);
> > extern void omap_set_dma_src_burst_mode(int lch,
> > enum omap_dma_burst_mode burst_mode);
> >
> > -extern void omap_set_dma_dest_params(int lch, int dest_port, int
> > dest_amode,
> > -unsigned long dest_start,
> > -int dst_ei, int dst_fi);
> > extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
> > extern void omap_set_dma_dest_data_pack(int lch, int enable);
> > -extern void omap_set_dma_dest_burst_mode(int lch,
> > -enum omap_dma_burst_mode burst_mode);
> >
> > extern void omap_set_dma_params(int lch,
> > struct omap_dma_channel_params *params);
> >
> > -extern void omap_dma_link_lch(int lch_head, int lch_queue);
> > extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
> >
> > extern int omap_set_dma_callback(int lch,
> > @@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
> >
> > /* Chaining APIs */
> > #ifndef CONFIG_ARCH_OMAP1
> > -extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> > - void (*callback) (int lch, u16 ch_status,
> > - void *data),
> > - int *chain_id, int no_of_chans,
> > - int chain_mode,
> > - struct omap_dma_channel_params params);
> > -extern int omap_free_dma_chain(int chain_id);
> > extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
> > int dest_start, int elem_count,
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140613 03:30]:
> Hi Tony,
>
> On Friday 13 June 2014 00:53:25 Tony Lindgren wrote:
> > * Laurent Pinchart [140612 23:48]:
> > > On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote:
> > > > 1. They live in separate hardware modules that can be clocked separately
> > >
> > > Actually I don't think that's true. The CSI2 PHY is part of the camera
> > > device, with all its registers but the one above in the camera device
> > > register space. For some weird reason a couple of bits were pushed to the
> > > control module, but that doesn't make the CSI2 PHY itself a separate
> > > device.
> >
> > Yes they are separate. Anything in the system control module is
> > a separate hardware module from the other devices. So in this case
> > the CSI2 PHY is part of the system control module, not the camera
> > module.
>
> Section 8.2.3 ("ISS CSI2 PHY") of the OMAP4460 TRM (revision AA) documents
> the
> CSI2 PHY is being part of the ISS, with three PHY registers in the ISS
> register space (not counting the PHY interrupt and status bits in several
> other ISS registers) and one register in the system control module register
> space. It's far from clear which power domain(s) is (are) involved.
OK I see. The register in the system control module just contains some
pin and clock related resources for the phy.
> > > > 2. Doing a read-back to flush a posted write in one hardware module most
> > > >likely won't flush the write to other and that can lead into hard to
> > > >find mysterious bugs
> > >
> > > The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ?
> >
> > Right, but you would have to do readbacks both from the phy register and
> > camera register to ensure writes get written. It's best to keep the
> > logic completely separate especially considering that they can be
> > clocked separately.
> >
> > > > 3. If we ever have a common system control module driver, we need to
> > > >rewrite all the system control module register tinkering in the
> > > >drivers
> > >
> > > Sure, but that's already the case today, as the OMAP4 ISS driver already
> > > accesses the control module register directly. I won't make that worse :-)
> >
> > Well it's in staging for a reason :)
> >
> > > > So it's best to try to use an existing framework for it. That avoids
> > > > tons of pain later on ;)
> > >
> > > I agree, but I don't think the PHY framework would be the right
> > > abstraction. As explained above the CSI2 PHY is part of the OMAP4 ISS, so
> > > modeling its single control module register as a PHY would be a hack.
> >
> > Well that register belongs to the system control module, not the
> > camera module. It's not like the camera IO space is out of registers
> > or something! :)
>
> The PHY has 3 registers in the ISS I/O space and one register in the control
> module I/O space. I have no idea why they've split it that way. The clock
> enable bits are especially "interested", the source clock (CAM_PHY_CTRL_FCLK)
> comes from the ISS as documented in section 8.1.1 ("ISS Integration"), is
> gated by the control module (the gated clock is called CTRLCLK) and then goes
> back to the ISS CSI2 PHY (it's mentioned in the CSI2 PHY "REGISTER1"
> documentation).
>
> > We're already handling similar control module phy cases, see for
> > example drivers/phy/phy-omap-control.c. Maybe you have most of the
> > code already there?
>
> I'm afraid not. For PHYs that are in the system control module that solution
> is perfectly fine, but the CSI2 PHY isn't (or at least not all of it).
>
> I would be fine with writing a separate PHY driver if the PHY was completely
> separate. As the documentation doesn't make it clear which part of the
> hardware belongs to which module, matching the software implementation with
> an
> unknown hardware implementation would be pretty difficult :-)
Yeah it seems the phy driver would still have to use the pin resources
in the system control module.
> If you have a couple of minutes to spare and can look at the CSI2 PHY
> documentation in the TRM, you might be more successful than me figuring out
> how the hardware is implemented.
Took a look and it seems the phy is split into two parts. So probably
using the syscon mapping for the register in scm are is a good start.
At least then there's some protection from drivers tinkering directly
with the system control modules.
Maybe s ee what drivers/regulator/pbias-regulator.c is doing with
syscon to see if that works? Moving that to some phy driver later on
should be trivial if needed :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140612 23:48]: > On Thursday 12 June 2014 22:30:44 Tony Lindgren wrote: > > > > 1. They live in separate hardware modules that can be clocked separately > > Actually I don't think that's true. The CSI2 PHY is part of the camera > device, > with all its registers but the one above in the camera device register space. > For some weird reason a couple of bits were pushed to the control module, but > that doesn't make the CSI2 PHY itself a separate device. Yes they are separate. Anything in the system control module is a separate hardware module from the other devices. So in this case the CSI2 PHY is part of the system control module, not the camera module. > > 2. Doing a read-back to flush a posted write in one hardware module most > >likely won't flush the write to other and that can lead into hard to > >find mysterious bugs > > The OMAP4 ISS driver can just read back the CAMERA_RX register, can't it ? Right, but you would have to do readbacks both from the phy register and camera register to ensure writes get written. It's best to keep the logic completely separate especially considering that they can be clocked separately. > > 3. If we ever have a common system control module driver, we need to > >rewrite all the system control module register tinkering in the drivers > > Sure, but that's already the case today, as the OMAP4 ISS driver already > accesses the control module register directly. I won't make that worse :-) Well it's in staging for a reason :) > > So it's best to try to use an existing framework for it. That avoids tons of > > pain later on ;) > > I agree, but I don't think the PHY framework would be the right abstraction. > As explained above the CSI2 PHY is part of the OMAP4 ISS, so modeling its > single control module register as a PHY would be a hack. Well that register belongs to the system control module, not the camera module. It's not like the camera IO space is out of registers or something! :) We're already handling similar control module phy cases, see for example drivers/phy/phy-omap-control.c. Maybe you have most of the code already there? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140612 08:32]: > Hi Tony, > > On Thursday 12 June 2014 08:15:35 Tony Lindgren wrote: > > * Laurent Pinchart [140612 07:52]: > > > On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > > > > These should just use either pinctrl-single.c instead for muxing. > > > > Or if they are not mux registers, we do have the syscon mapping > > > > available in omap4.dtsi that pbias-regulator.c is already using. > > > > > > > > Laurent, got any better ideas? > > > > > > The ISS driver needs to write a single register, which contains several > > > independent fields. They thus need to be controlled by a single driver. > > > Some of them might be considered to be related to pinmuxing (although I > > > disagree on that), others are certainly not about muxing (there are clock > > > gate bits for instance). > > > > > > Using the syscon mapping seems like the best option. I'll give it a try. > > > > OK if it's not strictly pinctrl related then let's not use > > pinctrl-single,bits for it. You may be able to implement one or more > > framework drivers for it for pinctrl/regulator/clock/transceiver > > whatever that register is doing. > > > > In any case it's best to have that handling in a separate helper driver > > somewhere as it's a separate piece of hardware from the camera module. > > If it does not fit into any existing frameworks then it's best to have > > it in a separate driver with the camera driver. > > The register contains the following fields that control the two CSI2 PHYs > (PHY1 and PHY2). > > 31CAMERARX_CSI22_LANEENABLE2 PHY2 Lane 2 (CSI22_DX2, CSI22_DY2) Enable > 30CAMERARX_CSI22_LANEENABLE1 PHY2 Lane 1 (CSI22_DX1, CSI22_DY1) Enable > 29CAMERARX_CSI22_LANEENABLE0 PHY2 Lane 0 (CSI22_DX0, CSI22_DY0) Enable > 28CAMERARX_CSI21_LANEENABLE4 PHY1 Lane 4 (CSI21_DX4, CSI21_DY4) Enable > 27CAMERARX_CSI21_LANEENABLE3 PHY1 Lane 3 (CSI21_DX3, CSI21_DY3) Enable > 26CAMERARX_CSI21_LANEENABLE2 PHY1 Lane 2 (CSI21_DX2, CSI21_DY2) Enable > 25CAMERARX_CSI21_LANEENABLE1 PHY1 Lane 1 (CSI21_DX1, CSI21_DY1) Enable > 24CAMERARX_CSI21_LANEENABLE0 PHY1 Lane 0 (CSI21_DX0, CSI21_DY0) Enable > 21CAMERARX_CSI22_CTRLCLKEN PHY2 Clock Enable > 20:19 CAMERARX_CSI22_CAMMODE PHY2 Mode (CCP2, CSI1, CSI2) > 18CAMERARX_CSI21_CTRLCLKEN PHY1 Clock Enable > 17:16 CAMERARX_CSI21_CAMMODE PHY1 Mode (CCP2, CSI1, CSI2) > > Bits 18 and 21 could be exposed through CCF. Bits 24 to 31 enable/disable the > CSI2 lanes, so it could be argued that they could be exposed through the > pinctrl framework. However, they need to be configured independently, > possibly > at runtime. I'm thus not sure pinctrl would be a good idea. Bits 17:16 and > 20:19 don't fit in existing frameworks. OK thanks for the info. Sounds like drivers/phy might be the right location for it then and then the phy driver can use the syscon regmap. > Given that this register is specific to the ISS, I think handling it as a > separate device through a separate driver would only complicate the > implementation without any real benefit. Even though it's one register, it shoud still be treated separately from the camera driver. The problems with keeping the register access to the control module in the camera driver are at least following: 1. They live in separate hardware modules that can be clocked separately 2. Doing a read-back to flush a posted write in one hardware module most likely won't flush the write to other and that can lead into hard to find mysterious bugs 3. If we ever have a common system control module driver, we need to rewrite all the system control module register tinkering in the drivers So it's best to try to use an existing framework for it. That avoids tons of pain later on ;) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Laurent Pinchart [140612 07:52]: > On Wednesday 11 June 2014 07:47:54 Tony Lindgren wrote: > > > > These should just use either pinctrl-single.c instead for muxing. > > Or if they are not mux registers, we do have the syscon mapping > > available in omap4.dtsi that pbias-regulator.c is already using. > > > > Laurent, got any better ideas? > > The ISS driver needs to write a single register, which contains several > independent fields. They thus need to be controlled by a single driver. Some > of them might be considered to be related to pinmuxing (although I disagree > on > that), others are certainly not about muxing (there are clock gate bits for > instance). > > Using the syscon mapping seems like the best option. I'll give it a try. OK if it's not strictly pinctrl related then let's not use pinctrl-single,bits for it. You may be able to implement one or more framework drivers for it for pinctrl/regulator/clock/transceiver whatever that register is doing. In any case it's best to have that handling in a separate helper driver somewhere as it's a separate piece of hardware from the camera module. If it does not fit into any existing frameworks then it's best to have it in a separate driver with the camera driver. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Arnd Bergmann [140611 07:51]:
> On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
> > On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
> > > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> > > of which can be loadable modules. This causes build failures
> > > if we want the camera driver to be built-in.
> > >
> > > This can be solved by turning the option into "tristate",
> > > which unfortunately causes another problem, because the
> > > driver incorrectly calls a platform-internal interface
> > > for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
> > > To work around that, we can export those symbols, but
> > > that isn't really the correct solution, as we should not
> > > have dependencies on platform code this way.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > ---
> > > This is one of just two patches we currently need to get
> > > 'make allmodconfig' to build again on ARM.
> > >
> > > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> > > index 751f354..05d2d98 100644
> > > --- a/arch/arm/mach-omap2/control.c
> > > +++ b/arch/arm/mach-omap2/control.c
> > > @@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
> > > {
> > > return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
> > > }
> > > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
> > >
> > > void omap4_ctrl_pad_writel(u32 val, u16 offset)
> > > {
> > > writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
> > > }
> > > +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
> > >
> > > #ifdef CONFIG_ARCH_OMAP3
> > >
> > > diff --git a/drivers/staging/media/omap4iss/Kconfig
> > > b/drivers/staging/media/omap4iss/Kconfig
> > > index 78b0fba..0c3e3c1 100644
> > > --- a/drivers/staging/media/omap4iss/Kconfig
> > > +++ b/drivers/staging/media/omap4iss/Kconfig
> > > @@ -1,5 +1,5 @@
> > > config VIDEO_OMAP4
> > > - bool "OMAP 4 Camera support"
> > > + tristate "OMAP 4 Camera support"
> > > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> > > select VIDEOBUF2_DMA_CONTIG
> > > ---help---
> > >
> >
> > This was discussed in detail here:
> > http://marc.info/?t=14019869251&r=1&w=2
> > Direct dependency from a staging driver to mach-omap2 driver is not
> > something we'd like, right?
>
> So it was decided to just leave ARM allmodconfig broken?
>
> Why not at least do this instead?
>
> 8<
> From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann
> Date: Tue, 21 Jan 2014 09:32:43 +0100
> Subject: [PATCH] [media] staging: tighten omap4iss dependencies
>
> The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> of which can be loadable modules. This causes build failures
> if we want the camera driver to be built-in.
>
> This can be solved by turning the option into "tristate",
> which unfortunately causes another problem, because the
> driver incorrectly calls a platform-internal interface
> for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
>
> Instead, this patch just forbids the invalid configurations
> and ensures that the driver can only be built if all its
> dependencies are built-in.
Makes sense to me if the media people are OK with this:
Acked-by: Tony Lindgren
> Signed-off-by: Arnd Bergmann
>
> diff --git a/drivers/staging/media/omap4iss/Kconfig
> b/drivers/staging/media/omap4iss/Kconfig
> index 78b0fba..8afc6fe 100644
> --- a/drivers/staging/media/omap4iss/Kconfig
> +++ b/drivers/staging/media/omap4iss/Kconfig
> @@ -1,6 +1,6 @@
> config VIDEO_OMAP4
> bool "OMAP 4 Camera support"
> - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> + depends on VIDEO_V4L2=y && VIDEO_V4L2_SUBDEV_API && I2C=y && ARCH_OMAP4
> select VIDEOBUF2_DMA_CONTIG
> ---help---
> Driver for an OMAP 4 ISS controller.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] staging: allow omap4iss to be modular
* Arnd Bergmann [140611 07:37]:
> The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> of which can be loadable modules. This causes build failures
> if we want the camera driver to be built-in.
That's good news, but let's not fix it this way.
> This can be solved by turning the option into "tristate",
> which unfortunately causes another problem, because the
> driver incorrectly calls a platform-internal interface
> for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
> To work around that, we can export those symbols, but
> that isn't really the correct solution, as we should not
> have dependencies on platform code this way.
>
> Signed-off-by: Arnd Bergmann
> ---
> This is one of just two patches we currently need to get
> 'make allmodconfig' to build again on ARM.
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index 751f354..05d2d98 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
> {
> return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
> }
> +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
>
> void omap4_ctrl_pad_writel(u32 val, u16 offset)
> {
> writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
> }
> +EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
>
> #ifdef CONFIG_ARCH_OMAP3
Exporting these will likely cause immediate misuse in other
drivers all over the place.
These should just use either pinctrl-single.c instead for muxing.
Or if they are not mux registers, we do have the syscon mapping
available in omap4.dtsi that pbias-regulator.c is already using.
Laurent, got any better ideas?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
* Laurent Pinchart [140218 07:05]: > Hi Igor, > > On Tuesday 18 February 2014 16:03:44 Igor Grinberg wrote: > > On 02/18/14 14:47, Laurent Pinchart wrote: > > > On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote: > > >> The camera sensor will soon require regulators and clocks. Register > > >> fixed regulators for its VAA and VDD power supplies and a fixed rate > > >> clock for its master clock. > > > > > > This patch is a prerequisite for a set of 4 patches that need to go > > > through the linux-media tree. It would simpler if it could go through the > > > same tree as well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen > > > very little activity recently I believe the risk of conflict is pretty > > > low. > > > > Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped > > updating the board-cm-t35.c file. > > DT support for the OMAP3 ISP is coming. Too slowly, but it's coming :-) > > > > Tony, would > > > that be fine with you ? > > > > > >> Signed-off-by: Laurent Pinchart > > > > Acked-by: Igor Grinberg > > Thank you. Tony, could I get your ack as well to push this through Mauro's > tree ? Sure, the board-*.c files will get removed soonish, but meanwhile: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] ARM: dts: omap: update usb_otg_hs data
* Kishon Vijay Abraham I [130717 23:53]:
> Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
> binding in order for the driver to use the new generic PHY framework.
> Also updated the Documentation to include the binding information.
> The PHY binding information can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Signed-off-by: Kishon Vijay Abraham I
> Acked-by: Felipe Balbi
> Reviewed-by: Sylwester Nawrocki
In general the .dts changes should be separate to avoid pointless
merge conflicts. But sounds like things will stop working for
USB unless we do it like this so:
Acked-by: Tony Lindgren
> ---
> Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
> Documentation/devicetree/bindings/usb/usb-phy.txt |6 ++
> arch/arm/boot/dts/omap3-beagle-xm.dts |2 ++
> arch/arm/boot/dts/omap3-evm.dts|2 ++
> arch/arm/boot/dts/omap3-overo.dtsi |2 ++
> arch/arm/boot/dts/omap4.dtsi |3 +++
> arch/arm/boot/dts/twl4030.dtsi |1 +
> 7 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 57e71f6..825790d 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -19,6 +19,9 @@ OMAP MUSB GLUE
> - power : Should be "50". This signifies the controller can supply up to
> 100mA when operating in host mode.
> - usb-phy : the phandle for the PHY device
> + - phys : the phandle for the PHY device (used by generic PHY framework)
> + - phy-names : the names of the PHY corresponding to the PHYs present in the
> + *phy* phandle.
>
> Optional properties:
> - ctrl-module : phandle of the control module this glue uses to write to
> @@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
> num-eps = <16>;
> ram-bits = <12>;
> ctrl-module = <&omap_control_usb>;
> + phys = <&usb2_phy>;
> + phy-names = "usb2-phy";
> };
>
> Board specific device node entry
> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
> b/Documentation/devicetree/bindings/usb/usb-phy.txt
> index 61496f5..c0245c8 100644
> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> @@ -5,6 +5,8 @@ OMAP USB2 PHY
> Required properties:
> - compatible: Should be "ti,omap-usb2"
> - reg : Address and length of the register set for the device.
> + - #phy-cells: determine the number of cells that should be given in the
> + phandle while referencing this phy.
>
> Optional properties:
> - ctrl-module : phandle of the control module used by PHY driver to power on
> @@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
> compatible = "ti,omap-usb2";
> reg = <0x4a0ad080 0x58>;
> ctrl-module = <&omap_control_usb>;
> + #phy-cells = <0>;
> };
>
> OMAP USB3 PHY
> @@ -25,6 +28,8 @@ Required properties:
> - reg : Address and length of the register set for the device.
> - reg-names: The names of the register addresses corresponding to the
> registers
> filled in "reg".
> + - #phy-cells: determine the number of cells that should be given in the
> + phandle while referencing this phy.
>
> Optional properties:
> - ctrl-module : phandle of the control module used by PHY driver to power on
> @@ -39,4 +44,5 @@ usb3phy@4a084400 {
> <0x4a084c00 0x40>;
> reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> ctrl-module = <&omap_control_usb>;
> + #phy-cells = <0>;
> };
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index afdb164..533b2da 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -144,6 +144,8 @@
> &usb_otg_hs {
> interface-type = <0>;
> usb-phy = <&usb2_phy>;
> + phys = <&usb2_phy>;
> + phy-names = "usb2-phy";
> mode = <3>;
> power = <50>;
> };
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 7d4329d..4134dd0 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -70,6 +70,8 @@
> &usb_otg_hs {
> interface-type = <0>;
> usb-phy = <&usb2_phy>;
> + phys = <&usb2_phy>;
> + phy-names = &qu
Re: [PATCH 04/15] ARM: OMAP: USB: Add phy binding information
* Kishon Vijay Abraham I [130717 23:53]:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy device name) should be added in the platform
> data of the controller.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Sylwester Nawrocki
> Acked-by: Felipe Balbi
> ---
> arch/arm/mach-omap2/usb-musb.c |3 +++
> include/linux/usb/musb.h |3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 8c4de27..6aa7cbf 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data
> *musb_board_data)
> musb_plat.mode = board_data->mode;
> musb_plat.extvbus = board_data->extvbus;
>
> + if (cpu_is_omap34xx())
> + musb_plat.phy_label = "twl4030";
> +
> if (soc_is_am35xx()) {
> oh_name = "am35x_otg_hs";
> name = "musb-am35x";
I don't think there's a USB PHY on non-twl4030 chips, so this should
be OK:
Acked-by: Tony Lindgren
> diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
> index 053c268..596f8c8 100644
> --- a/include/linux/usb/musb.h
> +++ b/include/linux/usb/musb.h
> @@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
> /* for clk_get() */
> const char *clock;
>
> + /* phy label */
> + const char *phy_label;
> +
> /* (HOST or OTG) switch VBUS on/off */
> int (*set_vbus)(struct device *dev, int is_on);
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] ir: IR_RX51 only works on OMAP2
* Timo Kokkonen [130314 23:43]: > On 03.14 2013 22:56:44, Arnd Bergmann wrote: > > This driver can be enabled on OMAP1 at the moment, which breaks > > allyesconfig for that platform. Let's mark it OMAP2PLUS-only > > in Kconfig, since that is the only thing it builds on. > > > > Acked-by: Timo Kokkonen Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] [media] ir-rx51: fix clock API related build issues
* Timo Kokkonen [130305 22:26]: > On 03.05 2013 17:09:53, Tony Lindgren wrote: > > * Mauro Carvalho Chehab [130305 16:28]: > > > Em Tue, 5 Mar 2013 23:16:46 +0100 > > > Arnd Bergmann escreveu: > > > > > > > OMAP1 no longer provides its own clock interfaces since patch > > > > a135eaae52 "ARM: OMAP: remove plat/clock.h". This is great, but > > > > we now have to convert the ir-rx51 driver to use the generic > > > > interface from linux/clk.h. > > > > > > > > The driver also uses the omap_dm_timer_get_fclk() function, > > > > which is not exported for OMAP1, so we have to move the > > > > definition out of the OMAP2 specific section. > > > > > > > > Signed-off-by: Arnd Bergmann > > > > Cc: Mauro Carvalho Chehab > > > > > > From my side: > > > Acked-by: Mauro Carvalho Chehab > > > > There's just one issue, this driver most likely only needed on > > rx51 board.. So I suggest we just mark the driver depends on > > ARCH_OMAP2PLUS and let's drop this patch. > > > > This driver is already disabled for ARCH_MULTIPLATFORM > > as we need to move dmtimer.c to drivers and have some minimal > > include/linux/timer-omap.h for it. > > > > I've also had this cunning plan that if or when the PWM subsystem > starts supporting the PWM output in OMAP3, I could convert this driver > to generate the IR carrier wave through the PWM subsystem and then use > HR timers to generate the pulses. I think that's much better approach > than trying to depend on interfaces that are not easily > available. Should be possible, but I haven't proven yet that it will > work :) Sounds good to me. > Unfortunately I haven't got into executing on that plan yet. In > addition to the challenge of scheduling some of my free time for doing > this, my RX51 device is not enumerating the USB with the latest kernel > and I haven't figured out that yet. And because of that, I haven't > been able to get my user space running over nfsroot setup I've been > using.. Git bisect might help there. Maybe post the output and cc the usb people? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] [media] ir-rx51: fix clock API related build issues
* Mauro Carvalho Chehab [130305 16:28]:
> Em Tue, 5 Mar 2013 23:16:46 +0100
> Arnd Bergmann escreveu:
>
> > OMAP1 no longer provides its own clock interfaces since patch
> > a135eaae52 "ARM: OMAP: remove plat/clock.h". This is great, but
> > we now have to convert the ir-rx51 driver to use the generic
> > interface from linux/clk.h.
> >
> > The driver also uses the omap_dm_timer_get_fclk() function,
> > which is not exported for OMAP1, so we have to move the
> > definition out of the OMAP2 specific section.
> >
> > Signed-off-by: Arnd Bergmann
> > Cc: Mauro Carvalho Chehab
>
> From my side:
> Acked-by: Mauro Carvalho Chehab
There's just one issue, this driver most likely only needed on
rx51 board.. So I suggest we just mark the driver depends on
ARCH_OMAP2PLUS and let's drop this patch.
This driver is already disabled for ARCH_MULTIPLATFORM
as we need to move dmtimer.c to drivers and have some minimal
include/linux/timer-omap.h for it.
> > --- a/arch/arm/plat-omap/dmtimer.c
> > +++ b/arch/arm/plat-omap/dmtimer.c
> > @@ -333,6 +333,14 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
> > }
> > EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
> >
> > +struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > +{
> > + if (timer)
> > + return timer->fclk;
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > +
> > #if defined(CONFIG_ARCH_OMAP1)
> > #include
> > /**
> > @@ -371,14 +379,6 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
> >
> > #else
> >
> > -struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > -{
> > - if (timer)
> > - return timer->fclk;
> > - return NULL;
> > -}
> > -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > -
> > __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
> > {
> > BUG();
Then omap_dm_timer_get_fclk() won't work on omap1 as there's no
separate functional clock. We probably should not even export
this function eventually when things are fixed up.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
* Laurent Pinchart [130121 05:37]: > Hi Mike, > > On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > > > Hello, > > > > > > Now that the OMAP3 supports the common clock framework, clock rate > > > back-propagation is available for the ISP clocks. Instead of setting the > > > cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark > > > the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > > back-propagation, and set the cam_mclk rate directly. This simplifies the > > > ISP clocks configuration. > > > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > > a negative diffstat :) > > > > Reviewed-by: Mike Turquette > > Thanks. > > Would you like to take the arch/ patch in your tree, or should I push it > through the linux-media tree along with the omap3isp patch ? The arch/arm/*omap* clock changes need to be queued by Paul to avoid potential stupid merge conflicts when the clock data gets moved to live under drivers/clk/omap. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: Don't include
* Laurent Pinchart [130103 13:24]: > The plat/*.h headers are not available to drivers in multiplatform > kernels. As the header isn't needed, just remove it. Please consider merging this for the -rc cycle, so I can make plat/cpu.h produce an error for omap2+ to prevent new drivers including it. Acked-by: Tony Lindgren > Signed-off-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/isp.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c > index 50cea08..07eea5b 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -71,8 +71,6 @@ > #include > #include > > -#include > - > #include "isp.h" > #include "ispreg.h" > #include "ispccdc.h" > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/7] ir-rx51: Handle signals properly
* Timo Kokkonen [121214 11:33]: > On 12/14/12 19:26, Felipe Balbi wrote: > > > > if it's really for PWM, shouldn't we be using drivers/pwm/ ?? > > > > Now that Neil Brown posted the PWM driver for omap, I've been thinking > about whether converting the ir-rx51 into the PWM API would work. Maybe > controlling the PWM itself would be sufficient, but the ir-rx51 uses > also another dmtimer for creating accurate (enough) timing source for > the IR pulse edges. OK. > I haven't tried whether the default 32kHz clock source is enough for > that. Now that I think about it, I don't see why it wouldn't be good > enough. I think it would even be possible to just use the PWM api alone Cool. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/7] ir-rx51: Handle signals properly
* Felipe Balbi [121214 09:59]: > On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote: > > * Felipe Balbi [121214 09:36]: > > > > > > if it's really for PWM, shouldn't we be using drivers/pwm/ ?? > > > > > > Meaning that $SUBJECT would just request a PWM device and use it. That > > > doesn't solve the whole problem, however, as pwm-omap.c would still need > > > access to timer-omap.h. > > > > That would only help with omap_dm_timer_set_pwm() I think. > > > > The other functions are also needed by the clocksource and clockevent > > drivers. And tidspbridge too: > > well, we _do_ have drivers/clocksource ;-) That's where the dmtimer code should live. But still it does not help with the header. Thomas, maybe we could use the hrtimer framework for it if there was some way to completely leave out the rb tree for the dedicated hardware timers? There's no queue needed as there's always just one value tied to a specific timer. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/7] ir-rx51: Handle signals properly
* Felipe Balbi [121214 09:36]:
> Hi,
>
> On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren [121120 12:00]:
> > > Hi,
> > >
> > > * Timo Kokkonen [121118 07:15]:
> > > > --- a/drivers/media/rc/ir-rx51.c
> > > > +++ b/drivers/media/rc/ir-rx51.c
> > > > @@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51
> > > > *lirc_rx51)
> > > > OMAP_TIMER_TRIGGER_NONE);
> > > > }
> > > >
> > > > +static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
> > > > +{
> > > > + if (lirc_rx51->wbuf_index < 0)
> > > > + return;
> > > > +
> > > > + lirc_rx51_off(lirc_rx51);
> > > > + lirc_rx51->wbuf_index = -1;
> > > > + omap_dm_timer_stop(lirc_rx51->pwm_timer);
> > > > + omap_dm_timer_stop(lirc_rx51->pulse_timer);
> > > > + omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
> > > > + wake_up(&lirc_rx51->wqueue);
> > > > +}
> > > > +
> > > > static int init_timing_params(struct lirc_rx51 *lirc_rx51)
> > > > {
> > > > u32 load, match;
> > >
> > > Good fixes in general.. But you won't be able to access the
> > > omap_dm_timer functions after we enable ARM multiplatform support
> > > for omap2+. That's for v3.9 probably right after v3.8-rc1.
> > >
> > > We need to find some Linux generic API to use hardware timers
> > > like this, so I've added Thomas Gleixner and linux-arm-kernel
> > > mailing list to cc.
> > >
> > > If no such API is available, then maybe we can export some of
> > > the omap_dm_timer functions if Thomas is OK with that.
> >
> > Just to update the status on this.. It seems that we'll be moving
> > parts of plat/dmtimer into a minimal include/linux/timer-omap.h
> > unless people have better ideas on what to do with custom
> > hardware timers for PWM etc.
>
> if it's really for PWM, shouldn't we be using drivers/pwm/ ??
>
> Meaning that $SUBJECT would just request a PWM device and use it. That
> doesn't solve the whole problem, however, as pwm-omap.c would still need
> access to timer-omap.h.
That would only help with omap_dm_timer_set_pwm() I think.
The other functions are also needed by the clocksource and clockevent
drivers. And tidspbridge too:
$ grep -r omap_dm_timer drivers/
...
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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/7] ir-rx51: Handle signals properly
* Tony Lindgren [121120 12:00]:
> Hi,
>
> * Timo Kokkonen [121118 07:15]:
> > --- a/drivers/media/rc/ir-rx51.c
> > +++ b/drivers/media/rc/ir-rx51.c
> > @@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
> > OMAP_TIMER_TRIGGER_NONE);
> > }
> >
> > +static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
> > +{
> > + if (lirc_rx51->wbuf_index < 0)
> > + return;
> > +
> > + lirc_rx51_off(lirc_rx51);
> > + lirc_rx51->wbuf_index = -1;
> > + omap_dm_timer_stop(lirc_rx51->pwm_timer);
> > + omap_dm_timer_stop(lirc_rx51->pulse_timer);
> > + omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
> > + wake_up(&lirc_rx51->wqueue);
> > +}
> > +
> > static int init_timing_params(struct lirc_rx51 *lirc_rx51)
> > {
> > u32 load, match;
>
> Good fixes in general.. But you won't be able to access the
> omap_dm_timer functions after we enable ARM multiplatform support
> for omap2+. That's for v3.9 probably right after v3.8-rc1.
>
> We need to find some Linux generic API to use hardware timers
> like this, so I've added Thomas Gleixner and linux-arm-kernel
> mailing list to cc.
>
> If no such API is available, then maybe we can export some of
> the omap_dm_timer functions if Thomas is OK with that.
Just to update the status on this.. It seems that we'll be moving
parts of plat/dmtimer into a minimal include/linux/timer-omap.h
unless people have better ideas on what to do with custom
hardware timers for PWM etc.
> The other alternative is to set them up as platform_data
> function pointers, but that won't work after we make omap2+
> device tree only. And that really just postpones the problem.
>
> Cheers,
>
> Tony
>
>
> > @@ -163,13 +176,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int
> > irq, void *ptr)
> >
> > return IRQ_HANDLED;
> > end:
> > - /* Stop TX here */
> > - lirc_rx51_off(lirc_rx51);
> > - lirc_rx51->wbuf_index = -1;
> > - omap_dm_timer_stop(lirc_rx51->pwm_timer);
> > - omap_dm_timer_stop(lirc_rx51->pulse_timer);
> > - omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
> > - wake_up_interruptible(&lirc_rx51->wqueue);
> > + lirc_rx51_stop_tx(lirc_rx51);
> >
> > return IRQ_HANDLED;
> > }
> > @@ -249,8 +256,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
> > char *buf,
> > if ((count > WBUF_LEN) || (count % 2 == 0))
> > return -EINVAL;
> >
> > - /* Wait any pending transfers to finish */
> > - wait_event_interruptible(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0);
> > + /* We can have only one transmit at a time */
> > + if (lirc_rx51->wbuf_index >= 0)
> > + return -EBUSY;
> >
> > if (copy_from_user(lirc_rx51->wbuf, buf, n))
> > return -EFAULT;
> > @@ -276,9 +284,18 @@ static ssize_t lirc_rx51_write(struct file *file,
> > const char *buf,
> >
> > /*
> > * Don't return back to the userspace until the transfer has
> > -* finished
> > +* finished. However, we wish to not spend any more than 500ms
> > +* in kernel. No IR code TX should ever take that long.
> > +*/
> > + i = wait_event_timeout(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0,
> > + HZ / 2);
> > +
> > + /*
> > +* Ensure transmitting has really stopped, even if the timers
> > +* went mad or something else happened that caused it still
> > +* sending out something.
> > */
> > - wait_event_interruptible(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0);
> > + lirc_rx51_stop_tx(lirc_rx51);
> >
> > /* We can sleep again */
> > lirc_rx51->pdata->set_max_mpu_wakeup_lat(lirc_rx51->dev, -1);
> > --
> > 1.8.0
> >
> > --
> > 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
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
* Laurent Pinchart [121129 01:37]: > Hi Tomi, > > On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote: > > On 2012-11-28 17:13, Laurent Pinchart wrote: > > > On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: > > >> Hi, > > >> > > >> This patch removes use of cpu_is_* funcs from omap_vout, and uses > > >> omapdss's version instead. The other patch removes an unneeded plat/dma.h > > >> include. > > >> > > >> These are based on current omapdss master branch, which has the omapdss > > >> version code. The omapdss version code is queued for v3.8. I'm not sure > > >> which is the best way to handle these patches due to the dependency to > > >> omapdss. The easiest option is to merge these for 3.9. > > >> > > >> There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last > > >> OMAP dependency in the omap_vout driver. I'm not going to touch that, as > > >> it doesn't look as trivial as this cpu_is_* removal, and I don't have > > >> much knowledge of the omap_vout driver. > > >> > > >> Compiled, but not tested. > > > > > > Tested on a Beagleboard-xM. > > > > > > Tested-by: Laurent Pinchart > > > Acked-by: Laurent Pinchart > > > > Thanks. > > > > > The patches depend on unmerged OMAP DSS patches. Would you like to push > > > this series through linuxtv or through your DSS tree ? The later might be > > > easier, depending on when the required DSS patches will hit mainline. > > > > The DSS patches will be merged for 3.8. I can take this via the omapdss > > tree, as there probably won't be any conflicts with other v4l2 stuff. > > > > Or, we can just delay these until 3.9. These patches remove omap > > platform dependencies, helping the effort to get common ARM kernel. > > However, as there's still the VRFB code in the omap_vout driver, the > > dependency remains. Thus, in way, these patches alone don't help > > anything, and we could delay these for 3.9 and hope that > > omap_vout_vrfb.c gets converted also for that merge window. > > OK, I'll queue them for v3.9 then. Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/7] ir-rx51: Handle signals properly
Hi,
* Timo Kokkonen [121118 07:15]:
> --- a/drivers/media/rc/ir-rx51.c
> +++ b/drivers/media/rc/ir-rx51.c
> @@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
> OMAP_TIMER_TRIGGER_NONE);
> }
>
> +static void lirc_rx51_stop_tx(struct lirc_rx51 *lirc_rx51)
> +{
> + if (lirc_rx51->wbuf_index < 0)
> + return;
> +
> + lirc_rx51_off(lirc_rx51);
> + lirc_rx51->wbuf_index = -1;
> + omap_dm_timer_stop(lirc_rx51->pwm_timer);
> + omap_dm_timer_stop(lirc_rx51->pulse_timer);
> + omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
> + wake_up(&lirc_rx51->wqueue);
> +}
> +
> static int init_timing_params(struct lirc_rx51 *lirc_rx51)
> {
> u32 load, match;
Good fixes in general.. But you won't be able to access the
omap_dm_timer functions after we enable ARM multiplatform support
for omap2+. That's for v3.9 probably right after v3.8-rc1.
We need to find some Linux generic API to use hardware timers
like this, so I've added Thomas Gleixner and linux-arm-kernel
mailing list to cc.
If no such API is available, then maybe we can export some of
the omap_dm_timer functions if Thomas is OK with that.
The other alternative is to set them up as platform_data
function pointers, but that won't work after we make omap2+
device tree only. And that really just postpones the problem.
Cheers,
Tony
> @@ -163,13 +176,7 @@ static irqreturn_t lirc_rx51_interrupt_handler(int irq,
> void *ptr)
>
> return IRQ_HANDLED;
> end:
> - /* Stop TX here */
> - lirc_rx51_off(lirc_rx51);
> - lirc_rx51->wbuf_index = -1;
> - omap_dm_timer_stop(lirc_rx51->pwm_timer);
> - omap_dm_timer_stop(lirc_rx51->pulse_timer);
> - omap_dm_timer_set_int_enable(lirc_rx51->pulse_timer, 0);
> - wake_up_interruptible(&lirc_rx51->wqueue);
> + lirc_rx51_stop_tx(lirc_rx51);
>
> return IRQ_HANDLED;
> }
> @@ -249,8 +256,9 @@ static ssize_t lirc_rx51_write(struct file *file, const
> char *buf,
> if ((count > WBUF_LEN) || (count % 2 == 0))
> return -EINVAL;
>
> - /* Wait any pending transfers to finish */
> - wait_event_interruptible(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0);
> + /* We can have only one transmit at a time */
> + if (lirc_rx51->wbuf_index >= 0)
> + return -EBUSY;
>
> if (copy_from_user(lirc_rx51->wbuf, buf, n))
> return -EFAULT;
> @@ -276,9 +284,18 @@ static ssize_t lirc_rx51_write(struct file *file, const
> char *buf,
>
> /*
>* Don't return back to the userspace until the transfer has
> - * finished
> + * finished. However, we wish to not spend any more than 500ms
> + * in kernel. No IR code TX should ever take that long.
> + */
> + i = wait_event_timeout(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0,
> + HZ / 2);
> +
> + /*
> + * Ensure transmitting has really stopped, even if the timers
> + * went mad or something else happened that caused it still
> + * sending out something.
>*/
> - wait_event_interruptible(lirc_rx51->wqueue, lirc_rx51->wbuf_index < 0);
> + lirc_rx51_stop_tx(lirc_rx51);
>
> /* We can sleep again */
> lirc_rx51->pdata->set_max_mpu_wakeup_lat(lirc_rx51->dev, -1);
> --
> 1.8.0
>
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
* Tomi Valkeinen [121112 05:35]: > Hi, > > This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's > version instead. The other patch removes an unneeded plat/dma.h include. > > These are based on current omapdss master branch, which has the omapdss > version > code. The omapdss version code is queued for v3.8. I'm not sure which is the > best way to handle these patches due to the dependency to omapdss. The easiest > option is to merge these for 3.9. > > There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP > dependency in the omap_vout driver. I'm not going to touch that, as it doesn't > look as trivial as this cpu_is_* removal, and I don't have much knowledge of > the omap_vout driver. > > Compiled, but not tested. Thanks for fixing this. Can you please resend with the selected people cc:d from output of: $ scripts/get_maintainer.pl -f drivers/media/platform/omap So we get the necessary acks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM common zImage support. Further work should continue
in the iommu framework context as only pure platform data will
be communicated from arch/arm/*omap*/* code to the iommu
framework.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Omar Ramirez Luna
Cc: linux-media@vger.kernel.org
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/iommu2.c |1
arch/arm/plat-omap/include/plat/iommu.h| 10 +--
arch/arm/plat-omap/include/plat/iovmm.h| 89
drivers/iommu/omap-iommu-debug.c |2 -
drivers/iommu/omap-iommu.c |1
drivers/iommu/omap-iovmm.c | 46 ++
drivers/media/platform/omap3isp/isp.c |1
drivers/media/platform/omap3isp/isp.h |4 -
drivers/media/platform/omap3isp/ispccdc.c |1
drivers/media/platform/omap3isp/ispstat.c |1
drivers/media/platform/omap3isp/ispvideo.c |2 -
include/linux/omap-iommu.h | 52
12 files changed, 107 insertions(+), 103 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
create mode 100644 include/linux/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..e8116cf 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..a4b71b1 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_RAM_PADDR_SHIFT12
#define MMU_RAM_PADDR_MASK \
((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
+
#define MMU_RAM_ENDIAN_MASK(1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+
#define MMU_RAM_ELSZ_16(1 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_32(2 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
@@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
void *priv),
void *isr_priv);
-extern void omap_iommu_save_ctx(struct device *dev);
-extern void omap_iommu_restore_ctx(struct device *dev);
-
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
deleted file mode 100644
index 498e57c..000
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * omap iommu: simple virtual address space management
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __IOMMU_MMAP_H
-#define __IOMMU_MMAP_H
-
-#include
-
-struct iovm_struct {
- struct omap_iommu *iommu; /* iommu object which this belongs to */
- u32 da_start; /* area definition */
- u32 da_end;
- u32 flags; /* IOVMF_: see below */
- struct list_headlist; /* linked in ascending order */
- const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
- void*va; /* mpu side mapped address */
-};
-
-/*
- * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
- *
- * lower 16 bit is used for h/w and upper 16 bit is for s/w.
- */
-#define IOVMF_SW_SHIFT 16
-
-/*
- * iovma: h/w flags derived from cam and ram attribute
- */
-#define IOVMF_CAM_MASK (~((1 << 10) - 1))
-#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
-
-#define IOVMF_PGSZ_MASK(3 << 0)
-#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
-#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
-#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
-#define IOVMF_PGSZ
[PATCH 4/6] ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|2
arch/arm/plat-omap/include/plat/iommu.h | 272 ++-
drivers/iommu/Makefile |1
drivers/iommu/omap-iommu-debug.c|1
drivers/iommu/omap-iommu.c | 19 ++
drivers/iommu/omap-iommu.h | 255 +
drivers/iommu/omap-iommu2.c |2
drivers/iommu/omap-iopgtable.h | 22 ---
drivers/iommu/omap-iovmm.c |1
9 files changed, 293 insertions(+), 282 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..d6721a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -184,8 +184,6 @@ obj-$(CONFIG_HW_PERF_EVENTS)+= pmu.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index a4b71b1..c677b9f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -10,103 +10,21 @@
* published by the Free Software Foundation.
*/
-#ifndef __MACH_IOMMU_H
-#define __MACH_IOMMU_H
-
-#include
-
-#if defined(CONFIG_ARCH_OMAP1)
-#error "iommu for this processor not implemented yet"
-#endif
-
-struct iotlb_entry {
- u32 da;
- u32 pa;
- u32 pgsz, prsvd, valid;
- union {
- u16 ap;
- struct {
- u32 endian, elsz, mixed;
- };
- };
-};
-
-struct omap_iommu {
- const char *name;
- struct module *owner;
- struct clk *clk;
- void __iomem*regbase;
- struct device *dev;
- void*isr_priv;
- struct iommu_domain *domain;
-
- unsigned intrefcount;
- spinlock_t iommu_lock; /* global for this whole object */
-
- /*
-* We don't change iopgd for a situation like pgd for a task,
-* but share it globally for each iommu.
-*/
- u32 *iopgd;
- spinlock_t page_table_lock; /* protect iopgd */
-
- int nr_tlb_entries;
-
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
- void *ctx; /* iommu context: registres saved area */
- u32 da_start;
- u32 da_end;
-};
-
-struct cr_regs {
- union {
- struct {
- u16 cam_l;
- u16 cam_h;
- };
- u32 cam;
- };
- union {
- struct {
- u16 ram_l;
- u16 ram_h;
- };
- u32 ram;
- };
-};
-
-struct iotlb_lock {
- short base;
- short vict;
-};
-
-/* architecture specific functions */
-struct iommu_functions {
- unsigned long version;
-
- int (*enable)(struct omap_iommu *obj);
- void (*disable)(struct omap_iommu *obj);
- void (*set_twl)(struct omap_iommu *obj, bool on);
- u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
-
- void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
- void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
-
- struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
- struct iotlb_entry *e);
- int (*cr_valid)(struct cr_regs *cr);
- u32 (*cr_to_virt)(struct cr_regs *cr);
- void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
- ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
- char *buf);
-
- u32 (*get_pte_attr)(struct iotlb_entry *e);
+#define MMU_REG_SIZE 256
- void (*save_ctx)(struct omap_iommu *obj);
- void (*restore_ctx)(struct omap_iommu *obj);
- ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iom
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Tony Lindgren [121030 09:31]: > > OK so are people happy with the patches in this series? > > Please everybody ack if no more comments so we can move on > towards getting CONFIG_MULTIPLATFORM to work for omaps. Looks like Joerg has a new email address, I'll send this series out one more time. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Tony Lindgren [121026 11:02]: > * Ohad Ben-Cohen [121026 02:56]: > > Hi Laurent, > > > > On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart > > wrote: > > > That's on my to-do list, as well as porting the OMAP3 ISP driver to > > > videobuf2, > > > adding DT support, moving to the common clock framework (when that will be > > > available for the OMAP3), supporting missing V4L2 features, ... All this > > > in my > > > spare time of course, otherwise it wouldn't be fun, would it ? ;-) > > > > Hmm, seems like a short to-do list ;) > > Sounds Laurent will take care of it :) > > > > I would also like to move the tidspbridge to the DMA API, but I think > > > we'll > > > need to move step by step there, and using the OMAP IOMMU and IOVMM APIs > > > as an > > > intermediate step would allow splitting patches in reviewable chunks. I > > > know > > > it's a step backwards in term of OMAP IOMMU usage, but that's in my > > > opinion a > > > temporary nuisance to make the leap easier. > > > > Since tidspbridge is in staging I guess it's not a problem, though it > > sounds to me like using the correct API in the first place is going to > > make less churn. > > Not related to these patches, but also sounds like we may need to drop > some staging/tidspbridge code to be able to move forward with the > ARM common zImage plans. See the "[GIT PULL] omap plat header removal > for v3.8 merge window, part1" thread for more info. OK so are people happy with the patches in this series? Please everybody ack if no more comments so we can move on towards getting CONFIG_MULTIPLATFORM to work for omaps. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Ohad Ben-Cohen [121026 02:56]: > Hi Laurent, > > On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart > wrote: > > That's on my to-do list, as well as porting the OMAP3 ISP driver to > > videobuf2, > > adding DT support, moving to the common clock framework (when that will be > > available for the OMAP3), supporting missing V4L2 features, ... All this in > > my > > spare time of course, otherwise it wouldn't be fun, would it ? ;-) > > Hmm, seems like a short to-do list ;) Sounds Laurent will take care of it :) > > I would also like to move the tidspbridge to the DMA API, but I think we'll > > need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as > > an > > intermediate step would allow splitting patches in reviewable chunks. I know > > it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion > > a > > temporary nuisance to make the leap easier. > > Since tidspbridge is in staging I guess it's not a problem, though it > sounds to me like using the correct API in the first place is going to > make less churn. Not related to these patches, but also sounds like we may need to drop some staging/tidspbridge code to be able to move forward with the ARM common zImage plans. See the "[GIT PULL] omap plat header removal for v3.8 merge window, part1" thread for more info. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Laurent Pinchart [121025 13:23]: > Hi Tony, > > On Thursday 25 October 2012 09:56:44 Tony Lindgren wrote: > > * Laurent Pinchart [121025 01:39]: > > > I still think you should split this in two files, omap-iommu.h and omap- > > > iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h > > > moved to include/linux.h. > > > > Can you please explain a bit more why you're thinking a separate > > omap-iovmm.h is needed in addtion to omap-iommu.h? > > The IOVMM API is layered top of the IOMMU API. It's really a separate API, so > two header files make sense. This patch creates a hybrid omap-iommu.h header > with mixed definitions, it just doesn't feel right :-) I won't insist for a > split though, if you think it's better to have a single header we can keep it > that way. Yes it's true it's a separate layer. But it's still iommu specific. The functions exported by omap-iovmm.c have iommu_ prefix in the name except for one: drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_find_iovm_area); drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_da_to_va); drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_iommu_vmap); drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_iommu_vunmap); drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_iommu_vmalloc); drivers/iommu/omap-iovmm.c:EXPORT_SYMBOL_GPL(omap_iommu_vfree); So it should be OK to keep it all in omap-iommu.h file. Let's see hear what.. > > My reasoning for not adding it is that neither intel nor amd needs > > more than intel-iommu.h and amd-iommu.h. And hopefully the iommu > > framework will eventually provide the API needed. And I'd rather > > not be the person introducing this second new file into > > include/linux :) > > > > Joerg and Ohad, do you have any opinions on this? ..Joerg and Ohad say. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Laurent Pinchart [121025 01:39]: > > I still think you should split this in two files, omap-iommu.h and omap- > iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h > moved > to include/linux.h. Can you please explain a bit more why you're thinking a separate omap-iovmm.h is needed in addtion to omap-iommu.h? My reasoning for not adding it is that neither intel nor amd needs more than intel-iommu.h and amd-iommu.h. And hopefully the iommu framework will eventually provide the API needed. And I'd rather not be the person introducing this second new file into include/linux :) Joerg and Ohad, do you have any opinions on this? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Laurent Pinchart [121024 16:54]: > On Wednesday 24 October 2012 15:34:12 Tony Lindgren wrote: > > > > BTW, doing a test compile on v3.7-rc2, I'm seeing the following warnings > > for omap3isp for isp_video_ioctl_ops: > > > > drivers/media/platform/omap3isp/ispvideo.c:1213: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/ispccdc.c:2303: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/ispccdc.c:2304: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_aewb.c:282: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_aewb.c:283: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_af.c:347: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_af.c:348: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isphist.c:453: warning: initialization from > > incompatible pointer type > > drivers/media/platform/omap3isp/isphist.c:454: warning: initialization from > > incompatible pointer type > > I've just sent a pull request to linux-media for v3.7 with fixes for those. OK thanks! Tony -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
