* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Johnny Hung @ 2009-11-19 10:19 UTC (permalink / raw)
To: Viral Mehta; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <4B05187F.6030809@einfochips.com>
It doesn't works. :(
2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
> How about putting \n at the end ?
>
> Just try out,
>
> __asm__ volatile ("movl %0, %%ebx\n"
> "movl %1, %%ecx\n"
>
>
>
>
> Thanks,
> Viral Mehta,
> Embedded Software Engineer,
> Tel. No. 91 79 26563705, Ext. 423
> www.einfochips.com <http://www.einfochips.com>
> Prepare and Prevent rather than Repair and Repent
>
>
> Johnny Hung wrote:
>>
>> Hi All:
>> I want to move two local valuables to x86 arch CPU ebx, ecx
>> register and do outb cpu instruction by using AT&A inline asm in
>> kernel driver. The following code was I wrote but gcc report syntax
>> error:
>> ==
>> unsigned int val = 10;
>> unsigned int tmp = 5;
>> ....
>> __asm__ volatile ("movl %0, %%ebx"
>> "movl %1, %%ecx"
>> "outb $0x27, $0xb2"
>> :
>> :"r"(val), "r"(tmp)
>> :"%ebx", "%ecx"
>> );
>>
>> Does anyone can point me out. Any reply is appreciated.
>>
>> BRs, H. Johnny
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>>
>> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>>
>>
>>
>
> --
> _____________________________________________________________________
> Disclaimer: This e-mail message and all attachments transmitted with it
> are intended solely for the use of the addressee and may contain legally
> privileged and confidential information. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby
> notified that any dissemination, distribution, copying, or other use of
> this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any
> views expressed in this message are those of the individual sender
> unless otherwise stated.Company has taken enough precautions to prevent
> the spread of viruses. However the company accepts no liability for any
> damage caused by any virus transmitted by this email.
> _____________________________________________________________________
>
>
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Viral Mehta @ 2009-11-19 10:21 UTC (permalink / raw)
To: Johnny Hung; +Cc: kernelnewbies, linux-embedded
In-Reply-To: <cb9ecdfa0911190219r11fa165v331a590889edcfd0@mail.gmail.com>
[root@viral temp_c_files]# gcc foo.c
[root@viral temp_c_files]# cat foo.c
#include <stdio.h>
int main()
{
unsigned int val = 10;
unsigned int tmp = 5;
__asm__ volatile ("movl (%0), %%ebx\n"
"movl (%1), %%ecx\n"
: : "r"(val), "r"(tmp) );
}
[root@viral temp_c_files]#
Thanks,
Viral Mehta,
Embedded Software Engineer,
Tel. No. 91 79 26563705, Ext. 423
www.einfochips.com <http://www.einfochips.com>
Prepare and Prevent rather than Repair and Repent
Johnny Hung wrote:
> It doesn't works. :(
>
> 2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
>
>> How about putting \n at the end ?
>>
>> Just try out,
>>
>> __asm__ volatile ("movl %0, %%ebx\n"
>> "movl %1, %%ecx\n"
>>
>>
>>
>>
>> Thanks,
>> Viral Mehta,
>> Embedded Software Engineer,
>> Tel. No. 91 79 26563705, Ext. 423
>> www.einfochips.com <http://www.einfochips.com>
>> Prepare and Prevent rather than Repair and Repent
>>
>>
>> Johnny Hung wrote:
>>
>>> Hi All:
>>> I want to move two local valuables to x86 arch CPU ebx, ecx
>>> register and do outb cpu instruction by using AT&A inline asm in
>>> kernel driver. The following code was I wrote but gcc report syntax
>>> error:
>>> ==
>>> unsigned int val = 10;
>>> unsigned int tmp = 5;
>>> ....
>>> __asm__ volatile ("movl %0, %%ebx"
>>> "movl %1, %%ecx"
>>> "outb $0x27, $0xb2"
>>> :
>>> :"r"(val), "r"(tmp)
>>> :"%ebx", "%ecx"
>>> );
>>>
>>> Does anyone can point me out. Any reply is appreciated.
>>>
>>> BRs, H. Johnny
>>>
>>> --
>>> To unsubscribe from this list: send an email with
>>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>>
>>>
>>>
>>> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>>>
>>>
>>>
>>>
>> --
>> _____________________________________________________________________
>> Disclaimer: This e-mail message and all attachments transmitted with it
>> are intended solely for the use of the addressee and may contain legally
>> privileged and confidential information. If the reader of this message
>> is not the intended recipient, or an employee or agent responsible for
>> delivering this message to the intended recipient, you are hereby
>> notified that any dissemination, distribution, copying, or other use of
>> this message or its attachments is strictly prohibited. If you have
>> received this message in error, please notify the sender immediately by
>> replying to this message and please delete it from your computer. Any
>> views expressed in this message are those of the individual sender
>> unless otherwise stated.Company has taken enough precautions to prevent
>> the spread of viruses. However the company accepts no liability for any
>> damage caused by any virus transmitted by this email.
>> _____________________________________________________________________
>>
>>
>>
>
>
> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>
>
>
--
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
_____________________________________________________________________
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Johnny Hung @ 2009-11-19 11:11 UTC (permalink / raw)
To: Viral Mehta; +Cc: kernelnewbies, linux-embedded
In-Reply-To: <4B051C40.5040003@einfochips.com>
Thank you. I got error because the valuable I actually pass is a
member of structure point. ex.
__asm__ volatile ("movl (%0), %%ebx\n"
"movl (%1), %%ecx\n"
: : "r"(ptr->cnt), "r"(ptr->blk) );
I reassigned ptr->cnt and ptr->blk to local unsigned int valuable and
compile successfully. BTW, the first ':' is mean output operands,
second ':' is mean input operands but how about third ':'. Does it
mean which registers had been changed in inline asm code? So, does gcc
do push and pop to retain these registers in the front and end of asm
code?
I have tried to compile inline asm in user space application and
use gcc -S flag to translate c code to asm code. How do I translate
kernel driver to asm code without compile to obj file?
Thank your help
BR, H. Johnny
2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
> [root@viral temp_c_files]# gcc foo.c
> [root@viral temp_c_files]# cat foo.c
> #include <stdio.h>
> int main()
> {
> unsigned int val = 10;
> unsigned int tmp = 5;
>
> __asm__ volatile ("movl (%0), %%ebx\n"
> "movl (%1), %%ecx\n"
> : : "r"(val), "r"(tmp) );
> }
>
> [root@viral temp_c_files]#
> Thanks,
> Viral Mehta,
> Embedded Software Engineer,
> Tel. No. 91 79 26563705, Ext. 423
> www.einfochips.com <http://www.einfochips.com>
> Prepare and Prevent rather than Repair and Repent
>
>
> Johnny Hung wrote:
>>
>> It doesn't works. :(
>>
>> 2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
>>
>>>
>>> How about putting \n at the end ?
>>>
>>> Just try out,
>>>
>>> __asm__ volatile ("movl %0, %%ebx\n"
>>> "movl %1, %%ecx\n"
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Viral Mehta,
>>> Embedded Software Engineer,
>>> Tel. No. 91 79 26563705, Ext. 423
>>> www.einfochips.com <http://www.einfochips.com>
>>> Prepare and Prevent rather than Repair and Repent
>>>
>>>
>>> Johnny Hung wrote:
>>>
>>>>
>>>> Hi All:
>>>> I want to move two local valuables to x86 arch CPU ebx, ecx
>>>> register and do outb cpu instruction by using AT&A inline asm in
>>>> kernel driver. The following code was I wrote but gcc report syntax
>>>> error:
>>>> ==
>>>> unsigned int val = 10;
>>>> unsigned int tmp = 5;
>>>> ....
>>>> __asm__ volatile ("movl %0, %%ebx"
>>>> "movl %1, %%ecx"
>>>> "outb $0x27, $0xb2"
>>>> :
>>>> :"r"(val), "r"(tmp)
>>>> :"%ebx", "%ecx"
>>>> );
>>>>
>>>> Does anyone can point me out. Any reply is appreciated.
>>>>
>>>> BRs, H. Johnny
>>>>
>>>> --
>>>> To unsubscribe from this list: send an email with
>>>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
>>>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>>>
>>>>
>>>>
>>>> Email Scanned for Virus & Dangerous Content by :
>>>> www.CleanMailGateway.com
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> Disclaimer: This e-mail message and all attachments transmitted with it
>>> are intended solely for the use of the addressee and may contain legally
>>> privileged and confidential information. If the reader of this message
>>> is not the intended recipient, or an employee or agent responsible for
>>> delivering this message to the intended recipient, you are hereby
>>> notified that any dissemination, distribution, copying, or other use of
>>> this message or its attachments is strictly prohibited. If you have
>>> received this message in error, please notify the sender immediately by
>>> replying to this message and please delete it from your computer. Any
>>> views expressed in this message are those of the individual sender
>>> unless otherwise stated.Company has taken enough precautions to prevent
>>> the spread of viruses. However the company accepts no liability for any
>>> damage caused by any virus transmitted by this email.
>>> _____________________________________________________________________
>>>
>>>
>>>
>>
>>
>> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>>
>>
>>
>
> --
> _____________________________________________________________________
> Disclaimer: This e-mail message and all attachments transmitted with it
> are intended solely for the use of the addressee and may contain legally
> privileged and confidential information. If the reader of this message
> is not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby
> notified that any dissemination, distribution, copying, or other use of
> this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any
> views expressed in this message are those of the individual sender
> unless otherwise stated.Company has taken enough precautions to prevent
> the spread of viruses. However the company accepts no liability for any
> damage caused by any virus transmitted by this email.
> _____________________________________________________________________
>
>
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: stas @ 2009-11-20 6:04 UTC (permalink / raw)
To: Johnny Hung; +Cc: Viral Mehta, kernelnewbies, linux-embedded
In-Reply-To: <cb9ecdfa0911190311j6cc50c34hfc7e398cbf0a1072@mail.gmail.com>
It seems to me that this example code is not free of errors. After the
third ":" we should list registers "ebx" and "ecx" to let gcc know they
could change in asm section. There can be no difference in -O0 but may
have large impact on result in -O{2,3} modes.
Actually resulting code may not include "push <some reg>"->"asm
section"->"pop <some reg>" code. In the compile time gcc would decide
when and what should be on registers. So it may look like "movl smth,
reg"->"asm section"->"do nothing with reg, because we don't need it any
more or directly put some value using movl".
__asm__ volatile (
"movl (%0), %%ebx\n\t"
"movl (%1), %%ecx\n\t"
"outl %%ebx, $0xb2\n\t"
"outl %%ecx, $0xb6\n\t"
:
: "r"(var_a), "r"(var_b)
: "ebx", "ecx"
);
There is another way. You can select registers should be used to pass
arguments into the asm section (you can select registers to get results
too). That should look much more pretty.
The SAME code:
__asm__ volatile (
"outl %%ebx, $0xb2\n\t"
"outl %%ecx, $0xb6\n\t"
:
: "b"(var_a), "c"(var_b)
);
And much more pretty way:
/* taken from linux-2.6./include/asm-generic/io.h
If you want to use it in user-space just replace u8 with unsigned char,
u16 with unsigned short. In kernel space just insert #include directive.
*/
static inline void outb(u8 v, u16 port)
{
asm volatile("outb %0,%1" : : "a" (v), "dN" (port));
}
...
outb(var_a, 0xb2);
outb(var_b, 0xb6);
> Thank you. I got error because the valuable I actually pass is a
> member of structure point. ex.
>
> __asm__ volatile ("movl (%0), %%ebx\n"
> "movl (%1), %%ecx\n"
> : : "r"(ptr->cnt), "r"(ptr->blk) );
>
> I reassigned ptr->cnt and ptr->blk to local unsigned int valuable and
> compile successfully. BTW, the first ':' is mean output operands,
> second ':' is mean input operands but how about third ':'. Does it
> mean which registers had been changed in inline asm code? So, does gcc
> do push and pop to retain these registers in the front and end of asm
> code?
> I have tried to compile inline asm in user space application and
> use gcc -S flag to translate c code to asm code. How do I translate
> kernel driver to asm code without compile to obj file?
>
> Thank your help
> BR, H. Johnny
>
> 2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
> > [root@viral temp_c_files]# gcc foo.c
> > [root@viral temp_c_files]# cat foo.c
> > #include <stdio.h>
> > int main()
> > {
> > unsigned int val = 10;
> > unsigned int tmp = 5;
> >
> > __asm__ volatile ("movl (%0), %%ebx\n"
> > "movl (%1), %%ecx\n"
> > : : "r"(val), "r"(tmp) );
> > }
> >
> > [root@viral temp_c_files]#
> > Thanks,
> > Viral Mehta,
> > Embedded Software Engineer,
> > Tel. No. 91 79 26563705, Ext. 423
> > www.einfochips.com <http://www.einfochips.com>
> > Prepare and Prevent rather than Repair and Repent
> >
> >
> > Johnny Hung wrote:
> >>
> >> It doesn't works. :(
> >>
> >> 2009/11/19 Viral Mehta <viral.mehta@einfochips.com>:
> >>
> >>>
> >>> How about putting \n at the end ?
> >>>
> >>> Just try out,
> >>>
> >>> __asm__ volatile ("movl %0, %%ebx\n"
> >>> "movl %1, %%ecx\n"
> >>>
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Viral Mehta,
> >>> Embedded Software Engineer,
> >>> Tel. No. 91 79 26563705, Ext. 423
> >>> www.einfochips.com <http://www.einfochips.com>
> >>> Prepare and Prevent rather than Repair and Repent
> >>>
> >>>
> >>> Johnny Hung wrote:
> >>>
> >>>>
> >>>> Hi All:
> >>>> I want to move two local valuables to x86 arch CPU ebx, ecx
> >>>> register and do outb cpu instruction by using AT&A inline asm in
> >>>> kernel driver. The following code was I wrote but gcc report syntax
> >>>> error:
> >>>> ==
> >>>> unsigned int val = 10;
> >>>> unsigned int tmp = 5;
> >>>> ....
> >>>> __asm__ volatile ("movl %0, %%ebx"
> >>>> "movl %1, %%ecx"
> >>>> "outb $0x27, $0xb2"
> >>>> :
> >>>> :"r"(val), "r"(tmp)
> >>>> :"%ebx", "%ecx"
> >>>> );
> >>>>
> >>>> Does anyone can point me out. Any reply is appreciated.
> >>>>
> >>>> BRs, H. Johnny
> >>>>
> >>>> --
> >>>> To unsubscribe from this list: send an email with
> >>>> "unsubscribe kernelnewbies" to ecartis@nl.linux.org
> >>>> Please read the FAQ at http://kernelnewbies.org/FAQ
> >>>>
> >>>>
> >>>>
> >>>> Email Scanned for Virus & Dangerous Content by :
> >>>> www.CleanMailGateway.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> _____________________________________________________________________
> >>> Disclaimer: This e-mail message and all attachments transmitted with it
> >>> are intended solely for the use of the addressee and may contain legally
> >>> privileged and confidential information. If the reader of this message
> >>> is not the intended recipient, or an employee or agent responsible for
> >>> delivering this message to the intended recipient, you are hereby
> >>> notified that any dissemination, distribution, copying, or other use of
> >>> this message or its attachments is strictly prohibited. If you have
> >>> received this message in error, please notify the sender immediately by
> >>> replying to this message and please delete it from your computer. Any
> >>> views expressed in this message are those of the individual sender
> >>> unless otherwise stated.Company has taken enough precautions to prevent
> >>> the spread of viruses. However the company accepts no liability for any
> >>> damage caused by any virus transmitted by this email.
> >>> _____________________________________________________________________
> >>>
> >>>
> >>>
> >>
> >>
> >> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
> >>
> >>
> >>
> >
> > --
> > _____________________________________________________________________
> > Disclaimer: This e-mail message and all attachments transmitted with it
> > are intended solely for the use of the addressee and may contain legally
> > privileged and confidential information. If the reader of this message
> > is not the intended recipient, or an employee or agent responsible for
> > delivering this message to the intended recipient, you are hereby
> > notified that any dissemination, distribution, copying, or other use of
> > this message or its attachments is strictly prohibited. If you have
> > received this message in error, please notify the sender immediately by
> > replying to this message and please delete it from your computer. Any
> > views expressed in this message are those of the individual sender
> > unless otherwise stated.Company has taken enough precautions to prevent
> > the spread of viruses. However the company accepts no liability for any
> > damage caused by any virus transmitted by this email.
> > _____________________________________________________________________
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Américo Wang @ 2009-11-20 6:48 UTC (permalink / raw)
To: Johnny Hung; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <cb9ecdfa0911190150w4edbacdfp24a7069c618193f4@mail.gmail.com>
On Thu, Nov 19, 2009 at 5:50 PM, Johnny Hung <johnny.hacking@gmail.com> wrote:
> Hi All:
> I want to move two local valuables to x86 arch CPU ebx, ecx
> register and do outb cpu instruction by using AT&A inline asm in
> kernel driver. The following code was I wrote but gcc report syntax
> error:
You must mean AT&T.
> ==
> unsigned int val = 10;
> unsigned int tmp = 5;
> ....
> __asm__ volatile ("movl %0, %%ebx"
You need to put "\n\t" in the end of each asm statement.
> "movl %1, %%ecx"
> "outb $0x27, $0xb2"
This is wrong, 'outb' instruction cann't accept both of
its operands as constants, IIRC.
> :
> :"r"(val), "r"(tmp)
> :"%ebx", "%ecx"
> );
>
> Does anyone can point me out. Any reply is appreciated.
Regards.
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Jiri Slaby @ 2009-11-20 8:45 UTC (permalink / raw)
To: Johnny Hung; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <cb9ecdfa0911190150w4edbacdfp24a7069c618193f4@mail.gmail.com>
On 11/19/2009 10:50 AM, Johnny Hung wrote:
> Hi All:
> I want to move two local valuables to x86 arch CPU ebx, ecx
> register and do outb cpu instruction by using AT&A inline asm in
> kernel driver. The following code was I wrote but gcc report syntax
> error:
> ==
> unsigned int val = 10;
> unsigned int tmp = 5;
> ....
> __asm__ volatile ("movl %0, %%ebx"
> "movl %1, %%ecx"
> "outb $0x27, $0xb2"
> :
> :"r"(val), "r"(tmp)
> :"%ebx", "%ecx"
> );
>
> Does anyone can point me out. Any reply is appreciated.
Why not just:
("outb $0x27, %%al" : : "a" (0xb2), "b"(val), "c" (tmp));
--
js
Faculty of Informatics, Masaryk University
Suse Labs, Novell
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: David Woodhouse @ 2009-11-20 10:43 UTC (permalink / raw)
To: stas; +Cc: Johnny Hung, Viral Mehta, kernelnewbies, linux-embedded
In-Reply-To: <1258697050.16509.36.camel@sotona>
On Fri, 2009-11-20 at 09:04 +0300, stas wrote:
> It seems to me that this example code is not free of errors. After the
> third ":" we should list registers "ebx" and "ecx" to let gcc know
> they could change in asm section.
>
> __asm__ volatile (
> "movl (%0), %%ebx\n\t"
> "movl (%1), %%ecx\n\t"
> "outl %%ebx, $0xb2\n\t"
> "outl %%ecx, $0xb6\n\t"
>
>
> :
> : "r"(var_a), "r"(var_b)
> : "ebx", "ecx"
That's not good enough. Because the compiler could choose to use %ebx
for passing in 'var_b', and then it would get clobbered before you move
it to %ecx in the second instruction.
You'd need to make it an earlyclobber too.
>
> The SAME code:
> __asm__ volatile (
> "outl %%ebx, $0xb2\n\t"
> "outl %%ecx, $0xb6\n\t"
> :
> : "b"(var_a), "c"(var_b)
> );
That's the better approach, although yours didn't do what Johnny's
original seemed to. Jiri Slaby posted something which looks correct.
> /* taken from linux-2.6./include/asm-generic/io.h
> If you want to use it in user-space just replace u8 with unsigned char,
> u16 with unsigned short. In kernel space just insert #include directive.
> */
> static inline void outb(u8 v, u16 port)
And that's just an entirely gratuitous use of our kernel nonsense-types.
Just use the proper C types uint16_t and uint8_t instead.
Or just 'unsigned char' and 'unsigned short', for that matter -- I
believe Linux would blow up horribly if those types ever changed from
8-bit and 16-bit respectively.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-20 22:14 UTC (permalink / raw)
To: David Brownell; +Cc: Mike Frysinger, Bill Gatliff, linux-embedded
In-Reply-To: <200911162347.02364.david-b@pacbell.net>
On Tue, Nov 17, 2009 at 12:47 AM, David Brownell <david-b@pacbell.net> wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>> Right now, I don't
>> see a fundamental difference is between GPIO and PWM pin management.
>> It is essentially the same problem, and in many cases PWM pins can
>> also be used as GPIOs.
>
> Pin management for a given SoC is going to be relevant to setting
> every signal, no matter what peripheral it's associated with. The
> same argument applies to an MDIO bus, I2C, 1-wire, and more.
>
> And I don't buy it in those cases either.
>
>
>> I think the question should be flipped around;
>> rather than asking for a compelling reason for them to be merged; I
>> want to know the compelling reason to keep them separate. What is the
>> fundamental difference that keeps them apart?
>
> PWM is about periodic signal generation without CPU intervention.
>
> GPIO is about explicit CPU management/interrogation of single
> signals.
Can also be viewed from the perspective: It is about putting a pin
into a particular state until I explicitly tell you to change it.
Whether that state be a GPIO input, a GPIO high, a GPIO low, or a PWM
periodic.
>> What I would like to see is the PWM functions added to the GPIO API.
>
> No. If you want a pin mux interface, come up with one of them.
>
> It shouldn't be a PWM interface, a GPIO interface, an I2C interface,
> a SPI interface, an MDIO interface, a 1-wire interface ... or any of
> dozens of other things. It'd be purely for pinmux.
I'm not talking about a pin mux interface. I'm talking about discrete
controllable entities. I agree that pin muxing is an entirely
different scope. I'm also not talking about layers on top of the
GPIO. I'm talking about the management code to obtain a reference to
the pin your interested in. There is a non-trivial amount of code
associated with getting a reference to a pin and the behaviour
required is largely identical between GPIO and PWM. I don't want to
see a new subsystem that largely does the exact same job, but is
different in subtle ways. I think it should either be a unified
PWM/GPIO pin management subsystem, or a common library used by each.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-20 22:21 UTC (permalink / raw)
To: David Brownell; +Cc: Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <200911170027.38664.david-b@pacbell.net>
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell <david-b@pacbell.net> wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>> I'm concerned about the approach taken here. As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external signal line, just like GPIO lines.
>
> PWM is not GPIO, and doesn't fit into a GPIO framework.
>
> Since *everything* boils down to one or more signal lines,
> your argument leads directly to Linux having no native
> hardware interface except GPIOs. Not ... practical. ;)
I think you've missed my point and taken it to an illogical extreme to
counter it. I agree that PWMs are not GPIOs and visa versa. However,
*some* devices are both GPIOs and PWMs. Also what is needed to manage
GPIO and PWM pins is pretty much identical.
>> The difference being
>> that PWMs cannot do input, and has additional capabilities (can be
>> programmed with a signal; not just on/off/tristate)
>
> If you want to combine PWM with something else ... timers would
> be a better target. They're both fundamentally about periodic
> phenomena. And quite a lot of timers support PWM output modes...
>
> (A generic interface to hardware timers is lacking, too.)
>
>
>> What is the reason for bringing in an entirely new framework instead
>> of extending the GPIO API or gpiolib? I'm not too excited about
>> having two entirely different frameworks for what basically boils down
>> to "numbered signal pins".
>
> You seem to mis-understand what PWM is all about, then.
> The whole point of a PWM is to set up a periodic activity
> that will run without CPU intervention.
I understand that.
> GPIOs, on the other hand, are packaged for manual bit
> twiddling. While it's possible to create low-speed
> implementations of serial protocols using GPIOs (like
> 2-wire/I2C, one-wire, and various SPI variants), those
> are explicitly the high-overhead (and low performance)
> substitutes, to be used only when native hardware isn't
> available (or is broken etc).
But that *isn't* the primary purpose of the GPIO subsystem. All that
stuff is layered on top of the GPIO pin management code and doesn't
really play into this debate.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-20 22:49 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, Mike Frysinger, David Brownell
In-Reply-To: <4B02C3A6.5030000@billgatliff.com>
On Tue, Nov 17, 2009 at 8:39 AM, Bill Gatliff <bgat@billgatliff.com> wrote:
> Grant Likely wrote:
>> Hi Bill
>>
>> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff <bgat@billgatliff.com> wrote:
>>
>>> This series implements a Generic PWM Device API, including reference
>>> implementations for the Atmel PWMC device, an LED device, and an LED
>>> trigger. It is based on linux-2.6.27.
>>>
>> [...]
>>
>>> The implementation of the Generic PWM Device API is structurally
>>> similar to the generic GPIO API, except that the PWM code uses
>>> platform bus_id strings instead of integers to identify target
>>> deviices. A configuration structure is also provided, both to
>>> facilitate atomic hardware state changes and so that the API can be
>>> extended in a source-code-compatible way to accomodate devices with
>>> features not anticipated by the current code.
>>>
>>
>> Hey Bill,
>>
>> I'm concerned about the approach taken here. As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external signal line, just like GPIO lines. The difference being
>> that PWMs cannot do input, and has additional capabilities (can be
>> programmed with a signal; not just on/off/tristate). Actually, many
>> GPIOs have these properties too. I've got a part with output-only
>> gpios, and gpio devices that also have a PWM.
>
> It's true that PWM signals can be emitted via GPIO pins, and in fact the
> API code I submitted uses the GPIO API combined with an hrtimer to
> generate a low-speed PWM output.
>
> It's also true that things like LEDs might want to be driven by PWM
> signals, and indeed LEDs can also be driven by GPIO pins.
>
> Finally, it's accurate to say that a lot of microcontrollers multiplex
> GPIO functions onto pins that also provide PWM functionality.
>
> But in my opinion, none of the above means that the PWM API and GPIO API
> should be coupled at the interface abstraction. All it means is that in
> some cases, one implementation might be able to "stand in" as an
> embodiment of the other's interface. And we all agree on that for PWM
> and GPIO.
I have no problem with the PWM API. I think it describes most of the
PWM *usage* requirements well, and I agree that GPIO devices can never
implement the PWM API.
> Given a PWM-capable chip that you control over an I2C or SPI interface,
> I don't think anyone would argue that such chips should be viewed as an
> extension of the SPI or I2C APIs just because the chips use those
> communications protocols.
Nor would I.
> I think it's a similar argument for PWM and GPIO.
I don't think that's true, but I'm approaching it from the viewpoint
of managing pins; not the usage API. ie. the difference between
gpiolib (management) and the gpio api (usage).
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-20 22:51 UTC (permalink / raw)
To: David Brownell; +Cc: Bill Gatliff, Mike Frysinger, linux-embedded
In-Reply-To: <200911170853.17994.david-b@pacbell.net>
On Tue, Nov 17, 2009 at 9:53 AM, David Brownell <david-b@pacbell.net> wrote:
> On Tuesday 17 November 2009, Bill Gatliff wrote:
>> David Brownell wrote:
>> >
>> > It'd be purely for pinmux.
>> >
>>
>> Ugh. That would be a tough interface to design.
>
> True. That's part of why I object to wanting to combine
> it with GPIOs ... or, combine everything else with GPIOs
> too (like PWMs).
>
> But Grant talks about wanting such things, and if he can
> deliver it, more power to him.
Just to be clear, I'm *not* talking about pin mux. I fully agree that
is a different problem.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Johnny Hung @ 2009-11-23 3:14 UTC (permalink / raw)
To: Jiri Slaby; +Cc: kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <4B065712.4050202@gmail.com>
After testing:
# gcc inlineasm.c
inlineasm.c: Assembler messages:
inlineasm.c:7: Error: suffix or operands invalid for `out'
[root@debian-johnny] ~/workspace/test
# cat inlineasm.c
#include <stdio.h>
int main ()
{
unsigned int val = 5, tmp = 10;
asm volatile ("outb $0x27, %%al"
:
: "a" (0xb2), "b"(val), "c" (tmp)
);
}
It seems the source of outb instruction cannot be a constant. Is
there a AT&T instructions document for x86?
BRs, H. Johnny
> Why not just:
> ("outb $0x27, %%al" : : "a" (0xb2), "b"(val), "c" (tmp));
> --
> js
> Faculty of Informatics, Masaryk University
> Suse Labs, Novell
>
^ permalink raw reply
* Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
From: Brian Gerst @ 2009-11-23 5:43 UTC (permalink / raw)
To: Johnny Hung; +Cc: Jiri Slaby, kernelnewbies, linux-kernel, linux-embedded
In-Reply-To: <cb9ecdfa0911221914t78f7849h9f00c68420f63d14@mail.gmail.com>
On Sun, Nov 22, 2009 at 10:14 PM, Johnny Hung <johnny.hacking@gmail.com> wrote:
> After testing:
>
> # gcc inlineasm.c
> inlineasm.c: Assembler messages:
> inlineasm.c:7: Error: suffix or operands invalid for `out'
> [root@debian-johnny] ~/workspace/test
>
> # cat inlineasm.c
> #include <stdio.h>
>
> int main ()
> {
> unsigned int val = 5, tmp = 10;
> asm volatile ("outb $0x27, %%al"
> :
> : "a" (0xb2), "b"(val), "c" (tmp)
> );
> }
>
> It seems the source of outb instruction cannot be a constant. Is
> there a AT&T instructions document for x86?
In AT&T syntax, the source register comes first. So it should be
"outb %%al, $0x27", assuming that 0x27 is the port number you are
trying to write to.
--
Brian Gerst
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-23 14:12 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, Mike Frysinger, linux-embedded
In-Reply-To: <fa686aa40911201414u6a9023e6y9addc97635d1c88@mail.gmail.com>
Grant Likely wrote:
> I'm talking about discrete controllable entities.
At the extreme, I see discrete, single-pin GPIO as being a degenerate
case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a
single output, and no dependencies with any other channels or pins.
But the perspectives of the two groups of users are completely
different, so I don't see any advantage to having a combined user-facing
API.
> I'm talking about the management code to obtain a reference to
> the pin your interested in. There is a non-trivial amount of code
> associated with getting a reference to a pin and the behaviour
> required is largely identical between GPIO and PWM.
True, but anything involving pins has to be dealt with at the platform
level. And the general approach for that so far is that the board's
startup code sets the pins how it wants them, and the peripheral drivers
more or less assume that things are as they should be when it comes time
to activate the peripherals themselves. Anything more sophisticated
than that and you prevent the kind of reuse that's taking place now
between AVR32 and AT91, for example.
Maybe that's an opportunity for improvement: an API for pin reservation,
that GPIO, PWM and other platform-oriented drivers could use to request
the pins that they want. A kind of common version of the OMAP mux
management code, if you will.
But I don't think such an API would be all that useful for GPIO- and
PWM-related scenarios. Out of necessity, PWM and GPIO are very specific
to the board hardware, and on-the-fly pin configuration changes aren't
possible: either the hardware needs that pin to be an output, or it
doesn't. You can't make that decision at runtime because you'd probably
have to swap out or add resistors, drivers, etc. The software to do
*that* would be.... tricky. :)
> I don't want to see a new subsystem that largely does the exact same job, but is
> different in subtle ways. I think it should either be a unified
> PWM/GPIO pin management subsystem, or a common library used by each.
>
Where is there overlap? My PWM code is totally pin-agnostic, at least
for the drivers I've worked with so far. And I'm not aware of any GPIO
chip drivers that deal with pin multiplexing, either. Not saying there
aren't any, only that I haven't seen them.
It's a nice idea in the abstract, but I sure don't see how to make it
work well enough in practice to be worth the effort. I'm not saying it
can't be done, just that it isn't my focus. Yours? :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Bill Gatliff @ 2009-11-23 14:13 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linux-embedded, Mike Frysinger
In-Reply-To: <fa686aa40911201421k67d1de27u2c6dbe337989696b@mail.gmail.com>
Grant Likely wrote:
>
> But that *isn't* the primary purpose of the GPIO subsystem. All that
> stuff is layered on top of the GPIO pin management code and doesn't
> really play into this debate.
>
I don't understand you. You are saying that the majority of gpiochip
implementations also deal with pin multiplexing? They must be terribly
broken on the platforms I'm working on, then, because they don't seem to
work at all! :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Mark Brown @ 2009-11-23 15:29 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <fa686aa40911201421k67d1de27u2c6dbe337989696b@mail.gmail.com>
On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
> On Tue, Nov 17, 2009 at 1:27 AM, David Brownell <david-b@pacbell.net> wrote:
> > Since *everything* boils down to one or more signal lines,
> > your argument leads directly to Linux having no native
> > hardware interface except GPIOs. ?Not ... practical. ;)
> I think you've missed my point and taken it to an illogical extreme to
> counter it. I agree that PWMs are not GPIOs and visa versa. However,
> *some* devices are both GPIOs and PWMs. Also what is needed to manage
> GPIO and PWM pins is pretty much identical.
On most of the ARM SoCs PWM and GPIO aren't particularly special here -
most of the on-SoC functionality is multiplexed onto pins through the
same hardware interface. A very large proportion of the pins of the SoC
will have muxes to bring out the signals from the internal IP blocks,
and pretty much all of those will have GPIO as one of those functions.
For many SoCs there will be multiple pin options for bringing out each
of the internal signals which complicates matters further.
> But that *isn't* the primary purpose of the GPIO subsystem. All that
> stuff is layered on top of the GPIO pin management code and doesn't
> really play into this debate.
The GPIO subsystem isn't doing pin management in that way for most
systems, it's just controlling the GPIO functionality and relies on
separate configuration to ensure that the relevant pins are in GPIO
mode.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-23 17:39 UTC (permalink / raw)
To: Bill Gatliff; +Cc: David Brownell, Mike Frysinger, linux-embedded
In-Reply-To: <4B0A9832.20908@billgatliff.com>
On Mon, Nov 23, 2009 at 7:12 AM, Bill Gatliff <bgat@billgatliff.com> wrote:
> Grant Likely wrote:
>> I'm talking about discrete controllable entities.
>
> At the extreme, I see discrete, single-pin GPIO as being a degenerate
> case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a
> single output, and no dependencies with any other channels or pins.
yes
> But the perspectives of the two groups of users are completely
> different, so I don't see any advantage to having a combined user-facing
> API.
... for the control API; yes. ie, the functions that set the GPIO pin
state or the PWM duty cycle. There is no overlap here (except for the
degenerate case of using a PWM as an output only GPIO... which is
useful. Board designers do crazy things).
>> I'm talking about the management code to obtain a reference to
>> the pin your interested in. There is a non-trivial amount of code
>> associated with getting a reference to a pin and the behaviour
>> required is largely identical between GPIO and PWM.
>
> True, but anything involving pins has to be dealt with at the platform
> level.
Not exactly true. GPIO pins do not have to be dealt with at the
platform level when GPIO lib is used. I've got several platforms
where the routing of GPIOs is specified in the device tree data, and
platform code never touches them. When the driver probes a device
implemented via GPIOs, it reads the data and requests the GPIO numbers
that it needs.
*however* I do agree that it is the responsibility of platform code to
set up chip-internal pin muxing and routing. Actually, further than
that, I think it is actually firmware's responsibility to set up chip
internal pin muxing because it leads to more common platform code in
the kernel (less board specific fixups), but the kernel can fix it up
in a pinch. But I'm not arguing about the pin (hardware) setup code.
> And the general approach for that so far is that the board's
> startup code sets the pins how it wants them, and the peripheral drivers
> more or less assume that things are as they should be when it comes time
> to activate the peripherals themselves. Anything more sophisticated
> than that and you prevent the kind of reuse that's taking place now
> between AVR32 and AT91, for example.
>
> Maybe that's an opportunity for improvement: an API for pin reservation,
> that GPIO, PWM and other platform-oriented drivers could use to request
> the pins that they want. A kind of common version of the OMAP mux
> management code, if you will.
Perhaps. But that's not what I'm taking issue with.
> But I don't think such an API would be all that useful for GPIO- and
> PWM-related scenarios. Out of necessity, PWM and GPIO are very specific
> to the board hardware, and on-the-fly pin configuration changes aren't
> possible: either the hardware needs that pin to be an output, or it
> doesn't. You can't make that decision at runtime because you'd probably
> have to swap out or add resistors, drivers, etc. The software to do
> *that* would be.... tricky. :)
>
>
>> I don't want to see a new subsystem that largely does the exact same job, but is
>> different in subtle ways. I think it should either be a unified
>> PWM/GPIO pin management subsystem, or a common library used by each.
>
> Where is there overlap? My PWM code is totally pin-agnostic, at least
> for the drivers I've worked with so far. And I'm not aware of any GPIO
> chip drivers that deal with pin multiplexing, either. Not saying there
> aren't any, only that I haven't seen them.
The overlap is in the management of registered pins. I do not take
issue with the API. In fact, I don't take issue with the code that
you've written either. It appears to be well written. I take issue
with all the common code behind the API to make it work and to allow
GPIOs or PWMs to be registered at runtime. The overlap is the code
and behaviour used to register pins and to obtain a reference to a
pin.
On the PWM side; it's the code backing pwm_register().
pwm_unregister(), pwm_request(), pwm_free(), and the sysfs hooks.
For GPIO; it's gpiochip_add(), gpiochip_remove(), gpio_request(),
gpio_free(), the sysfs hooks, and the device tree bindings.
They perform exactly the same task. The difference is that PWM
devices implement the PWM API and GPIO devices implement the GPIO API;
but the behaviour needed to manage them is identical. I don't like
the fact that it will be implemented twice with subtle differences
between them.
The argument has been made that the split is appropriate because the
use case between GPIO and PWM is considerably different, and to a
point I agree. The PWM use case definitely requires a different API.
However, the argument also makes the assumption that what is a GPIO
and what is a PWM can easily be pinned down. For example, I've got
output only GPIOs, input only GPIOs, and a device that implements both
PWM and GPIO behaviour (not pin muxing). And, as you say, the
degenerate of PWM behaviour is analogous to GPIO output. The range of
behaviour supported by a PWM or GPIO device is entirely dependent on
what the hardware designer chooses to implement, and there isn't a
canonical definition of either GPIO or PWM. If a hard distinction is
made now to manage GPIO and PWM pins separately, what then do we do
with other similar-yet-different pin controllers? What about a
multi-voltage output GPIO pin? Or a Frequency generator pin? Is it
appropriate to create a new subsystem for managing each one? And then
have devices that implement more than one common-case api to register
against each subsystem?
What an API can do is capture the common use cases, but it can never
capture the full range of behaviour implemented by a particular
device. What I see as important to driver writers (PWM/GPIO users) is
the ability to obtain and use a reference to a controllable pin. Then
it can either use a common-case API, or if it needs to, call device
specific extra hooks to do something funky, like hardware triggering.
For pin controller driver writers, the need is to export as much
behaviour as possible via a common-case API so that the device can
easily be reused by things the driver author hasn't even conceived of.
Some behaviors won't fit, and some devices don't support behaviour
exposed by the API. It is perfectly valid for a pin controller driver
to only implement the ops supported by the device and use -EINVAL if
an unsupported op is attempted.
I say that it is better to have a single pin-controller subsystem (and
again, not talking about pin-mux, that is something different) for
registering pins to, and leave it up to the drivers to choose which
ops to implement. It can implement just the PWM ops, or just the GPIO
ops, or both. A pin user will use the same mechanism to obtain a
reference to the pin regardless of the pin type, and can use that
reference to call the common case apis (gpio_get/set_value(),
pwm_config(), etc), or can use the reference when calling into a
driver-specific hook. When new capabilities are identified, the list
of implementable ops can be extended without impact on existing
drivers. Drivers can take advantage of the new behaviour by
implementing the new ops.
> It's a nice idea in the abstract, but I sure don't see how to make it
> work well enough in practice to be worth the effort. I'm not saying it
> can't be done, just that it isn't my focus. Yours? :)
The problem that I have is that it shifts the maintenance burden from
the time of development (ie. now) to code maintenance time. By
duplicating the infrastructure it doubles the code to be maintained.
It means there are differences between how a GPIO/PWM controllers
register their pins, and differences in how other drivers obtain and
use them. It also establishes a pattern of writing new subsystems to
handle similar-yet-different pin controllers. To me that is a
non-trivial cost.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-23 17:40 UTC (permalink / raw)
To: Bill Gatliff; +Cc: David Brownell, linux-embedded, Mike Frysinger
In-Reply-To: <4B0A989B.3070403@billgatliff.com>
On Mon, Nov 23, 2009 at 7:13 AM, Bill Gatliff <bgat@billgatliff.com> wrote:
> Grant Likely wrote:
>>
>> But that *isn't* the primary purpose of the GPIO subsystem. All that
>> stuff is layered on top of the GPIO pin management code and doesn't
>> really play into this debate.
>>
>
> I don't understand you. You are saying that the majority of gpiochip
> implementations also deal with pin multiplexing? They must be terribly
> broken on the platforms I'm working on, then, because they don't seem to
> work at all! :)
Nope. pin mux is a different problem. I'm talking about the code to
register pin controller drivers and for users to obtain a reference to
a pin.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Grant Likely @ 2009-11-23 17:44 UTC (permalink / raw)
To: Mark Brown; +Cc: David Brownell, Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <20091123152943.GC3987@sirena.org.uk>
On Mon, Nov 23, 2009 at 8:29 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
>> On Tue, Nov 17, 2009 at 1:27 AM, David Brownell <david-b@pacbell.net> wrote:
>
>> > Since *everything* boils down to one or more signal lines,
>> > your argument leads directly to Linux having no native
>> > hardware interface except GPIOs. ?Not ... practical. ;)
>
>> I think you've missed my point and taken it to an illogical extreme to
>> counter it. I agree that PWMs are not GPIOs and visa versa. However,
>> *some* devices are both GPIOs and PWMs. Also what is needed to manage
>> GPIO and PWM pins is pretty much identical.
>
> On most of the ARM SoCs PWM and GPIO aren't particularly special here -
> most of the on-SoC functionality is multiplexed onto pins through the
> same hardware interface. A very large proportion of the pins of the SoC
> will have muxes to bring out the signals from the internal IP blocks,
> and pretty much all of those will have GPIO as one of those functions.
Right, pin-mux is a different problem. But there are also devices
that implement both PWM and GPIO functionality in the same IP block.
I think pin muxing, and pin controller drivers are different problem
domains and should be handled separately.
>> But that *isn't* the primary purpose of the GPIO subsystem. All that
>> stuff is layered on top of the GPIO pin management code and doesn't
>> really play into this debate.
>
> The GPIO subsystem isn't doing pin management in that way for most
> systems, it's just controlling the GPIO functionality and relies on
> separate configuration to ensure that the relevant pins are in GPIO
> mode.
Sorry. when I said pin management I meant how Linux keeps track of pin
controllers. Not pin mux. I should use different terminology perhaps
to reduce confusion.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Mark Brown @ 2009-11-23 18:09 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <fa686aa40911230944o197c732bo2d2e5f0aacd936b7@mail.gmail.com>
On Mon, Nov 23, 2009 at 10:44:25AM -0700, Grant Likely wrote:
> Right, pin-mux is a different problem. But there are also devices
> that implement both PWM and GPIO functionality in the same IP block.
That's not the general case, though - most of the SoCs seem to have PWM
as a separate IP block. In the general case PWM and GPIO have nothing
to do with each other.
> I think pin muxing, and pin controller drivers are different problem
> domains and should be handled separately.
...
> Sorry. when I said pin management I meant how Linux keeps track of pin
> controllers. Not pin mux. I should use different terminology perhaps
> to reduce confusion.
I have to confess I'm a bit lost as to what you mean by a "pin
controller" as opposed to "pin mux" interface. For a substantial
proportion of ARMs they're going to be one and the same.
Judging from some of the other messages in the thread I suspect you're
thinking of a much closer mapping between PWM and GPIO pins - many SoCs
do have distinct PWM controllers that aren't terribly tied to a GPIO
pin. For them the whole concept of requesting a "pin" or having the PWM
controller be tied to a particular pin is going to be at best confusing,
you really do want to request the PWM controller itself and let the pin
mux setup figure out where that emerges from the SoC.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: Albrecht Dreß @ 2009-11-23 20:51 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <fa686aa40911230939q3c65c681jee8c4098331f70ee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Am 23.11.09 18:39 schrieb(en) Grant Likely:
> There is no overlap here (except for the degenerate case of using a PWM as an output only GPIO... which is useful. Board designers do crazy things).
But there may be cases where a device pin is used as GPIO *and* as pwm output. Think of a relay output driver which may be used a state GPIO to indicate that the device is up, or as a pulsed heartbeat output (some safety schemes require that) for the
same purpose, selected by a run-time (not device tree!) config option.
I actually do exactly this with one of the Freescale 5200's pins, and would therefore also appreciate a "unified" approach.
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-28 21:28 UTC (permalink / raw)
To: Grant Likely; +Cc: Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <fa686aa40911201449we09fe69i7c7601e705b9e39e@mail.gmail.com>
On Friday 20 November 2009, Grant Likely wrote:
> I don't think that's true, but I'm approaching it from the viewpoint
> of managing pins; not the usage API. ie. the difference between
> gpiolib (management) and the gpio api (usage).
Don't follow. The gpiolib code is unrelated to pin managment.
It's purely an aid for implementations of the API.
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-28 21:38 UTC (permalink / raw)
To: Grant Likely; +Cc: Bill Gatliff, Mike Frysinger, linux-embedded
In-Reply-To: <fa686aa40911230939q3c65c681jee8c4098331f70ee@mail.gmail.com>
On Monday 23 November 2009, Grant Likely wrote:
> *however* I do agree that it is the responsibility of platform code to
> set up chip-internal pin muxing and routing.
Fo over 95% of systems, I'd agree -- given that "platform" code
includes the arch/.../mach-X/board-Y.c files. It's not realistic
to expect boot loaders to always handle that stuff. If for no
other reason than the way they're produced: get something that
will boot <OS> and call it done. There will be nuances that need
to be corrected later.
> Actually, further than
> that, I think it is actually firmware's responsibility to set up chip
> internal pin muxing because it leads to more common platform code in
> the kernel (less board specific fixups), but the kernel can fix it up
> in a pinch.
That something-less-than-5% remaining includes a lot of developer
boards, where there are multiple viable configurations. The OS
needs to know which config it's going into at boot time.
And there's even a crazed subset of that 5% which wants to do
runtime reconfiguration. Those folk do not accept static board
configs, whether done by a bootloader or anything else.
Some of that subset isn't entirely crazed. I was reading a
chip errata document not long ago, which pointed out an issue
I've seen before: suspend/resume cycles needed to reconfigure
things dynamically, to prevent leakage. That's board-specific
and non-static.
> But I'm not arguing about the pin (hardware) setup code.
That's good, since I don't think there's a Grand Scheme that
can be agreed to in that space, either for boot time setup
or runtime reconfiguration. The hardware varies too much.
- Dave
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-28 21:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Grant Likely, Bill Gatliff, linux-embedded, Mike Frysinger
In-Reply-To: <20091123180920.GA1404@rakim.wolfsonmicro.main>
On Monday 23 November 2009, Mark Brown wrote:
> Judging from some of the other messages in the thread I suspect you're
> thinking of a much closer mapping between PWM and GPIO pins - many SoCs
> do have distinct PWM controllers that aren't terribly tied to a GPIO
> pin.
Sometimes they can be coupled to one of several pins ... possibly
even outputting to several at the same time.
> For them the whole concept of requesting a "pin" or having the PWM
> controller be tied to a particular pin is going to be at best confusing,
> you really do want to request the PWM controller itself and let the pin
> mux setup figure out where that emerges from the SoC.
Nicely put. At some level one ends with something like "pwm.2 channel 3"
getting allocated, and does not care about pins except as more low-level
artifacts to be ignored outside of board setup code.
- Dave
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-28 21:59 UTC (permalink / raw)
To: Grant Likely; +Cc: Bill Gatliff, Mike Frysinger, linux-embedded
In-Reply-To: <fa686aa40911230939q3c65c681jee8c4098331f70ee@mail.gmail.com>
On Monday 23 November 2009, Grant Likely wrote:
> I take issue
> with all the common code behind the API to make it work and to allow
> GPIOs or PWMs to be registered at runtime. The overlap is the code
> and behaviour used to register pins and to obtain a reference to a
> pin.
>
> On the PWM side; it's the code backing pwm_register().
> pwm_unregister(), pwm_request(), pwm_free(), and the sysfs hooks.
>
> For GPIO; it's gpiochip_add(), gpiochip_remove(), gpio_request(),
> gpio_free(), the sysfs hooks, and the device tree bindings.
>
> They perform exactly the same task. The difference is that PWM
> devices implement the PWM API and GPIO devices implement the GPIO API;
> but the behaviour needed to manage them is identical. I don't like
> the fact that it will be implemented twice with subtle differences
> between them.
Most of that stuff sits inside sysfs. What's actually sharable?
> The argument has been made that the split is appropriate because the
> use case between GPIO and PWM is considerably different, and to a
> point I agree. The PWM use case definitely requires a different API.
> However, the argument also makes the assumption that what is a GPIO
> and what is a PWM can easily be pinned down. For example, I've got
> output only GPIOs, input only GPIOs, and a device that implements both
> PWM and GPIO behaviour (not pin muxing).
In object oriented programming there's this thing called an "interface",
and its application here is: you write a driver implementing both
the "gpio" and "pwm" interfaces. Someone wanting a given behavior
goes through that interface.
> If a hard distinction is
> made now to manage GPIO and PWM pins separately, what then do we do
> with other similar-yet-different pin controllers? What about a
> multi-voltage output GPIO pin? Or a Frequency generator pin? Is it
> appropriate to create a new subsystem for managing each one?
None of those are particularly common. The Linux approach is to come
up with interfaces as needed ... then generalize once there's enough
data, if indeed there is enough. Just because you *can* come up with
hardware doesn't mean it's widespread enough to need a shared API.
> What an API can do is capture the common use cases, but it can never
> capture the full range of behaviour implemented by a particular
> device.
Right, so you need to become accustomed to the notion that there
can be platform-specific capabilities. Kitchen-sink APIs are bad.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox