On 23/05/13 22:44, Arnd Bergmann wrote:
Thankyou Arnd for extending this discussion.
> On Monday 20 May 2013, Srinivas KANDAGATLA wrote:
>> On 17/05/13 15:36, Arnd Bergmann wrote:
>>
>> On the other hand using device trees to describe the HW
>> configuration(sysconfs) made more sense and got rid of
On Monday 20 May 2013, Srinivas KANDAGATLA wrote:
> On 17/05/13 15:36, Arnd Bergmann wrote:
>
> Some of the drivers like Ethernet already provide higher level
> interfaces via callbacks. We did implement such a callbacks per each SOC
> in non-DT case, and ended up having code duplicated for each SO
Hi Arnd,
Thankyou for the comments.
On 17/05/13 15:36, Arnd Bergmann wrote:
> On Thursday 09 May 2013, Srinivas KANDAGATLA wrote:
>> On 08/05/13 20:48, Arnd Bergmann wrote:
>> I agree, my initial approach was having a dedicated driver specific to
>> ST syscon, however syscon seems to do things ver
On Thursday 09 May 2013, Srinivas KANDAGATLA wrote:
> On 08/05/13 20:48, Arnd Bergmann wrote:
> I agree, my initial approach was having a dedicated driver specific to
> ST syscon, however syscon seems to do things very much similar to what
> we want, so I have integrated those 3 functions in syscon
Hi Marc,
I would like to explain you bit more about "ST System Configuration
registers".
The SOCs are assembled from existing IP blocks, which don't change very
often. However these blocks are assembled in different configurations to
meet the device requirements. So most IP blocks as well as havi
On 09/05/13 15:40, Mark Brown wrote:
> So what exactly is the driver doing then? If the register maps look
> nothing like each other then what's the common functionality the driver
> is providing?
What I meant here is that, sysconf registers are reassigned per SOC, so
the sysconf register definiti
On Thu, May 09, 2013 at 03:00:16PM +0100, Srinivas KANDAGATLA wrote:
> Some of layouts of the sysconf registers are totally changed for each SOC.
> Looking at driver by driver maybe some drivers can take advantage of the
> patterns, but Am not sure if this will be a sustainable solution for all
>
On 09/05/13 14:26, Mark Brown wrote:
> On Thu, May 09, 2013 at 12:58:01PM +0100, Srinivas KANDAGATLA wrote:
>
>> Currently, we have two bits of information which come from device trees.
>> 1> The syscon bank/group definition itself.
>> 2> syscon register offsets and bits information to the drivers
On Thu, May 09, 2013 at 12:58:01PM +0100, Srinivas KANDAGATLA wrote:
> Currently, we have two bits of information which come from device trees.
> 1> The syscon bank/group definition itself.
> 2> syscon register offsets and bits information to the drivers.
> These are the 2 things which keep chang
On 09/05/13 10:51, Mark Brown wrote:
> On Wed, May 08, 2013 at 06:42:04PM +0100, Srinivas KANDAGATLA wrote:
>
> Fix your mailer to word wrap within paragraphs.
>
Sorry about that.
>> Ultimately the syscon_write use the regmap_update_bits, however we
>> really want is the flexibility in using/refe
Hi Arnd,
Thankyou for extending the discussion.
On 08/05/13 20:48, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
>> the pinctrl driver calls syconf_claim(np, "st,alt-control) to get a
>> field and then do a read/write on the field.
>>
>> Just in pinctrl driver we use
On Wed, May 08, 2013 at 06:42:04PM +0100, Srinivas KANDAGATLA wrote:
Fix your mailer to word wrap within paragraphs.
> Ultimately the syscon_write use the regmap_update_bits, however we
> really want is the flexibility in using/referring the syscon
> registers/bits in both device-trees and non-de
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
> the pinctrl driver calls syconf_claim(np, "st,alt-control) to get a
> field and then do a read/write on the field.
>
> Just in pinctrl driver we use around 50-100 sysconf registers scatters
> across different groups.
>
> Without these new API
Thankyou for the comments.
On 08/05/13 16:01, Mark Brown wrote:
> On Wed, May 08, 2013 at 04:50:22PM +0200, Arnd Bergmann wrote:
>
>>> In many cases a single syconf register contains bits related to multiple
>>> devices, and therefore it need to be shared across multiple drivers at
>>> bit level. T
Thankyou for your comments.
On 08/05/13 15:50, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>>
>> This patch introduces syscon_claim, syscon_read, syscon_write,
>> syscon_release APIs to help drivers to use syscon registers in much more
>
On Wed, May 08, 2013 at 04:50:22PM +0200, Arnd Bergmann wrote:
> > In many cases a single syconf register contains bits related to multiple
> > devices, and therefore it need to be shared across multiple drivers at
> > bit level. The same IP block can have different syscon mappings on
> > differen
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla
>
> This patch introduces syscon_claim, syscon_read, syscon_write,
> syscon_release APIs to help drivers to use syscon registers in much more
> flexible way.
>
> With this patch, a driver can claim few/all bits in t
17 matches
Mail list logo
