Message ID | 1250283702-5582-1-git-send-email-m-karicheri2@ti.com (mailing list archive) |
---|---|
State | RFC |
Headers | show |
On Friday 14 August 2009 23:01:41 m-karicheri2@ti.com wrote: > From: Muralidharan Karicheri <m-karicheri2@ti.com> > > This patch makes the following changes:- > 1) Modify vpif_subdev_info to add board_info, routing information > and vpif interface configuration. Remove addr since it is > part of board_info > > 2) Add code to setup channel mode and input decoder path for > vpif capture driver > > Also incorporated comments against version v0 of the patch series and > added a spinlock to protect writes to common registers A quick question: against which git tree are these arch changes applied? I've lost track of that :-) Regards, Hans
Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] >Sent: Saturday, August 15, 2009 8:10 AM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Friday 14 August 2009 23:01:41 m-karicheri2@ti.com wrote: >> From: Muralidharan Karicheri <m-karicheri2@ti.com> >> >> This patch makes the following changes:- >> 1) Modify vpif_subdev_info to add board_info, routing information >> and vpif interface configuration. Remove addr since it is >> part of board_info >> >> 2) Add code to setup channel mode and input decoder path for >> vpif capture driver >> >> Also incorporated comments against version v0 of the patch series and >> added a spinlock to protect writes to common registers > >A quick question: against which git tree are these arch changes applied? >I've lost track of that :-) > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: > Hans, > > They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. > > Davinci tree is at > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. Regards, Hans
Hans, Ok. I will rework the patch and send you the same. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] >Sent: Monday, August 17, 2009 2:47 PM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: >> Hans, >> >> They are applied against davinci tree (also mentioned in the patch). >General procedure what I follow is to create platform code against davinci >tree and v4l patches against v4l-dvb linux-next tree. The architecture part >of linux-next is not up to date. >> >> Davinci tree is at >> >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git > >I must have missed the mention of this tree. > >I have a problem, though, as the current v4l-dvb repository doesn't compile >against the linux-davinci git tree. And the only way I can get it to >compile >is to apply all five patches first. > >However, the whole tree should still compile after each patch is applied. >And >that goes wrong with your second patch where the Kconfig and Makefile are >modified when the new sources aren't even added yet! > >What I would like to see is a patch series that starts with one patch that >makes the current v4l-dvb tree compile again, then the arch patch is added, >then a series of v4l-dvb patches in such an order that everything compiles >after each step. > >Merging this is already complicated enough without breaking compilation in >this way. > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hans, Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] >Sent: Monday, August 17, 2009 2:47 PM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: >> Hans, >> >> They are applied against davinci tree (also mentioned in the patch). >General procedure what I follow is to create platform code against davinci >tree and v4l patches against v4l-dvb linux-next tree. The architecture part >of linux-next is not up to date. >> >> Davinci tree is at >> >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git > >I must have missed the mention of this tree. > >I have a problem, though, as the current v4l-dvb repository doesn't compile >against the linux-davinci git tree. And the only way I can get it to >compile >is to apply all five patches first. > >However, the whole tree should still compile after each patch is applied. >And >that goes wrong with your second patch where the Kconfig and Makefile are >modified when the new sources aren't even added yet! > >What I would like to see is a patch series that starts with one patch that >makes the current v4l-dvb tree compile again, then the arch patch is added, >then a series of v4l-dvb patches in such an order that everything compiles >after each step. > >Merging this is already complicated enough without breaking compilation in >this way. > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: > Hans, > > Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so that is the most appropriate tree to do the patches against. Regards, Hans
Hans, I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] >Sent: Monday, August 17, 2009 4:27 PM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: >> Hans, >> >> Would you like the architecture specific changes against v4l-dvb linux- >next tree or linux-davinci ? I will rework both the vpfe and vpif patches >as per your comment. > >v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, >so >that is the most appropriate tree to do the patches against. > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote: > Hans, > > I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree tonight. Thanks! Hans > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > new phone: 301-407-9583 > Old Phone : 301-515-3736 (will be deprecated) > email: m-karicheri2@ti.com > > >-----Original Message----- > >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] > >Sent: Monday, August 17, 2009 4:27 PM > >To: Karicheri, Muralidharan > >Cc: linux-media@vger.kernel.org; davinci-linux-open- > >source@linux.davincidsp.com; khilman@deeprootsystems.com > >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif > >capture driver > > > >On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: > >> Hans, > >> > >> Would you like the architecture specific changes against v4l-dvb linux- > >next tree or linux-davinci ? I will rework both the vpfe and vpif patches > >as per your comment. > > > >v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, > >so > >that is the most appropriate tree to do the patches against. > > > >Regards, > > > > Hans > > > >-- > >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > > >
On Tuesday 18 August 2009 08:49:13 Hans Verkuil wrote: > On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote: > > Hans, > > > > I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. > > These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree tonight. Oops, wrong tree. It's v4l-dvb-vpif. Regards, Hans
Mauro, I need to send a set of patches for adding vpif capture driver. Currently the linux-next doesn't have the last patch from Chaithrika applied for vpif display. Is it possible to apply this asap so that I can create the vpif capture patch today? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Hans Verkuil [mailto:hverkuil@xs4all.nl] >Sent: Tuesday, August 18, 2009 2:51 AM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Tuesday 18 August 2009 08:49:13 Hans Verkuil wrote: >> On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote: >> > Hans, >> > >> > I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. >> >> These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree >tonight. > >Oops, wrong tree. It's v4l-dvb-vpif. > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Tue, 18 Aug 2009 11:06:54 -0500 "Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > Mauro, > > I need to send a set of patches for adding vpif capture driver. Currently the linux-next doesn't have the last patch from Chaithrika applied for vpif display. Is it possible to apply this asap so that I can create the vpif capture patch today? Sure. Could you please point me what's the patchwork ID(s)[1] of the patch you need me to apply at our development tree and at linux-next? [1] http://patchwork.kernel.org/project/linux-media/list/ Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mauro, Here are the patches from Chaithrika that I am referring to. http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html Let me know once they are merged... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org] >Sent: Tuesday, August 18, 2009 1:28 PM >To: Karicheri, Muralidharan >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com; Hans Verkuil >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Em Tue, 18 Aug 2009 11:06:54 -0500 >"Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > >> Mauro, >> >> I need to send a set of patches for adding vpif capture driver. Currently >the linux-next doesn't have the last patch from Chaithrika applied for vpif >display. Is it possible to apply this asap so that I can create the vpif >capture patch today? > >Sure. Could you please point me what's the patchwork ID(s)[1] of the patch >you need >me to apply at our development tree and at linux-next? > [1] http://patchwork.kernel.org/project/linux-media/list/ > >Cheers, >Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mauro, Kevin has approved the architecture part of this patch. When can I expect these to be merged to linux-next? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-karicheri2@ti.com >-----Original Message----- >From: Karicheri, Muralidharan >Sent: Tuesday, August 18, 2009 5:51 PM >To: 'Mauro Carvalho Chehab' >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- >source@linux.davincidsp.com; khilman@deeprootsystems.com; Hans Verkuil >Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Mauro, > >Here are the patches from Chaithrika that I am referring to. >http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html >http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html > >Let me know once they are merged... > >Murali Karicheri >Software Design Engineer >Texas Instruments Inc. >Germantown, MD 20874 >new phone: 301-407-9583 >Old Phone : 301-515-3736 (will be deprecated) >email: m-karicheri2@ti.com > >>-----Original Message----- >>From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org] >>Sent: Tuesday, August 18, 2009 1:28 PM >>To: Karicheri, Muralidharan >>Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux- >open- >>source@linux.davincidsp.com; khilman@deeprootsystems.com; Hans Verkuil >>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >>capture driver >> >>Em Tue, 18 Aug 2009 11:06:54 -0500 >>"Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: >> >>> Mauro, >>> >>> I need to send a set of patches for adding vpif capture driver. >Currently >>the linux-next doesn't have the last patch from Chaithrika applied for >vpif >>display. Is it possible to apply this asap so that I can create the vpif >>capture patch today? >> >>Sure. Could you please point me what's the patchwork ID(s)[1] of the patch >>you need >>me to apply at our development tree and at linux-next? >> [1] http://patchwork.kernel.org/project/linux-media/list/ >> >>Cheers, >>Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Wed, 19 Aug 2009 10:32:07 -0500 "Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > Mauro, > > Kevin has approved the architecture part of this patch. When can I expect these to be merged to linux-next? > > Thanks. > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-karicheri2@ti.com > > >-----Original Message----- > >From: Karicheri, Muralidharan > >Sent: Tuesday, August 18, 2009 5:51 PM > >To: 'Mauro Carvalho Chehab' > >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- > >source@linux.davincidsp.com; khilman@deeprootsystems.com; Hans Verkuil > >Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif > >capture driver > > > >Mauro, > > > >Here are the patches from Chaithrika that I am referring to. > >http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html There's something wrong with this patch: $ patch -p1 -i 12453a.patch patching file arch/arm/mach-davinci/board-dm646x-evm.c Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 52 (offset -11 lines). Hunk #2 succeeded at 218 with fuzz 1 (offset -70 lines). Hunk #3 succeeded at 286 with fuzz 2 (offset -14 lines). Hunk #4 FAILED at 293. Hunk #5 succeeded at 254 (offset -79 lines). 1 out of 5 hunks FAILED -- saving rejects to file arch/arm/mach-davinci/board-dm646x-evm.c.rej patching file arch/arm/mach-davinci/dm646x.c Hunk #1 succeeded at 40 with fuzz 2 (offset 8 lines). Hunk #2 succeeded at 550 with fuzz 1 (offset -145 lines). Hunk #3 succeeded at 866 with fuzz 1 (offset 12 lines). patching file arch/arm/mach-davinci/include/mach/dm646x.h Hunk #1 succeeded at 47 with fuzz 2 (offset 18 lines). It seems that this patch is not based on my linux-next -git tree. Probably, this patch is dependent on some patch at Kevin tree. Kevin, As this patch touches only arch/arm/ stuff, I suspect that we'll have less conflicts if you could merge this one. From my side: Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> > >http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html Hmm... the second patch shows that bisect will be broken with the platform changes. This patch should be fold with the one that renamed the field, or before Kconfig/Makefile changes. I've applied this one on my tree, just before the Kbuild patch. Due to the DaVinci dependency order, I'll need to hold the DaVinci patches at the next upstream window to happen after Russell/Kevin trees, to avoid bisect troubles Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin & Mauro, Do I need to wait or this can be resolved by either of you for my work to proceed? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org] >Sent: Thursday, August 20, 2009 12:33 AM >To: Karicheri, Muralidharan; Kevin Hilman >Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab; linux- >media@vger.kernel.org; khilman@deeprootsystems.com; Hans Verkuil >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Em Wed, 19 Aug 2009 10:32:07 -0500 >"Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > >> Mauro, >> >> Kevin has approved the architecture part of this patch. When can I expect >these to be merged to linux-next? >> >> Thanks. >> >> Murali Karicheri >> Software Design Engineer >> Texas Instruments Inc. >> Germantown, MD 20874 >> email: m-karicheri2@ti.com >> >> >-----Original Message----- >> >From: Karicheri, Muralidharan >> >Sent: Tuesday, August 18, 2009 5:51 PM >> >To: 'Mauro Carvalho Chehab' >> >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux- >open- >> >source@linux.davincidsp.com; khilman@deeprootsystems.com; Hans Verkuil >> >Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support >vpif >> >capture driver >> > >> >Mauro, >> > >> >Here are the patches from Chaithrika that I am referring to. >> >http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html > >There's something wrong with this patch: > >$ patch -p1 -i 12453a.patch >patching file arch/arm/mach-davinci/board-dm646x-evm.c >Reversed (or previously applied) patch detected! Assume -R? [n] y >Hunk #1 succeeded at 52 (offset -11 lines). >Hunk #2 succeeded at 218 with fuzz 1 (offset -70 lines). >Hunk #3 succeeded at 286 with fuzz 2 (offset -14 lines). >Hunk #4 FAILED at 293. >Hunk #5 succeeded at 254 (offset -79 lines). >1 out of 5 hunks FAILED -- saving rejects to file arch/arm/mach- >davinci/board-dm646x-evm.c.rej >patching file arch/arm/mach-davinci/dm646x.c >Hunk #1 succeeded at 40 with fuzz 2 (offset 8 lines). >Hunk #2 succeeded at 550 with fuzz 1 (offset -145 lines). >Hunk #3 succeeded at 866 with fuzz 1 (offset 12 lines). >patching file arch/arm/mach-davinci/include/mach/dm646x.h >Hunk #1 succeeded at 47 with fuzz 2 (offset 18 lines). > >It seems that this patch is not based on my linux-next -git tree. Probably, >this patch is dependent on some patch at Kevin tree. > >Kevin, > >As this patch touches only arch/arm/ stuff, I suspect that we'll have less >conflicts if you could merge this one. From my side: > >Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> > >> >http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html > >Hmm... the second patch shows that bisect will be broken with the platform >changes. This patch should be fold with the one that renamed the field, or >before Kconfig/Makefile changes. > >I've applied this one on my tree, just before the Kbuild patch. > >Due to the DaVinci dependency order, I'll need to hold the DaVinci patches >at >the next upstream window to happen after Russell/Kevin trees, to avoid >bisect >troubles > > > >Cheers, >Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Thu, 20 Aug 2009 16:27:40 -0500 "Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > Kevin & Mauro, > > Do I need to wait or this can be resolved by either of you for my work to proceed? Murali, If I fix your patch in order to apply it on my tree, backporting it to the old arch header files, we'll have merge troubles upstream, when Kevin merge his changes. It will also mean that he'll need to apply a diff patch on his tree, in order to convert the patch to the new headers, and that git bisect may break. I might merge his tree here, but this means that, if he needs to rebase his tree (and sometimes people need to rebase their linux-next trees), I'll have troubles here, and I'll loose my work. So, the better solution is if he could apply this specific patch, merging his tree upstream before your patches. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin, How do we handle this? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@ti.com >-----Original Message----- >From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org] >Sent: Sunday, August 23, 2009 11:10 PM >To: Karicheri, Muralidharan >Cc: Kevin Hilman; Mauro Carvalho Chehab; linux-media@vger.kernel.org; Hans >Verkuil >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Em Thu, 20 Aug 2009 16:27:40 -0500 >"Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > >> Kevin & Mauro, >> >> Do I need to wait or this can be resolved by either of you for my work to >proceed? > >Murali, > >If I fix your patch in order to apply it on my tree, backporting it to the >old >arch header files, we'll have merge troubles upstream, when Kevin merge his >changes. It will also mean that he'll need to apply a diff patch on his >tree, >in order to convert the patch to the new headers, and that git bisect may >break. I might merge his tree here, but this means that, if he needs to >rebase >his tree (and sometimes people need to rebase their linux-next trees), I'll >have troubles here, and I'll loose my work. > >So, the better solution is if he could apply this specific patch, merging >his >tree upstream before your patches. > >Cheers, >Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 24, 2009 at 6:09 AM, Mauro Carvalho Chehab<mchehab@infradead.org> wrote: > Em Thu, 20 Aug 2009 16:27:40 -0500 > "Karicheri, Muralidharan" <m-karicheri2@ti.com> escreveu: > >> Kevin & Mauro, >> >> Do I need to wait or this can be resolved by either of you for my work to proceed? > > Murali, > > If I fix your patch in order to apply it on my tree, backporting it to the old > arch header files, we'll have merge troubles upstream, when Kevin merge his > changes. It will also mean that he'll need to apply a diff patch on his tree, > in order to convert the patch to the new headers, and that git bisect may > break. I might merge his tree here, but this means that, if he needs to rebase > his tree (and sometimes people need to rebase their linux-next trees), I'll > have troubles here, and I'll loose my work. > > So, the better solution is if he could apply this specific patch, merging his > tree upstream before your patches. OK, this is applied to DaVinci git master, and will add it to my 'for-next' branch which will be pulled into linux-next. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 8c88fd0..c8c65d8 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -33,7 +33,7 @@ #include <linux/i2c/at24.h> #include <linux/i2c/pcf857x.h> #include <linux/etherdevice.h> - +#include <media/tvp514x.h> #include <asm/setup.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> @@ -63,8 +63,8 @@ #define DM646X_EVM_PHY_MASK (0x2) #define DM646X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */ -#define VIDCLKCTL_OFFSET (0x38) -#define VSCLKDIS_OFFSET (0x6c) +#define VIDCLKCTL_OFFSET (DAVINCI_SYSTEM_MODULE_BASE + 0x38) +#define VSCLKDIS_OFFSET (DAVINCI_SYSTEM_MODULE_BASE + 0x6c) #define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8)) #define VCH2CLK_SYSCLK8 (BIT(9)) @@ -75,6 +75,18 @@ #define VIDCH2CLK (BIT(10)) #define VIDCH3CLK (BIT(11)) +#define VIDCH1CLK (BIT(4)) +#define TVP7002_INPUT (BIT(4)) +#define TVP5147_INPUT (~BIT(4)) +#define VPIF_INPUT_ONE_CHANNEL (BIT(5)) +#define VPIF_INPUT_TWO_CHANNEL (~BIT(5)) +#define TVP5147_CH0 "tvp514x-0" +#define TVP5147_CH1 "tvp514x-1" + +static void __iomem *vpif_vidclkctl_reg; +static void __iomem *vpif_vsclkdis_reg; +/* spin lock for updating above registers */ +static spinlock_t vpif_reg_lock; static struct davinci_uart_config uart_config __initdata = { .enabled_uarts = (1 << 0), @@ -348,7 +360,7 @@ static struct i2c_board_info __initdata i2c_info[] = { I2C_BOARD_INFO("cpld_reg0", 0x3a), }, { - I2C_BOARD_INFO("cpld_video", 0x3B), + I2C_BOARD_INFO("cpld_video", 0x3b), }, }; @@ -359,18 +371,20 @@ static struct davinci_i2c_platform_data i2c_pdata = { static int set_vpif_clock(int mux_mode, int hd) { + unsigned long flags; + unsigned int value; int val = 0; int err = 0; - unsigned int value; - void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE); - if (!cpld_client) + if (!vpif_vidclkctl_reg || !vpif_vsclkdis_reg || !cpld_client) return -ENXIO; /* disable the clock */ - value = __raw_readl(base + VSCLKDIS_OFFSET); + spin_lock_irqsave(&vpif_reg_lock, flags); + value = __raw_readl(vpif_vsclkdis_reg); value |= (VIDCH3CLK | VIDCH2CLK); - __raw_writel(value, base + VSCLKDIS_OFFSET); + __raw_writel(value, vpif_vsclkdis_reg); + spin_unlock_irqrestore(&vpif_reg_lock, flags); val = i2c_smbus_read_byte(cpld_client); if (val < 0) @@ -385,7 +399,7 @@ static int set_vpif_clock(int mux_mode, int hd) if (err) return err; - value = __raw_readl(base + VIDCLKCTL_OFFSET); + value = __raw_readl(vpif_vidclkctl_reg); value &= ~(VCH2CLK_MASK); value &= ~(VCH3CLK_MASK); @@ -394,24 +408,30 @@ static int set_vpif_clock(int mux_mode, int hd) else value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK); - __raw_writel(value, base + VIDCLKCTL_OFFSET); + __raw_writel(value, vpif_vidclkctl_reg); /* enable the clock */ - value = __raw_readl(base + VSCLKDIS_OFFSET); + spin_lock_irqsave(&vpif_reg_lock, flags); + value = __raw_readl(vpif_vsclkdis_reg); value &= ~(VIDCH3CLK | VIDCH2CLK); - __raw_writel(value, base + VSCLKDIS_OFFSET); + __raw_writel(value, vpif_vsclkdis_reg); + spin_unlock_irqrestore(&vpif_reg_lock, flags); return 0; } -static const struct vpif_subdev_info dm646x_vpif_subdev[] = { +static struct vpif_subdev_info dm646x_vpif_subdev[] = { { - .addr = 0x2A, .name = "adv7343", + .board_info = { + I2C_BOARD_INFO("adv7343", 0x2a), + }, }, { - .addr = 0x2C, .name = "ths7303", + .board_info = { + I2C_BOARD_INFO("ths7303", 0x2c), + }, }, }; @@ -421,7 +441,7 @@ static const char *output[] = { "S-Video", }; -static struct vpif_config dm646x_vpif_config = { +static struct vpif_display_config dm646x_vpif_display_config = { .set_clock = set_vpif_clock, .subdevinfo = dm646x_vpif_subdev, .subdev_count = ARRAY_SIZE(dm646x_vpif_subdev), @@ -430,6 +450,177 @@ static struct vpif_config dm646x_vpif_config = { .card_name = "DM646x EVM", }; +/** + * setup_vpif_input_path() + * @channel: channel id (0 - CH0, 1 - CH1) + * @sub_dev_name: ptr sub device name + * + * This will set vpif input to capture data from tvp514x or + * tvp7002. + */ +static int setup_vpif_input_path(int channel, const char *sub_dev_name) +{ + int err = 0; + int val; + + /* for channel 1, we don't do anything */ + if (channel != 0) + return 0; + + if (!cpld_client) + return -ENXIO; + + val = i2c_smbus_read_byte(cpld_client); + if (val < 0) + return val; + + if (!strcmp(sub_dev_name, TVP5147_CH0) || + !strcmp(sub_dev_name, TVP5147_CH1)) + val &= TVP5147_INPUT; + else + val |= TVP7002_INPUT; + + err = i2c_smbus_write_byte(cpld_client, val); + if (err) + return err; + return 0; +} + +/** + * setup_vpif_input_channel_mode() + * @mux_mode: mux mode. 0 - 1 channel or (1) - 2 channel + * + * This will setup input mode to one channel (TVP7002) or 2 channel (TVP5147) + */ +static int setup_vpif_input_channel_mode(int mux_mode) +{ + unsigned long flags; + int err = 0; + int val; + u32 value; + + if (!vpif_vsclkdis_reg || !cpld_client) + return -ENXIO; + + val = i2c_smbus_read_byte(cpld_client); + if (val < 0) + return val; + + spin_lock_irqsave(&vpif_reg_lock, flags); + value = __raw_readl(vpif_vsclkdis_reg); + if (mux_mode) { + val &= VPIF_INPUT_TWO_CHANNEL; + value |= VIDCH1CLK; + } else { + val |= VPIF_INPUT_ONE_CHANNEL; + value &= ~VIDCH1CLK; + } + __raw_writel(value, vpif_vsclkdis_reg); + spin_unlock_irqrestore(&vpif_reg_lock, flags); + + err = i2c_smbus_write_byte(cpld_client, val); + if (err) + return err; + + return 0; +} + +static struct tvp514x_platform_data tvp5146_pdata = { + .clk_polarity = 0, + .hs_polarity = 1, + .vs_polarity = 1 +}; + +#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) + +static struct vpif_subdev_info vpif_capture_sdev_info[] = { + { + .name = TVP5147_CH0, + .board_info = { + I2C_BOARD_INFO("tvp5146", 0x5d), + .platform_data = &tvp5146_pdata, + }, + .input = INPUT_CVBS_VI2B, + .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, + .can_route = 1, + .vpif_if = { + .if_type = VPIF_IF_BT656, + .hd_pol = 1, + .vd_pol = 1, + .fid_pol = 0, + }, + }, + { + .name = TVP5147_CH1, + .board_info = { + I2C_BOARD_INFO("tvp5146", 0x5c), + .platform_data = &tvp5146_pdata, + }, + .input = INPUT_SVIDEO_VI2C_VI1C, + .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, + .can_route = 1, + .vpif_if = { + .if_type = VPIF_IF_BT656, + .hd_pol = 1, + .vd_pol = 1, + .fid_pol = 0, + }, + }, +}; + +static const struct vpif_input dm6467_ch0_inputs[] = { + { + .input = { + .index = 0, + .name = "Composite", + .type = V4L2_INPUT_TYPE_CAMERA, + .std = TVP514X_STD_ALL, + }, + .subdev_name = TVP5147_CH0, + }, +}; + +static const struct vpif_input dm6467_ch1_inputs[] = { + { + .input = { + .index = 0, + .name = "S-Video", + .type = V4L2_INPUT_TYPE_CAMERA, + .std = TVP514X_STD_ALL, + }, + .subdev_name = TVP5147_CH1, + }, +}; + +static struct vpif_capture_config dm646x_vpif_capture_cfg = { + .setup_input_path = setup_vpif_input_path, + .setup_input_channel_mode = setup_vpif_input_channel_mode, + .subdev_info = vpif_capture_sdev_info, + .subdev_count = ARRAY_SIZE(vpif_capture_sdev_info), + .chan_config[0] = { + .inputs = dm6467_ch0_inputs, + .input_count = ARRAY_SIZE(dm6467_ch0_inputs), + }, + .chan_config[1] = { + .inputs = dm6467_ch1_inputs, + .input_count = ARRAY_SIZE(dm6467_ch1_inputs), + }, +}; + +static void __init evm_init_video(void) +{ + vpif_vidclkctl_reg = ioremap(VIDCLKCTL_OFFSET, 4); + vpif_vsclkdis_reg = ioremap(VSCLKDIS_OFFSET, 4); + if (!vpif_vidclkctl_reg || !vpif_vsclkdis_reg) { + pr_err("Can't map VPIF VIDCLKCTL or VSCLKDIS registers\n"); + return; + } + spin_lock_init(&vpif_reg_lock); + + dm646x_setup_vpif(&dm646x_vpif_display_config, + &dm646x_vpif_capture_cfg); +} + static void __init evm_init_i2c(void) { davinci_init_i2c(&i2c_pdata); @@ -457,7 +648,7 @@ static __init void evm_init(void) soc_info->emac_pdata->phy_mask = DM646X_EVM_PHY_MASK; soc_info->emac_pdata->mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY; - dm646x_setup_vpif(&dm646x_vpif_config); + evm_init_video(); } static __init void davinci_dm646x_evm_irq_init(void) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index a9b20e5..0976049 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -700,9 +700,23 @@ static u64 vpif_dma_mask = DMA_BIT_MASK(32); static struct resource vpif_resource[] = { { .start = DAVINCI_VPIF_BASE, - .end = DAVINCI_VPIF_BASE + 0x03fff, + .end = DAVINCI_VPIF_BASE + 0x03ff, .flags = IORESOURCE_MEM, + } +}; + +static struct platform_device vpif_dev = { + .name = "vpif", + .id = -1, + .dev = { + .dma_mask = &vpif_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), }, + .resource = vpif_resource, + .num_resources = ARRAY_SIZE(vpif_resource), +}; + +static struct resource vpif_display_resource[] = { { .start = IRQ_DM646X_VP_VERTINT2, .end = IRQ_DM646X_VP_VERTINT2, @@ -722,8 +736,32 @@ static struct platform_device vpif_display_dev = { .dma_mask = &vpif_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, - .resource = vpif_resource, - .num_resources = ARRAY_SIZE(vpif_resource), + .resource = vpif_display_resource, + .num_resources = ARRAY_SIZE(vpif_display_resource), +}; + +static struct resource vpif_capture_resource[] = { + { + .start = IRQ_DM646X_VP_VERTINT0, + .end = IRQ_DM646X_VP_VERTINT0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM646X_VP_VERTINT1, + .end = IRQ_DM646X_VP_VERTINT1, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device vpif_capture_dev = { + .name = "vpif_capture", + .id = -1, + .dev = { + .dma_mask = &vpif_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, + .resource = vpif_capture_resource, + .num_resources = ARRAY_SIZE(vpif_capture_resource), }; /*----------------------------------------------------------------------*/ @@ -854,7 +892,8 @@ void __init dm646x_init_mcasp1(struct snd_platform_data *pdata) platform_device_register(&dm646x_dit_device); } -void dm646x_setup_vpif(struct vpif_config *config) +void dm646x_setup_vpif(struct vpif_display_config *display_config, + struct vpif_capture_config *capture_config) { unsigned int value; void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE); @@ -872,8 +911,11 @@ void dm646x_setup_vpif(struct vpif_config *config) davinci_cfg_reg(DM646X_PTSOMUX_DISABLE); davinci_cfg_reg(DM646X_PTSIMUX_DISABLE); - vpif_display_dev.dev.platform_data = config; + vpif_display_dev.dev.platform_data = display_config; + vpif_capture_dev.dev.platform_data = capture_config; + platform_device_register(&vpif_dev); platform_device_register(&vpif_display_dev); + platform_device_register(&vpif_capture_dev); } void __init dm646x_init(void) diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h index 792c226..8cec746 100644 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ b/arch/arm/mach-davinci/include/mach/dm646x.h @@ -14,6 +14,8 @@ #include <mach/hardware.h> #include <mach/emac.h> #include <mach/asp.h> +#include <linux/i2c.h> +#include <linux/videodev2.h> #define DM646X_EMAC_BASE (0x01C80000) #define DM646X_EMAC_CNTRL_OFFSET (0x0000) @@ -31,26 +33,59 @@ void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); void dm646x_video_init(void); -struct vpif_output { - u16 id; - const char *name; +enum vpif_if_type { + VPIF_IF_BT656, + VPIF_IF_BT1120, + VPIF_IF_RAW_BAYER +}; + +struct vpif_interface { + enum vpif_if_type if_type; + unsigned hd_pol:1; + unsigned vd_pol:1; + unsigned fid_pol:1; }; struct vpif_subdev_info { - unsigned short addr; const char *name; + struct i2c_board_info board_info; + u32 input; + u32 output; + unsigned can_route:1; + struct vpif_interface vpif_if; }; -struct vpif_config { +struct vpif_display_config { int (*set_clock)(int, int); - const struct vpif_subdev_info *subdevinfo; + struct vpif_subdev_info *subdevinfo; int subdev_count; const char **output; int output_count; const char *card_name; }; +struct vpif_input { + struct v4l2_input input; + const char *subdev_name; +}; + +#define VPIF_CAPTURE_MAX_CHANNELS 2 + +struct vpif_capture_chan_config { + const struct vpif_input *inputs; + int input_count; +}; + +struct vpif_capture_config { + int (*setup_input_channel_mode)(int); + int (*setup_input_path)(int, const char *); + struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS]; + struct vpif_subdev_info *subdev_info; + int subdev_count; + const char *card_name; +}; -void dm646x_setup_vpif(struct vpif_config *config); +void dm646x_setup_vpif(struct vpif_display_config *, + struct vpif_capture_config *); #endif /* __ASM_ARCH_DM646X_H */