All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>,
	linux-kernel@vger.kernel.org, Kevin Hilman <khilman@ti.com>,
	Cyril Chemparathy <cyril@ti.com>,
	linux-arm-kernel@lists.infradead.org,
	davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [RFC/RFT 2/2] davinci: use generic memory mapped gpio for tnetv107x
Date: Wed, 13 Jul 2011 18:46:24 +0400	[thread overview]
Message-ID: <20110713144624.GA7875@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20110706220240.GF5371@ponder.secretlab.ca>

Hi Grant,

On Wed, Jul 06, 2011 at 04:02:40PM -0600, Grant Likely wrote:
[...]
> > +		{
> > +			.name	= "dat",
> > +			.start	= TNETV107X_GPIO_BASE + 0x4,
> > +			.end	= TNETV107X_GPIO_BASE + 0x4 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "set",
> > +			.start	= TNETV107X_GPIO_BASE + 0x10,
> > +			.end	= TNETV107X_GPIO_BASE + 0x10 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "dirin",
> > +			.start	= TNETV107X_GPIO_BASE + 0x1c,
> > +			.end	= TNETV107X_GPIO_BASE + 0x1c + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "en",
> > +			.start	= TNETV107X_GPIO_BASE + 0x28,
> > +			.end	= TNETV107X_GPIO_BASE + 0x28 + 0x4 - 1,
> > +		},
> > +	},
> > +};
> 
> Wow, this ends up looking horrible. (yes, I know it is not your
> fault).  I backed off earlier on using resources for the offsets, but
> I want to change my mind again and make interface a register range +
> offsets to the control registers.

Why is this horrible? Are you proposing a single resource + platform
data for the offsets? If so, this won't look any better, but in return

- this would complicate device registration logic and driver logic
  itself (i.e. we need to allocate platform data in the arch code,
  then parse and store the structure in the driver). The platform
  data is simply unnecessary -- we have resources that describe
  memory just fine, much better then raw 'unsigned long offset';

- we lose the ability to operate on spread registers (think of
  "enable" register is down below 2MB gap, near the pinmux
  registers block);

- In the device tree, we really want to describe registers in the
  regs = <> property, because that's where memory resources should
  be. (We also want to map address position into resource name, but
  that's different story).

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@gmail.com

WARNING: multiple messages have this Message-ID (diff)
From: cbouatmailru@gmail.com (Anton Vorontsov)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/RFT 2/2] davinci: use generic memory mapped gpio for tnetv107x
Date: Wed, 13 Jul 2011 18:46:24 +0400	[thread overview]
Message-ID: <20110713144624.GA7875@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <20110706220240.GF5371@ponder.secretlab.ca>

Hi Grant,

On Wed, Jul 06, 2011 at 04:02:40PM -0600, Grant Likely wrote:
[...]
> > +		{
> > +			.name	= "dat",
> > +			.start	= TNETV107X_GPIO_BASE + 0x4,
> > +			.end	= TNETV107X_GPIO_BASE + 0x4 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "set",
> > +			.start	= TNETV107X_GPIO_BASE + 0x10,
> > +			.end	= TNETV107X_GPIO_BASE + 0x10 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "dirin",
> > +			.start	= TNETV107X_GPIO_BASE + 0x1c,
> > +			.end	= TNETV107X_GPIO_BASE + 0x1c + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "en",
> > +			.start	= TNETV107X_GPIO_BASE + 0x28,
> > +			.end	= TNETV107X_GPIO_BASE + 0x28 + 0x4 - 1,
> > +		},
> > +	},
> > +};
> 
> Wow, this ends up looking horrible. (yes, I know it is not your
> fault).  I backed off earlier on using resources for the offsets, but
> I want to change my mind again and make interface a register range +
> offsets to the control registers.

Why is this horrible? Are you proposing a single resource + platform
data for the offsets? If so, this won't look any better, but in return

- this would complicate device registration logic and driver logic
  itself (i.e. we need to allocate platform data in the arch code,
  then parse and store the structure in the driver). The platform
  data is simply unnecessary -- we have resources that describe
  memory just fine, much better then raw 'unsigned long offset';

- we lose the ability to operate on spread registers (think of
  "enable" register is down below 2MB gap, near the pinmux
  registers block);

- In the device tree, we really want to describe registers in the
  regs = <> property, because that's where memory resources should
  be. (We also want to map address position into resource name, but
  that's different story).

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru at gmail.com

  parent reply	other threads:[~2011-07-13 14:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-05  5:10 [RFC/RFT 0/2] gpio: move tnetv107x gpio support to drivers/gpio Sekhar Nori
2011-07-05  5:10 ` Sekhar Nori
2011-07-05  5:10 ` [RFC/RFT 1/2] gpio/basic_mmio: add support for enable register Sekhar Nori
2011-07-05  6:15   ` Ryan Mallon
2011-07-05  6:15     ` Ryan Mallon
2011-07-05  8:32     ` Nori, Sekhar
2011-07-05  8:32       ` Nori, Sekhar
2011-07-06 21:10     ` Grant Likely
2011-07-06 21:10       ` Grant Likely
2011-07-07 16:45       ` Nori, Sekhar
2011-07-07 16:45         ` Nori, Sekhar
2011-07-07 18:37         ` Grant Likely
2011-07-07 18:37           ` Grant Likely
2011-07-07 21:23           ` Ryan Mallon
2011-07-07 21:23             ` Ryan Mallon
2011-07-05  5:11 ` [RFC/RFT 2/2] davinci: use generic memory mapped gpio for tnetv107x Sekhar Nori
2011-07-06 22:02   ` Grant Likely
2011-07-06 22:02     ` Grant Likely
2011-07-07 12:18     ` Nori, Sekhar
2011-07-07 12:18       ` Nori, Sekhar
2011-07-13 14:46     ` Anton Vorontsov [this message]
2011-07-13 14:46       ` Anton Vorontsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110713144624.GA7875@oksana.dev.rtsoft.ru \
    --to=cbouatmailru@gmail.com \
    --cc=cyril@ti.com \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=grant.likely@secretlab.ca \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nsekhar@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.