Date: Wed, 25 May 2011 15:35:27 +0200
From: Anatolij Gustschin <agust@denx.de>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, dzu@denx.de
Subject: Re: [PATCH 1/2] misc/eeprom: add driver for 93xx46 EEPROMs over
 GPIO
Message-ID: <20110525153527.2811487d@wker>
In-Reply-To: <4DDCCC82.90604@cam.ac.uk>
References: <1306252963-20746-1-git-send-email-agust@denx.de>
	<4DDCCC82.90604@cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1438
Lines: 33

On Wed, 25 May 2011 10:31:46 +0100
Jonathan Cameron <jic23@cam.ac.uk> wrote:

> On 05/24/11 17:02, Anatolij Gustschin wrote:
> > 93xx46 EEPROMs can be connected using GPIO lines. Add a generic
> > 93xx46 EEPROM driver using common GPIO API for such configurations.
> > A platform is supposed to register appropriate 93xx46 gpio device
> > providing GPIO interface description and using this driver
> > read/write/erase access to the EEPROM chip can be easily done
> > over sysfs files.
> Could you explain why this makes more sense than an spi driver and
> use of spi_gpio ?
> 
> It's microwire compatible according to random google provided datasheet,
> which iirc is a particular form of spi (half duplex, spi mode 0 according
> to wikipedia)
> 
> That would give us a more generally useful driver.

I thought about using spi_gpio first, then I decided to
do it in an independent driver since on the hardware the
driver was written for we additionally need to control
logic to hold pixel link chips in reset when eeprom access
is performed. Putting appropriate hacks to spi_gpio driver 
didn't seem to be right approach. Controlling this logic
from user space is error-prone, too.

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/