Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, Apr 11, 2011 at 12:42 PM, Devin Heitmueller wrote: > On Mon, Apr 11, 2011 at 12:32 PM, Eric B Munson wrote: >>> Can you tune to other known digital channels? >> >> I will have to see if I can set one up by hand and try it. I will get back >> to >> you when I am able to do this (should be later today). >> >>> >>> > Let me know if you need anything else. >>> >>> Are you tuning digital cable (North American QAM) or digital Over The >>> Air (ATSC)? >> >> I am using digital cable (NA QAM). > > This is going to seem a little nuts, but just as a test could you try > sticking the card into a different machine (with a different > motherboard)? I heard something a few months ago about an issue > related to the power sequencing that only occurred with a specific > motherboard. Using any other motherboard resulted in success. > > It would be useful if we could rule that out. I ruled this out today, my HTPC is using a Biostar G31D-M7 and my desktop is using an ASUS P6X58D and I see the same behavior from the hauppage card in both machines. -- 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
KNC ONE DVB-C [1894:0022] can't find any channels, PAT/SDT/NIT filter timeout
Hi, i'm having problems with my new DVB-C device on UPC DVB-C network (Bratislava, Slovakia, encrypted using Conax CAM module inserted in CI slot connected to the DVB-C card): 05:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) Subsystem: KNC One Device [1894:0022] Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at ff70 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av As you can see, the device is detected and modules loaded : # ls -l /dev/dvb/adapter0 total 0 crw-rw 1 root video 212, 6 Apr 13 23:58 ca0 crw-rw 1 root video 212, 4 Apr 13 23:58 demux0 crw-rw 1 root video 212, 5 Apr 13 23:58 dvr0 crw-rw 1 root video 212, 3 Apr 13 23:58 frontend0 crw-rw 1 root video 212, 7 Apr 13 23:58 net0 # lsmod (i did cut out the unnecessary bits) Module Size Used by sbs 8885 0 sbshc 2712 1 sbs ipv6 244116 33 tda100235443 1 i915 515809 1 budget_av 18830 0 saa7146_vv 38879 1 budget_av drm_kms_helper 23711 1 i915 videodev 72530 1 saa7146_vv drm 144199 2 i915,drm_kms_helper videobuf_dma_sg 6848 1 saa7146_vv videobuf_core 13183 2 saa7146_vv,videobuf_dma_sg budget_core 5956 1 budget_av i2c_algo_bit4304 1 i915 i2c_i8016866 0 dvb_core 75119 2 budget_av,budget_core saa714612490 3 budget_av,saa7146_vv,budget_core serio_raw 3358 0 ttpci_eeprom1364 1 budget_core r8169 34246 0 i2c_core 15854 11 lm75,tda10023,i915,budget_av,drm_kms_helper,videodev,drm,budget_core,i2c_algo_bit,i2c_i801,ttpci_eeprom dmesg: http://pastebin.com/uJDtLGYm The problem is that i can't even successfully scan for channels.To rule out hardware issue, first i tried to use it first with my Windows PC, it worked flawlessly (SD absolutely no problems, HD channels had some minor dropouts due the high bitrate). The result of scan for channels using GlobeTV (the Windows app) was this : http://pastebin.com/XNHvjAfb . Because i'm using a cable operator not listed in /usr/share/dvb files, i need to use w_scan and the result is something like this : http://pastebin.com/0fUS6Tzx . Because of those filter timeouts, it finds no channels using the same cable and card which had no problems on Windows and using the same cable which has no problems with the provided set top box from the cable operator. You might suggest me to use dvbsnoop, but only two commands which work are the signal and feinfo. pidscan returns nothing : # dvbsnoop -s signal dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - Transponder/Frequency signal strength statistics... - cycle: 1 d_time: 0.001 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 10 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 11 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 12 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 13 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 14 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 15 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 16 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 17 d_time: 0.008 s
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
> On 05/04/11 21:07, Steffen Barszus wrote:
>> On Tue, 05 Apr 2011 13:00:14 +0200
>> "Issa Gorissen" wrote:
>>
>>> Hi,
>>>
>>> Eutelsat made a recent migration from DVB-S to DVB-S2 (since
>>> 31/3/2011) on two transponders on HB13E
>>>
>>> - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500
>>> Msymb/s 0.2 Pilot off Polar H
>>>
>>> - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500
>>> Msymb/s 0.2 Pilot off Polar H
>>>
>>>
>>> Before those changes, with my TT S2 3200, I was able to watch TV on
>>> those transponders. Now, I cannot even tune on those transponders. I
>>> have tried with scan-s2 and w_scan and the latest drivers from git.
>>> They both find the transponders but cannot tune onto it.
>>>
>>> Something noteworthy is that my other card, a DuoFlex S2 can tune
>>> fine on those transponders.
>>>
>>> My question is; can someone try this as well with a TT S2 3200 and
>>> post the results ?
>> i read something about it lately here (german!):
>> http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938
>>
>> It says in stb0899_drv.c function:
>> static void stb0899_set_iterations(struct stb0899_state *state)
>>
>> This:
>> reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER);
>> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
>> stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER,
>> STB0899_OFF0_MAX_ITER, reg);
>>
>> should be replaced with this:
>>
>> reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER);
>> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
>> stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER,
>> STB0899_OFF0_MAX_ITER, reg);
>>
>> Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines
>> affected.
>>
>> Kind Regards
>>
>> Steffen
> Hi Steffen,
>
> Unfortunately, it does not help in my case. Thx anyway.
Try my locking fix. With above patch I can lock the
channels without problem.
Johns
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index 2da55ec..55f0c4e 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -338,36 +338,42 @@ static enum stb0899_status
stb0899_check_data(struct stb0899_state *state)
int lock = 0, index = 0, dataTime = 500, loop;
u8 reg;
- internal->status = NODATA;
+ reg = stb0899_read_reg(state, STB0899_VSTATUS);
+ lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
+ if ( !lock ) {
- /* RESET FEC*/
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 1);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
- msleep(1);
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 0);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
+ internal->status = NODATA;
- if (params->srate <= 200)
- dataTime = 2000;
- else if (params->srate <= 500)
- dataTime = 1500;
- else if (params->srate <= 1500)
- dataTime = 1000;
- else
- dataTime = 500;
-
- stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force
search loop */
- while (1) {
- /* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP*/
- reg = stb0899_read_reg(state, STB0899_VSTATUS);
- lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
- loop = STB0899_GETFIELD(VSTATUS_END_LOOPVIT, reg);
+ /* RESET FEC*/
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 1);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
+ msleep(1);
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 0);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
- if (lock || loop || (index > dataTime))
- break;
- index++;
+ msleep(1);
+ }
}
if (lock) { /* DATA LOCK indicator */
--
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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia czwartek 14 kwiecień 2011 o 00:00:08 Russell King - ARM Linux napisał(a): > On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: > > Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux > > > > napisał(a): > > > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: > > > > Taking into account that I'm just trying to fix a regression, > > > > and not invent a new, long term solution: are you able to name > > > > an ARM based board which a) is already supported in 2.6.39, b) > > > > is (or can be) equipped with a device supported by a V4L > > > > driver which uses videobuf- dma-config susbsystem, c) has a > > > > bus structure with which virt_to_phys(bus_to_virt(dma_handle)) > > > > is not equal dma_handle? > > > > > > I have no idea - and why should whether someone can name > > > something that may break be a justification to allow something > > > which is technically wrong? > > > > > > Surely it should be the other way around - if its technically > > > wrong and _may_ break something then it shouldn't be allowed. > > > > In theory - of course. In practice - couldn't we now, close to > > -rc3, relax the rules a little bit and stop bothering with > > something that may break in the future if it doesn't break on any > > board supported so far (I hope)? > > If we are worried about closeness to -final, then what should happen > is that the original commit is reverted; the "fix" for IOMMUs > resulted in a regression for existing users which isn't trivial to > resolve without risking possible breakage of other users. > > Do we even know whether bus_to_virt(iommu_bus_address) works? I > suspect it doesn't, so by doing so you're already re-breaking the > IOMMU case. Hard to deny with only me having actually tested this dirty hack on one single board :) Thanks for your support, Janusz -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: > Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux > napisał(a): > > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: > > > Taking into account that I'm just trying to fix a regression, and > > > not invent a new, long term solution: are you able to name an ARM > > > based board which a) is already supported in 2.6.39, b) is (or can > > > be) equipped with a device supported by a V4L driver which uses > > > videobuf- dma-config susbsystem, c) has a bus structure with which > > > virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? > > > > I have no idea - and why should whether someone can name something > > that may break be a justification to allow something which is > > technically wrong? > > > > Surely it should be the other way around - if its technically wrong > > and _may_ break something then it shouldn't be allowed. > > In theory - of course. In practice - couldn't we now, close to -rc3, > relax the rules a little bit and stop bothering with something that may > break in the future if it doesn't break on any board supported so far (I > hope)? If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the "fix" for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users. Do we even know whether bus_to_virt(iommu_bus_address) works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case. -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 23:01:55 Janusz Krzysztofik napisał(a): > Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): > > Hello. > > > > Janusz Krzysztofik wrote: > > >>> After switching from mem->dma_handle to > > >>> virt_to_phys(mem->vaddr) used for obtaining page frame number > > >>> passed to remap_pfn_range() (commit > > >>> 35d9f510b67b10338161aba6229d4f55b4000f5b), > > >>> videobuf-dma-contig > > >>> > > >> Please specify the commit summary -- for the human readers. > > > > > > Hi, > > > OK, I'll try to reword the summary using a more human friendly > > > language as soon as I have signs that Mauro (who seemed to > > > understand the message well enough) is willing to accept the > > > code. > > > > > I wasn't asking you to rework your summary but to specify the > > > > summary of the commit you've mentioned (in parens). > > Ah, I see. How about just reordered wording: > > After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from > mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page > frame number passed to remap_pfn_range()), > > Do you think this would be clear enough? Oh no, I probably missed your point again. You meant just quoting the commit original summary line, didn't you? Thanks, Janusz -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): > Hello. > > Janusz Krzysztofik wrote: > >>> After switching from mem->dma_handle to virt_to_phys(mem->vaddr) > >>> used for obtaining page frame number passed to remap_pfn_range() > >>> (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), > >>> videobuf-dma-contig > >>> > >> Please specify the commit summary -- for the human readers. > > > > Hi, > > OK, I'll try to reword the summary using a more human friendly > > language as soon as I have signs that Mauro (who seemed to > > understand the message well enough) is willing to accept the code. > > I wasn't asking you to rework your summary but to specify the > summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? Thanks, Janusz -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: > > Taking into account that I'm just trying to fix a regression, and > > not invent a new, long term solution: are you able to name an ARM > > based board which a) is already supported in 2.6.39, b) is (or can > > be) equipped with a device supported by a V4L driver which uses > > videobuf- dma-config susbsystem, c) has a bus structure with which > > virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? > > I have no idea - and why should whether someone can name something > that may break be a justification to allow something which is > technically wrong? > > Surely it should be the other way around - if its technically wrong > and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? > > I thought so too, but missed the fact that PowerPC implements it > > actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, > > which ARM doesn't so far. > > So, there's no problem adding that symbol to ARM. OK, I can provide a patch as soon as dma_mmap_coherent() really works for me. > > > Maybe the video drivers should try to resurect the idea, maybe > > > only allowing this support for architectures which provide > > > dma_mmap_coherent(). > > > > AFAICT, ARM implementation of dma_mmap_coherent() is not compatible > > with dma_declare_coherent_memory(), is it? If I'm wrong, please > > correct me, I'll get back to the idea presented in v1 of the fix. > > 1. dma_declare_coherent_memory() doesn't work on ARM for memory which > already exists (its not permitted to ioremap() the kernel > direct-mapped memory due to attribute aliasing issues.) But you had once inspired (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034879.html), then was supporting my attempts towards pushing ioremap() out of this function up to the caller (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html), which would allow for doing sane preallocations via dma_coherent_alloc() and caching them back into dma_declare_coherent_memory() at boot time for later reuse mempry from that pool as DMA coherent. Now, should my attepmts succeded, we would still end up with the following: > 2. dma_declare_coherent_memory() totally bypasses the DMA allocator, Would it still, under your terms, if it could accept dma_alloc_coherent() obtained cpu addresses, not trying to ioremap() them? > and so dma_mmap_coherent() has no knowledge of how to map the > memory. I think it _could_ have a good knowledge if that memory was first preallocated with dma_alloc_coherent() at boot time, unless that memory was then fetched from that pool in smaller chunks. I think this is the reason it didn't work for me when I tried using this method with dma_mmap_coherent(). Am I missing something? > If we had a proper way to map DMA memory into userspace, then we > wouldn't have these issues as the dma_declare_coherent_memory() > would already support that. > > And actually, talking about dma_declare_coherent_memory(), you've > just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) > won't work - dma_declare_coherent_memory() can be used to provide > on-device memory where the virt/handle may not be mappable with > bus_to_virt(). While I have no problems to agree with the principles, I can confirm that this _hack_ does coexist nicely with dma_declare_coherent_memory(), at least on my OMAP1 based board. It also coexists nicely with your WiP patches I mentioned before and you didn't quote here, so I provide the links again: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036461.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html. OTOH, dma_mmap_coherent() didn't work for me when I tried using it on top of those patches. This doesn't mean I'm against a dma_mmap_coherent() based solution. I just think we can't afford switching to it _now_. > > Otherwise, I think that switching to dma_mmap_coherent() is not an > > option for the videobuf-dma-contig subsystem as long as there is no > > good solution to the problem of dma_alloc_coherent() not > > guaranteed to succeed with high-order allocations at any time. > > Let me repeat: there is no official API or way to map DMA memory into > userspace. Doesn't dma_mmap_coherent(), already available on 2 architectures, ARM and PPC, aim to provide the correct API? From the fact you didn't dispute v1 of my patch, which provided a dma_mmap_coherent() based code path for architectures supporting it, I would conclude this is a solution which might get your support, isn't it? However, I think that even if it was a _proper_ solutio
Re: OMAP3 ISP deadlocks on my new arm
Bastian Hecht wrote: > Hello people, Hi Bastian, I'm cc'ing Laurent. > I switched to the new DM3730 from IGEP and while it's supposed to be > (almost) the same as the 3530 Version the isp deadlocks > deterministically after I start capturing the second time with yavta. Does the capture work the first time w/o issues? > All extra locking debug output is enabled in the kernel .config. I'm not fully certain on what this exactly is that you have below, but it looks like your system is staying in interrupt context all the time. My guess is that the ISP is producing interrupts that the driver is not handling properly, causing the interrupt handler to be called again immediately. Do you have the same sensor working on OMAP 3530? > I am unsure if this is an ISP thing or a problem in the > interrupthandling software. This has probably something to do with the ISP driver. :-) > The first block is the watchdog that detects the deadlock. The last > block is in the isp-code but how can it hang when trying to UNlock a > spinlock? I am unsure about the 2nd block. > The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S > Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I > give it a shot here first. > > I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Why so old kernel? I think you'd be best off using this one: http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/omap3isp-next-omap3isp> > Any ideas? Thanks for any help, > > Bastian Hecht > > > [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] > [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks > [ 190.071563] [] (unwind_backtrace+0x0/0xe4) from > [] (panic+0x50/0xd0) > [ 190.079711] [] (panic+0x50/0xd0) from [] > (softlockup_tick+0x134/0x158) > [ 190.088043] [] (softlockup_tick+0x134/0x158) from > [] (update_process_times+0x28/0x48) > [ 190.097656] [] (update_process_times+0x28/0x48) from > [] (tick_sched_timer+0x88/0xbc) > [ 190.107177] [] (tick_sched_timer+0x88/0xbc) from > [] (__run_hrtimer+0x44/0x84) > [ 190.116119] [] (__run_hrtimer+0x44/0x84) from > [] (hrtimer_interrupt+0x114/0x2c8) > [ 190.125305] [] (hrtimer_interrupt+0x114/0x2c8) from > [] (omap2_gp_timer_interrupt+0x20/0x2c) > [ 190.135437] [] (omap2_gp_timer_interrupt+0x20/0x2c) from > [] (handle_IRQ_event+0x24/0xe0) > [ 190.145324] [] (handle_IRQ_event+0x24/0xe0) from > [] (handle_level_irq+0x90/0xfc) > [ 190.154510] [] (handle_level_irq+0x90/0xfc) from > [] (asm_do_IRQ+0x6c/0x8c) > [ 190.163177] [] (asm_do_IRQ+0x6c/0x8c) from [] > (__irq_svc+0x34/0x80) > [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) > [ 190.176300] 3c80: > 0020 c03c20d0 > [ 190.184509] 3ca0: c0417240 da412000 0002 > ded72e84 000a dec54640 > [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 > c0051ad8 2113 > [ 190.200958] [] (__irq_svc+0x34/0x80) from [] > (__do_softirq+0x3c/0xf8) > [ 190.209167] [] (__do_softirq+0x3c/0xf8) from [] > (irq_exit+0x40/0x8c) > [ 190.217315] [] (irq_exit+0x40/0x8c) from [] > (asm_do_IRQ+0x70/0x8c) > [ 190.225280] [] (asm_do_IRQ+0x70/0x8c) from [] > (__irq_svc+0x34/0x80) > [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) > [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 > ded72e80 4013 ded72e84 > [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 > da413d68 bf01d4cc bf01d4ec > [ 190.254821] 3d60: 6013 > [ 190.258361] [] (__irq_svc+0x34/0x80) from [] > (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) > [ 190.269165] [] (omap3isp_video_queue_streamon+0x6c/0x7c > [omap3_isp]) from [] (isp_video_streamon+0x150/0x1f8 > [omap3_isp]) > [ 190.281951] [] (isp_video_streamon+0x150/0x1f8 > [omap3_isp]) from [] (__video_do_ioctl+0x1488/0x3bd0) > [ 190.292877] [] (__video_do_ioctl+0x1488/0x3bd0) from > [] (__video_usercopy+0x2d0/0x414) > [ 190.302581] [] (__video_usercopy+0x2d0/0x414) from > [] (v4l2_unlocked_ioctl+0x38/0x3c) > [ 190.312194] [] (v4l2_unlocked_ioctl+0x38/0x3c) from > [] (vfs_ioctl+0x2c/0x6c) > [ 190.321044] [] (vfs_ioctl+0x2c/0x6c) from [] > (do_vfs_ioctl+0x4cc/0x514) > [ 190.329437] [] (do_vfs_ioctl+0x4cc/0x514) from > [] (sys_ioctl+0x34/0x54) > [ 190.337829] [] (sys_ioctl+0x34/0x54) from [] > (ret_fast_syscall+0x0/0x30) > -- > 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 > Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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 2/2 v2] [media] rc/nuvoton-cir: enable CIR on w83667hg chip variant
Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The CIR and CIR wide-band sensor enable bits are
just in a different place on this hardware, so we only poke register
0x27 on 677 hardware now, and we poke register 0x2c on the 667 now.
Reported-by: Douglas Clowes
Signed-off-by: Jarod Wilson
---
drivers/media/rc/nuvoton-cir.c | 22 --
drivers/media/rc/nuvoton-cir.h |7 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index bc5c1e2..5d93384 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -291,13 +291,23 @@ static int nvt_hw_detect(struct nvt_dev *nvt)
static void nvt_cir_ldev_init(struct nvt_dev *nvt)
{
- u8 val;
+ u8 val, psreg, psmask, psval;
+
+ if (nvt->chip_major == CHIP_ID_HIGH_667) {
+ psreg = CR_MULTIFUNC_PIN_SEL;
+ psmask = MULTIFUNC_PIN_SEL_MASK;
+ psval = MULTIFUNC_ENABLE_CIR | MULTIFUNC_ENABLE_CIRWB;
+ } else {
+ psreg = CR_OUTPUT_PIN_SEL;
+ psmask = OUTPUT_PIN_SEL_MASK;
+ psval = OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB;
+ }
- /* output pin selection (Pin95=CIRRX, Pin96=CIRTX1, WB enabled */
- val = nvt_cr_read(nvt, CR_OUTPUT_PIN_SEL);
- val &= OUTPUT_PIN_SEL_MASK;
- val |= (OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB);
- nvt_cr_write(nvt, val, CR_OUTPUT_PIN_SEL);
+ /* output pin selection: enable CIR, with WB sensor enabled */
+ val = nvt_cr_read(nvt, psreg);
+ val &= psmask;
+ val |= psval;
+ nvt_cr_write(nvt, val, psreg);
/* Select CIR logical device and enable */
nvt_select_logical_dev(nvt, LOGICAL_DEV_CIR);
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index cc8cee3..379795d 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -345,6 +345,7 @@ struct nvt_dev {
#define CR_CHIP_ID_LO 0x21
#define CR_DEV_POWER_DOWN 0x22 /* bit 2 is CIR power, default power on */
#define CR_OUTPUT_PIN_SEL 0x27
+#define CR_MULTIFUNC_PIN_SEL 0x2c
#define CR_LOGICAL_DEV_EN 0x30 /* valid for all logical devices */
/* next three regs valid for both the CIR and CIR_WAKE logical devices */
#define CR_CIR_BASE_ADDR_HI0x60
@@ -368,10 +369,16 @@ struct nvt_dev {
#define CIR_INTR_MOUSE_IRQ_BIT 0x80
#define PME_INTR_CIR_PASS_BIT 0x08
+/* w83677hg CIR pin config */
#define OUTPUT_PIN_SEL_MASK0xbc
#define OUTPUT_ENABLE_CIR 0x01 /* Pin95=CIRRX, Pin96=CIRTX1 */
#define OUTPUT_ENABLE_CIRWB0x40 /* enable wide-band sensor */
+/* w83667hg CIR pin config */
+#define MULTIFUNC_PIN_SEL_MASK 0x1f
+#define MULTIFUNC_ENABLE_CIR 0x80 /* Pin75=CIRRX, Pin76=CIRTX1 */
+#define MULTIFUNC_ENABLE_CIRWB 0x20 /* enable wide-band sensor */
+
/* MCE CIR signal length, related on sample period */
/* MCE CIR controller signal length: about 43ms
--
1.7.1
--
Jarod Wilson
ja...@redhat.com
--
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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: > Taking into account that I'm just trying to fix a regression, and not > invent a new, long term solution: are you able to name an ARM based > board which a) is already supported in 2.6.39, b) is (or can be) > equipped with a device supported by a V4L driver which uses videobuf- > dma-config susbsystem, c) has a bus structure with which > virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. > I thought so too, but missed the fact that PowerPC implements it > actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM > doesn't so far. So, there's no problem adding that symbol to ARM. > > Maybe the video drivers should try to resurect the idea, maybe only > > allowing this support for architectures which provide > > dma_mmap_coherent(). > > AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with > dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, > I'll get back to the idea presented in v1 of the fix. 1. dma_declare_coherent_memory() doesn't work on ARM for memory which already exists (its not permitted to ioremap() the kernel direct-mapped memory due to attribute aliasing issues.) 2. dma_declare_coherent_memory() totally bypasses the DMA allocator, and so dma_mmap_coherent() has no knowledge of how to map the memory. If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the dma_declare_coherent_memory() would already support that. And actually, talking about dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work - dma_declare_coherent_memory() can be used to provide on-device memory where the virt/handle may not be mappable with bus_to_virt(). > Otherwise, I think that switching to dma_mmap_coherent() is not an > option for the videobuf-dma-contig subsystem as long as there is no good > solution to the problem of dma_alloc_coherent() not guaranteed to > succeed with high-order allocations at any time. Let me repeat: there is no official API or way to map DMA memory into userspace. Every way people try is a half-hacked up bodge which may or may not work for a limited subset of systems. Until someone (like you) puts some serious effort into persuading *everyone* that this feature is needed, things are just going to continue being bodged and fragile. All that's happening here is that you're changing one broken way which works for one subset with another broken way which works for a different subset of systems and architectures. What actually needs to happen is a _proper_ fix for this. -- 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Apr 13 19:00:29 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [PATCHES] Misc. trivial fixes
On 04/12/2011 04:31 PM, Robby Workman wrote: > On Tue, 12 Apr 2011, Andreas Oberritter wrote: > >> On 04/12/2011 04:10 AM, Robby Workman wrote: >>> --- a/Make.rules >>> +++ b/Make.rules >>> @@ -11,6 +11,7 @@ PREFIX = /usr/local >>> LIBDIR = $(PREFIX)/lib >>> # subdir below LIBDIR in which to install the libv4lx libc wrappers >>> LIBSUBDIR = libv4l >>> +MANDIR = /usr/share/man >> >> Why did you hardcode /usr instead of keeping $(PREFIX)/share/man? > > > Eek. I'd like to say that I sent the wrong patch, but alas, I > simply had a thinko. See attached (better) patch :-) Looks good. Mauro, will you pick up this patch? Regards, Andreas > > -RW > > > 0002-Allow-override-of-manpage-installation-directory.patch > > > From 6ef4a1fecee242be9658528ef7663845d9bd6bc6 Mon Sep 17 00:00:00 2001 > From: Robby Workman > Date: Tue, 12 Apr 2011 09:26:57 -0500 > Subject: [PATCH] Allow override of manpage installation directory > > This creates MANDIR in Make.rules and keeps the preexisting > default of $(PREFIX)/share/man, but allows packagers to easily > override via e.g. "make MANDIR=/usr/man" > --- > Make.rules |1 + > utils/keytable/Makefile |4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Make.rules b/Make.rules > index 0bb2eb8..875828a 100644 > --- a/Make.rules > +++ b/Make.rules > @@ -11,6 +11,7 @@ PREFIX = /usr/local > LIBDIR = $(PREFIX)/lib > # subdir below LIBDIR in which to install the libv4lx libc wrappers > LIBSUBDIR = libv4l > +MANDIR = $(PREFIX)/share/man > > # These ones should not be overriden from the cmdline > > diff --git a/utils/keytable/Makefile b/utils/keytable/Makefile > index 29a6ac4..e093280 100644 > --- a/utils/keytable/Makefile > +++ b/utils/keytable/Makefile > @@ -39,7 +39,7 @@ install: $(TARGETS) > install -m 644 -p rc_keymaps/* $(DESTDIR)/etc/rc_keymaps > install -m 755 -d $(DESTDIR)/lib/udev/rules.d > install -m 644 -p 70-infrared.rules $(DESTDIR)/lib/udev/rules.d > - install -m 755 -d $(DESTDIR)$(PREFIX)/share/man/man1 > - install -m 644 -p ir-keytable.1 $(DESTDIR)$(PREFIX)/share/man/man1 > + install -m 755 -d $(DESTDIR)$(MANDIR)/man1 > + install -m 644 -p ir-keytable.1 $(DESTDIR)$(MANDIR)/man1 > > include ../../Make.rules > -- 1.7.4.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 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello. Janusz Krzysztofik wrote: After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Thanks, Janusz WBR, Sergei -- 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: OMAP3 ISP deadlocks on my new arm
Hello, I attached the output without extra kernel lock info, here is the debug output: [ 375.811157] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2226] [ 375.817474] Kernel panic - not syncing: softlockup: hung tasks [ 375.823364] [] (unwind_backtrace+0x0/0xe4) from [] (panic+0x50/0xd4) [ 375.831512] [] (panic+0x50/0xd4) from [] (softlockup_tick+0x14c/0x170) [ 375.839813] [] (softlockup_tick+0x14c/0x170) from [] (update_process_times+0x28/0x48) [ 375.849456] [] (update_process_times+0x28/0x48) from [] (tick_sched_timer+0x88/0xbc) [ 375.858978] [] (tick_sched_timer+0x88/0xbc) from [] (__run_hrtimer+0x50/0x9c) [ 375.867889] [] (__run_hrtimer+0x50/0x9c) from [] (hrtimer_interrupt+0x10c/0x2d8) [ 375.877075] [] (hrtimer_interrupt+0x10c/0x2d8) from [] (omap2_gp_timer_interrupt+0x20/0x2c) [ 375.887237] [] (omap2_gp_timer_interrupt+0x20/0x2c) from [] (handle_IRQ_event+0x24/0xe4) [ 375.897125] [] (handle_IRQ_event+0x24/0xe4) from [] (handle_level_irq+0xac/0x128) [ 375.906402] [] (handle_level_irq+0xac/0x128) from [] (asm_do_IRQ+0x6c/0x8c) [ 375.915130] [] (asm_do_IRQ+0x6c/0x8c) from [] (__irq_svc+0x38/0xa0) [ 375.923187] Exception stack(0xdea1dc80 to 0xdea1dcc8) [ 375.928253] dc80: 0001 dea3e840 0110 0001dbb7 dea1c000 0002 dff0cac8 [ 375.936492] dca0: 000a deab8800 c0461080 c0773214 dea1dcc8 c0071ba0 c0054614 [ 375.944702] dcc0: 6113 [ 375.948211] [] (__irq_svc+0x38/0xa0) from [] (__do_softirq+0x4c/0x128) [ 375.956512] [] (__do_softirq+0x4c/0x128) from [] (irq_exit+0x50/0x9c) [ 375.964752] [] (irq_exit+0x50/0x9c) from [] (asm_do_IRQ+0x70/0x8c) [ 375.972686] [] (asm_do_IRQ+0x70/0x8c) from [] (__irq_svc+0x38/0xa0) [ 375.980743] Exception stack(0xdea1dd08 to 0xdea1dd50) [ 375.985809] dd00: 0001 dea3e840 0110 0001dbb4 4013 dff0caa8 [ 375.994049] dd20: dff0cac4 dff0cac8 dff0caa8 deab8800 4013 c089e5fc dea1dd50 [ 376.002258] dd40: c0071ba0 c02e3dc4 2013 [ 376.007354] [] (__irq_svc+0x38/0xa0) from [] (_raw_spin_unlock_irqrestore+0x40/0x44) [ 376.016906] [] (_raw_spin_unlock_irqrestore+0x40/0x44) from [] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) [ 376.029388] [] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) from [] (isp_video_streamon+0x15c/0x214 [omap3_isp]) [ 376.042175] [] (isp_video_streamon+0x15c/0x214 [omap3_isp]) from [] (__video_do_ioctl+0x1488/0x3bd0) [ 376.053100] [] (__video_do_ioctl+0x1488/0x3bd0) from [] (__video_usercopy+0x2d0/0x414) [ 376.062835] [] (__video_usercopy+0x2d0/0x414) from [] (v4l2_unlocked_ioctl+0x38/0x3c) [ 376.072448] [] (v4l2_unlocked_ioctl+0x38/0x3c) from [] (vfs_ioctl+0x2c/0x6c) [ 376.081268] [] (vfs_ioctl+0x2c/0x6c) from [] (do_vfs_ioctl+0x4e4/0x52c) [ 376.089660] [] (do_vfs_ioctl+0x4e4/0x52c) from [] (sys_ioctl+0x34/0x54) [ 376.098052] [] (sys_ioctl+0x34/0x54) from [] (ret_fast_syscall+0x0/0x3c) [ 376.106933] [ cut here ] [ 376.111572] WARNING: at kernel/lockdep.c:2327 panic+0xb0/0xd4() [ 376.117523] Modules linked in: board_bastix framix omap3_isp iovmm omap_iommu iommu2 iommu [ 376.125915] [] (unwind_backtrace+0x0/0xe4) from [] (warn_slowpath_common+0x4c/0x64) [ 376.135375] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x18/0x1c) [ 376.145080] [] (warn_slowpath_null+0x18/0x1c) from [] (panic+0xb0/0xd4) [ 376.153472] [] (panic+0xb0/0xd4) from [] (softlockup_tick+0x14c/0x170) [ 376.161804] [] (softlockup_tick+0x14c/0x170) from [] (update_process_times+0x28/0x48) [ 376.171417] [] (update_process_times+0x28/0x48) from [] (tick_sched_timer+0x88/0xbc) [ 376.180969] [] (tick_sched_timer+0x88/0xbc) from [] (__run_hrtimer+0x50/0x9c) [ 376.189880] [] (__run_hrtimer+0x50/0x9c) from [] (hrtimer_interrupt+0x10c/0x2d8) [ 376.199066] [] (hrtimer_interrupt+0x10c/0x2d8) from [] (omap2_gp_timer_interrupt+0x20/0x2c) [ 376.209197] [] (omap2_gp_timer_interrupt+0x20/0x2c) from [] (handle_IRQ_event+0x24/0xe4) [ 376.219085] [] (handle_IRQ_event+0x24/0xe4) from [] (handle_level_irq+0xac/0x128) [ 376.228363] [] (handle_level_irq+0xac/0x128) from [] (asm_do_IRQ+0x6c/0x8c) [ 376.237121] [] (asm_do_IRQ+0x6c/0x8c) from [] (__irq_svc+0x38/0xa0) [ 376.245147] Exception stack(0xdea1dc80 to 0xdea1dcc8) [ 376.250244] dc80: 0001 dea3e840 0110 0001dbb7 dea1c000 0002 dff0cac8 [ 376.258453] dca0: 000a deab8800 c0461080 c0773214 dea1dcc8 c0071ba0 c0054614 [ 376.22] dcc0: 6113 [ 376.270172] [] (__irq_svc+0x38/0xa0) from [] (__do_softirq+0x4c/0x128) [ 376.278503] [] (__do_softirq+0x4c/0x128) from [] (irq_exit+0x50/0x9c) [ 376.286712] [] (irq_exit+0x50/0x9c) from [] (asm_do_IRQ+0x70/0x8c) [ 376.294677] [] (asm_do_IRQ+0x70/0x8c) from [] (__irq_svc+0x38/0xa0) [ 376.302703] Exception stack(0xdea1dd08 to 0xdea1dd50) [ 376.307800] dd00: 0001 dea3e840 0110 0001dbb4 4013 dff0caa8 [ 376.316009] dd20: dff0cac4 dff0cac8 dff0caa8 de
Re: soc_camera with V4L2 driver
Hello Guennadi, > > Additional information. > > The ARM cpu is made by Renesas. > > Then, perhaps, something similar to > > arch/arm/mach-shmobile/board-ap4evb.c Thank you, I will look into it too. With kind regards, Akira -- Akira Tsukamoto -- 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: soc_camera with V4L2 driver
Hello Guennadi, Thank you for the quick response. > > I am implementing 2mega pixel camera driver made by sharp and > > attached my primal kernel driver. > > (I still do not have the data sheet yet...) > > Thanks for attaching your driver. You can have a look at another driver > for a Sharp camera sensor: > > drivers/media/video/rj54n1cb0c.c > > and at its platform glue in arch/sh/boards/mach-kfr2r09/setup.c, there you > find > > struct platform_device kfr2r09_camera > > which links to > > struct soc_camera_link rj54n1_link > > etc. It would also help to know, with which SoC you're working, because in > your platform code you'll need both platform data for the sensor and for > the host. Feel free to ask, if you have more questions, but please also cc > the mailing list. Great! I will look into rj54n1cb0c.c and mach-kfr2r09/setup.c of the: struct soc_camera_link rj54n1_link The ARM CPU is Renesas SoC. > > On Wed, 13 Apr 2011 08:29:31 -0300 > > Mauro Carvalho Chehab mentioned: > > > > Thank you for the great advice. > > > > How do I bind the driver to soc_camera in my attached file? > > > > > > You'll need to add some glue on it, via platform_data. I never wrote such > > > glue for soc_camera, > > > so I can't give you the exact directions, but feel free to contact > > > Guennadi (soc_camera author > > > and maintainer) to get more details. > > > > How do I glue together my attached driver with your soc_camera? > > May I have a pointer or suggestion? > > > > I was project leader of PlayStaion3 Linux and now moved > > Nomovok to develop ARM based embedded devices. With kind regards, Akira > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ -- Akira Tsukamoto -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 14:03:44 Sergei Shtylyov napisał(a): > Hello. > > On 13-04-2011 1:06, Janusz Krzysztofik wrote: > > After switching from mem->dma_handle to virt_to_phys(mem->vaddr) > > used for obtaining page frame number passed to remap_pfn_range() > > (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), > > videobuf-dma-contig > > Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. Thanks, Janusz -- 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
OMAP3 ISP deadlocks on my new arm
Hello people, I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. All extra locking debug output is enabled in the kernel .config. I am unsure if this is an ISP thing or a problem in the interrupthandling software. The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [] (unwind_backtrace+0x0/0xe4) from [] (panic+0x50/0xd0) [ 190.079711] [] (panic+0x50/0xd0) from [] (softlockup_tick+0x134/0x158) [ 190.088043] [] (softlockup_tick+0x134/0x158) from [] (update_process_times+0x28/0x48) [ 190.097656] [] (update_process_times+0x28/0x48) from [] (tick_sched_timer+0x88/0xbc) [ 190.107177] [] (tick_sched_timer+0x88/0xbc) from [] (__run_hrtimer+0x44/0x84) [ 190.116119] [] (__run_hrtimer+0x44/0x84) from [] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [] (hrtimer_interrupt+0x114/0x2c8) from [] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [] (omap2_gp_timer_interrupt+0x20/0x2c) from [] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [] (handle_IRQ_event+0x24/0xe0) from [] (handle_level_irq+0x90/0xfc) [ 190.154510] [] (handle_level_irq+0x90/0xfc) from [] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [] (asm_do_IRQ+0x6c/0x8c) from [] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [] (__irq_svc+0x34/0x80) from [] (__do_softirq+0x3c/0xf8) [ 190.209167] [] (__do_softirq+0x3c/0xf8) from [] (irq_exit+0x40/0x8c) [ 190.217315] [] (irq_exit+0x40/0x8c) from [] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [] (asm_do_IRQ+0x70/0x8c) from [] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc bf01d4ec [ 190.254821] 3d60: 6013 [ 190.258361] [] (__irq_svc+0x34/0x80) from [] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) [ 190.269165] [] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) from [] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) [ 190.281951] [] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) from [] (__video_do_ioctl+0x1488/0x3bd0) [ 190.292877] [] (__video_do_ioctl+0x1488/0x3bd0) from [] (__video_usercopy+0x2d0/0x414) [ 190.302581] [] (__video_usercopy+0x2d0/0x414) from [] (v4l2_unlocked_ioctl+0x38/0x3c) [ 190.312194] [] (v4l2_unlocked_ioctl+0x38/0x3c) from [] (vfs_ioctl+0x2c/0x6c) [ 190.321044] [] (vfs_ioctl+0x2c/0x6c) from [] (do_vfs_ioctl+0x4cc/0x514) [ 190.329437] [] (do_vfs_ioctl+0x4cc/0x514) from [] (sys_ioctl+0x34/0x54) [ 190.337829] [] (sys_ioctl+0x34/0x54) from [] (ret_fast_syscall+0x0/0x30) -- 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] V4L2 API for flash devices
Sung Hee Park wrote: > Here are two more use-cases for flash that might help inform the API design. > Sakari encouraged me to post these. The person writing this is Andrew Adams, > but I'm sending this from Sung Hee's account, because I only just subscribed > to linux-media and can't immediately figure out how to reply to messages > from before I subscribed. Sung Hee and I are both grad students at Stanford > who work on FCam (http://fcam.garage.maemo.org/) Hi Andrew, Many thanks for the comments. > Second-curtain-sync: > > Sometimes you want to fire the flash at the end of a long exposure time. > It's usually a way to depict motion. Here's an example: > http://www.flickr.com/photos/latitudes/133206615/. > > This only really applies to xenon flashes because you can't get a crisp > image out of a longer duration LED flash. Even then it's somewhat > problematic on rolling-shutter sensors but still possible provided you don't > mind a slight shear to the crisp part of the image. From an API perspective, > it requires you to be able to specify a trigger time at some number of > microseconds into the exposure. On the N900 we did this with a real-time > thread. > > Triggering external hardware: > > This use-case is a little weirder, but it has the same API requirement. Some > photographic setups require you to synchronize some piece of hardware with > the exposure (e.g. an oscilloscope, or an external slave flash). On embedded > devices this is generally difficult. If you can at least fire the flash at a > precise delay into the exposure, you can attach a photodiode to it, and use > the flash+photodiode as an opto-isolator to trigger your external hardware. > > So we're in favor of having user-settable flash duration, and also > user-settable trigger times (with reference to the start of the exposure > time). I'm guessing that in a SMIA++ driver the trigger time would actually > be a control on the sensor device, but it seemed relevant to bring up while > you guys were talking about the flash API. >From this I reckon that in a general case the handling of the flash timing cannot be left for the drivers only. There must be a way to control it. So I'd think that also the level/edge trigger for the flash should be visible. On edge trigger, the only limiting factor for the flash duration on hardware would be the relatively coarse watchdog timer, and I'd think the user should be able to know that. The flash timing controls should be exposed by the sensor driver since the sensor is what actually performs the timing. Laurent; what do you think? Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello. On 13-04-2011 1:06, Janusz Krzysztofik wrote: After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures. The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic virt_to_phys(mem->vaddr). I think this should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both translations, performed in opposite directions, should compensate. Tested on ARM OMAP1 based Amstrad Delta board. Signed-off-by: Janusz Krzysztofik WBR, Sergei -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote: > On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: > > The patch tries to solve this regression by using > > virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic > > virt_to_phys(mem->vaddr). > > Who says that DMA handles are bus addresses in the strictest sense? > > DMA handles on ARM are the bus address to program 'dev' with in order > for it to access the memory mapped by dma_alloc_coherent(). On some > ARM platforms, this bus address is dependent on 'dev' - such as > platforms with more than one root PCI bus, and so bus_to_virt() just > doesn't hack it. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? If there is one, then I agree that my short-term fix is wrong. > What is really needed is for this problem - the mapping of DMA > coherent memory into userspace - to be solved with a proper arch API > rather than all these horrible hacks which subsystems instead > invent. That's something I tried to do with the dma_mmap_coherent() > stuff but it was shot down by linux-arch as (iirc) PA-RISC objected > to it. > > Hence why ARM only implements it. I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. > Maybe the video drivers should try to resurect the idea, maybe only > allowing this support for architectures which provide > dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Any chance for your already proposed (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036463.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html), or perhaps a new, better solution ever finding its way to the mainline tree? Thanks, Janusz -- 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: V4L/ARM: videobuf-dma-contig no longer works on my ARM machine
Dnia sobota 09 kwiecień 2011 o 18:42:40 Jiri Slaby napisał(a): > On 04/09/2011 05:10 PM, Janusz Krzysztofik wrote: > > (CC: Jiri Slaby, the author of the problematic change; truncate > > subject) > > > > On Sat, 09 Apr 2011, at 09:16:24, Russell King - ARM Linux wrote: > >> On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote: > >>> Since there were no actual problems reported before, I suppose > >>> the old code, which was passing to remap_pfn_range() a physical > >>> page number calculated from dma_alloc_coherent() privided > >>> dma_handle, worked correctly on all platforms actually using > >>> videobud-dma-config. > > No, it didn't when IOMMU was used. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name a board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf-dma-config susbsystem, c) uses IOMMU? If there is one, than I agree that reverting the patch is not a good option. > Because remap_pfn_range didn't get > a physical page address. If I didn't understand it, I wouldn't try to find a solution other than reverting your patch. Thanks, Janusz -- 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
[GIT PULL FOR 2.6.40] Anysee
Moikka Mauro, PULL following patches for the 2.6.40. There is new silicon tuner driver for NXP TDA18212HN. This basically adds support for two Anysee models: 1. E30 Combo Plus (new revision, TDA18212 tuner) 2. E7 TC t. Antti The following changes since commit d9954d8547181f9a6a23f835cc1413732700b785: Merge branch 'linus' into staging/for_v2.6.40 (2011-04-04 16:04:30 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (12): NXP TDA18212HN silicon tuner driver anysee: I2C address fix anysee: fix multibyte I2C read anysee: change some messages anysee: reimplement demod and tuner attach anysee: add support for TDA18212 based E30 Combo Plus anysee: add support for Anysee E7 TC anysee: fix E30 Combo Plus TDA18212 GPIO anysee: fix E30 Combo Plus TDA18212 DVB-T anysee: enhance demod and tuner attach anysee: add support for two byte I2C address anysee: add more info about known board configs drivers/media/common/tuners/Kconfig |8 + drivers/media/common/tuners/Makefile|1 + drivers/media/common/tuners/tda18212.c | 265 ++ drivers/media/common/tuners/tda18212.h | 48 +++ drivers/media/common/tuners/tda18212_priv.h | 44 +++ drivers/media/dvb/dvb-usb/Kconfig |1 + drivers/media/dvb/dvb-usb/anysee.c | 519 +- drivers/media/dvb/dvb-usb/anysee.h | 22 +- 8 files changed, 806 insertions(+), 102 deletions(-) create mode 100644 drivers/media/common/tuners/tda18212.c create mode 100644 drivers/media/common/tuners/tda18212.h create mode 100644 drivers/media/common/tuners/tda18212_priv.h -- http://palosaari.fi/ -- 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
[GIT PULL FOR 2.6.39] s5p-fimc driver updates
Hi Mauro, please pull from git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro for a few s5p-fimc driver bugfixes. The following changes since commit 28df73703e738d8ae7a958350f74b08b2e9fe9ed: [media] xc5000: Improve it to work better with 6MHz-spaced channels (2011-03-28 15:49:28 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro Sylwester Nawrocki (4): s5p-fimc: Fix FIMC3 pixel limits on Exynos4 s5p-fimc: Do not allow changing format after REQBUFS s5p-fimc: Fix bytesperline and plane payload setup s5p-fimc: Add support for the buffer timestamps and sequence drivers/media/video/s5p-fimc/fimc-capture.c |8 ++- drivers/media/video/s5p-fimc/fimc-core.c| 74 +-- 2 files changed, 52 insertions(+), 30 deletions(-) Thank you, -- Sylwester Nawrocki Samsung Poland R&D Center -- 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
[RFC 1/1] v4l: Improve error handling in v4l2_device_register_subdev()
In some cases v4l2_device_register_subdev() did not module_put() a module
the user count of which was incremented by try_module_get() earlier.
Signed-off-by: Sakari Ailus
---
Hi,
I'm sending this as an RFC since technically this leaves still room for
improvement.
v4l2_ctrl_add_handler() error handling is still to be implemented. The
controls are added to the parent and that needs to be cleaned up ---
actually, even if v4l2_ctrl_add_handler() fails, the added controls would
have to be removed from the v4l2_dev parent.
I don't see an easy way to do this, except to call v4l2_ctrl_handler_free().
But that also cleans up the existing controls in the parent, which might not
be desirable.
As far as I understand, no driver initialises the v4l2_dev->ctrl_handler for
the moment.
---
drivers/media/video/v4l2-device.c | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index 5aeaf87..773146d 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -156,27 +156,20 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
if (sd->internal_ops && sd->internal_ops->registered) {
err = sd->internal_ops->registered(sd);
if (err)
- return err;
+ goto err_registered;
}
/* This just returns 0 if either of the two args is NULL */
err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, sd->ctrl_handler);
- if (err) {
- if (sd->internal_ops && sd->internal_ops->unregistered)
- sd->internal_ops->unregistered(sd);
- return err;
- }
+ if (err)
+ goto err_v4l2_ctrl_add_handler;
#if defined(CONFIG_MEDIA_CONTROLLER)
/* Register the entity. */
if (v4l2_dev->mdev) {
err = media_device_register_entity(v4l2_dev->mdev, entity);
- if (err < 0) {
- if (sd->internal_ops && sd->internal_ops->unregistered)
- sd->internal_ops->unregistered(sd);
- module_put(sd->owner);
- return err;
- }
+ if (err < 0)
+ goto err_media_device_register_entity;
}
#endif
@@ -185,6 +178,19 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
spin_unlock(&v4l2_dev->lock);
return 0;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+err_media_device_register_entity:
+#endif
+err_v4l2_ctrl_add_handler:
+ /* FIXME: v4l2_ctrl_add_handler() error handling. */
+ if (sd->internal_ops && sd->internal_ops->unregistered)
+ sd->internal_ops->unregistered(sd);
+
+err_registered:
+ module_put(sd->owner);
+
+ return err;
}
EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
--
1.7.2.5
--
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
