Hi,
If the following program is performed for touch screen control, we expect
1 tx command for controlling SPI and 2 Rx commands for reading data
-
spi_message_init(m);
/* y- still on; turn on only y+ (and ADC) */
ts->read_y = READ_Y(vref);
x->tx_buf = &ts->re
Hello,
I've got an AT91RM9200, running 2.6.20. I'd like to be able to do
something like:
% dd if=myfile.dat of=/dev/mtdblock/2
which is an Atmel dataflash on SPI. I get 'operation not permitted'.
The device file is marked as writable, and I removed the mask bit that
says the
On Fri, 11 Jan 2008 10:33:16 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> > > +struct device *class_find_device(struct class *class, void *data,
> > > +int (*match)(struct device *, void *))
> > > +{
> > > + struct device *dev;
> > > +
> > > + if (!clas
On Jan 11, 2008 4:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Jan 2008 10:33:16 +0800,
> "Dave Young" <[EMAIL PROTECTED]> wrote:
>
>
> > > > +struct device *class_find_device(struct class *class, void *data,
> > > > +int (*match)(struct device *, voi
On Jan 10, 2008 9:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008 17:48:43 +0800,
> Dave Young <[EMAIL PROTECTED]> wrote:
>
> Please add a kerneldoc comment for each of the new interfaces.
Will do.
>
> > +int class_for_each_device(struct class *class, void *data,
> > +
On Jan 10, 2008 11:41 PM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008, Dave Young wrote:
>
> > Hi,
> > The patches are done on my side, please help to check.
> >
> > This is the first one of the series about driver core changes.
> > If this one is accepted and there's no other probl
On Jan 11, 2008 2:39 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
> > The patches are done on my side, please help to check.
>
> Along with all of the other comments from people, I have a few.
>
> > This is the first one of the series about dr
On Wed, Jan 09, 2008 at 02:39:23PM +0800, Dave Young wrote:
> On Jan 9, 2008 2:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 9, 2008 2:13 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> > > > On Jan 9, 2008 6:48 AM, G
Dave Young wrote:
> This is the first one of the series about driver core changes.
Please always provide kerneldoc comments when you add new API elements;
here: exported functions.
It's unfortunate that the driver core's API isn't fully documented yet,
and you shouldn't make it worse.
That's onl
On Thu, Jan 10, 2008 at 05:48:43PM +0800, Dave Young wrote:
> The patches are done on my side, please help to check.
Along with all of the other comments from people, I have a few.
> This is the first one of the series about driver core changes.
> If this one is accepted and there's no other pr
On Jan 10, 2008 8:34 PM, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Dave Young wrote:
> > This is the first one of the series about driver core changes.
>
> Please always provide kerneldoc comments when you add new API elements;
> here: exported functions.
>
> It's unfortunate that the driver core
On Jan 9, 2008 6:48 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
> > On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> > > > It's already in the driver core to th
On Jan 9, 2008 2:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
>
> On Jan 9, 2008 2:13 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> > > On Jan 9, 2008 6:48 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > On Tue, Jan 08, 2008 at 03:05:
On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> It's already in the driver core to the most part. It remains to be seen
> what is less complicated in the end: Transparent mutex-protected list
> accesses provided by driver core (requires the iterator), or all the
> necessary lock
On Jan 9, 2008 2:13 PM, Dave Young <[EMAIL PROTECTED]> wrote:
>
> On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> > On Jan 9, 2008 6:48 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
> > > > On Jan 8, 2008 1:20 AM, Greg KH <[EM
On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> On Jan 9, 2008 6:48 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
> > > On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > On Mon, Jan 07, 2008 at 06:13:37PM +0100,
On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> > It's already in the driver core to the most part. It remains to be seen
> > what is less complicated in the end: Transparent mutex-protected list
> > accesses provided
On Tue, Jan 08, 2008 at 03:05:10PM +0800, Dave Young wrote:
> On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> > > It's already in the driver core to the most part. It remains to be seen
> > > what is less complicated
Greg KH wrote:
> On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
>> David Brownell wrote:
>> > On Monday 07 January 2008, Greg KH wrote:
>> >> Most of the non-driver core code should be converted to not use the
>> >> lock in the class at all. They should use a local lock instead.
>
David Brownell wrote:
> On Monday 07 January 2008, Greg KH wrote:
>> Most of the non-driver core code should be converted to not use the
>> lock in the class at all. They should use a local lock instead.
>
> Or better yet, that yet-to-be-written class_for_each_instance()
> iterator ... :)
By far
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
> David Brownell wrote:
> > On Monday 07 January 2008, Greg KH wrote:
> >> Most of the non-driver core code should be converted to not use the
> >> lock in the class at all. They should use a local lock instead.
> >
> > Or better yet
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
> David Brownell wrote:
> > On Monday 07 January 2008, Greg KH wrote:
> >> Most of the non-driver core code should be converted to not use the
> >> lock in the class at all. They should use a local lock instead.
> >
> > Or better yet
Jarek Poplawski wrote:
>> David Brownell wrote:
>> > On Monday 07 January 2008, Greg KH wrote:
>> >> Most of the non-driver core code should be converted to not use the
>> >> lock in the class at all. They should use a local lock instead.
>> >
>> > Or better yet, that yet-to-be-written class_for_
On Sun, Jan 06, 2008 at 07:41:29PM +0100, Stefan Richter wrote:
> Dave Young wrote:
> > Convert semaphore to mutex in struct class.
> > All the patches in this series should be applyed simultaneously
>
> Therefore you eventually need to repost it as a single patch. It can't
> go into one of the m
On Mon, Jan 07, 2008 at 10:09:44AM +0800, Dave Young wrote:
>
> Thanks for your comment, I rewrite it for 2.6.24-rc7 as a all-in-one
> patch, please see following. Drop i2c maintainer and list in cc
> because there's no changes about i2c in this patch:
>
> Convert semaphore to mutex in struct cla
On Jan 7, 2008 4:45 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 07, 2008 at 10:09:44AM +0800, Dave Young wrote:
> >
> > Thanks for your comment, I rewrite it for 2.6.24-rc7 as a all-in-one
> > patch, please see following. Drop i2c maintainer and list in cc
> > because there's no changes ab
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
> On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
> > Convert semaphore to mutex in struct class.
> ...
> > One lockdep warning detected as following, thus use mutex_lock_nested with
> > SINGLE_DEPTH_NESTING in class_devi
On Jan 3, 2008 3:24 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
> > On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
> > > Convert semaphore to mutex in struct class.
> > ...
> > > One lockdep warning detected as follo
On Thu, Jan 03, 2008 at 03:21:36PM +0800, Dave Young wrote:
...
> I don't know if there's other possible warning places with this mutex
> or not, if you have any ideas about this, please tell me.
I think lockdep is just to tell such things. So, the question is, how
much it was tested already, bec
Dave Young wrote:
> Convert semaphore to mutex in struct class.
> All the patches in this series should be applyed simultaneously
Therefore you eventually need to repost it as a single patch. It can't
go into one of the maintainer trees otherwise, because they only take
fully bijectable patches.
Convert semaphore to mutex in struct class.
All the patches in this series should be applyed simultaneously
toc:
---
1-driver-core-struct-class-convert-semaphore-to-mutex.patch
2-i2c-struct-class-convert-semaphore-to-mutex.patch
3-ieee1394-struct-class-convert-semaphore-to-mutex.patch
4-power-stru
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
> Convert semaphore to mutex in struct class.
...
> One lockdep warning detected as following, thus use mutex_lock_nested with
> SINGLE_DEPTH_NESTING in class_device_add
>
> Jan 3 10:45:15 darkstar kernel: ==
On Thu, 10 Jan 2008, Dave Young wrote:
> Hi,
> The patches are done on my side, please help to check.
>
> This is the first one of the series about driver core changes.
> If this one is accepted and there's no other problem I will post the others
> for maintainer's review (they need your comme
On Monday 07 January 2008, Greg KH wrote:
> Most of the non-driver core code should be converted to not use the
> lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
iterator ... :)
-
On Mon, 7 Jan 2008, Stefan Richter wrote:
> Semi off-topic: What about struct device.sem? Is there any chance to
> rip this out of the driver core and let drivers serialize everything? I
> suppose not...
There isn't. The core uses that lock.
Alan Stern
-
On Thu, 10 Jan 2008 17:48:43 +0800,
Dave Young <[EMAIL PROTECTED]> wrote:
Please add a kerneldoc comment for each of the new interfaces.
> +int class_for_each_device(struct class *class, void *data,
> +int (*fn)(struct device *, void *))
> +{
> + struct device *dev;
>
36 matches
Mail list logo
