From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay005.isp.belgacom.be (mailrelay005.isp.belgacom.be [195.238.6.171]) by ozlabs.org (Postfix) with ESMTP id 03F75DDECA for ; Fri, 29 Aug 2008 18:45:35 +1000 (EST) From: Laurent Pinchart To: Scott Wood Subject: Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ? Date: Fri, 29 Aug 2008 10:45:27 +0200 References: <200808281757.16903.laurentp@cse-semaphore.com> <200808281907.53607.laurentp@cse-semaphore.com> <48B6DCFD.4020802@freescale.com> In-Reply-To: <48B6DCFD.4020802@freescale.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1459860.kPh0mcWAeo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <200808291045.31668.laurentp@cse-semaphore.com> Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --nextPart1459860.kPh0mcWAeo Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Scott, On Thursday 28 August 2008, Scott Wood wrote: > Laurent Pinchart wrote: > > On Thursday 28 August 2008, Scott Wood wrote: > >> On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote: > >>> I'm facing a situation where I need to call cpm2_clk_setup and=20 > >>> cpm2_set_pin from a device driver compiled as a module. Before=20 > >>> submitting a patch to export both functions, I'd like to make > >>> sure there isn't a cleaner way to implement the desired > >>> functionality without calling functions that are supposed to be > >>> used by board setup code. > >> Have you looked at using the GPIO API? > >=20 > > Yes, but the GPIO API doesn't support dedicated pin usage. Basically > > all I can do is configure a pin as a general purpose input or output, > > and set its level when configured as an output. The GPIO API doesn't > > provide any way to access the PAR and SOR registers. >=20 > OK, wasn't sure what it was that you needed to set at runtime. Are you=20 > actually switching between dedicated functions dynamically? Why do you=20 > need to do this? > > > Beside, the GPIO API won't help configuring clock routing. >=20 > Why does the clock routing need to change dynamically? The Infineon SHDSL chip uses separate clocks for transmit and receives. The= receive clock is always derived from the analog line and is routed from th= e SHDSL chip to a clock input on the MPC8248. The transmit clock is a bit trickier to handle, as it depends on which mode= the SHDSL channel is configured in. When in Central Office mode, the trans= mit clock is generated by the MPC8248 using one of its BRG and output on an= I/O pin. Clock routing on the MPC8248 routes CLKx to the SCC RX clock and = BRGx to the SCC transmit clock. The CLKx and BRGx I/O pins must be configur= ed accordingly. When in Remote Terminal mode, the receive clock must be looped to the trans= mit clock. This is achieved using a tristate buffer. The transmit clock sig= nal is thus driven by the buffer instead of being driven by the MPC8248 BRG= x pin. To avoid electrical conflicts I have to switch the BRGx I/O pin to a= n input. Clock routing must be reconfigured to route CLKx to both the SCC R= X and TX clocks. > If it turns out this really does need to happen, we can add some locks=20 > and export the functions, but I'd like to hear more about the use case=20 > first. GPIO configuration might be worked around by extending the GPIO API or prov= iding CPM2-specific extensions. Clock routing configuration is in my opinio= n required at runtime and I can't see any easy work around this. Feel free = to prove me wrong :-) Best regards, =2D-=20 Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 =46 +32 (2) 387 42 75 --nextPart1459860.kPh0mcWAeo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAki3tysACgkQ8y9gWxC9vpfyLACeM+xy4Hp7ejgsg3HZDX/lnNwm e08An0nD11Uc+hn7hUpkGn4pKGQ0hn07 =JWwF -----END PGP SIGNATURE----- --nextPart1459860.kPh0mcWAeo--