Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Felipe,
ping..
On Wednesday 14 August 2013 08:35 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
>> On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
>>> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
> On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
>> On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
>>> On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
>> wrote:
> IMHO we need a lookup method for PHYs, just like for clocks,
> regulators, PWMs or even i2c busses because there are complex
> cases
> when passing just a name using platform data will not work. I
> would
> second what Stephen said [1] and define a structure doing
> things
> in a
> DT-like way.
>
> Example;
>
> [platform code]
>
> static const struct phy_lookup my_phy_lookup[] = {
>
> PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1",
> "phy.2"),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
>>>
>>> I don't think this is a problem. All the existing lookup
>>> methods
>>> already
>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c,
>>> ...). You
>>> can simply add a requirement that the ID must be assigned
>>> manually,
>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>>
>> And I'm saying that this idea, of using a specific name and id,
>> is
>> frought with fragility and will break in the future in various
>> ways
>> when
>> devices get added to systems, making these strings constantly
>> have
>> to be
>> kept up to date with different board configurations.
>>
>> People, NEVER, hardcode something like an id. The fact that
>> this
>> happens today with the clock code, doesn't make it right, it
>> makes
>> the
>> clock code wrong. Others have already said that this is wrong
>> there
>> as
>> well, as systems change and dynamic ids get used more and more.
>>
>> Let's not repeat the same mistakes of the past just because we
>> refuse to
>> learn from them...
>>
>> So again, the "find a phy by a string" functions should be
>> removed,
>> the
>> device id should be automatically created by the phy core just
>> to
>> make
>> things unique in sysfs, and no driver code should _ever_ be
>> reliant
>> on
>> the number that is being created, and the pointer to the phy
>> structure
>> should be used everywhere instead.
>>
>> With those types of changes, I will consider merging this
>> subsystem,
>> but
>> without them, sorry, I will not.
>
> I'll agree with Greg here, the very fact that we see people
> trying to
> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
> points
> to a big problem in the framework.
>
> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
> end up
> adding similar infrastructure to the driver themselves to make
> sure
> we
> don't end up with duplicate names in sysfs in case we have
> multiple
> instances of the same IP in the SoC (or several of the same PCIe
> card).
> I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.>
>>>
>>> you shouldn't drop support for non-DT platform, in any case we
>>> lived
>>> without DT (and still do) for years. Gotta find a better way ;-)
>>
>> hmm..
>>
>> how about passing the device names of PHY in platform data of the
>> controller? It should be deterministic as the PHY framework assigns
>> its
>> own id and we *don't* want to add any requirement that the ID must
>> be
>> assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
>> of
>> *phy_init_data* in the v10 patch series
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
>> This isn't right. There are USB host controllers that use PIO, not
>> DMA. The HAS_DMA dependency should go with the controller driver, not
>> the USB core.
>>
>> On the other hand, the USB core does call various routines like
>> dma_unmap_single. It ought to be possible to compile these calls even
>> when DMA isn't enabled. That is, they should be defined as do-nothing
>> stubs.
>
> The asm-generic/dma-mapping-broken.h file intentionally causes link
> errors, but that could be changed.
>
> The better approach in my mind would be to replace code like
>
>
> if (hcd->self.uses_dma)
>
> with
>
> if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {
>
> which will reliably cause that reference to be omitted from object code,
> but not stop giving link errors for drivers that actually require
> DMA.
This can be done for drivers/usb/core/hcd.c.
But I'm a bit puzzled by drivers/usb/core/buffer.c. E.g.
void *hcd_buffer_alloc(...)
{
/* some USB hosts just use PIO */
if (!bus->controller->dma_mask &&
!(hcd->driver->flags & HCD_LOCAL_MEM)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
if (size <= pool_max[i])
return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
}
return dma_alloc_coherent(hcd->self.controller, size, dma, mem_flags);
}
which is called from usb_hcd_map_urb_for_dma():
if (hcd->self.uses_dma) {
} else if (hcd->driver->flags & HCD_LOCAL_MEM) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
&urb->setup_dma,
(void **)&urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
...
}
So if DMA is not used (!hcd->self.uses_dma, i.e. bus->controller->dma_mask
is zero), and HCD_LOCAL_MEM is set, we still end up calling dma_pool_alloc()?
(Naively, I'm not so familiar with the USB code) I'd expect it to use
kmalloc() instead?
So I would change it to
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!bus->controller->dma_mask &&
!(hcd->driver->flags & HCD_LOCAL_MEM))) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
Thanks for your clarification!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] s5p-jpeg: Add initial device tree support for S5PV210/Exynos4210 SoCs
This patch enables the JPEG codec on S5PV210 and Exynos4210 SoCs. There are
some differences in newer versions of the JPEG codec IP on SoCs like Exynos4x12
and Exynos5 series and support for them will be added in subsequent patches.
Cc: Andrzej Pietrasiewicz
Signed-off-by: Sylwester Nawrocki
---
.../bindings/media/exynos-jpeg-codec.txt | 11 +++
drivers/media/platform/s5p-jpeg/jpeg-core.c| 12 +++-
2 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
new file mode 100644
index 000..937b755
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -0,0 +1,11 @@
+Samsung S5P/EXYNOS SoC series JPEG codec
+
+Required properties:
+
+- compatible : should be one of:
+ "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg";
+- reg : address and length of the JPEG codec IP register set;
+- interrupts : specifies the JPEG codec IP interrupt;
+- clocks : should contain the JPEG codec IP gate clock specifier, from
the
+ common clock bindings;
+- clock-names : should contain "jpeg" entry.
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 15d2396..88c5beb 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1513,10 +1514,20 @@ static const struct dev_pm_ops s5p_jpeg_pm_ops = {
.runtime_resume = s5p_jpeg_runtime_resume,
};
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_jpeg_of_match[] = {
+ { .compatible = "samsung,s5pv210-jpeg" },
+ { .compatible = "samsung,exynos4210-jpeg" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, s5p_jpeg_of_match);
+#endif
+
static struct platform_driver s5p_jpeg_driver = {
.probe = s5p_jpeg_probe,
.remove = s5p_jpeg_remove,
.driver = {
+ .of_match_table = of_match_ptr(s5p_jpeg_of_match),
.owner = THIS_MODULE,
.name = S5P_JPEG_M2M_NAME,
.pm = &s5p_jpeg_pm_ops,
@@ -1528,4 +1539,3 @@ module_platform_driver(s5p_jpeg_driver);
MODULE_AUTHOR("Andrzej Pietrasiewicz ");
MODULE_DESCRIPTION("Samsung JPEG codec driver");
MODULE_LICENSE("GPL");
-
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2-ctrl: Suppress build warning from v4l2_ctrl_new_std_menu()
Prevent following build warning:
drivers/media/v4l2-core/v4l2-ctrls.c: In function ‘v4l2_ctrl_new_std_menu’:
drivers/media/v4l2-core/v4l2-ctrls.c:1768:15: warning: 'qmenu_int_len’ may be
used uninitialized in this function
Cc: Arun Kumar K
Signed-off-by: Sylwester Nawrocki
---
drivers/media/v4l2-core/v4l2-ctrls.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c6dc1fd..c3f0803 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1763,9 +1763,9 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
{
const char * const *qmenu = NULL;
const s64 *qmenu_int = NULL;
+ unsigned int qmenu_int_len = 0;
const char *name;
enum v4l2_ctrl_type type;
- unsigned int qmenu_int_len;
s32 min;
s32 step;
u32 flags;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-tv: Include missing v4l2-dv-timings.h header file
Include the v4l2-dv-timings.h header file which in the s5p-tv driver which was supposed to be updated in commit 2576415846bcbad3c0a6885fc44f95083710 "[media] v4l2: move dv-timings related code to v4l2-dv-timings.c" This fixes following build error: drivers/media/platform/s5p-tv/hdmi_drv.c: In function ‘hdmi_s_dv_timings’: drivers/media/platform/s5p-tv/hdmi_drv.c:628:3: error: implicit declaration of function ‘v4l_match_dv_timings’ Cc: Hans Verkuil Signed-off-by: Sylwester Nawrocki --- drivers/media/platform/s5p-tv/hdmi_drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c b/drivers/media/platform/s5p-tv/hdmi_drv.c index 1b34c36..f9af2c2 100644 --- a/drivers/media/platform/s5p-tv/hdmi_drv.c +++ b/drivers/media/platform/s5p-tv/hdmi_drv.c @@ -37,6 +37,7 @@ #include #include #include +#include #include "regs-hdmi.h" -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff" > inside. Maybe the Si2165 is similar? Excellent. -- Steven Toth - Kernel Labs http://www.kernellabs.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: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
> I tried to apply the dvbsky-linux-3.9-hps-v2.diff to media_build.git (used > do_patches.sh from > http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2), but I > was not able to compile it. I already changed some includes, but then I got > the next error. > I just wanted to test if the si2168 module will work with si2165, but as I > don't expect it to work I stopped trying to compile the si2168. I don't see a si2165 driver in the tarball. Did I miss something? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Aug 18 19:00:22 CEST 2013 git branch: test git hash: bfd22c490bc74f9603ea90c37823036660a313e2 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: ERRORS linux-git-arm-davinci: ERRORS linux-git-arm-exynos: ERRORS linux-git-arm-mx: ERRORS linux-git-arm-omap: ERRORS linux-git-arm-omap1: ERRORS linux-git-arm-pxa: ERRORS linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.10-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.10-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API 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: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/18/2013 06:00 PM, Ulf wrote: I added Mr. Hans Petter Selasky back to Cc. I think it is better to keep all involved in To/Cc even it is mailing list. Personally I pay special attention for messages coming to my INBOX than those which are filtered to list basis folders. And everyone could personalize from mailing list settings if he wants duplicates or will mailing list drop it. Hi, It is DVB-S driver. HVR-900 is DVB-T and DVB-C. The si2168 is a DVB-T2, DVB-T, and DVB-C demodulator http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2168-A20-short.pdf. I tried to apply the dvbsky-linux-3.9-hps-v2.diff to media_build.git (used do_patches.sh from http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2), but I was not able to compile it. I already changed some includes, but then I got the next error. I just wanted to test if the si2168 module will work with si2165, but as I don't expect it to work I stopped trying to compile the si2168. I looked wrong place and driver =) That driver is asked few times already, nice! +History: + Max Nibble wrote the initial code, but only released it in + binary form. Assembly to C conversion done by HP Selasky. + Some possible endian issues fixed. It is big possibility same DVB-T/C/T2 blocks are used with different chips as none wants to reinvent the wheel. That has happened many times. I wonder is there any change to start mainlining that driver as it is converted from the binary? Make documentation and then write clean driver? regards Antti -- 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
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/18/13 17:00, Ulf wrote: Hi, It is DVB-S driver. HVR-900 is DVB-T and DVB-C. The si2168 is a DVB-T2, DVB-T, and DVB-C demodulator http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2168-A20-short.pdf. I tried to apply the dvbsky-linux-3.9-hps-v2.diff to media_build.git (used do_patches.sh from http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2), but I was not able to compile it. I already changed some includes, but then I got the next error. I just wanted to test if the si2168 module will work with si2165, but as I don't expect it to work I stopped trying to compile the si2168. Hi, You need to replace the "media_tree" with a symbolic link to a real media_tree. Then it will work! The sources provided with webcamd are simply minimal. There is a file called "sources.txt": Media tree sources used: git clone git://linuxtv.org/media_tree.git git checkout remotes/origin/master top commit dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d Else you could install FreeBSD in VirtualBox or something like that and test. Package is here: http://www.freshports.org/multimedia/webcamd/ --HPS -- 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: em28xx + ov2640 and v4l2-clk
Em Sun, 18 Aug 2013 13:40:25 +0200 Frank Schäfer escreveu: > Am 17.08.2013 12:51, schrieb Guennadi Liakhovetski: > > Hi Frank, > > As I mentioned on the list, I'm currently on a holiday, so, replying > > briefly. > Sorry, I missed that (can't read all mails on the list). > > > Since em28xx is a USB device, I conclude, that it's supplying clock to its > > components including the ov2640 sensor. So, yes, I think the driver should > > export a V4L2 clock. > Ok, so it's mandatory on purpose ? > I'll take a deeper into the v4l2-clk code and the > em28xx/ov2640/soc-camera interaction this week. > Have a nice holiday ! commit 9aea470b399d797e88be08985c489855759c6c60 Author: Guennadi Liakhovetski Date: Fri Dec 21 13:01:55 2012 -0300 [media] soc-camera: switch I2C subdevice drivers to use v4l2-clk Instead of centrally enabling and disabling subdevice master clocks in soc-camera core, let subdevice drivers do that themselves, using the V4L2 clock API and soc-camera convenience wrappers. Signed-off-by: Guennadi Liakhovetski Acked-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab (c/c the ones that acked with this broken changeset) We need to fix it ASAP or to revert the ov2640 changes, as some em28xx cameras are currently broken on 3.10. I'll also reject other ports to the async API if the drivers are used outside an embedded driver, as no PC driver currently defines any clock source. The same applies to regulators. Guennadi, Next time, please check if the i2c drivers are used outside soc_camera and apply the fixes where needed, as no regressions are allowed. Regards, Mauro > > Regards, > Frank > > Thanks > > Guennadi > > > > > > -Original Message- > > From: "Frank Schäfer" > > To: Guennadi Liakhovetski , Linux Media Mailing List > > > > Sent: Fr., 16 Aug 2013 21:03 > > Subject: em28xx + ov2640 and v4l2-clk > > > > Hi Guennadi, > > > > since commit 9aea470b399d797e88be08985c489855759c6c60 "soc-camera: > > switch I2C subdevice drivers to use v4l2-clk", the em28xx driver fails > > to register the ov2640 subdevice (if needed). > > The reason is that v4l2_clk_get() fails in ov2640_probe(). > > Does the em28xx driver have to register a (pseudo ?) clock first ? > > > > Regards, > > Frank > > -- > 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 -- Cheers, Mauro -- 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: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
Hi, >It is DVB-S driver. HVR-900 is DVB-T and DVB-C. The si2168 is a DVB-T2, DVB-T, and DVB-C demodulator http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2168-A20-short.pdf. I tried to apply the dvbsky-linux-3.9-hps-v2.diff to media_build.git (used do_patches.sh from http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2), but I was not able to compile it. I already changed some includes, but then I got the next error. I just wanted to test if the si2168 module will work with si2165, but as I don't expect it to work I stopped trying to compile the si2168. -- 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 v9] V4L2: soc_camera: Renesas R-Car VIN driver
Em Fri, 09 Aug 2013 00:57:34 +0400
Sergei Shtylyov escreveu:
> Hello.
>
> On 07/26/2013 12:23 AM, Sergei Shtylyov wrote:
>
> > From: Vladimir Barinov
>
> > Add Renesas R-Car VIN (Video In) V4L2 driver.
>
> > Based on the patch by Phil Edworthy .
>
> > Signed-off-by: Vladimir Barinov
> > [Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum
> > chip_id'
> > values, reordered rcar_vin_id_table[] entries, removed senseless parens
> > from
> > to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
> > *if* statement and used 'bool' values instead of 0/1 where necessary,
> > removed
> > unused macros, done some reformatting and clarified some comments.]
> > Signed-off-by: Sergei Shtylyov
>
> Guennadi, Mauro, if you don't have issues with this version, perhaps we
> still can merge it to 3.11 using "the new drivers can't cause regressions, so
> mergeable any time" rule?
AFAICT, while sometimes that happens, this is not a rule. The rule is to
merge new drivers during the merge window. What we during -rc is to accept
fix patches and even some updates for the new drivers merged at the very
latest merge window, as those won't cause regressions.
Anyway, IMO, we're too late at -rc cycle to propose this as an exception.
Regards,
Mauro
>
> 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
--
Cheers,
Mauro
--
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] [media] saa7115: make multi-line comments compliant with CodingStyle
changeset 2ccf12a did a crappy job when added multi-line comment lines,
violating CodingStyle.
Change the comments added there to fulfill CodingStyle, and document
the platform_data using Documentation/kernel-doc-nano-HOWTO.txt.
Cc: Jon Arne Jørgensen
Cc: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/i2c/saa7115.c | 24 +-
include/media/saa7115.h | 49 +++--
2 files changed, 43 insertions(+), 30 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 5cc48f7..637d026 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -225,12 +225,14 @@ static const unsigned char saa7111_init[] = {
0x00, 0x00
};
-/* This table has one illegal value, and some values that are not
- correct according to the datasheet initialization table.
-
- If you need a table with legal/default values tell the driver in
- i2c_board_info.platform_data, and you will get the gm7113c_init
- table instead. */
+/*
+ * This table has one illegal value, and some values that are not
+ * correct according to the datasheet initialization table.
+ *
+ * If you need a table with legal/default values tell the driver in
+ * i2c_board_info.platform_data, and you will get the gm7113c_init
+ * table instead.
+ */
/* SAA7113 Init codes */
static const unsigned char saa7113_init[] = {
@@ -265,10 +267,12 @@ static const unsigned char saa7113_init[] = {
0x00, 0x00
};
-/* GM7113C is a clone of the SAA7113 chip
- This init table is copied out of the saa7113 datasheet.
- In R_08 we enable "Automatic Field Detection" [AUFD],
- this is disabled when saa711x_set_v4lstd is called. */
+/*
+ * GM7113C is a clone of the SAA7113 chip
+ * This init table is copied out of the saa7113 datasheet.
+ * In R_08 we enable "Automatic Field Detection" [AUFD],
+ * this is disabled when saa711x_set_v4lstd is called.
+ */
static const unsigned char gm7113c_init[] = {
R_01_INC_DELAY, 0x08,
R_02_INPUT_CNTL_1, 0xc0,
diff --git a/include/media/saa7115.h b/include/media/saa7115.h
index e8d512a..76911e7 100644
--- a/include/media/saa7115.h
+++ b/include/media/saa7115.h
@@ -47,9 +47,11 @@
#define SAA7111_FMT_YUV411 0xc0
/* config flags */
-/* Register 0x85 should set bit 0 to 0 (it's 1 by default). This bit
+/*
+ * Register 0x85 should set bit 0 to 0 (it's 1 by default). This bit
* controls the IDQ signal polarity which is set to 'inverted' if the bit
- * it 1 and to 'default' if it is 0. */
+ * it 1 and to 'default' if it is 0.
+ */
#define SAA7115_IDQ_IS_DEFAULT (1 << 0)
/* s_crystal_freq values and flags */
@@ -84,11 +86,13 @@ enum saa7113_r10_ofts {
SAA7113_OFTS_VFLAG_BY_DATA_TYPE
};
-/* Register 0x12 "Output control" [Bit 0..3 Or Bit 4..7]:
+/*
+ * Register 0x12 "Output control" [Bit 0..3 Or Bit 4..7]:
* This is used to select what data is output on the RTS0 and RTS1 pins.
* RTS1 [Bit 4..7] Defaults to DOT_IN. (This value can not be set for RTS0)
* RTS0 [Bit 0..3] Defaults to VIPB in gm7113c_init as specified
- * in the datasheet, but is set to HREF_HS in the saa7113_init table. */
+ * in the datasheet, but is set to HREF_HS in the saa7113_init table.
+ */
enum saa7113_r12_rts {
SAA7113_RTS_DOT_IN = 0, /* OBS: Only for RTS1 (Default RTS1) */
SAA7113_RTS_VIPB, /* Default RTS0 For gm7113c_init */
@@ -108,24 +112,29 @@ enum saa7113_r12_rts {
SAA7113_RTS_FID
};
+/**
+ * struct saa7115_platform_data - Allow overriding default initialization
+ *
+ * @saa7113_force_gm7113c_init:Force the use of the gm7113c_init table
+ * instead of saa7113_init table
+ * (saa7113 only)
+ * @saa7113_r08_htc: [R_08 - Bit 3..4]
+ * @saa7113_r10_vrln: [R_10 - Bit 3]
+ * default: Disabled for gm7113c_init
+ * Enabled for saa7113c_init
+ * @saa7113_r10_ofts: [R_10 - Bit 6..7]
+ * @saa7113_r12_rts0: [R_12 - Bit 0..3]
+ * @saa7113_r12_rts1: [R_12 - Bit 4..7]
+ * @saa7113_r13_adlsb: [R_13 - Bit 7] - default: disabled
+ */
struct saa7115_platform_data {
- /* saa7113 only: Force the use of the gm7113c_init table,
-* instead of the old saa7113_init table. */
bool saa7113_force_gm7113c_init;
-
- /* SAA7113/GM7113C Specific configurations */
- enum saa7113_r08_htc *saa7113_r08_htc; /* [R_08 - Bit 3..4] */
-
- bool *saa7113_r10_vrln; /* [R_10 - Bit 3]
- Disabled for gm7113c_init
- Enabled for saa7113c_init */
- enum saa7113_r10_ofts *saa7113_r10_ofts;/* [R_10 - Bit 6..7] */
-
- enum saa7113_r12_rts *saa7113_r12_rts0; /* [R_12 - Bit 0..3] */
- enum saa7113_r12_rts *sa
[PATCH] [media] media/v4l2: VIDEO_SH_VEU should depend on HAS_DMA
If NO_DMA=y:
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration
of function ‘dma_mmap_coherent’
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
‘vb2_dc_get_base_sgt’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration
of function ‘dma_get_sgtable’
Commit da508f5799659241a359e2d07abb8af905f6291c ("[media] media/v4l2:
VIDEOBUF2_DMA_CONTIG should depend on HAS_DMA") added a dependency on
HAS_DMA to VIDEO_SH_VEU, as it selects VIDEOBUF2_DMA_CONTIG.
However, this got lost in the merge conflict resolution in commit
df90e2258950fd631cdbf322c1ee1f22068391aa ("Merge branch 'devel-for-v3.10'
into v4l_for_linus").
Re-add the dependency to fix this.
Signed-off-by: Geert Uytterhoeven
---
drivers/media/platform/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 08de865..126d0fc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -203,7 +203,7 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && GENERIC_HARDIRQS
+ depends on VIDEO_DEV && VIDEO_V4L2 && GENERIC_HARDIRQS && HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
--
1.7.9.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
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/18/2013 02:54 PM, Hans Petter Selasky wrote: On 08/17/13 13:53, Antti Palosaari wrote: On 08/17/2013 02:30 PM, Ulf wrote: Hi, I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165 demodulator was already discussed http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 and http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266. Just for me as a confirmation nobody plans to work on a driver for si2165. Is there any chance how to push the development? comment mode http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266 As far as I know there is none working with si2165 Linux driver. Last week I dumped out simple sniff from initial tuning to DVB-T channel and parsed log - it was 1.1 MB after parsing - wow. I haven't analyzed if it yet, but if it appears it is si2165 which generates that much control I/O it could be big task to write driver. Anyone has the idea if that amount of USB I/O traffic is caused by cx231xx ? regards Antti Hi, FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff" inside. Maybe the Si2165 is similar? http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2 It is DVB-S driver. HVR-900 is DVB-T and DVB-C. regards Antti -- 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
Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165
On 08/17/13 13:53, Antti Palosaari wrote: On 08/17/2013 02:30 PM, Ulf wrote: Hi, I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165 demodulator was already discussed http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 and http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266. Just for me as a confirmation nobody plans to work on a driver for si2165. Is there any chance how to push the development? comment mode http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266 As far as I know there is none working with si2165 Linux driver. Last week I dumped out simple sniff from initial tuning to DVB-T channel and parsed log - it was 1.1 MB after parsing - wow. I haven't analyzed if it yet, but if it appears it is si2165 which generates that much control I/O it could be big task to write driver. Anyone has the idea if that amount of USB I/O traffic is caused by cx231xx ? regards Antti Hi, FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff" inside. Maybe the Si2165 is similar? http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2 --HPS -- 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: em28xx + ov2640 and v4l2-clk
Am 17.08.2013 12:51, schrieb Guennadi Liakhovetski: > Hi Frank, > As I mentioned on the list, I'm currently on a holiday, so, replying briefly. Sorry, I missed that (can't read all mails on the list). > Since em28xx is a USB device, I conclude, that it's supplying clock to its > components including the ov2640 sensor. So, yes, I think the driver should > export a V4L2 clock. Ok, so it's mandatory on purpose ? I'll take a deeper into the v4l2-clk code and the em28xx/ov2640/soc-camera interaction this week. Have a nice holiday ! Regards, Frank > Thanks > Guennadi > > > -Original Message- > From: "Frank Schäfer" > To: Guennadi Liakhovetski , Linux Media Mailing List > > Sent: Fr., 16 Aug 2013 21:03 > Subject: em28xx + ov2640 and v4l2-clk > > Hi Guennadi, > > since commit 9aea470b399d797e88be08985c489855759c6c60 "soc-camera: > switch I2C subdevice drivers to use v4l2-clk", the em28xx driver fails > to register the ov2640 subdevice (if needed). > The reason is that v4l2_clk_get() fails in ov2640_probe(). > Does the em28xx driver have to register a (pseudo ?) clock first ? > > Regards, > Frank -- 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
