Matthias Fuchs wrote:
> On Tuesday 12 September 2006 18:46, Wolfgang Grandegger wrote:
>> Matthias Fuchs wrote:
>>> Hi,
>>>
>>> here's the 2nd try:
>>> - updated external clock frequency handling
>>> - use request_mem_region() before remapping memory
>>> - renamed local variable mem to vmem in clea
On Tuesday 12 September 2006 18:46, Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
> > Hi,
> >
> > here's the 2nd try:
> > - updated external clock frequency handling
> > - use request_mem_region() before remapping memory
> > - renamed local variable mem to vmem in clean loop because it shadowe
Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
>> Hi,
>>
>> here's the 2nd try:
>> - updated external clock frequency handling
>> - use request_mem_region() before remapping memory
>> - renamed local variable mem to vmem in clean loop because it shadowed
>> a
>> module parameter
>
> I have
Matthias Fuchs wrote:
Hi,
here's the 2nd try:
- updated external clock frequency handling
- use request_mem_region() before remapping memory
- renamed local variable mem to vmem in clean loop because it shadowed a
module parameter
I have one more comment, sorry. I think you should use:
Hi,
here's the 2nd try:
- updated external clock frequency handling
- use request_mem_region() before remapping memory
- renamed local variable mem to vmem in clean loop because it shadowed a
module parameter
Now it's on you to decide if we should merge and/or rename. I wouldn't merge
be
Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
>> Hi Wolfgang,
>>
>> On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote:
>>> What about using request_mem_region()? While looking to the driver I now
>> ... will be added, of course.
>>> realize, that it's mainly duplicated code. Does
Matthias Fuchs wrote:
Hi Wolfgang,
On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote:
What about using request_mem_region()? While looking to the driver I now
... will be added, of course.
realize, that it's mainly duplicated code. Does it not make more sense
to make a combined io
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi,
attached you will find a patch that adds support for memory mapped
SJA1000 CAN controllers as they often can be found on embedded boards.
The driver is based on the rtmen_isa driver.
What about using request_m
Hi Wolfgang,
On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote:
> What about using request_mem_region()? While looking to the driver I now
... will be added, of course.
> realize, that it's mainly duplicated code. Does it not make more sense
> to make a combined io/mem driver. If io
Wolfgang Grandegger wrote:
> Hi Matthias,
>
> Matthias Fuchs wrote:
>> Hi,
>>
>> attached you will find a patch that adds support for memory mapped
>> SJA1000 CAN controllers as they often can be found on embedded boards.
>> The driver is based on the rtmen_isa driver.
>
> What about using reques
Matthias Fuchs wrote:
> Hi,
>
> attached you will find a patch that adds support for memory mapped SJA1000
> CAN
> controllers as they often can be found on embedded boards. The driver is
> based on the rtmen_isa driver.
Thanks for your patch! Below are only cleanup comments, not all directed
Hi Matthias,
Matthias Fuchs wrote:
Hi,
attached you will find a patch that adds support for memory mapped SJA1000 CAN
controllers as they often can be found on embedded boards. The driver is
based on the rtmen_isa driver.
What about using request_mem_region()? While looking to the driver I
Hi,
attached you will find a patch that adds support for memory mapped SJA1000 CAN
controllers as they often can be found on embedded boards. The driver is
based on the rtmen_isa driver.
The driver has been tested on esd's embedded PowerPC boards with AMCC PPC405
CPUs.
Thanks to Jan for givin
13 matches
Mail list logo
