From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6801 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757989Ab3ETVAy convert rfc822-to-8bit (ORCPT ); Mon, 20 May 2013 17:00:54 -0400 Date: Mon, 20 May 2013 18:00:29 -0300 From: Mauro Carvalho Chehab To: Jon Arne =?UTF-8?B?SsO4cmdlbnNlbg==?= Cc: Andy Walls , Ezequiel Garcia , Timo Teras , linux-media@vger.kernel.org Subject: Re: saa7115/gm7113c - device specific initialization Message-ID: <20130520180029.7e487432@redhat.com> In-Reply-To: <20130520162044.GB14615@dell.arpanet.local> References: <20130520102414.GA14615@dell.arpanet.local> <87943042-6e28-4718-b27a-efba8b178fc0@email.android.com> <20130520162044.GB14615@dell.arpanet.local> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-media-owner@vger.kernel.org List-ID: Em Mon, 20 May 2013 18:20:44 +0200 Jon Arne Jørgensen escreveu: > On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote: > > "Jon Arne Jørgensen" wrote: > > > > >Hi, > > >I've recently discovered that the smi2021 device have some pretty > > >specific > > >needs for the setup of the gm7113c chip. > > > > > >Both the smi2021 driver and the stk1160 driver needs registers > > >0x14 -> 0x17 to be zeroed, this is what forced me to add the gm7113c > > >chip to the saa7115 driver in the first place. > > > > > >Then Timo reported that the Terratec Grabby hwrev2 needs some of the > > >initial register settings to be changed for the device to work. > > >He posted a small list of required changes. > > >One of these changes is a change to register 0x12 which sets > > >up what to output on the RTS0 pin on the chip. > > > > > >Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV > > >to be generated by VREF - whatever that means :). > > >That is, I need bit 7 to be clear and bit 6 to be set in register 0x10. > > >To have the device behave correctly. > > > > > >Both the change for the smi2021 driver and the changes for the Terratec > > >device are pretty hardware specific. > > >They should probably not be part of the generic gm7113c setup. > > > > > >I would also guess that if other devices with the gm7113c chip should > > >surface, these devices might also have different needs for the setup of > > >the chip. > > > > > >I'm not sure what would be the correct way to handle these > > >differences. > > >The only sollution I'we tried is to bypass the saa7115 > > >driver, and push the needed changes directly over usb to the device, > > >after the initial setup is sent by the saa7115 driver. > > >This is a major hack, and the changes should probably go through > > >the saa7115 driver. > > > > > >Should the saa7115 driver be extended with an interface to change > > >random > > >register settings, or does the i2c subsystem already have a way to > > >handle this? > > > > > >Any idea about what might could be a better sollution? > > > > > >Best regards > > >Jon Arne Jørgensen > > > > > >-- > > >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 > > > > For v4l2_subdev's there is a way to pass in platform/bridge device specific data so initialization can be different than the default, based on the needs of the bridge driver. > > Ok, can you give any pointers to any documentation/source files I can > look at for this? Look, for example, at drivers/media/i2c/mt9v011.c. At mt9v011_probe, it checks if c->dev.platform_data exists. If so, it changes the xtal frequency to the one specified by the driver. -- Cheers, Mauro