Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 12:14 Thu 12 Apr , Mohammed, Afzal wrote: > Hi Jean, > > On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > If ATMEL is also going driver way, then probably our voice together may be > > > heard and hopefully it will expedite the matter. > > I'm going to add it too my idea was to create something similiar as the > > pintrl > > you register the ddifferent bank supported buy the SoC and then the driver > > request the bank for the dev_name > > > > at soc level you will set the default timings and then the drvier may > > manipulate them > > > > I already update the API of sam9_smc to abstract the access to the register. > > Is SMC code being converted to driver ? no I'm busy on pinctrl I just cereate an abstracted API Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
Hi Jean, On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: > > If ATMEL is also going driver way, then probably our voice together may be > > heard and hopefully it will expedite the matter. > I'm going to add it too my idea was to create something similiar as the > pintrl > you register the ddifferent bank supported buy the SoC and then the driver > request the bank for the dev_name > > at soc level you will set the default timings and then the drvier may > manipulate them > > I already update the API of sam9_smc to abstract the access to the register. Is SMC code being converted to driver ? Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 07:06 Thu 12 Apr , Mohammed, Afzal wrote: > + omap ml > > Hi Jean, Andrew, Nicolas, > > On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote: > > + ahb { > > + apb { > > + dbgu: serial@f200 { > > + status = "okay"; > > + }; > > + > > + usart0: serial@fffb { > > + status = "okay"; > > + }; > > + > > + usart1: serial@fffb4000 { > > + status = "okay"; > > + }; > > + > > + macb0: ethernet@fffc4000 { > > + phy-mode = "rmii"; > > + status = "okay"; > > + }; > > + > > + usb1: gadget@fffa4000 { > > + atmel,vbus-gpio = <&pioC 5 0>; > > + status = "okay"; > > + }; > > + }; > > + > > + nand0: nand@4000 { > > + nand-bus-width = <8>; > > + nand-ecc-mode = "soft"; > > + nand-on-flash-bbt; > > + status = "okay"; > > I have a few queries about handling static memory controller (SMC) of ATMEL > > 1. How is SMC configured when DT is used ? > 2. With "d6a0166 atmel/nand: add DT support", ek_add_device_nand() is no more > present (which was earlier configuring SMC), so is SMC configuration handled > by Kernel on DT boot or is it done by bootloader when DT ? > 3. How ek_add_device_dm9000() is going to be achieved with DT ? > 4. Is there any plan to create a driver out of SMC code & use DT with it ? > > Reason for bringing these queries is that TI OMAP chips have GPMC [1], SMC in > ATMEL > seems somewhat similar and currently GPMC is configured in platform code, & > we are creating a driver out of that code [2]. There are different views on > where > GPMC driver should go, mfd, misc folders etc, but could not yet get concrete > suggestions even with a loud cry. put me in ccc I'll take a look > > If ATMEL is also going driver way, then probably our voice together may be > heard and hopefully it will expedite the matter. I'm going to add it too my idea was to create something similiar as the pintrl you register the ddifferent bank supported buy the SoC and then the driver request the bank for the dev_name at soc level you will set the default timings and then the drvier may manipulate them I already update the API of sam9_smc to abstract the access to the register. I expect the code for the request to be generic but handling of the timing IP specific Evenif the GPMC is smiliar as the SMC I do not expect a generic API to manage it easly (for the timings). Best Regrds, J -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
+ omap ml Hi Jean, Andrew, Nicolas, On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote: > + ahb { > + apb { > + dbgu: serial@f200 { > + status = "okay"; > + }; > + > + usart0: serial@fffb { > + status = "okay"; > + }; > + > + usart1: serial@fffb4000 { > + status = "okay"; > + }; > + > + macb0: ethernet@fffc4000 { > + phy-mode = "rmii"; > + status = "okay"; > + }; > + > + usb1: gadget@fffa4000 { > + atmel,vbus-gpio = <&pioC 5 0>; > + status = "okay"; > + }; > + }; > + > + nand0: nand@4000 { > + nand-bus-width = <8>; > + nand-ecc-mode = "soft"; > + nand-on-flash-bbt; > + status = "okay"; I have a few queries about handling static memory controller (SMC) of ATMEL 1. How is SMC configured when DT is used ? 2. With "d6a0166 atmel/nand: add DT support", ek_add_device_nand() is no more present (which was earlier configuring SMC), so is SMC configuration handled by Kernel on DT boot or is it done by bootloader when DT ? 3. How ek_add_device_dm9000() is going to be achieved with DT ? 4. Is there any plan to create a driver out of SMC code & use DT with it ? Reason for bringing these queries is that TI OMAP chips have GPMC [1], SMC in ATMEL seems somewhat similar and currently GPMC is configured in platform code, & we are creating a driver out of that code [2]. There are different views on where GPMC driver should go, mfd, misc folders etc, but could not yet get concrete suggestions even with a loud cry. If ATMEL is also going driver way, then probably our voice together may be heard and hopefully it will expedite the matter. Regards Afzal [1] GPMC (General Purpose Memory Controller) in brief: GPMC is an unified memory controller dedicated to interfacing external memory devices like Asynchronous SRAM like memories and application specific integrated circuit devices. Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash Pseudo-SRAM devices GPMC has to be configured as required by timings of the connected peripheral. It needs to be configured only initially. Once it is configured it can be used to handle different protocols like NAND, NOR. Various kinds of devices like ethernet, uart, usb, fpga etc can work using GPMC interface. GPMC has a seperate additional functionality of NAND handling [2] https://lkml.org/lkml/2012/4/5/210 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html