Re: [PATCH] ide.c: microscopic size and readability optimization
Hello Borislav, Thursday, May 17, 2007, 2:25:54 PM, you wrote: > - > From: [EMAIL PROTECTED] > A very small size (object file 432 bytes smaller) and readability > optimization of ide.c And how these "optimizations" fit with BUG_ON() purpose - to be able to easily identify cause and place of the failure? You could just remove them altogether and claim that you did even "better" "optimization". > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> > -- > Index: 22-rc1/drivers/ide/ide.c > === > --- 22-rc1/drivers/ide/ide.c.orig > +++ 22-rc1/drivers/ide/ide.c > @@ -568,10 +568,8 @@ void ide_unregister(unsigned int index) > ide_hwgroup_t *hwgroup; > int irq_count = 0, unit; > - BUG_ON(index >= MAX_HWIFS); > + BUG_ON(index >= MAX_HWIFS || in_interrupt() || irqs_disabled()); > - BUG_ON(in_interrupt()); > - BUG_ON(irqs_disabled()); > down(_cfg_sem); -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide.c: microscopic size and readability optimization
Hello Borislav, Thursday, May 17, 2007, 2:25:54 PM, you wrote: - From: [EMAIL PROTECTED] A very small size (object file 432 bytes smaller) and readability optimization of ide.c And how these optimizations fit with BUG_ON() purpose - to be able to easily identify cause and place of the failure? You could just remove them altogether and claim that you did even better optimization. Signed-off-by: Borislav Petkov [EMAIL PROTECTED] -- Index: 22-rc1/drivers/ide/ide.c === --- 22-rc1/drivers/ide/ide.c.orig +++ 22-rc1/drivers/ide/ide.c @@ -568,10 +568,8 @@ void ide_unregister(unsigned int index) ide_hwgroup_t *hwgroup; int irq_count = 0, unit; - BUG_ON(index = MAX_HWIFS); + BUG_ON(index = MAX_HWIFS || in_interrupt() || irqs_disabled()); - BUG_ON(in_interrupt()); - BUG_ON(irqs_disabled()); down(ide_cfg_sem); -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Correct location for ADC/DAC drivers
Hello Bodo, Sunday, May 6, 2007, 3:19:59 PM, you wrote: > Robin Getz <[EMAIL PROTECTED]> wrote: >> On Fri 4 May 2007 16:52, Robert Schwebel pondered: >>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote: >>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA), >>> > that would be nice to put in the "right" place - I don't think that >>> > drivers/char is the right place, nor drivers/misc - I also don't think >>> > that /adc is a descriptive place for DAC or mixed signal front ends >>> > (MxFE). >>> >>> What userspace interface do your drivers have? >> >> Right now, it is a little rudimentary char interface, it needs a little care >> to be a bit more general purpose, but it suited needs of what the people who >> were using it. > [...] >> I would be interested in having a detailed discussion/random thoughts on >> this - what is the best way to expose these types of devices? > Since you ask for random thoughts: > IO of data streams from or to a DAC/ADC is essentially what soundcards do. > I'm wondering if these cards are similar enough to use alsa, and if using > that interface would ease or hinder programming the driver. FYI, within handhelds.org kernel project, we also saw the need for consistent ADC infrastructure, and developed such, based on classdev concept, on todo to be submitted for review. Our API/userspace interface however optimized for individual (or fixed-batch) readings over stream operations, our target usage are touchscreen, battery, hwmon drivers. -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Correct location for ADC/DAC drivers
Hello Bodo, Sunday, May 6, 2007, 3:19:59 PM, you wrote: Robin Getz [EMAIL PROTECTED] wrote: On Fri 4 May 2007 16:52, Robert Schwebel pondered: On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote: We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA), that would be nice to put in the right place - I don't think that drivers/char is the right place, nor drivers/misc - I also don't think that /adc is a descriptive place for DAC or mixed signal front ends (MxFE). What userspace interface do your drivers have? Right now, it is a little rudimentary char interface, it needs a little care to be a bit more general purpose, but it suited needs of what the people who were using it. [...] I would be interested in having a detailed discussion/random thoughts on this - what is the best way to expose these types of devices? Since you ask for random thoughts: IO of data streams from or to a DAC/ADC is essentially what soundcards do. I'm wondering if these cards are similar enough to use alsa, and if using that interface would ease or hinder programming the driver. FYI, within handhelds.org kernel project, we also saw the need for consistent ADC infrastructure, and developed such, based on classdev concept, on todo to be submitted for review. Our API/userspace interface however optimized for individual (or fixed-batch) readings over stream operations, our target usage are touchscreen, battery, hwmon drivers. -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
Hello ian, Saturday, May 5, 2007, 4:46:26 PM, you wrote: > On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote: >> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any >> control signaling over the USB bus for power-control purposes), > it might be dumb, but it is useful to know wether the PDA is charging > from usb or mains power. and some devices allow one to switch on / off > the ability to charge via usb And USB does have power budgetting requirements, etc. (like was already pointed in own of initial review messages). So, USB is definitely not the same thing as "dumb DC". -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
Hello Anton,
Saturday, May 5, 2007, 3:32:30 PM, you wrote:
> Hello Henrique, Shem,
> On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
>> On Fri, 04 May 2007, Shem Multinymous wrote:
>> > >+enum power_supply_type {
>> > >+ POWER_SUPPLY_TYPE_BATTERY = 0,
>> > >+ POWER_SUPPLY_TYPE_UPS,
>> > >+ POWER_SUPPLY_TYPE_AC,
>> > >+ POWER_SUPPLY_TYPE_USB,
>> > >+};
>> >
>> > How about dumb (non-USB) DC power? Any reason to distinguish it from AC?
>>
[]
> I think I got the start point of confusion. It's indeed bad to call such
> power supply type as AC.
Ok, let's try to at least find the root of this confusion. Of
course, course, what we mean by "AC" is exactly continuous, "infinite"
power source. Of course, from real physicist point of view, this is
incorrect - hardly any device in topic domain (i.e.
portable/battery-power) has AC cord sticking out of case. There's usually
an AC/DC adapter, and DC is what really fed into device.
But in real world, it's rather common to colloquially name
such kind of power "AC", and that's "term" is known to many-many
people, and intuitively understood even for those, who didn't hit it yet.
Actually, this discussion is good confirmation that's the case -
people understand in what meaning it is used here, and go to point
that it's not "scientifically" correct.
> Maybe I should it rename to ADAPTER? Or WALL?
Well-well, above was pointed out, that "AC" even if not fully
correct, that at least colloquial term of choice for the phenomena inq
question. Words above on the other hand seems like out-of-scope and
ambiguous. There's actually a nice and terse term for that - mains,
but I wonder how well non-English speaking people are familiar with it
(I personally saw them only in manuals, which, as well known, nobody
reads).
Summing up, it may be worth a quick thought, should it be
"absolutely correct and absolutely useless", or just well-understood
up to the level that even elementary school pupil could write an
eloquence essay criticizing it ;-).
[]
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
Hello Anton,
Saturday, May 5, 2007, 3:32:30 PM, you wrote:
Hello Henrique, Shem,
On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 04 May 2007, Shem Multinymous wrote:
+enum power_supply_type {
+ POWER_SUPPLY_TYPE_BATTERY = 0,
+ POWER_SUPPLY_TYPE_UPS,
+ POWER_SUPPLY_TYPE_AC,
+ POWER_SUPPLY_TYPE_USB,
+};
How about dumb (non-USB) DC power? Any reason to distinguish it from AC?
[]
I think I got the start point of confusion. It's indeed bad to call such
power supply type as AC.
Ok, let's try to at least find the root of this confusion. Of
course, course, what we mean by AC is exactly continuous, infinite
power source. Of course, from real physicist point of view, this is
incorrect - hardly any device in topic domain (i.e.
portable/battery-power) has AC cord sticking out of case. There's usually
an AC/DC adapter, and DC is what really fed into device.
But in real world, it's rather common to colloquially name
such kind of power AC, and that's term is known to many-many
people, and intuitively understood even for those, who didn't hit it yet.
Actually, this discussion is good confirmation that's the case -
people understand in what meaning it is used here, and go to point
that it's not scientifically correct.
Maybe I should it rename to ADAPTER? Or WALL?
Well-well, above was pointed out, that AC even if not fully
correct, that at least colloquial term of choice for the phenomena inq
question. Words above on the other hand seems like out-of-scope and
ambiguous. There's actually a nice and terse term for that - mains,
but I wonder how well non-English speaking people are familiar with it
(I personally saw them only in manuals, which, as well known, nobody
reads).
Summing up, it may be worth a quick thought, should it be
absolutely correct and absolutely useless, or just well-understood
up to the level that even elementary school pupil could write an
eloquence essay criticizing it ;-).
[]
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
Hello ian, Saturday, May 5, 2007, 4:46:26 PM, you wrote: On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote: Given that USB-power *is* usually also dumb (i.e. it doesn't do any control signaling over the USB bus for power-control purposes), it might be dumb, but it is useful to know wether the PDA is charging from usb or mains power. and some devices allow one to switch on / off the ability to charge via usb And USB does have power budgetting requirements, etc. (like was already pointed in own of initial review messages). So, USB is definitely not the same thing as dumb DC. -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 1/8] remove "#if 0" from find_bus function, export it.
Hello Greg, Friday, May 4, 2007, 2:14:59 AM, you wrote: > On Fri, May 04, 2007 at 01:31:21AM +0400, Anton Vorontsov wrote: >> This function were placed in "#if 0" because nobody was using it. >> We using it now. > Why? Shouldn't you just export the pointer you need instead? >> See http://lwn.net/Articles/210610/ > I don't understand the need for this link, it talks about how the api > changes all the time, something we all know :) No, it talked about how complete APIs regress into random set of functions, lacking complete coverage of target domain. The response was that when users for the specific function in question will be in mainline, it will be resurrected. So, here it comes ;-) > And if you really want it, and you convince me you really need it, can > you change it to be "bus_find" to play nicer in the namespace? > thanks, > greg k-h -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 1/8] remove #if 0 from find_bus function, export it.
Hello Greg, Friday, May 4, 2007, 2:14:59 AM, you wrote: On Fri, May 04, 2007 at 01:31:21AM +0400, Anton Vorontsov wrote: This function were placed in #if 0 because nobody was using it. We using it now. Why? Shouldn't you just export the pointer you need instead? See http://lwn.net/Articles/210610/ I don't understand the need for this link, it talks about how the api changes all the time, something we all know :) No, it talked about how complete APIs regress into random set of functions, lacking complete coverage of target domain. The response was that when users for the specific function in question will be in mainline, it will be resurrected. So, here it comes ;-) And if you really want it, and you convince me you really need it, can you change it to be bus_find to play nicer in the namespace? thanks, greg k-h -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Wednesday, May 2, 2007, 12:17:33 AM, you wrote: > Hello Paul, > Paul Sokolovsky wrote: >>> ASIC-related code (I mean core) forms additional platform layer, so I >>> suggest >>> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but >>> ASIC drivers to drivers/asic/ directory. >> >> There problem here is the same - our target chips are not >> just ASICs. > You say they are chips so they are integrated circuits (ICs), they > are designed to solve some specific needs, so they are > application-specific ICs, i.e. ASICs, what's the problem? The issue is that in this case functional organization what's important, not thing like (original) design purpose/method, expressed in vague terms like ASIC. A "passive" (from CPU point of view) chip of 30-50 gates dealing with clock/control signals destribution is of course ASIC too, but has nothing to do with chips in question. >> It just happens that the one we start with called such, >> but we have different ones too. > Interesting what are they? > Power management ICs? Power management + audio > + touchscreen + ADC + USB transceiver + UART + whatever > all such chips may be considered as ASICs. "May" is a keyword here. They may be considered SoCs too, as they share one important trait with them: multiple devices of different functions in one package. I'd of course love idea of calling any chip but CPU and memory an ASIC, but that doesn't correspond with reality. As an example, ICH, etc chipsets are of course ASICs, but I personally never heard them called such, and I'm sure few listeners would be confused, if someone called them such. >> It's still important that they contain >> blocks with different functionality, and drivers we propose deal with >> basic, common functionality of chips. > That different functionality blocks will be handled by appropriate > device drivers, and in general the drivers should not depend on > a particular ASIC but use common ASIC API. > But "common functionality" drivers are ASIC-specific. >> Now that it was pointed out that >> there's place in the tree for such drivers, it would be not wise to >> try to create another one. >> >> >> > Perhaps, so. Actually, MFD (multi functional device) doesn't > imply a platform-level device but ASIC seems does. That's also a subject of interpretation for specific chip/driver. Proposed soc-core is actually a helper, not a strict API to follow. We just found that many our drivers do common things, so factored out functionality for easier reuse. It of course can be extended given the need (but yes, so far all our MFD chips and their subdevices are treated as platform devices). But back from ontology to specific ideas of patch restructuring. Given a need to distinguish discussed chips' handling model from "generic" MFDs (like ones already in drivers/mfd/), and the fact that Ian Molton, author of soc-core.*, likes ASIC designator, this warrants rename of it to asic-core.*, I guess. All it still goes to drivers/mfd/ to not create more stuff than needed. As for driver headers, they apparently go to include/linux/ . That's of course keeps being out of hand, but small guy's way to a solution is apparently to accelerate that. When number of files in include/linux/ will hit 1K, I guess core maintainers will notice that something's wrong and find a global solution. (One good idea is to separate driver-specific headers from global and subsystem ones, but all that is out of scope for this discussion...). > Thanks, > Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Wednesday, May 2, 2007, 12:17:33 AM, you wrote: Hello Paul, Paul Sokolovsky wrote: ASIC-related code (I mean core) forms additional platform layer, so I suggest adding ASIC helpers to generic platform code i.e. drivers/platform.c, but ASIC drivers to drivers/asic/ directory. There problem here is the same - our target chips are not just ASICs. You say they are chips so they are integrated circuits (ICs), they are designed to solve some specific needs, so they are application-specific ICs, i.e. ASICs, what's the problem? The issue is that in this case functional organization what's important, not thing like (original) design purpose/method, expressed in vague terms like ASIC. A passive (from CPU point of view) chip of 30-50 gates dealing with clock/control signals destribution is of course ASIC too, but has nothing to do with chips in question. It just happens that the one we start with called such, but we have different ones too. Interesting what are they? Power management ICs? Power management + audio + touchscreen + ADC + USB transceiver + UART + whatever all such chips may be considered as ASICs. May is a keyword here. They may be considered SoCs too, as they share one important trait with them: multiple devices of different functions in one package. I'd of course love idea of calling any chip but CPU and memory an ASIC, but that doesn't correspond with reality. As an example, ICH, etc chipsets are of course ASICs, but I personally never heard them called such, and I'm sure few listeners would be confused, if someone called them such. It's still important that they contain blocks with different functionality, and drivers we propose deal with basic, common functionality of chips. That different functionality blocks will be handled by appropriate device drivers, and in general the drivers should not depend on a particular ASIC but use common ASIC API. But common functionality drivers are ASIC-specific. Now that it was pointed out that there's place in the tree for such drivers, it would be not wise to try to create another one. Perhaps, so. Actually, MFD (multi functional device) doesn't imply a platform-level device but ASIC seems does. That's also a subject of interpretation for specific chip/driver. Proposed soc-core is actually a helper, not a strict API to follow. We just found that many our drivers do common things, so factored out functionality for easier reuse. It of course can be extended given the need (but yes, so far all our MFD chips and their subdevices are treated as platform devices). But back from ontology to specific ideas of patch restructuring. Given a need to distinguish discussed chips' handling model from generic MFDs (like ones already in drivers/mfd/), and the fact that Ian Molton, author of soc-core.*, likes ASIC designator, this warrants rename of it to asic-core.*, I guess. All it still goes to drivers/mfd/ to not create more stuff than needed. As for driver headers, they apparently go to include/linux/ . That's of course keeps being out of hand, but small guy's way to a solution is apparently to accelerate that. When number of files in include/linux/ will hit 1K, I guess core maintainers will notice that something's wrong and find a global solution. (One good idea is to separate driver-specific headers from global and subsystem ones, but all that is out of scope for this discussion...). Thanks, Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 10:08:23 PM, you wrote: > ian wrote: >> On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote: >>> If you used ASIC acronym it would be more appropriate and not so >>> ambiguous. >> >> Actually, thats not bad. I'd be ok with that is SoC isnt used. >> > I'm ok with that too, i.e. very rough definition is: > SoC (system-on-chip) is a platform level chip which incorporates processor > devices (CPU, cache, coprocessors, memory controller etc.), system devices > (timers, interrupt controllers etc.) and peripheral devices > (UARTs, LCD controllers, USB controllers etc), > while ASIC (Application-specific integrated circuit) is also a platform > level > chip which incorporates peripheral and system devices but does not include > processor devices. ASICs are designed to expand processor functionality, > it could supplement a normal processor (non-SoC) and also could supplement > a SoC processor. > ASIC-related code (I mean core) forms additional platform layer, so I > suggest > adding ASIC helpers to generic platform code i.e. drivers/platform.c, but > ASIC drivers to drivers/asic/ directory. There problem here is the same - our target chips are not just ASICs. It just happens that the one we start with called such, but we have different ones too. It's still important that they contain blocks with different functionality, and drivers we propose deal with basic, common functionality of chips. Now that it was pointed out that there's place in the tree for such drivers, it would be not wise to try to create another one. > Regards, > Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Richard, Tuesday, May 1, 2007, 6:01:15 PM, you wrote: > On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote: >> Either way, I don't pledge to be a HW designer with >> contemporary lexicon. The aim was simple - as a single word would be >> too ambiguous, general, or vice-versa, omitting, then acronym is >> needed, hopefully existing, and not new, and SoC is the most fitting >> TLA, IMHO. But I'm open to specific suggestions for improvement. For >> example, if I was to write a Documentation/ entry for that, I'd mention >> companion chips, peripheral/integrated controllers, etc. But renaming >> drivers/soc/ to drivers/companion/ would be more confusing, as the >> concept described is not tied to companion chips per se (even though >> many of chips we (handhelds.org) deal with, can be classified as >> such). > A while back I proposed drivers/mfd/ (multi function devices) and there > are a couple of drivers in there in mainline which probably fit your > description of SoC. The code I had once intended for there is probably > more ASoC related now... Well, while description catches the essence of course, TLA is far from being perfect: 1) Completely unknown; 2) can be easily confused with mtd. But it's even more funny: there *is* drivers/mfd/ already in mainline. I'd say that we were blind, but even you say "proposed", not "exists", nor anybody else brought that to attention. I'm afraid, that proves point 1 above ;-). Well, now that it's there, we have little choice but use it, so we'll move our stuff there. Thanks everyone for hints! > Richard -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 7:38:44 PM, you wrote: > ian wrote: >> On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote: >>> Hi Paul, >> >>> I think your referring to the term "SoC (system-on-chip)" is confusing >>> (at least for me). You rather consider companion chips than SoCs. >> >> A 'System' does not imply a CPU. A 'Computer System' would but the word >> system itself doesnt even imply electronic. >> >> > A "system" means something complete. Yes I agree it doesn't imply a CPU, > but acronym SoC traditionally imply something different than you propose. > Adding another meaning for SoC will confuse people because they will have > to distinguish if it is a processor or just a slave IC. I'm afraid we'd just have ontological argument unless tried to bring in some references. But wikipedia does agree with you, http://en.wikipedia.org/wiki/System-on-a-chip . So, well, down with redefining SoC then. But "companion" is still too narrow and buzzwordy, so let's explore Richard Purdie suggestion (in the other mail). > Thanks, > Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 4:53:09 PM, you wrote: > Hi Paul, > Paul Sokolovsky wrote: >> In contemporary systems, lots of functionality oftentimes handled by various >> kinds of SoCs (system-on-chip), representing a number of deversified >> controllers packaged in one chip. > I think your referring to the term "SoC (system-on-chip)" is confusing > (at least for me). You rather consider companion chips than SoCs. > Yes, any chip integrating a number of controllers could be considered > as a system-on-chip but if the chip doesn't make sense without > some master chip (processor) I'd consider the chip as a companion > (to the processor) chip. Ditto for me - I find "companion" thing confusing. What's important for the RFC/topic discussed is that it is integrated controller with many diversified functions, not what it is helper to something. I understand that for many people SoC means CPU with ties, but IMHO, it's less stretch to take such chip, remove CPU, and still call it a SoC, than call an integrated audio/touchscreen controller a companion chip (well, of course it is; and RAM chip too ;-) ). Either way, I don't pledge to be a HW designer with contemporary lexicon. The aim was simple - as a single word would be too ambiguous, general, or vice-versa, omitting, then acronym is needed, hopefully existing, and not new, and SoC is the most fitting TLA, IMHO. But I'm open to specific suggestions for improvement. For example, if I was to write a Documentation/ entry for that, I'd mention companion chips, peripheral/integrated controllers, etc. But renaming drivers/soc/ to drivers/companion/ would be more confusing, as the concept described is not tied to companion chips per se (even though many of chips we (handhelds.org) deal with, can be classified as such). > Regards, > Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
Hello Alan, Tuesday, May 1, 2007, 1:27:51 PM, you wrote: >> > + * Copyright 2001 Compaq Computer Corporation. >> > + * >> > + * Use consistent with the GNU GPL is permitted, >> > + * provided that this copyright notice is >> > + * preserved in its entirety in all copies and derived works. >> > + * >> > + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, >> > + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS >> > + * FITNESS FOR ANY PARTICULAR PURPOSE. > This doesn't appear to be self consistent or GPL compatible. Any binary > will be a derivative work and will not contain the copyright notice. Well, this is one of those hard questions... Fortunately, people who worked on this and were Compaq employees are reachable, so I contacted Jamie Hicks, who is one of the authors of iPaq ports, regarding solution for this. Jamie, would it be possible to leave Compaq and other copyright notices, and Compaq disclaimer intact, but replace following paragraph: > + * Use consistent with the GNU GPL is permitted, > + * provided that this copyright notice is > + * preserved in its entirety in all copies and derived works. With more common wording as appears in kernel sources: > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version. (or GPL2 wording, or verbose wording, whatever you see fit) Thanks! > Alan -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Ben, Tuesday, May 1, 2007, 11:39:00 AM, you wrote: > On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote: [] >> Initial implementation from few years ago registered per-SoC bus >> for the purpose of attaching subdevices, but during LKML reviews it >> was pointed out that there're no good reasons for that, as such bus >> does not have any special functionality attached, so now platform_bus >> is used instead, for good. >> >> For the most part, subdevices are allocated dynamically, and SoC >> base driver calculates/fixes up resources and parameters for them, >> to be suitable for specific configuration (for example, different >> base address of SoC). >> >> What exact functionality and API a SoC base driver provides depends >> largely on specific chip, there's no specific API a SoC driver should >> implement. Here is a list of common tasks the driver usually would do: >> >> 1. Access handling to the chip (serialization, locking, etc.) >> 2. Managing common chip resources: >> 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) >> 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, >> we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). >> 2.3. Clocks (Using Platform Clock API) >> 2.4. Other kinds of "enable" and "power" switches (in adhoc manner or >> (ab)using the Clocks API, and waiting for generalization of it). >> 3. Calculating properties and registerting subdevices. > Wow, platform devices with a new name. I don't see how any of this is > not handled by platfrom device. > GPIO devices could be handled by a new resource type of GPIO > > The only other item in the list which we do not yet have is a > form of the clock API which can be extended past the base CPU > clock implementation. > > Anything registering new IRQs could create sub platform devices > with the correct resources. Where did you see a new name? I specially mentioned that era of new names are gone. We talk about device drivers and platform devices, plain and straight. It's just a driver which does convenience operations for a group of platform_devices, and sure, all these convenience operations are well familiar to anyone in topic. How such drivers (SoC base ones) are still useful is also pretty obvious: first of all, they are there, like mentioned sa.c and locomo.c. This RFC just calls for recognition of them as a special class of drivers, instead of keeping them hoard arch dirs. As for registering subdevices by SoC driver, it should be also clear why that's useful: as was mentioned, we have 12 devices using ASIC3 now. Instead of polluting machine definitions with duplicate subdevices declarations, we declare a SoC chip devices in them, and let chip driver declare subdevices, handling other boring tasks, as resource munging, at the same time (like that bus_shift thing - some ASIC3 devices has 2 byte register spacing, some 4 (essentially attached to off-by-one address lines)). [] -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Ben, Tuesday, May 1, 2007, 11:39:00 AM, you wrote: On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote: [] Initial implementation from few years ago registered per-SoC bus for the purpose of attaching subdevices, but during LKML reviews it was pointed out that there're no good reasons for that, as such bus does not have any special functionality attached, so now platform_bus is used instead, for good. For the most part, subdevices are allocated dynamically, and SoC base driver calculates/fixes up resources and parameters for them, to be suitable for specific configuration (for example, different base address of SoC). What exact functionality and API a SoC base driver provides depends largely on specific chip, there's no specific API a SoC driver should implement. Here is a list of common tasks the driver usually would do: 1. Access handling to the chip (serialization, locking, etc.) 2. Managing common chip resources: 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). 2.3. Clocks (Using Platform Clock API) 2.4. Other kinds of enable and power switches (in adhoc manner or (ab)using the Clocks API, and waiting for generalization of it). 3. Calculating properties and registerting subdevices. Wow, platform devices with a new name. I don't see how any of this is not handled by platfrom device. GPIO devices could be handled by a new resource type of GPIO The only other item in the list which we do not yet have is a form of the clock API which can be extended past the base CPU clock implementation. Anything registering new IRQs could create sub platform devices with the correct resources. Where did you see a new name? I specially mentioned that era of new names are gone. We talk about device drivers and platform devices, plain and straight. It's just a driver which does convenience operations for a group of platform_devices, and sure, all these convenience operations are well familiar to anyone in topic. How such drivers (SoC base ones) are still useful is also pretty obvious: first of all, they are there, like mentioned sa.c and locomo.c. This RFC just calls for recognition of them as a special class of drivers, instead of keeping them hoard arch dirs. As for registering subdevices by SoC driver, it should be also clear why that's useful: as was mentioned, we have 12 devices using ASIC3 now. Instead of polluting machine definitions with duplicate subdevices declarations, we declare a SoC chip devices in them, and let chip driver declare subdevices, handling other boring tasks, as resource munging, at the same time (like that bus_shift thing - some ASIC3 devices has 2 byte register spacing, some 4 (essentially attached to off-by-one address lines)). [] -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
Hello Alan, Tuesday, May 1, 2007, 1:27:51 PM, you wrote: + * Copyright 2001 Compaq Computer Corporation. + * + * Use consistent with the GNU GPL is permitted, + * provided that this copyright notice is + * preserved in its entirety in all copies and derived works. + * + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS + * FITNESS FOR ANY PARTICULAR PURPOSE. This doesn't appear to be self consistent or GPL compatible. Any binary will be a derivative work and will not contain the copyright notice. Well, this is one of those hard questions... Fortunately, people who worked on this and were Compaq employees are reachable, so I contacted Jamie Hicks, who is one of the authors of iPaq ports, regarding solution for this. Jamie, would it be possible to leave Compaq and other copyright notices, and Compaq disclaimer intact, but replace following paragraph: + * Use consistent with the GNU GPL is permitted, + * provided that this copyright notice is + * preserved in its entirety in all copies and derived works. With more common wording as appears in kernel sources: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. (or GPL2 wording, or verbose wording, whatever you see fit) Thanks! Alan -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 4:53:09 PM, you wrote: Hi Paul, Paul Sokolovsky wrote: In contemporary systems, lots of functionality oftentimes handled by various kinds of SoCs (system-on-chip), representing a number of deversified controllers packaged in one chip. I think your referring to the term SoC (system-on-chip) is confusing (at least for me). You rather consider companion chips than SoCs. Yes, any chip integrating a number of controllers could be considered as a system-on-chip but if the chip doesn't make sense without some master chip (processor) I'd consider the chip as a companion (to the processor) chip. Ditto for me - I find companion thing confusing. What's important for the RFC/topic discussed is that it is integrated controller with many diversified functions, not what it is helper to something. I understand that for many people SoC means CPU with ties, but IMHO, it's less stretch to take such chip, remove CPU, and still call it a SoC, than call an integrated audio/touchscreen controller a companion chip (well, of course it is; and RAM chip too ;-) ). Either way, I don't pledge to be a HW designer with contemporary lexicon. The aim was simple - as a single word would be too ambiguous, general, or vice-versa, omitting, then acronym is needed, hopefully existing, and not new, and SoC is the most fitting TLA, IMHO. But I'm open to specific suggestions for improvement. For example, if I was to write a Documentation/ entry for that, I'd mention companion chips, peripheral/integrated controllers, etc. But renaming drivers/soc/ to drivers/companion/ would be more confusing, as the concept described is not tied to companion chips per se (even though many of chips we (handhelds.org) deal with, can be classified as such). Regards, Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 7:38:44 PM, you wrote: ian wrote: On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote: Hi Paul, I think your referring to the term SoC (system-on-chip) is confusing (at least for me). You rather consider companion chips than SoCs. A 'System' does not imply a CPU. A 'Computer System' would but the word system itself doesnt even imply electronic. A system means something complete. Yes I agree it doesn't imply a CPU, but acronym SoC traditionally imply something different than you propose. Adding another meaning for SoC will confuse people because they will have to distinguish if it is a processor or just a slave IC. I'm afraid we'd just have ontological argument unless tried to bring in some references. But wikipedia does agree with you, http://en.wikipedia.org/wiki/System-on-a-chip . So, well, down with redefining SoC then. But companion is still too narrow and buzzwordy, so let's explore Richard Purdie suggestion (in the other mail). Thanks, Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 0/4] SoC base drivers
Hello Richard, Tuesday, May 1, 2007, 6:01:15 PM, you wrote: On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote: Either way, I don't pledge to be a HW designer with contemporary lexicon. The aim was simple - as a single word would be too ambiguous, general, or vice-versa, omitting, then acronym is needed, hopefully existing, and not new, and SoC is the most fitting TLA, IMHO. But I'm open to specific suggestions for improvement. For example, if I was to write a Documentation/ entry for that, I'd mention companion chips, peripheral/integrated controllers, etc. But renaming drivers/soc/ to drivers/companion/ would be more confusing, as the concept described is not tied to companion chips per se (even though many of chips we (handhelds.org) deal with, can be classified as such). A while back I proposed drivers/mfd/ (multi function devices) and there are a couple of drivers in there in mainline which probably fit your description of SoC. The code I had once intended for there is probably more ASoC related now... Well, while description catches the essence of course, TLA is far from being perfect: 1) Completely unknown; 2) can be easily confused with mtd. But it's even more funny: there *is* drivers/mfd/ already in mainline. I'd say that we were blind, but even you say proposed, not exists, nor anybody else brought that to attention. I'm afraid, that proves point 1 above ;-). Well, now that it's there, we have little choice but use it, so we'll move our stuff there. Thanks everyone for hints! Richard -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers
Hello Dmitry, Tuesday, May 1, 2007, 10:08:23 PM, you wrote: ian wrote: On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote: If you used ASIC acronym it would be more appropriate and not so ambiguous. Actually, thats not bad. I'd be ok with that is SoC isnt used. I'm ok with that too, i.e. very rough definition is: SoC (system-on-chip) is a platform level chip which incorporates processor devices (CPU, cache, coprocessors, memory controller etc.), system devices (timers, interrupt controllers etc.) and peripheral devices (UARTs, LCD controllers, USB controllers etc), while ASIC (Application-specific integrated circuit) is also a platform level chip which incorporates peripheral and system devices but does not include processor devices. ASICs are designed to expand processor functionality, it could supplement a normal processor (non-SoC) and also could supplement a SoC processor. ASIC-related code (I mean core) forms additional platform layer, so I suggest adding ASIC helpers to generic platform code i.e. drivers/platform.c, but ASIC drivers to drivers/asic/ directory. There problem here is the same - our target chips are not just ASICs. It just happens that the one we start with called such, but we have different ones too. It's still important that they contain blocks with different functionality, and drivers we propose deal with basic, common functionality of chips. Now that it was pointed out that there's place in the tree for such drivers, it would be not wise to try to create another one. Regards, Dmitry -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 3/4] SoC base drivers: ASIC3 driver
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
drivers/soc/Kconfig| 22 +
drivers/soc/Makefile |5 +
drivers/soc/asic3_base.c | 1177
include/linux/soc/asic3_base.h | 100
include/linux/soc/tmio_mmc.h | 17 +
5 files changed, 1321 insertions(+), 0 deletions(-)
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
new file mode 100644
index 000..2c9d846
--- /dev/null
+++ b/drivers/soc/Kconfig
@@ -0,0 +1,22 @@
+#
+# SoC drivers
+#
+# System-on-Chip are chips that implement a number of virtually unrelated
+# functions but sharing some common circuitry, for example power management
+# or an auxiliary interrupt controller.
+#
+
+menu "SoC drivers"
+
+config SOC_ASIC3
+ tristate "HTC ASIC3 SoC support (iPAQ & HTC PDAs)"
+
+config SOC_ASIC3_DS1WM
+ bool "Support HTC ASIC3 builtin DS1WM block"
+ depends on SOC_ASIC3
+ help
+ Choose Y here if you want to include support for ASIC3's builtin
+ W1 controller. Some devices do not use it, and yet other have
+ separate DS1WM controller. For them, choose N.
+
+endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
new file mode 100644
index 000..13031b1
--- /dev/null
+++ b/drivers/soc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for SoC drivers.
+#
+
+obj-$(CONFIG_SOC_ASIC3)+= asic3_base.o soc-core.o
diff --git a/drivers/soc/asic3_base.c b/drivers/soc/asic3_base.c
new file mode 100644
index 000..ca0f862
--- /dev/null
+++ b/drivers/soc/asic3_base.c
@@ -0,0 +1,1177 @@
+/*
+ * Driver interface to HTC "ASIC3"
+ *
+ * Copyright 2001 Compaq Computer Corporation.
+ * Copyright 2004-2005 Phil Blundell
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED,
+ * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS
+ * FITNESS FOR ANY PARTICULAR PURPOSE.
+ *
+ * Author: Andrew Christian
+ * <[EMAIL PROTECTED]>
+ * October 2001
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef CONFIG_PLAT_S3C24XX
+#include
+#define clk_register(clk) s3c24xx_register_clock(clk)
+#define clk_unregister(clk)
+#else
+#include
+#endif
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include "soc-core.h"
+
+
+struct asic3_data
+{
+ void *mapping;
+ unsigned int bus_shift;
+ int irq_base;
+ int irq_nr;
+
+ u16 irq_bothedge[4];
+ struct device *dev;
+
+ struct platform_device *mmc_dev;
+};
+
+static spinlock_t asic3_gpio_lock;
+
+static int asic3_remove(struct platform_device *dev);
+
+static inline unsigned long asic3_address(struct device *dev,
+ unsigned int reg)
+{
+ struct asic3_data *adata;
+
+ adata = (struct asic3_data *)dev->driver_data;
+
+ return (unsigned long)adata->mapping + (reg >> (2 - adata->bus_shift));
+}
+
+void asic3_write_register(struct device *dev, unsigned int reg, u32 value)
+{
+ __raw_writew(value, asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_write_register);
+
+u32 asic3_read_register(struct device *dev, unsigned int reg)
+{
+ return __raw_readw(asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_read_register);
+
+static inline void __asic3_write_register(struct asic3_data *asic,
+ unsigned int reg, u32 value)
+{
+ __raw_writew(value, (unsigned long)asic->mapping
+ + (reg >> (2 - asic->bus_shift)));
+}
+
+static inline u32 __asic3_read_register(struct asic3_data *asic,
+ unsigned int reg)
+{
+ return __raw_readw((unsigned long)asic->mapping
+ + (reg >> (2 - asic->bus_shift)));
+}
+
+#define ASIC3_GPIO_FN(get_fn_name, set_fn_name, REG) \
+u32 get_fn_name(struct device *dev)\
+{ \
+ return asic3_read_register(dev, REG); \
+} \
+EXPORT_SYMBOL(get_fn_name);\
+ \
+void set_fn_name(struct device *dev, u32 bits, u32 val)
[RFC, PATCH 4/4] SoC base drivers: ASIC3 support for iPaq rx3715
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h | 19 ++
3 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2440/mach-rx3715.c
b/arch/arm/mach-s3c2440/mach-rx3715.c
index ae1d0a8..0c7285f 100644
--- a/arch/arm/mach-s3c2440/mach-rx3715.c
+++ b/arch/arm/mach-s3c2440/mach-rx3715.c
@@ -2,6 +2,7 @@
*
* Copyright (c) 2003,2004 Simtec Electronics
* Ben Dooks <[EMAIL PROTECTED]>
+ * Copyright 2006 Roman Moravcik <[EMAIL PROTECTED]>
*
* http://www.handhelds.org/projects/rx3715.html
*
@@ -50,6 +51,11 @@
#include
#include
+#include
+#include
+#include
+#include
+
static struct map_desc rx3715_iodesc[] __initdata = {
/* dump ISA space somewhere unused */
@@ -107,6 +113,84 @@ static struct s3c2410_uartcfg rx3715_uartcfgs[] = {
}
};
+/* ASIC3 SoC data */
+static struct asic3_platform_data rx3715_asic3_cfg = {
+ .gpio_a = {
+ .dir= 0x,
+ .init = 0x0028,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0030,
+ .batt_fault_out = 0x0030,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_b = {
+ .dir= 0x,
+ .init = 0x1a02,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0402,
+ .batt_fault_out = 0x0402,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_c = {
+ .dir= 0x,
+ .init = 0x0600,
+ .sleep_mask = 0x,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x0007,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_d = {
+ .dir= 0xfff0,
+ .init = 0x0040,
+ .sleep_mask = 0xfff0,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .irq_base = RX3000_ASIC3_IRQ_BASE,
+
+ /*.child_platform_devs = child_devices,
+ .num_child_platform_devs = ARRAY_SIZE(child_devices),*/
+};
+
+static struct resource s3c_asic3_resources[] = {
+ [0] = {
+ .start = 0x0800,
+ .end= 0x0800 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_EINT12,
+ .end= IRQ_EINT12,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* SD part */
+ [2] = {
+ .start = 0x1000,
+ .end= 0x1000 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [3] = {
+ .start = IRQ_EINT14,
+ .end= IRQ_EINT14,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device s3c_device_asic3 = {
+ .name = "asic3",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c_asic3_resources),
+ .resource = s3c_asic3_resources,
+ .dev = { .platform_data = _asic3_cfg, }
+};
+
+EXPORT_SYMBOL(s3c_device_asic3);
+
/* framebuffer lcd controller information */
static struct s3c2410fb_mach_info rx3715_lcdcfg __initdata = {
diff --git a/include/asm-arm/arch-s3c2410/rx3000-asic3.h
b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
new file mode 100644
index 000..5ffbeb4
--- /dev/null
+++ b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
@@ -0,0 +1,63 @@
+/*
+ * linux/include/asm-arm/arch-s3c2410/rx3000-asic3.h
+ *
+ * Written by Roman Moravcik <[EMAIL PROTECTED]>
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#ifndef __ASM_ARCH_RX3000_ASIC3_H
+#define __ASM_ARCH_RX3000_ASIC3_H "rx3000-asic3.h"
+
+#include
+
+/* GPIOA */
+#define ASIC3_GPA0 (1 << 0) /* charger enable, 0 =
disable, 1 = enable */
+#define ASIC3_GPA1 (1 << 1) /* audio mute, 0 = mute, 1 =
unmute */
+#define ASIC3_GPA2 (1 << 2) /* audio reset, 0 = disable,
1 = enable */
+#define ASIC3_GPA3 (1 << 3) /* usb d+ pullup, 0 =
disable, 1 = enable */
+#define ASIC3_GPA13(1 << 13) /* charger mode, 0 = slow, 1
= fast */
+#define ASIC3_GPA15(1 << 15) /* bluetooth clock 32kHz, 0 =
disable, 1 = enable */
+
+/* GPIOB */
+#define ASIC3_GPB1 (1 <<
[RFC, PATCH 0/4] SoC base drivers
Hello linux-kernel, In contemporary systems, lots of functionality oftentimes handled by various kinds of SoCs (system-on-chip), representing a number of deversified controllers packaged in one chip. Handling them is arguably an ongoing problem, as diversity and number of devices included make it hard to come with maintainable and reusable solution for writing drivers. Common examples are developing one monolithic driver for all internal devices, or making one of device drivers export functions required by others, leading to not very clean dependencies like touchscreen driver depending on a sound one. Handhelds.org kernel project (dealing with Linux porting to consumer, real-world embedded devices, and majority of our devices have different kinds of SoCs) for few years developed a more clean approach to handling SoCs - using the concept of "SoC base drivers". This is not the first time we're submitting these patches, with reworking and elaborating them based on the feedback received. We also extend supported machine base for these drivers (for example, asic3_base driver in the following patches is used by a dozen of machines). SoC base drivers - concept -- A SoC base driver is a special kind of driver which manages a SoC chip's common and shared resources and functionality, and provides interfaces for subdevice drivers to use. This in particukar solves "tangled dependencies" issues mentioned above - different subdevices now depend not on each other, but on a common foundation, forming a hierarchial structure. Term "interfaces" is used intentionally, as besides offering an API adhoc to specific SoC functionality, the intent is to reuse existing kernel susbystems/interfaces as much as possible, essentially breaking tight coupledness of subdevice drivers and base driver. For example, Generic IRQ Subsystem is used to handle SoC interrupts, so subdevice drivers just use existing generic API to request and free IRQs. More importantly, existing driver model is used to handle subdevices of a SoC. For each subdevice, a standard struct device is allocated, and LDM is used to handle driver binding and further lifecycle. So, this is a special trair of SoC base drivers: these are the drivers which register other devices (note that it is not a case of "legacy" driver where single module registers both a device and a driver serving it - SoC base driver registers other devices to be handled by other driver, namely SoC individual subdevices and drivers for them). Initial implementation from few years ago registered per-SoC bus for the purpose of attaching subdevices, but during LKML reviews it was pointed out that there're no good reasons for that, as such bus does not have any special functionality attached, so now platform_bus is used instead, for good. For the most part, subdevices are allocated dynamically, and SoC base driver calculates/fixes up resources and parameters for them, to be suitable for specific configuration (for example, different base address of SoC). What exact functionality and API a SoC base driver provides depends largely on specific chip, there's no specific API a SoC driver should implement. Here is a list of common tasks the driver usually would do: 1. Access handling to the chip (serialization, locking, etc.) 2. Managing common chip resources: 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). 2.3. Clocks (Using Platform Clock API) 2.4. Other kinds of "enable" and "power" switches (in adhoc manner or (ab)using the Clocks API, and waiting for generalization of it). 3. Calculating properties and registerting subdevices. There's a helper soc-core API to help SoC base drivers with common tasks, like registering subdevices. The implementation and patches following is structured as follows: 1. include/linux/soc/ and drivers/soc/ directories are created to keep namespaces clean (we have around 10 SoC base drivers now). Note that these dirs are for base drivers only, subdevice drivers go to one of standard dirs based on their functionality (for a example, video driver goes to driver/video/). 2. soc-core.c, soc-core.h: helper API to calculate subdevice resources and register them based on template definitions provided by SoC drivers. 3. asic3_base.c and associated headers: SoC base driver for HTC ASIC3, a popular SoC for ARM-based handheld devices, currently known to be used in 12 machines, including one machine which is already in mainline. 4. mach-3715.c: A patch for HP iPaq rx3715 machine, already in mainline, to add ASIC3 support using asic3_base driver. I would like to end this RFC with the fact that mainline of course already contains drivers for non-CPU SoC chips. arch/arm/common/sa.c and arch/arm/common/locomo.c are two examples from the ARM realm. This RFC grows from
[RFC, PATCH 1/4] SoC base drivers: SoC helper API
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c | 106
drivers/soc/soc-core.h | 30 +
include/linux/ioport.h |3 +
5 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7baca2..da7d318 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -997,6 +997,8 @@ source "drivers/mmc/Kconfig"
source "drivers/rtc/Kconfig"
+source "drivers/soc/Kconfig"
+
endmenu
source "fs/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 920c975..3fb8cf1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_GENERIC_TIME)+= clocksource/
obj-$(CONFIG_DMA_ENGINE) += dma/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
+obj-y += soc/
diff --git a/drivers/soc/soc-core.c b/drivers/soc/soc-core.c
new file mode 100644
index 000..24c654c
--- /dev/null
+++ b/drivers/soc/soc-core.c
@@ -0,0 +1,106 @@
+/*
+ * drivers/soc/soc-core.c
+ *
+ * core SoC support
+ * Copyright (c) 2006 Ian Molton
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains functionality used by many SoC type devices.
+ *
+ * Created: 2006-11-28
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "soc-core.h"
+
+void soc_free_devices(struct platform_device *devices, int nr_devs)
+{
+ struct platform_device *dev = devices;
+ int i;
+
+ for (i = 0; i < nr_devs; i++) {
+ struct resource *res = dev->resource;
+ platform_device_unregister(dev++);
+ kfree(res);
+ }
+ kfree(devices);
+}
+EXPORT_SYMBOL_GPL(soc_free_devices);
+
+#define SIGNED_SHIFT(val, shift) ((shift) >= 0 ? ((val) << (shift)) : ((val)
>> -(shift)))
+
+struct platform_device *soc_add_devices(struct platform_device *dev,
+ struct soc_device_data *soc, int
nr_devs,
+ struct resource *mem,
+ int relative_addr_shift, int irq_base)
+{
+ struct platform_device *devices;
+ int i, r, base;
+
+ devices = kzalloc(nr_devs * sizeof(struct platform_device), GFP_KERNEL);
+ if (!devices)
+ return NULL;
+
+ for (i = 0; i < nr_devs; i++) {
+ struct platform_device *sdev = [i];
+ struct soc_device_data *blk = [i];
+ struct resource *res;
+
+ sdev->id = -1;
+ sdev->name = blk->name;
+
+ sdev->dev.parent = >dev;
+ sdev->dev.platform_data = (void *)blk->hwconfig;
+ sdev->num_resources = blk->num_resources;
+
+ /* Allocate space for the subdevice resources */
+ res = kzalloc (blk->num_resources * sizeof (struct resource),
GFP_KERNEL);
+ if (!res)
+ goto fail;
+
+ for (r = 0 ; r < blk->num_resources ; r++) {
+ res[r].name = blk->res[r].name; // Fixme - should copy
+
+ /* Find out base to use */
+ base = 0;
+ if (blk->res[r].flags & IORESOURCE_MEM) {
+ base = mem->start;
+ } else if ((blk->res[r].flags & IORESOURCE_IRQ) &&
+ (blk->res[r].flags &
IORESOURCE_IRQ_SOC_SUBDEVICE)) {
+ base = irq_base;
+ }
+
+ /* Adjust resource */
+ if (blk->res[r].flags & IORESOURCE_MEM) {
+ res[r].parent = mem;
+ res[r].start = base +
SIGNED_SHIFT(blk->res[r].start, relative_addr_shift);
+ res[r].end = base +
SIGNED_SHIFT(blk->res[r].end, relative_addr_shift);
+ } else {
+ res[r].start = base + blk->res[r].start;
+ res[r].end = base + blk->res[r].end;
+ }
+ res[r].flags = blk->res[r].flags;
+ }
+
+ sdev->resource = res;
+ if (platform_device_register(sdev)) {
+ kfree(res);
+ goto fail;
+ }
+
+ printk(KERN_INFO "SoC: registering %s\n", blk->name);
+
[RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
Hello linux-kernel, Intro: This is a header with hardware definitions for ASIC3 chip, contributed by HP/Compaq. It is provided as-is, as a vendor-originated header. - ipaq-asic3.h: Hardware definitions for ASIC3 chip, found in ~12 handheld devices from HP/Compaq and HTC. Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]> include/asm-arm/hardware/ipaq-asic3.h | 609 + 1 files changed, 609 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/hardware/ipaq-asic3.h b/include/asm-arm/hardware/ipaq-asic3.h new file mode 100644 index 000..789bb16 --- /dev/null +++ b/include/asm-arm/hardware/ipaq-asic3.h @@ -0,0 +1,609 @@ +/* + * + * Definitions for the HTC ASIC3 chip found in several handheld devices + * + * Copyright 2001 Compaq Computer Corporation. + * + * Use consistent with the GNU GPL is permitted, + * provided that this copyright notice is + * preserved in its entirety in all copies and derived works. + * + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS + * FITNESS FOR ANY PARTICULAR PURPOSE. + * + * Author: Andrew Christian + * + */ + +#ifndef IPAQ_ASIC3_H +#define IPAQ_ASIC3_H + +// +/* IPAQ, ASIC #3, replaces ASIC #1 */ + +#define IPAQ_ASIC3(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## y +#define IPAQ_ASIC3_N(_b,s,x,y,z) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _ ## y ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## z + +#define IPAQ_ASIC3_GPIO(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_GPIO_ ## x ## _Base + (_IPAQ_ASIC3_GPIO_ ## y + +#define IPAQ_ASIC3_OFFSET(x,y) (_IPAQ_ASIC3_ ## x ## _Base + _IPAQ_ASIC3_ ## x ## _ ## y) +#define IPAQ_ASIC3_GPIO_OFFSET(x,y) (_IPAQ_ASIC3_GPIO_ ## x ## _Base + _IPAQ_ASIC3_GPIO_ ## y) + + +/* All offsets below are specified with this address bus shift */ +#define ASIC3_DEFAULT_ADDR_SHIFT 2 + +#define _IPAQ_ASIC3_GPIO_A_Base 0x +#define _IPAQ_ASIC3_GPIO_B_Base 0x0100 +#define _IPAQ_ASIC3_GPIO_C_Base 0x0200 +#define _IPAQ_ASIC3_GPIO_D_Base 0x0300 + +#define _IPAQ_ASIC3_GPIO_Mask 0x00/* R/W 0:don't mask, 1:mask interrupt */ +#define _IPAQ_ASIC3_GPIO_Direction 0x04/* R/W 0:input, 1:output */ +#define _IPAQ_ASIC3_GPIO_Out 0x08/* R/W 0:output low, 1:output high*/ +#define _IPAQ_ASIC3_GPIO_TriggerType 0x0c/* R/W 0:level, 1:edge */ +#define _IPAQ_ASIC3_GPIO_EdgeTrigger 0x10/* R/W 0:falling, 1:rising */ +#define _IPAQ_ASIC3_GPIO_LevelTrigger 0x14/* R/W 0:low, 1:high level detect */ +#define _IPAQ_ASIC3_GPIO_SleepMask 0x18/* R/W 0:don't mask, 1:mask trigger in sleep mode */ +#define _IPAQ_ASIC3_GPIO_SleepOut 0x1c/* R/W level 0:low, 1:high in sleep mode */ +#define _IPAQ_ASIC3_GPIO_BattFaultOut 0x20/* R/W level 0:low, 1:high in batt_fault */ +#define _IPAQ_ASIC3_GPIO_IntStatus 0x24/* R/W 0:none, 1:detect */ +#define _IPAQ_ASIC3_GPIO_AltFunction 0x28/* R/W 0:normal control 1:LED register control */ +#define _IPAQ_ASIC3_GPIO_SleepConf 0x2c/* R/W bit 1: autosleep 0: disable gposlpout in normal mode, enable gposlpout in sleep mode */ +#define _IPAQ_ASIC3_GPIO_Status0x30/* R Pin status */ + +#define IPAQ_ASIC3_GPIO_A_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, A, Mask ) +#define IPAQ_ASIC3_GPIO_A_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Direction ) +#define IPAQ_ASIC3_GPIO_A_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Out ) +#define IPAQ_ASIC3_GPIO_A_LEVELTRI(_b)IPAQ_ASIC3_GPIO( _b, u16, A, TriggerType ) +#define IPAQ_ASIC3_GPIO_A_RISING(_b) IPAQ_ASIC3_GPIO( _b, u16, A, EdgeTrigger ) +#define IPAQ_ASIC3_GPIO_A_LEVEL(_b) IPAQ_ASIC3_GPIO( _b, u16, A, LevelTrigger ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_MASK(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepMask ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepOut ) +#define IPAQ_ASIC3_GPIO_A_BATT_FAULT_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, BattFaultOut ) +#define IPAQ_ASIC3_GPIO_A_INT_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, IntStatus ) +#define IPAQ_ASIC3_GPIO_A_ALT_FUNCTION(_b)IPAQ_ASIC3_GPIO( _b, u16, A, AltFunction ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_CONF(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepConf ) +#define IPAQ_ASIC3_GPIO_A_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Status ) + +#define IPAQ_ASIC3_GPIO_B_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, B, Mask ) +#define IPAQ_ASIC3_GPIO_B_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, B, Direction ) +#define IPAQ_ASIC3_GPIO_B_
[RFC, PATCH 0/4] SoC base drivers
Hello linux-kernel, In contemporary systems, lots of functionality oftentimes handled by various kinds of SoCs (system-on-chip), representing a number of deversified controllers packaged in one chip. Handling them is arguably an ongoing problem, as diversity and number of devices included make it hard to come with maintainable and reusable solution for writing drivers. Common examples are developing one monolithic driver for all internal devices, or making one of device drivers export functions required by others, leading to not very clean dependencies like touchscreen driver depending on a sound one. Handhelds.org kernel project (dealing with Linux porting to consumer, real-world embedded devices, and majority of our devices have different kinds of SoCs) for few years developed a more clean approach to handling SoCs - using the concept of SoC base drivers. This is not the first time we're submitting these patches, with reworking and elaborating them based on the feedback received. We also extend supported machine base for these drivers (for example, asic3_base driver in the following patches is used by a dozen of machines). SoC base drivers - concept -- A SoC base driver is a special kind of driver which manages a SoC chip's common and shared resources and functionality, and provides interfaces for subdevice drivers to use. This in particukar solves tangled dependencies issues mentioned above - different subdevices now depend not on each other, but on a common foundation, forming a hierarchial structure. Term interfaces is used intentionally, as besides offering an API adhoc to specific SoC functionality, the intent is to reuse existing kernel susbystems/interfaces as much as possible, essentially breaking tight coupledness of subdevice drivers and base driver. For example, Generic IRQ Subsystem is used to handle SoC interrupts, so subdevice drivers just use existing generic API to request and free IRQs. More importantly, existing driver model is used to handle subdevices of a SoC. For each subdevice, a standard struct device is allocated, and LDM is used to handle driver binding and further lifecycle. So, this is a special trair of SoC base drivers: these are the drivers which register other devices (note that it is not a case of legacy driver where single module registers both a device and a driver serving it - SoC base driver registers other devices to be handled by other driver, namely SoC individual subdevices and drivers for them). Initial implementation from few years ago registered per-SoC bus for the purpose of attaching subdevices, but during LKML reviews it was pointed out that there're no good reasons for that, as such bus does not have any special functionality attached, so now platform_bus is used instead, for good. For the most part, subdevices are allocated dynamically, and SoC base driver calculates/fixes up resources and parameters for them, to be suitable for specific configuration (for example, different base address of SoC). What exact functionality and API a SoC base driver provides depends largely on specific chip, there's no specific API a SoC driver should implement. Here is a list of common tasks the driver usually would do: 1. Access handling to the chip (serialization, locking, etc.) 2. Managing common chip resources: 2.1. Interrupts control, demultiplexing, etc. (using Generic IRQ subsystem) 2.2. GPIO handling (adhoc, while eagerly waiting for an extensible GPIO API, we posted our implementation at http://lkml.org/lkml/2007/4/10/299 ). 2.3. Clocks (Using Platform Clock API) 2.4. Other kinds of enable and power switches (in adhoc manner or (ab)using the Clocks API, and waiting for generalization of it). 3. Calculating properties and registerting subdevices. There's a helper soc-core API to help SoC base drivers with common tasks, like registering subdevices. The implementation and patches following is structured as follows: 1. include/linux/soc/ and drivers/soc/ directories are created to keep namespaces clean (we have around 10 SoC base drivers now). Note that these dirs are for base drivers only, subdevice drivers go to one of standard dirs based on their functionality (for a example, video driver goes to driver/video/). 2. soc-core.c, soc-core.h: helper API to calculate subdevice resources and register them based on template definitions provided by SoC drivers. 3. asic3_base.c and associated headers: SoC base driver for HTC ASIC3, a popular SoC for ARM-based handheld devices, currently known to be used in 12 machines, including one machine which is already in mainline. 4. mach-3715.c: A patch for HP iPaq rx3715 machine, already in mainline, to add ASIC3 support using asic3_base driver. I would like to end this RFC with the fact that mainline of course already contains drivers for non-CPU SoC chips. arch/arm/common/sa.c and arch/arm/common/locomo.c are two examples from the ARM realm. This RFC grows from this fact,
[RFC, PATCH 1/4] SoC base drivers: SoC helper API
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c | 106
drivers/soc/soc-core.h | 30 +
include/linux/ioport.h |3 +
5 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7baca2..da7d318 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -997,6 +997,8 @@ source drivers/mmc/Kconfig
source drivers/rtc/Kconfig
+source drivers/soc/Kconfig
+
endmenu
source fs/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 920c975..3fb8cf1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_GENERIC_TIME)+= clocksource/
obj-$(CONFIG_DMA_ENGINE) += dma/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
+obj-y += soc/
diff --git a/drivers/soc/soc-core.c b/drivers/soc/soc-core.c
new file mode 100644
index 000..24c654c
--- /dev/null
+++ b/drivers/soc/soc-core.c
@@ -0,0 +1,106 @@
+/*
+ * drivers/soc/soc-core.c
+ *
+ * core SoC support
+ * Copyright (c) 2006 Ian Molton
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains functionality used by many SoC type devices.
+ *
+ * Created: 2006-11-28
+ *
+ */
+
+#include linux/ioport.h
+#include linux/slab.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include soc-core.h
+
+void soc_free_devices(struct platform_device *devices, int nr_devs)
+{
+ struct platform_device *dev = devices;
+ int i;
+
+ for (i = 0; i nr_devs; i++) {
+ struct resource *res = dev-resource;
+ platform_device_unregister(dev++);
+ kfree(res);
+ }
+ kfree(devices);
+}
+EXPORT_SYMBOL_GPL(soc_free_devices);
+
+#define SIGNED_SHIFT(val, shift) ((shift) = 0 ? ((val) (shift)) : ((val)
-(shift)))
+
+struct platform_device *soc_add_devices(struct platform_device *dev,
+ struct soc_device_data *soc, int
nr_devs,
+ struct resource *mem,
+ int relative_addr_shift, int irq_base)
+{
+ struct platform_device *devices;
+ int i, r, base;
+
+ devices = kzalloc(nr_devs * sizeof(struct platform_device), GFP_KERNEL);
+ if (!devices)
+ return NULL;
+
+ for (i = 0; i nr_devs; i++) {
+ struct platform_device *sdev = devices[i];
+ struct soc_device_data *blk = soc[i];
+ struct resource *res;
+
+ sdev-id = -1;
+ sdev-name = blk-name;
+
+ sdev-dev.parent = dev-dev;
+ sdev-dev.platform_data = (void *)blk-hwconfig;
+ sdev-num_resources = blk-num_resources;
+
+ /* Allocate space for the subdevice resources */
+ res = kzalloc (blk-num_resources * sizeof (struct resource),
GFP_KERNEL);
+ if (!res)
+ goto fail;
+
+ for (r = 0 ; r blk-num_resources ; r++) {
+ res[r].name = blk-res[r].name; // Fixme - should copy
+
+ /* Find out base to use */
+ base = 0;
+ if (blk-res[r].flags IORESOURCE_MEM) {
+ base = mem-start;
+ } else if ((blk-res[r].flags IORESOURCE_IRQ)
+ (blk-res[r].flags
IORESOURCE_IRQ_SOC_SUBDEVICE)) {
+ base = irq_base;
+ }
+
+ /* Adjust resource */
+ if (blk-res[r].flags IORESOURCE_MEM) {
+ res[r].parent = mem;
+ res[r].start = base +
SIGNED_SHIFT(blk-res[r].start, relative_addr_shift);
+ res[r].end = base +
SIGNED_SHIFT(blk-res[r].end, relative_addr_shift);
+ } else {
+ res[r].start = base + blk-res[r].start;
+ res[r].end = base + blk-res[r].end;
+ }
+ res[r].flags = blk-res[r].flags;
+ }
+
+ sdev-resource = res;
+ if (platform_device_register(sdev)) {
+ kfree(res);
+ goto fail;
+ }
+
+ printk(KERN_INFO SoC: registering %s\n, blk-name);
+ }
+ return devices;
+
+fail:
+ soc_free_devices(devices, i + 1);
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_add_devices);
diff --git a/drivers/soc
[RFC, PATCH 2/4] SoC base drivers: ASIC3 SoC hardware definitions
Hello linux-kernel, Intro: This is a header with hardware definitions for ASIC3 chip, contributed by HP/Compaq. It is provided as-is, as a vendor-originated header. - ipaq-asic3.h: Hardware definitions for ASIC3 chip, found in ~12 handheld devices from HP/Compaq and HTC. Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED] include/asm-arm/hardware/ipaq-asic3.h | 609 + 1 files changed, 609 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/hardware/ipaq-asic3.h b/include/asm-arm/hardware/ipaq-asic3.h new file mode 100644 index 000..789bb16 --- /dev/null +++ b/include/asm-arm/hardware/ipaq-asic3.h @@ -0,0 +1,609 @@ +/* + * + * Definitions for the HTC ASIC3 chip found in several handheld devices + * + * Copyright 2001 Compaq Computer Corporation. + * + * Use consistent with the GNU GPL is permitted, + * provided that this copyright notice is + * preserved in its entirety in all copies and derived works. + * + * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, + * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS + * FITNESS FOR ANY PARTICULAR PURPOSE. + * + * Author: Andrew Christian + * + */ + +#ifndef IPAQ_ASIC3_H +#define IPAQ_ASIC3_H + +// +/* IPAQ, ASIC #3, replaces ASIC #1 */ + +#define IPAQ_ASIC3(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## y +#define IPAQ_ASIC3_N(_b,s,x,y,z) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_ ## x ## _ ## y ## _Base + (_IPAQ_ASIC3_ ## x ## _ ## z + +#define IPAQ_ASIC3_GPIO(_b,s,x,y) \ + (*((volatile s *) (_b + _IPAQ_ASIC3_GPIO_ ## x ## _Base + (_IPAQ_ASIC3_GPIO_ ## y + +#define IPAQ_ASIC3_OFFSET(x,y) (_IPAQ_ASIC3_ ## x ## _Base + _IPAQ_ASIC3_ ## x ## _ ## y) +#define IPAQ_ASIC3_GPIO_OFFSET(x,y) (_IPAQ_ASIC3_GPIO_ ## x ## _Base + _IPAQ_ASIC3_GPIO_ ## y) + + +/* All offsets below are specified with this address bus shift */ +#define ASIC3_DEFAULT_ADDR_SHIFT 2 + +#define _IPAQ_ASIC3_GPIO_A_Base 0x +#define _IPAQ_ASIC3_GPIO_B_Base 0x0100 +#define _IPAQ_ASIC3_GPIO_C_Base 0x0200 +#define _IPAQ_ASIC3_GPIO_D_Base 0x0300 + +#define _IPAQ_ASIC3_GPIO_Mask 0x00/* R/W 0:don't mask, 1:mask interrupt */ +#define _IPAQ_ASIC3_GPIO_Direction 0x04/* R/W 0:input, 1:output */ +#define _IPAQ_ASIC3_GPIO_Out 0x08/* R/W 0:output low, 1:output high*/ +#define _IPAQ_ASIC3_GPIO_TriggerType 0x0c/* R/W 0:level, 1:edge */ +#define _IPAQ_ASIC3_GPIO_EdgeTrigger 0x10/* R/W 0:falling, 1:rising */ +#define _IPAQ_ASIC3_GPIO_LevelTrigger 0x14/* R/W 0:low, 1:high level detect */ +#define _IPAQ_ASIC3_GPIO_SleepMask 0x18/* R/W 0:don't mask, 1:mask trigger in sleep mode */ +#define _IPAQ_ASIC3_GPIO_SleepOut 0x1c/* R/W level 0:low, 1:high in sleep mode */ +#define _IPAQ_ASIC3_GPIO_BattFaultOut 0x20/* R/W level 0:low, 1:high in batt_fault */ +#define _IPAQ_ASIC3_GPIO_IntStatus 0x24/* R/W 0:none, 1:detect */ +#define _IPAQ_ASIC3_GPIO_AltFunction 0x28/* R/W 0:normal control 1:LED register control */ +#define _IPAQ_ASIC3_GPIO_SleepConf 0x2c/* R/W bit 1: autosleep 0: disable gposlpout in normal mode, enable gposlpout in sleep mode */ +#define _IPAQ_ASIC3_GPIO_Status0x30/* R Pin status */ + +#define IPAQ_ASIC3_GPIO_A_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, A, Mask ) +#define IPAQ_ASIC3_GPIO_A_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Direction ) +#define IPAQ_ASIC3_GPIO_A_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Out ) +#define IPAQ_ASIC3_GPIO_A_LEVELTRI(_b)IPAQ_ASIC3_GPIO( _b, u16, A, TriggerType ) +#define IPAQ_ASIC3_GPIO_A_RISING(_b) IPAQ_ASIC3_GPIO( _b, u16, A, EdgeTrigger ) +#define IPAQ_ASIC3_GPIO_A_LEVEL(_b) IPAQ_ASIC3_GPIO( _b, u16, A, LevelTrigger ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_MASK(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepMask ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepOut ) +#define IPAQ_ASIC3_GPIO_A_BATT_FAULT_OUT(_b) IPAQ_ASIC3_GPIO( _b, u16, A, BattFaultOut ) +#define IPAQ_ASIC3_GPIO_A_INT_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, IntStatus ) +#define IPAQ_ASIC3_GPIO_A_ALT_FUNCTION(_b)IPAQ_ASIC3_GPIO( _b, u16, A, AltFunction ) +#define IPAQ_ASIC3_GPIO_A_SLEEP_CONF(_b) IPAQ_ASIC3_GPIO( _b, u16, A, SleepConf ) +#define IPAQ_ASIC3_GPIO_A_STATUS(_b) IPAQ_ASIC3_GPIO( _b, u16, A, Status ) + +#define IPAQ_ASIC3_GPIO_B_MASK(_b)IPAQ_ASIC3_GPIO( _b, u16, B, Mask ) +#define IPAQ_ASIC3_GPIO_B_DIR(_b) IPAQ_ASIC3_GPIO( _b, u16, B, Direction ) +#define IPAQ_ASIC3_GPIO_B_OUT(_b
[RFC, PATCH 3/4] SoC base drivers: ASIC3 driver
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
drivers/soc/Kconfig| 22 +
drivers/soc/Makefile |5 +
drivers/soc/asic3_base.c | 1177
include/linux/soc/asic3_base.h | 100
include/linux/soc/tmio_mmc.h | 17 +
5 files changed, 1321 insertions(+), 0 deletions(-)
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
new file mode 100644
index 000..2c9d846
--- /dev/null
+++ b/drivers/soc/Kconfig
@@ -0,0 +1,22 @@
+#
+# SoC drivers
+#
+# System-on-Chip are chips that implement a number of virtually unrelated
+# functions but sharing some common circuitry, for example power management
+# or an auxiliary interrupt controller.
+#
+
+menu SoC drivers
+
+config SOC_ASIC3
+ tristate HTC ASIC3 SoC support (iPAQ HTC PDAs)
+
+config SOC_ASIC3_DS1WM
+ bool Support HTC ASIC3 builtin DS1WM block
+ depends on SOC_ASIC3
+ help
+ Choose Y here if you want to include support for ASIC3's builtin
+ W1 controller. Some devices do not use it, and yet other have
+ separate DS1WM controller. For them, choose N.
+
+endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
new file mode 100644
index 000..13031b1
--- /dev/null
+++ b/drivers/soc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for SoC drivers.
+#
+
+obj-$(CONFIG_SOC_ASIC3)+= asic3_base.o soc-core.o
diff --git a/drivers/soc/asic3_base.c b/drivers/soc/asic3_base.c
new file mode 100644
index 000..ca0f862
--- /dev/null
+++ b/drivers/soc/asic3_base.c
@@ -0,0 +1,1177 @@
+/*
+ * Driver interface to HTC ASIC3
+ *
+ * Copyright 2001 Compaq Computer Corporation.
+ * Copyright 2004-2005 Phil Blundell
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ * COMPAQ COMPUTER CORPORATION MAKES NO WARRANTIES, EXPRESSED OR IMPLIED,
+ * AS TO THE USEFULNESS OR CORRECTNESS OF THIS CODE OR ITS
+ * FITNESS FOR ANY PARTICULAR PURPOSE.
+ *
+ * Author: Andrew Christian
+ * [EMAIL PROTECTED]
+ * October 2001
+ */
+
+#include linux/module.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/irq.h
+#include linux/clk.h
+#include linux/ds1wm.h
+#ifdef CONFIG_PLAT_S3C24XX
+#include asm/plat-s3c24xx/clock.h
+#define clk_register(clk) s3c24xx_register_clock(clk)
+#define clk_unregister(clk)
+#else
+#include asm/arch/clock.h
+#endif
+
+#include asm/hardware.h
+#include asm/irq.h
+#include asm/io.h
+
+#include asm/hardware/ipaq-asic3.h
+#include linux/soc/asic3_base.h
+#include linux/soc/tmio_mmc.h
+#include soc-core.h
+
+
+struct asic3_data
+{
+ void *mapping;
+ unsigned int bus_shift;
+ int irq_base;
+ int irq_nr;
+
+ u16 irq_bothedge[4];
+ struct device *dev;
+
+ struct platform_device *mmc_dev;
+};
+
+static spinlock_t asic3_gpio_lock;
+
+static int asic3_remove(struct platform_device *dev);
+
+static inline unsigned long asic3_address(struct device *dev,
+ unsigned int reg)
+{
+ struct asic3_data *adata;
+
+ adata = (struct asic3_data *)dev-driver_data;
+
+ return (unsigned long)adata-mapping + (reg (2 - adata-bus_shift));
+}
+
+void asic3_write_register(struct device *dev, unsigned int reg, u32 value)
+{
+ __raw_writew(value, asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_write_register);
+
+u32 asic3_read_register(struct device *dev, unsigned int reg)
+{
+ return __raw_readw(asic3_address(dev, reg));
+}
+EXPORT_SYMBOL(asic3_read_register);
+
+static inline void __asic3_write_register(struct asic3_data *asic,
+ unsigned int reg, u32 value)
+{
+ __raw_writew(value, (unsigned long)asic-mapping
+ + (reg (2 - asic-bus_shift)));
+}
+
+static inline u32 __asic3_read_register(struct asic3_data *asic,
+ unsigned int reg)
+{
+ return __raw_readw((unsigned long)asic-mapping
+ + (reg (2 - asic-bus_shift)));
+}
+
+#define ASIC3_GPIO_FN(get_fn_name, set_fn_name, REG) \
+u32 get_fn_name(struct device *dev)\
+{ \
+ return asic3_read_register(dev, REG); \
+} \
+EXPORT_SYMBOL(get_fn_name);\
+ \
+void set_fn_name(struct device *dev, u32 bits, u32 val
[RFC, PATCH 4/4] SoC base drivers: ASIC3 support for iPaq rx3715
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h | 19 ++
3 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2440/mach-rx3715.c
b/arch/arm/mach-s3c2440/mach-rx3715.c
index ae1d0a8..0c7285f 100644
--- a/arch/arm/mach-s3c2440/mach-rx3715.c
+++ b/arch/arm/mach-s3c2440/mach-rx3715.c
@@ -2,6 +2,7 @@
*
* Copyright (c) 2003,2004 Simtec Electronics
* Ben Dooks [EMAIL PROTECTED]
+ * Copyright 2006 Roman Moravcik [EMAIL PROTECTED]
*
* http://www.handhelds.org/projects/rx3715.html
*
@@ -50,6 +51,11 @@
#include asm/plat-s3c24xx/cpu.h
#include asm/plat-s3c24xx/pm.h
+#include linux/soc/asic3_base.h
+#include asm/hardware/ipaq-asic3.h
+#include asm/arch/rx3000.h
+#include asm/arch/rx3000-asic3.h
+
static struct map_desc rx3715_iodesc[] __initdata = {
/* dump ISA space somewhere unused */
@@ -107,6 +113,84 @@ static struct s3c2410_uartcfg rx3715_uartcfgs[] = {
}
};
+/* ASIC3 SoC data */
+static struct asic3_platform_data rx3715_asic3_cfg = {
+ .gpio_a = {
+ .dir= 0x,
+ .init = 0x0028,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0030,
+ .batt_fault_out = 0x0030,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_b = {
+ .dir= 0x,
+ .init = 0x1a02,
+ .sleep_mask = 0x,
+ .sleep_out = 0x0402,
+ .batt_fault_out = 0x0402,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_c = {
+ .dir= 0x,
+ .init = 0x0600,
+ .sleep_mask = 0x,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x0007,
+ .sleep_conf = 0x0008,
+ },
+ .gpio_d = {
+ .dir= 0xfff0,
+ .init = 0x0040,
+ .sleep_mask = 0xfff0,
+ .sleep_out = 0x,
+ .batt_fault_out = 0x,
+ .alt_function = 0x,
+ .sleep_conf = 0x0008,
+ },
+ .irq_base = RX3000_ASIC3_IRQ_BASE,
+
+ /*.child_platform_devs = child_devices,
+ .num_child_platform_devs = ARRAY_SIZE(child_devices),*/
+};
+
+static struct resource s3c_asic3_resources[] = {
+ [0] = {
+ .start = 0x0800,
+ .end= 0x0800 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_EINT12,
+ .end= IRQ_EINT12,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* SD part */
+ [2] = {
+ .start = 0x1000,
+ .end= 0x1000 + IPAQ_ASIC3_MAP_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [3] = {
+ .start = IRQ_EINT14,
+ .end= IRQ_EINT14,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device s3c_device_asic3 = {
+ .name = asic3,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c_asic3_resources),
+ .resource = s3c_asic3_resources,
+ .dev = { .platform_data = rx3715_asic3_cfg, }
+};
+
+EXPORT_SYMBOL(s3c_device_asic3);
+
/* framebuffer lcd controller information */
static struct s3c2410fb_mach_info rx3715_lcdcfg __initdata = {
diff --git a/include/asm-arm/arch-s3c2410/rx3000-asic3.h
b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
new file mode 100644
index 000..5ffbeb4
--- /dev/null
+++ b/include/asm-arm/arch-s3c2410/rx3000-asic3.h
@@ -0,0 +1,63 @@
+/*
+ * linux/include/asm-arm/arch-s3c2410/rx3000-asic3.h
+ *
+ * Written by Roman Moravcik [EMAIL PROTECTED]
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#ifndef __ASM_ARCH_RX3000_ASIC3_H
+#define __ASM_ARCH_RX3000_ASIC3_H rx3000-asic3.h
+
+#include asm/hardware/ipaq-asic3.h
+
+/* GPIOA */
+#define ASIC3_GPA0 (1 0) /* charger enable, 0 =
disable, 1 = enable */
+#define ASIC3_GPA1 (1 1) /* audio mute, 0 = mute, 1 =
unmute */
+#define ASIC3_GPA2 (1 2) /* audio reset, 0 = disable,
1 = enable */
+#define ASIC3_GPA3 (1 3) /* usb d+ pullup, 0 =
disable, 1 = enable */
+#define ASIC3_GPA13(1 13) /* charger mode, 0 = slow, 1
= fast */
+#define ASIC3_GPA15
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>> >> > So, talking about what an (optional) implementation framework might
>> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
>> >> > I've looked at):
>>
>> > See patches in following messages ... a preliminary "gpio_chip" core
>> > for such a framework, plus example support for one SOC family's GPIOs,
>> > and then updating one board's handling of GPIOs, including over I2C.
>>
>> Just to compare, diffstats for GPIODEV:
> Now, if they were functionally equivalent, such a comparison
> would be less of an apples/oranges thing!
But of course they are functionally equivalent! They do the
same thing - manage GPIOs. They even do it in very similar ways. To
remind, the only differences we (I) come to, are:
1. Structured GPIO identifiers instead of scalar.
2. No explicit adhoc structures similar to irq_desc & irq_chip.
3. Lesser (even though slightly) latency.
4. Not tied to not really directly related notions like "platform".
Any optimization which you apply to your implementation can be
applied to GPIODEV. GPIODEV was submitted in that form because its
first requirement was to replace simple chip-adhoc GPIO accessors, so
there's no additional things like reporting GPIO info to userspace
(but again, that can be added, even based on your implementation).
> The most useful comparison would focus on technical aspects of
> the gpio_chip abstraction itself (i.e. $SUBJECT).
Nice. But $SUBJECT is a specific question, and it was answered
in one of the first messages of the thread: No, there's no GPIO chip
framework like IRQ chips [in the mainline], and there're concerns if a
framework in such form ("like IRQ chips") is needed at all, and
alternative implementation was proposed.
>> it needs work - it doesn't adhere to your own
>> optimization scheme by using lookup table instead of list.
> I thought it was more important to address the $SUBJECT first:
Well, is this your last argument why your implementation is
better: GPIO chip framework is needed just because there's some random
mail subject which mentions it?
Anyway, the discussion happens under this subject just because
current of discussion followed in this way. The one of topics of
the discussion was presentation of alternative to gpio_chip
implementation, so please don't tell I do offtopic here.
> get a working gpio_chip abstraction which covers all the needed
> functionality. The patch had a hook for implementing such tweaks,
> but it wasn't used.
> The next version you'll see lets the platform code use its own
> existing lookup code, as part of slimming things down a bit.
> I also decided to take out the debugfs support.
>>you speak about constructor
>> parts which "anyone" can use to construct whatever GPIO API they like,
>> whereas I'm speaking about exact API implementation which can be used
>> right away.
> I most certainly did not speak about "whatever GPIO API they like"!!
> Quite the contrary, in fact. Please don't put words in my mouth.
> (You've been doing it quite extensively in this thread; it's rude.)
I kindly apologize if heat of discussion led me so far. But
maybe information you supplied was a bit scarce, and that made me
imagine too much?
Let's recollect with what the discussion started: proposal
from myself and other HH.org developers of the alternative implementation,
and you quickly verdicted that without specific patches, you stop the
discussion. They were posted, technical aspects of them were
discussed, and compared to your proposed implementation. In the end,
you posted your patches, which doesn't even correspond with the
implementation you yourself presented, and adapted only for OMAP.
And we both understand well why we can't reach agreement here:
we represent different communities with different needs. You
represent "platform hacking" community, and it's all sunny in your
realm, while we're machine-hacking guys, and we'd rather exactly hack
machines, but regularly bump into different "platform" and
"architecture" issues which we'd be glad not to deal with at all. But
we have to, and then based on this painful experience we design new
things which are not unnecessarily tied to specific platform or
architecture, at the same time trying to alleviate burden on
platform on architecture maintainers.
> And that "core" patch I posted was clearly usable "right away";
> otherwise the two examples _using_ it couldn't have worked.
It works "right away" only on OMAP. For other (sub)archs,
header patching is required and that's clearly not "right away" for
the scope of mainline Linux, which we discuss here (because it makes
little sense to discuss feudalistic trees at all - in them, anything
can be done in any way without my or your guidelines how to do that).
Now that other (sub)archs need cut'n'paste patches, it's quite
another
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David, Thursday, April 19, 2007, 5:22:44 AM, you wrote: So, talking about what an (optional) implementation framework might look like (and which could handle the SOC, FPGA, I2C, and MFD cases I've looked at): See patches in following messages ... a preliminary gpio_chip core for such a framework, plus example support for one SOC family's GPIOs, and then updating one board's handling of GPIOs, including over I2C. Just to compare, diffstats for GPIODEV: Now, if they were functionally equivalent, such a comparison would be less of an apples/oranges thing! But of course they are functionally equivalent! They do the same thing - manage GPIOs. They even do it in very similar ways. To remind, the only differences we (I) come to, are: 1. Structured GPIO identifiers instead of scalar. 2. No explicit adhoc structures similar to irq_desc irq_chip. 3. Lesser (even though slightly) latency. 4. Not tied to not really directly related notions like platform. Any optimization which you apply to your implementation can be applied to GPIODEV. GPIODEV was submitted in that form because its first requirement was to replace simple chip-adhoc GPIO accessors, so there's no additional things like reporting GPIO info to userspace (but again, that can be added, even based on your implementation). The most useful comparison would focus on technical aspects of the gpio_chip abstraction itself (i.e. $SUBJECT). Nice. But $SUBJECT is a specific question, and it was answered in one of the first messages of the thread: No, there's no GPIO chip framework like IRQ chips [in the mainline], and there're concerns if a framework in such form (like IRQ chips) is needed at all, and alternative implementation was proposed. it needs work - it doesn't adhere to your own optimization scheme by using lookup table instead of list. I thought it was more important to address the $SUBJECT first: Well, is this your last argument why your implementation is better: GPIO chip framework is needed just because there's some random mail subject which mentions it? Anyway, the discussion happens under this subject just because current of discussion followed in this way. The one of topics of the discussion was presentation of alternative to gpio_chip implementation, so please don't tell I do offtopic here. get a working gpio_chip abstraction which covers all the needed functionality. The patch had a hook for implementing such tweaks, but it wasn't used. The next version you'll see lets the platform code use its own existing lookup code, as part of slimming things down a bit. I also decided to take out the debugfs support. you speak about constructor parts which anyone can use to construct whatever GPIO API they like, whereas I'm speaking about exact API implementation which can be used right away. I most certainly did not speak about whatever GPIO API they like!! Quite the contrary, in fact. Please don't put words in my mouth. (You've been doing it quite extensively in this thread; it's rude.) I kindly apologize if heat of discussion led me so far. But maybe information you supplied was a bit scarce, and that made me imagine too much? Let's recollect with what the discussion started: proposal from myself and other HH.org developers of the alternative implementation, and you quickly verdicted that without specific patches, you stop the discussion. They were posted, technical aspects of them were discussed, and compared to your proposed implementation. In the end, you posted your patches, which doesn't even correspond with the implementation you yourself presented, and adapted only for OMAP. And we both understand well why we can't reach agreement here: we represent different communities with different needs. You represent platform hacking community, and it's all sunny in your realm, while we're machine-hacking guys, and we'd rather exactly hack machines, but regularly bump into different platform and architecture issues which we'd be glad not to deal with at all. But we have to, and then based on this painful experience we design new things which are not unnecessarily tied to specific platform or architecture, at the same time trying to alleviate burden on platform on architecture maintainers. And that core patch I posted was clearly usable right away; otherwise the two examples _using_ it couldn't have worked. It works right away only on OMAP. For other (sub)archs, header patching is required and that's clearly not right away for the scope of mainline Linux, which we discuss here (because it makes little sense to discuss feudalistic trees at all - in them, anything can be done in any way without my or your guidelines how to do that). Now that other (sub)archs need cut'n'paste patches, it's quite another task to push them back to mainline, as again, that would go thru overbusy platform
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David, Sunday, April 15, 2007, 10:47:57 PM, you wrote: > On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote: >> Wednesday, April 11, 2007, 7:52:20 AM, you wrote: >> > So, talking about what an (optional) implementation framework might >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases >> > I've looked at): > See patches in following messages ... a preliminary "gpio_chip" core > for such a framework, plus example support for one SOC family's GPIOs, > and then updating one board's handling of GPIOs, including over I2C. Just to compare, diffstats for GPIODEV: Core API, 0 bytes of dedicated support code: diffstat 0001-gpiodev-api.patch gpiodev.h | 43 +++ 1 file changed, 43 insertions(+) Adding GPIODEV for GPIOs without dedicated device (would be less if there was struct device already): diffstat 0002-gpiodev-for-pxa.patch generic.c | 37 + 1 file changed, 37 insertions(+) While it's understood that your code contains refactors, extensive error checking, debugging support, etc. it's clear that gpiolib.c has some weight to drop into kernel. But I'm a bit stumbled by that code. What's that? Is it just example of implementation of your approach? Or is it code to go into kernel? In this case, it needs work - it doesn't adhere to your own optimization scheme by using lookup table instead of list. Or is it again example of what should be done by folks who want to use extensible GPIO at all - specifically, hacking platform header to plug there such framework? In the latter case, we again speak about different things, or about different levels of such things - you speak about constructor parts which "anyone" can use to construct whatever GPIO API they like, whereas I'm speaking about exact API implementation which can be used right away. [] > The fact that there are now three simple generic drivers (i2c-gpio, > leds-gpio, gpio_keys) and various additional drivers using those same > interfaces -- working already on multiple platforms! -- illustrates > that anything more than a programming interface, with support on a > handful of "seed" platforms, wasn't required initially. Well, besides gpio_keys we here have asic3_keys, samcop_keys, etc. - all that duplication just because the current GPIO API doesn't allow extensibility to more chips. >> Yes, and let that's something which can be entailed from your >> approach: you argue that it's extensible interface, but kernel is >> exactly not C++ classlib, there must be implementation. > I said "implementation choice" not "extensible interface"; those > are two very different approaches. > You keep bringing C++ into this. Sorry, how could I? I didn't post a single line of C++ code, vice-versa, posted patches in plain C, which work for any platform/architecture/etc. Words like "interface" are used only on design stage. After that, there's just C code ready for calls. There's no "one implementation strategy is", "another implementation strategy is", etc. > You may not know that doesn't win points in Linux. Why, I believe I know local taboos and labels. ;-) > If the point is solid, it doesn't need to > rely on parallels to languages that won't be used in the kernel. > (Plus, why would you imply C++ class libraries don't need to > have implementations?) >> And that >> implementation: a) will contain inline access for CPU SOC GPIO >> controllers, just because "they are always there"; > Not what I said. You said "will", I said "can"; there's a big > difference. Consider that for example the OMAP infrastructure > for GPIOs already has a fair amount of indirection, while most > other platforms started more simply ... some of them only > included inlines, others just had simple accessor functions. > My "can" allows all those; your "will" disallows most of them. Yes, in the same sense as some wheel-producing machine disallows production of square and hexagon wheels. As I told, that was one of the reason I decided to submit my patches as patches, not just RFC, and argue for them - there're already bunch of square pegs in ARM Linux, and allowing only round (or square) ones instead of both seems like refreshing change. > And none of them unified that model with non-SOC GPIOs. [] >> Yes, you argue that anyone who needs to extend Generic GPIO API to >> their case can do that, and in such way that he won't lose single tick >> comparing to using direct low-level methods. > Again, not what I said ... I've discouraged changing/extending the > programming interface.
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David, Sunday, April 15, 2007, 10:47:57 PM, you wrote: On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote: Wednesday, April 11, 2007, 7:52:20 AM, you wrote: So, talking about what an (optional) implementation framework might look like (and which could handle the SOC, FPGA, I2C, and MFD cases I've looked at): See patches in following messages ... a preliminary gpio_chip core for such a framework, plus example support for one SOC family's GPIOs, and then updating one board's handling of GPIOs, including over I2C. Just to compare, diffstats for GPIODEV: Core API, 0 bytes of dedicated support code: diffstat 0001-gpiodev-api.patch gpiodev.h | 43 +++ 1 file changed, 43 insertions(+) Adding GPIODEV for GPIOs without dedicated device (would be less if there was struct device already): diffstat 0002-gpiodev-for-pxa.patch generic.c | 37 + 1 file changed, 37 insertions(+) While it's understood that your code contains refactors, extensive error checking, debugging support, etc. it's clear that gpiolib.c has some weight to drop into kernel. But I'm a bit stumbled by that code. What's that? Is it just example of implementation of your approach? Or is it code to go into kernel? In this case, it needs work - it doesn't adhere to your own optimization scheme by using lookup table instead of list. Or is it again example of what should be done by folks who want to use extensible GPIO at all - specifically, hacking platform header to plug there such framework? In the latter case, we again speak about different things, or about different levels of such things - you speak about constructor parts which anyone can use to construct whatever GPIO API they like, whereas I'm speaking about exact API implementation which can be used right away. [] The fact that there are now three simple generic drivers (i2c-gpio, leds-gpio, gpio_keys) and various additional drivers using those same interfaces -- working already on multiple platforms! -- illustrates that anything more than a programming interface, with support on a handful of seed platforms, wasn't required initially. Well, besides gpio_keys we here have asic3_keys, samcop_keys, etc. - all that duplication just because the current GPIO API doesn't allow extensibility to more chips. Yes, and let that's something which can be entailed from your approach: you argue that it's extensible interface, but kernel is exactly not C++ classlib, there must be implementation. I said implementation choice not extensible interface; those are two very different approaches. You keep bringing C++ into this. Sorry, how could I? I didn't post a single line of C++ code, vice-versa, posted patches in plain C, which work for any platform/architecture/etc. Words like interface are used only on design stage. After that, there's just C code ready for calls. There's no one implementation strategy is, another implementation strategy is, etc. You may not know that doesn't win points in Linux. Why, I believe I know local taboos and labels. ;-) If the point is solid, it doesn't need to rely on parallels to languages that won't be used in the kernel. (Plus, why would you imply C++ class libraries don't need to have implementations?) And that implementation: a) will contain inline access for CPU SOC GPIO controllers, just because they are always there; Not what I said. You said will, I said can; there's a big difference. Consider that for example the OMAP infrastructure for GPIOs already has a fair amount of indirection, while most other platforms started more simply ... some of them only included inlines, others just had simple accessor functions. My can allows all those; your will disallows most of them. Yes, in the same sense as some wheel-producing machine disallows production of square and hexagon wheels. As I told, that was one of the reason I decided to submit my patches as patches, not just RFC, and argue for them - there're already bunch of square pegs in ARM Linux, and allowing only round (or square) ones instead of both seems like refreshing change. And none of them unified that model with non-SOC GPIOs. [] Yes, you argue that anyone who needs to extend Generic GPIO API to their case can do that, and in such way that he won't lose single tick comparing to using direct low-level methods. Again, not what I said ... I've discouraged changing/extending the programming interface. But I've certainly pointed out ways that existing performance expectations can be preserved without changing that programming interface. Ok, so this, IMHO, keeps to be the most valid point in favor of continuing to use flat GPIO namespace. Challenging that would mean to challenge original requirements for API, and that was done in January, and I don't want
Re: [Kernel-discuss] Re: [PATCH 7/7] [RFC] APM emulation driver for class batteries
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
> On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
>> +static void (*old_apm_get_power_status)(struct apm_power_info*);
>> +
>> +static int __init apm_battery_init(void)
>> +{
>> + printk(KERN_INFO "APM Battery Driver\n");
>> +
>> + old_apm_get_power_status = apm_get_power_status;
>> + apm_get_power_status = apm_battery_apm_get_power_status;
>> + return 0;
>> +}
>> +
>> +static void __exit apm_battery_exit(void)
>> +{
>> + apm_get_power_status = old_apm_get_power_status;
>> + return;
>> +}
> Utterly unsafe. What happens if some other module gets loaded which
> does this, and then this module is unloaded followed by the other
> module. Result: Oops.
That's apparently why "APM emulation" goes on its way towards
deprecation, right? And why people so detailed about new battery API, as it's
everyone's hope that it should replace APM.
We exactly provide APM emulation on top of battery API as separate
driver because of such issues with APM API. Anyway, any suggestions on solving
this "pointer API" issue? Would at least assigning NULL on exit be more safe?
(Because yes, there just shouldn't be two APM drivers, and for the weird case
there're, it would be nice to at least not segfault.)
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 7/7] [RFC] APM emulation driver for class batteries
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
+static void (*old_apm_get_power_status)(struct apm_power_info*);
+
+static int __init apm_battery_init(void)
+{
+ printk(KERN_INFO APM Battery Driver\n);
+
+ old_apm_get_power_status = apm_get_power_status;
+ apm_get_power_status = apm_battery_apm_get_power_status;
+ return 0;
+}
+
+static void __exit apm_battery_exit(void)
+{
+ apm_get_power_status = old_apm_get_power_status;
+ return;
+}
Utterly unsafe. What happens if some other module gets loaded which
does this, and then this module is unloaded followed by the other
module. Result: Oops.
That's apparently why APM emulation goes on its way towards
deprecation, right? And why people so detailed about new battery API, as it's
everyone's hope that it should replace APM.
We exactly provide APM emulation on top of battery API as separate
driver because of such issues with APM API. Anyway, any suggestions on solving
this pointer API issue? Would at least assigning NULL on exit be more safe?
(Because yes, there just shouldn't be two APM drivers, and for the weird case
there're, it would be nice to at least not segfault.)
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Matthew, Thursday, April 12, 2007, 5:24:30 PM, you wrote: > On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote: >> On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote: >> > ACPI batteries can report capacity and rate in either mA or mW. Given >> >> You sure, capacity in mA? Then I don't know. But you can safely >> fallback and create your own attribute (just as in David's battery class, >> where every battery required to create its own attributes), plus create >> capacity_units attribute. So, user space will know your driver's specific >> units. > Well, mAh, but yes. Clearly it's possible to add extra attributes, but > speccing standard attributes that don't entirely cover the most common > non-embedded battery class seems less than ideal. Why not just require > capacity_units and rate_units attributes? Yes, that's apparently the way to go. We just should consider if mAh and mWh are enough, or we go wider and allow whole collection of units. Btw, original handhelds.org code used Joules ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] gpiodev - API definitions
Hello Juergen,
Wednesday, April 11, 2007, 9:47:01 AM, you wrote:
> Am Dienstag, 10. April 2007 23:30 schrieb Paul Sokolovsky:
>> Hello linux-arm-kernel,
>>
>> GPIODEV API: Core API definitions. Provided are:
>> 1. struct gpiodev_ops which must be included into platform_data structure
>> of a device which will provide GPIODEV API; driver for a device must
>> initialize this structure.
>> 2. Structural definition of generalized GPIO identifier (struct gpio).
>> 2. Set of API calls for clients. This fully follow Generic GPIO API
>> naming and semantics, except that they have "gpiodev" prefix and
>> accept struct gpio instead of integer gpio identifiers.
>>
>>
[]
>> +/* API functions */
>> +
>> +static inline int gpiodev_get_value(struct gpio *gpio)
>> +{
>> + struct gpiodev_ops *ops = gpio->gpio_dev->dev.platform_data;
> wouldn't it be more sure to verify if xxx function is NOT null
> before using it ?? Perhaps something like that
> BUG_ON(!ops->get);
GPIODEV is considered to be low-level one and critical for speed, so
all method pointers assumed to be set properly. In particular, if some
operation is not available for a device (say, GPI/GPO case), a method
must be set to a stab function.
BUG_ON would be acceptable, as it can be compiled out based on
CONFIG setting, but as was pointed out, doesn't add much into picture
anyway.
But I'd be happy to add comment to struct gpiodev_ops declaration
about the described method constraints, thanks for comment.
[]
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
> On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>>
>> > /* defined by the platform using array, if/else/..., IDR, or
>> > whatever */
>> > struct gpio_yyy *gpio_to_yyy(unsigned gpio);
>>
>>I assume by "platform" you mean CPU architecture.
> Nope. ARM (v4, v5, v6, etc) is a CPU architecture. "Platform" is
> fuzzily defined but it's more than the CPU. It's a "family" notion
> that probably ties better to SOC chip vendor and branding ... things
> work differently on TI OMAP processors than on Intel IOP ones, or than
> the PXA ones (originally from Intel). For many folk, "platform" is a
> board-level notion ... like "x86_PC with ACPI firmware".
>>For example, say, ASIC3 appears in both PXA and S3Cxxx
>> devices. Suppose driver which uses ASIC3 works well on PXA, but acts up
>> on S3Cxxx.
> The thing to do with bugs is fix them. If S3C were to have a failure
> at that level, there'd be a lot more failures than just that one.
Programmers fix bugs. System designers make systems without
inclination to have bugs at random places. So, let's try to do the
former ;-) (in the sense, let's try to make a framework which will be
devoid of possibility for such variations; note that this doesn't mean
that framework which allows them, but has other benefits, is *not*
outruled by this).
>>So, let me
>> continue this and ask: how GPIO handling relates to CPU architecture
>> at all (and that's what I assume you mean by "platform")? The answer:
>> it does not.
> Certainly not ... and the interface doesn't. Any more than IRQs do.
> Implementations most certainly can be platform-specific. And they
> usually are, of necessity (different controllers, etc).
> So, talking about what an (optional) implementation framework might
> look like (and which could handle the SOC, FPGA, I2C, and MFD cases
> I've looked at):
>> > then you could do something like this (maybe passing "private" not "yyy"):
>>
>> > int gpio_get_value(unsigned gpio)
>> > {
>> > struct gpio_yyy *yyy = gpio_to_yyy(gpio);
>>
>> > return yyy->get(yyy, gpio - base);
>>
>> ^^^ this subtraction makes me wonder what
>> exactly it does here - anything useful, or ... ?
> See the next lines:
>> > /* where get(yyy, offset) might look like:
>> > * u32 mask = 1 << offset;
>> > * return mask & __raw_readl(yyy->private +
>> > GPIO_PIN_READ);
>> > */
> Each GPIO controller manages no more than a few pins at a time,
> normally as many as fit into one register.
Thanks for describing this once again. But I really looked into your
January's code and this code already. And I fully agree that this will
work! And your code could have been long ago in git, but is not, so I
assume that your January's code was an RFC, asking what people think,
and if there're any alternatives. So, we here present exactly an
alternative, and it has its technical merits, I hope it's visible.
>> > }
>> >
>> []
>>
>> > ... of course, those two might also be wrapped to understand that
>> > the first N gpios could become inlined accesses to the relevant
>> > platform registers when "gpio" is constant ...
>>
>> Why first N could be inlined? What if I need second N inlined?
>> Here, PXA GPIOs have really low-frequency stuff, while ASIC3 does
>> bitbanging,
> What's being bit-banged? I2C isn't speed-critical. SPI can be.
Well, not me started to spoke about bit-banging. It's obviously just
one of usecases for GPIO API.
> My opinion on the inlining is that the API should _allow_ that as
> a source-compatible optimization, for cases where e.g. 1 Mbit/sec
> isn't good enough but 2Mbit/sec is.
Exactly! For runtime-extensible GPIO API, speed is apparently not
top-level goal, as - well, extensibility is. But if can shave few
cycles off by ditching table lookups and subtraction, let's do that.
For someone, being able to bit-bang on 1.2MHz instead of 1MHz can be
real life-saver.
> Luckily that optimization (to
> make GPIO access into about three instructions, no subroutining, if
> the particular GPIO is known at compile time) can be very easy.
> GPIOs are a really light weight hardware mechanism, and should never
> become fat'n'heavy. Remember: GPIO ~= Bit. Keep it simple.
> If a given implementation doesn't
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
/* defined by the platform using array, if/else/..., IDR, or
whatever */
struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by platform you mean CPU architecture.
Nope. ARM (v4, v5, v6, etc) is a CPU architecture. Platform is
fuzzily defined but it's more than the CPU. It's a family notion
that probably ties better to SOC chip vendor and branding ... things
work differently on TI OMAP processors than on Intel IOP ones, or than
the PXA ones (originally from Intel). For many folk, platform is a
board-level notion ... like x86_PC with ACPI firmware.
For example, say, ASIC3 appears in both PXA and S3Cxxx
devices. Suppose driver which uses ASIC3 works well on PXA, but acts up
on S3Cxxx.
The thing to do with bugs is fix them. If S3C were to have a failure
at that level, there'd be a lot more failures than just that one.
Programmers fix bugs. System designers make systems without
inclination to have bugs at random places. So, let's try to do the
former ;-) (in the sense, let's try to make a framework which will be
devoid of possibility for such variations; note that this doesn't mean
that framework which allows them, but has other benefits, is *not*
outruled by this).
So, let me
continue this and ask: how GPIO handling relates to CPU architecture
at all (and that's what I assume you mean by platform)? The answer:
it does not.
Certainly not ... and the interface doesn't. Any more than IRQs do.
Implementations most certainly can be platform-specific. And they
usually are, of necessity (different controllers, etc).
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
then you could do something like this (maybe passing private not yyy):
int gpio_get_value(unsigned gpio)
{
struct gpio_yyy *yyy = gpio_to_yyy(gpio);
return yyy-get(yyy, gpio - base);
^^^ this subtraction makes me wonder what
exactly it does here - anything useful, or ... ?
See the next lines:
/* where get(yyy, offset) might look like:
* u32 mask = 1 offset;
* return mask __raw_readl(yyy-private +
GPIO_PIN_READ);
*/
Each GPIO controller manages no more than a few pins at a time,
normally as many as fit into one register.
Thanks for describing this once again. But I really looked into your
January's code and this code already. And I fully agree that this will
work! And your code could have been long ago in git, but is not, so I
assume that your January's code was an RFC, asking what people think,
and if there're any alternatives. So, we here present exactly an
alternative, and it has its technical merits, I hope it's visible.
}
[]
... of course, those two might also be wrapped to understand that
the first N gpios could become inlined accesses to the relevant
platform registers when gpio is constant ...
Why first N could be inlined? What if I need second N inlined?
Here, PXA GPIOs have really low-frequency stuff, while ASIC3 does
bitbanging,
What's being bit-banged? I2C isn't speed-critical. SPI can be.
Well, not me started to spoke about bit-banging. It's obviously just
one of usecases for GPIO API.
My opinion on the inlining is that the API should _allow_ that as
a source-compatible optimization, for cases where e.g. 1 Mbit/sec
isn't good enough but 2Mbit/sec is.
Exactly! For runtime-extensible GPIO API, speed is apparently not
top-level goal, as - well, extensibility is. But if can shave few
cycles off by ditching table lookups and subtraction, let's do that.
For someone, being able to bit-bang on 1.2MHz instead of 1MHz can be
real life-saver.
Luckily that optimization (to
make GPIO access into about three instructions, no subroutining, if
the particular GPIO is known at compile time) can be very easy.
GPIOs are a really light weight hardware mechanism, and should never
become fat'n'heavy. Remember: GPIO ~= Bit. Keep it simple.
If a given implementation doesn't implement inline optimization,
some drivers may observe suckage but it probably won't matter for
most cases. However, if an interface doesn't *ever* allow that
optimization, that's a sign of something wrong.
Also fully agree with these passages! But let's exactly keep it
simple and untangled. If your API motivates people to do adhoc
optimizations (by creating per-platform header-file based
inline implementations for example), let's keep it that way, clean and
nice, and don't try to mix it with *runtime* extensibility. As was
pointed out, these two requirement are opposite to some extent, and
trying to merry them can
Re: [RFC, PATCH 1/3] gpiodev - API definitions
Hello Juergen,
Wednesday, April 11, 2007, 9:47:01 AM, you wrote:
Am Dienstag, 10. April 2007 23:30 schrieb Paul Sokolovsky:
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO identifier (struct gpio).
2. Set of API calls for clients. This fully follow Generic GPIO API
naming and semantics, except that they have gpiodev prefix and
accept struct gpio instead of integer gpio identifiers.
[]
+/* API functions */
+
+static inline int gpiodev_get_value(struct gpio *gpio)
+{
+ struct gpiodev_ops *ops = gpio-gpio_dev-dev.platform_data;
wouldn't it be more sure to verify if xxx function is NOT null
before using it ?? Perhaps something like that
BUG_ON(!ops-get);
GPIODEV is considered to be low-level one and critical for speed, so
all method pointers assumed to be set properly. In particular, if some
operation is not available for a device (say, GPI/GPO case), a method
must be set to a stab function.
BUG_ON would be acceptable, as it can be compiled out based on
CONFIG setting, but as was pointed out, doesn't add much into picture
anyway.
But I'd be happy to add comment to struct gpiodev_ops declaration
about the described method constraints, thanks for comment.
[]
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Matthew, Thursday, April 12, 2007, 5:24:30 PM, you wrote: On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote: On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote: ACPI batteries can report capacity and rate in either mA or mW. Given You sure, capacity in mA? Then I don't know. But you can safely fallback and create your own attribute (just as in David's battery class, where every battery required to create its own attributes), plus create capacity_units attribute. So, user space will know your driver's specific units. Well, mAh, but yes. Clearly it's possible to add extra attributes, but speccing standard attributes that don't entirely cover the most common non-embedded battery class seems less than ideal. Why not just require capacity_units and rate_units attributes? Yes, that's apparently the way to go. We just should consider if mAh and mWh are enough, or we go wider and allow whole collection of units. Btw, original handhelds.org code used Joules ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] gpiodev - API definitions
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
> it looks ok, but I have several questions:
> 1. why should we bind this to platform_device, what if the gpio device
> is not actually a "platform_device", say, a I2C device, a SPI device or
> even a USB device?
Good point. That was handhelds.org-specific "optimization", as we so
far mostly dealing with GPIO devices on platform bus, and could save
us writing "". This must be changed to use struct device,
sure.
> 2. I still doubt the benefit of using of a structure for a gpio, isn't a gpio
> number not enough?
Well, I replied to David's earlier post to LAKML after posting this,
and discussed both approach in more detail (and even more color). To
sum up, yes, we can use either structures for GPIOs, or scalar ints.
But both these approaches leads to some tradeoffs. Our argument is
that "scalar" (aka flat) approach leads to more tradeoffs - you need
to "flatten" your GPIO space first, and this is least evil, as indeed
this could be done using compile-time defines. But then you need to
"unflatten" it, and this happens at runtime, wasting cycles.
Using structure GPIO ids skips this "flattening"/"unflattening"
(maybe multiplexing/demultiplexing are better terms) phases. Trade off
is necessity to write:
.gpio = {_device, GPIO_DEVICE_GPIO_1}
instead of:
#define BASE_FOR_GPIO_DEVICE_ON_MY_BOARD 1000
.gpio = BASE_FOR_GPIO_DEVICE_ON_MY_BOARD + GPIO_DEVICE_GPIO_1
IMHO, pretty acceptable syntactical tradeoff ;-)
> 3. If one is going to use a GPIO, he has to initialize a "struct gpio"
> before that, how is he suppose to know the value for "gpio->gpio_dev"?
Yes, so the target usage of GPIODEV API is to write
device-independent driver. Such driver simply shouldn't care what
device is used for GPIO - it should be able to accept any, - and how
exactly GPIO ops are performed.
But something should care what actual GPIO device is being used. And
we know what's that - something which people call "platform code", but
I better call old good "machine definition file", to remove any
ambiguities. Such a definition is written for a specific machine, so
obviously you know what GPIO devices it has, and for what purpose pins
of them I used for. So, you have something like:
struct platform_device my_gpio_device = { .dev = {.name = "asic_foo"}};
struct some_driver_platform_data some_driver_pdata = {
...
.pullup = {_gpio_device.dev, ASIC_FOO_GPIO_PULLUP},
...
}
Important thing to note here is that structured GPIO id's are still
constants! Link-time constant, not compile-time, as scalar id's would
be, but still there's zero overhead at runtime.
> 4. how can we optimize to a direct register access instruction (e.g.
> to GPDR in PXA) for bit-banging operation (pardon me, I don't exactly
> remember the name for such operation, maybe bit-banging)
Well, you should first decide what exactly you want. If you want to
do bit-banging on PXA, then well, - you don't need GPIODEV and its
polymorphic support at all! If you know GPIO# beforehand, just use
David's GPIO API - it will constant-optimize it to GPCR/GPSR access
rigth away.
If you need to support arbitrary GPIO#, you can get better
frequency/throughput by skipping GPIO API still, like in the following
pseudocode:
MASK = 1 << GPIO#;
for (;count < SIZE; count--) {
GPSR = MASK;
nop;
GPCR = MASK;
}
If you'd use GPIO API, it would recompute MASK on each call, wasting
your cycles.
But now it's completely different story if you have a need to
write a driver which will bang bits on any GPIO of any device,
including such devices which you can't imagine at the time of driver's
writing at all - that's the GPIODEV estate. Obviously, for such general
usage it doesn't make too much sense to speak about optimization for a one
tiny specific device out of infinity of its domain - it's purpose is
exactly generality, not optimality, and it's well known that these
notions are reciprocals.
If you still want super-optimal handling for PXA case, while being
able to still support anything else, solution is also known - have two
drivers, one fast and PXA-adhoc, another generic but slower, and use
extraneous logic to select which one to use.
Back to GPIODEV's traits, it's still offers best performance which
can be achieved for infinitely extendable solution (within bounds of
the interface defined, of course), because it uses best known solution
for such problem (and such solution is simple and fast) - indirect
function call, and all data needed for such call are available right
away due to the magic of structural GPIO id's.
In this regard, your implementation draft, which uses scalars and
looping to find out owning GPIO device/handler, pretty bad suited for
bit-banging at all: just consider that GPIO operation overhead in this
case is dependent on number of GPIO devices present. Add new one, and
your (supposedly) carefully tuned latencies and delay "float".
David's code, which
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
> On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
>> > Nobody who really wants to have such an implementation framework has yet
>> > ponied up and done the work to make one.
>>
>> Well, sorry if it wasn't made clear, but we (handhelds.org) made such
>> an implementation. It is in turn based on low-overhead and flexible
>> patterns of object-oriented virtual methods. It is presented here:
>> http://lkml.org/lkml/2007/3/27/63
> There's a lot of precedent for how to abstract methods in kernel code,
> and unfortunately that approach didn't follow *ANY* of it. Get rid of
> the VTABLE() and METHOD() macros. Stop thinking in C++ for kernel code!
Fixed.
>> 1. Extended API header (uses "gpio_dev" (to be renamed to "gpiodev")
>> prefix instead of "gpio"; such API is intended to be used side by side
>> with your implementation, as the latter has important feature of
>> reducing to direct GPIo register access in case of constant GPIO#).
>> http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/include/linux/gpio_dev.h?rev=1.2=text/x-cvsweb-markup
> VTABLE() and METHOD() ... you were already told no way to such
> "crappage". That's makes reviewing the rest pointless...
Fixed. Thanks for not stopping on the first parse error ;-)
> Now, translated to more traditional approaches, and looking
> more like I was first thinking about rather than the IDR-based
> thing in
> http://lkml.org/lkml/2007/1/1/87
[]
> /* defined by the platform using array, if/else/..., IDR, or whatever
> */
> struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by "platform" you mean CPU architecture. So, well... It
indeed must be very flexible, scalable, maintainable, and completely
not error-prone to let each platform reimplement wheel in its own
special way. For example, say, ASIC3 appears in both PXA and S3Cxxx
devices. Suppose driver which uses ASIC3 works well on PXA, but acts up
on S3Cxxx. Reason? Just because PXA uses "IDR" for its "gpio_to_yyy",
while S3Cxxx uses "whatever".
But here's a point which made me to cleanup patches and resubmit
them again, and continue this discussion (because I really don't feel
like fighting against the tide) - I read "Re: Any possible to split
the pxa-regs.h?" thread, and see some fresh trend in it. So, let me
continue this and ask: how GPIO handling relates to CPU architecture
at all (and that's what I assume you mean by "platform")? The answer:
it does not.
We for long time took for granted that the whole system world spins
around plastic package with label "CPU". Apparently, that's wrong, it
spins only around the CPU core which happens to be in that plastic.
Anything else in that plastic is just that - external devices. So sorry,
why do we need to define external device access in terms of what CPU
controls them? Maybe it makes sense to define that access just in the same
way as for any other external device - using a driver and a framework
a driver should follow? (And yes, plain vanilla LDM is not enough here,
a minuscule extension needs to be applied.)
> then you could do something like this (maybe passing "private" not "yyy"):
> int gpio_get_value(unsigned gpio)
> {
> struct gpio_yyy *yyy = gpio_to_yyy(gpio);
> return yyy->get(yyy, gpio - base);
^^^ this subtraction makes me wonder what
exactly it does here - anything useful, or ... ?
> /* where get(yyy, offset) might look like:
> * u32 mask = 1 << offset;
> * return mask & __raw_readl(yyy->private +
> GPIO_PIN_READ);
> */
> }
>
[]
> ... of course, those two might also be wrapped to understand that
> the first N gpios could become inlined accesses to the relevant
> platform registers when "gpio" is constant ...
Why first N could be inlined? What if I need second N inlined?
Here, PXA GPIOs have really low-frequency stuff, while ASIC3 does
bitbanging, so that's what should be inlined. And on system X, GPIO
chips #1, #3, #4, #7 needs to be inlined, while the rest could be not.
So, why don't we handle this in following way: have two different
levels of API: one which is concerned with inlinability (as noone
disagrees this is important feature), and another - with generality
and extensibility? That's why gpiodev API proposed to be on top of
gpio API.
[]
> Fair enough? You were making a few other implementation choices
> too,
Yes, that's true. There're always some choices and compromises
among different requirements, but
[RFC, PATCH 3/3] gpiodev - ASIC3 SoC implementation (informal)
Hello linux-arm-kernel,
GPIODEV API: Support for ASIC3 SoC, found in several PDAs from HP and
HTC.
Note: ASIC3 driver is not yet in mainline (GPIODEV is one thing on
critical path to have it submitted), and itself is pretty packaged
System-on-Chip with many controllers, and thus big drivers. Patch
below shows snippets relevant to its GPIO controller, as a sample what
changes should be made to a generic driver for a GPIO-providing
device to make it GPIODEV-compliant. Full driver can be found at
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/soc/asic3_base.c?content-type=text/plain=h
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: include/linux/soc/asic3_base.h
===
RCS file: include/linux/soc/asic3_base.h
diff -N include/linux/soc/asic3_base.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ include/linux/soc/asic3_base.h 10 Apr 2007 15:35:33 - 1.12
@@ -0,0 +1,98 @@
+#include
+
+/* Private defines - for internal use only */
+#define HDR_IPAQ_ASIC3_ACTION(ACTION,action,fn,FN) \
+u32 asic3_get_gpio_ ## action ## _ ## fn (struct device *dev); \
+void asic3_set_gpio_ ## action ## _ ## fn (struct device *dev, u32 bits, u32
val);
+
+#define HDR_IPAQ_ASIC3_FN(fn,FN) \
+ HDR_IPAQ_ASIC3_ACTION ( MASK,mask,fn,FN) \
+ HDR_IPAQ_ASIC3_ACTION ( DIR, dir, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( OUT, out, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( LEVELTRI, trigtype, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( RISING, rising, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( LEVEL, triglevel, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_MASK, sleepmask, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_OUT, sleepout, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( BATT_FAULT_OUT, battfaultout, fn, FN)
\
+ HDR_IPAQ_ASIC3_ACTION ( INT_STATUS, intstatus, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( ALT_FUNCTION, alt_fn, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_CONF, sleepconf, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( STATUS, status, fn, FN)
+
+#define ASIC3_GPIOA_IRQ_BASE 0
+#define ASIC3_GPIOB_IRQ_BASE 16
+#define ASIC3_GPIOC_IRQ_BASE 32
+#define ASIC3_GPIOD_IRQ_BASE 48
+#define ASIC3_LED0_IRQ 64
+#define ASIC3_LED1_IRQ 65
+#define ASIC3_LED2_IRQ 66
+#define ASIC3_SPI_IRQ 67
+#define ASIC3_SMBUS_IRQ68
+#define ASIC3_OWM_IRQ 69
+
+#define ASIC3_NR_GPIO_IRQS 64 /* 16 bits each GPIO A...D banks */
+#define ASIC3_NR_IRQS (ASIC3_OWM_IRQ + 1)
+
+/* Public API */
+
+extern int asic3_irq_base (struct device *dev);
+
+void asic3_write_register (struct device *dev, unsigned int reg, unsigned long
value);
+unsigned long asic3_read_register (struct device *dev, unsigned int reg);
+
+/* old clock api */
+extern void asic3_set_clock_sel (struct device *dev, unsigned long bits,
unsigned long val);
+extern u32 asic3_get_clock_cdex (struct device *dev);
+extern void asic3_set_clock_cdex (struct device *dev, unsigned long bits,
unsigned long val);
+
+extern void asic3_set_extcf_select (struct device *dev, unsigned long bits,
unsigned long val);
+extern void asic3_set_extcf_reset (struct device *dev, unsigned long bits,
unsigned long val);
+extern void asic3_set_sdhwctrl (struct device *dev, unsigned long bits,
unsigned long val);
+
+void asic3_set_led( struct device *dev, int led_num, int duty_time, int
cycle_time);
+
+extern int asic3_register_mmc (struct device *dev);
+extern int asic3_unregister_mmc (struct device *dev);
+
+/* Accessors for GPIO banks */
+HDR_IPAQ_ASIC3_FN(a, A)
+HDR_IPAQ_ASIC3_FN(b, B)
+HDR_IPAQ_ASIC3_FN(c, C)
+HDR_IPAQ_ASIC3_FN(d, D)
+
+#define _IPAQ_ASIC3_GPIO_BANK_A 0
+#define _IPAQ_ASIC3_GPIO_BANK_B 1
+#define _IPAQ_ASIC3_GPIO_BANK_C 2
+#define _IPAQ_ASIC3_GPIO_BANK_D 3
+
+#define ASIC3_GPIO_bit(gpio) (1 << (gpio & 0xf))
+
+extern int asic3_get_gpio_bit(struct device *dev, int gpio);
+extern void asic3_set_gpio_bit(struct device *dev, int gpio, int val);
+
+
+struct tmio_mmc_hwconfig;
+
+struct asic3_platform_data
+{
+ // Must be first member
+ struct gpiodev_ops gpiodev_ops;
+
+ struct {
+ u32 dir;
+ u32 init;
+ u32 sleep_mask;
+ u32 sleep_out;
+ u32 batt_fault_out;
+ u32 sleep_conf;
+ u32 alt_function;
+ } gpio_a, gpio_b, gpio_c, gpio_d;
+
+ unsigned long bus_shift;
+
+ struct platform_device **child_platform_devs;
+ int num_child_platform_devs;
+
+ struct tmio_mmc_hwconfig *tmio_mmc_hwconfig;
+};
Index: drivers/soc/asic3_base.c
===
RCS file: /cv
[RFC, PATCH 2/3] gpiodev - ARM PXA implementation
Hello linux-arm-kernel,
GPIODEV API: Support for ARM PXA2xx CPU. Implementation is based on
Generic GPIO API. Generally, GPIODEV implementation should be provided
by device driver. But CPU-builtin devices in the current code are
treated is special manner ("arch devices"), so this approach is
followed for GPIODEV too.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: arch/arm/mach-pxa/generic.c
===
RCS file: /cvs/linux/kernel26/arch/arm/mach-pxa/generic.c,v
retrieving revision 1.39
retrieving revision 1.41
diff -u -r1.39 -r1.41
--- arch/arm/mach-pxa/generic.c 24 Feb 2007 13:14:41 - 1.39
+++ arch/arm/mach-pxa/generic.c 10 Apr 2007 15:35:33 - 1.41
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -530,6 +531,41 @@
.id = -1,
};
+
+static int pxa_gpiodev_get_value(struct device *dev, int gpio)
+{
+ return __gpio_get_value(gpio);
+}
+
+static void pxa_gpiodev_set_value(struct device *dev, int gpio, int value)
+{
+ __gpio_set_value(gpio, value);
+}
+
+static int pxa_gpiodev_to_irq(struct device *dev, int gpio)
+{
+ return IRQ_GPIO(gpio);
+}
+
+
+struct pxagpio_platform_data {
+ struct gpiodev_ops gpiodev_ops;
+} pxagpio_platform_data = {
+ .gpiodev_ops = {
+ .get = pxa_gpiodev_get_value,
+ .set = pxa_gpiodev_set_value,
+ .to_irq = pxa_gpiodev_to_irq,
+ }
+};
+
+struct platform_device pxagpio_device = {
+ .name = "pxa2xx-gpio",
+ .id = -1,
+ .dev= {
+ .platform_data = _platform_data
+ }
+};
+
static struct platform_device *devices[] __initdata = {
_device,
_device,
@@ -541,6 +580,7 @@
_device,
_device,
_device,
+ _device,
};
static int __init pxa_init(void)
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 1/3] gpiodev - API definitions
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO identifier (struct gpio).
2. Set of API calls for clients. This fully follow Generic GPIO API
naming and semantics, except that they have "gpiodev" prefix and
accept struct gpio instead of integer gpio identifiers.
Index: include/linux/gpiodev.h
===
RCS file: include/linux/gpiodev.h
diff -N include/linux/gpiodev.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ include/linux/gpiodev.h 10 Apr 2007 19:17:12 - 1.5
@@ -0,0 +1,43 @@
+#ifndef __GPIODEV_H
+#define __GPIODEV_H
+
+#include
+#include
+#include
+
+/* Interface */
+
+/* This structure must be first member of device platform_data structure
+ of a device which provides gpiodev interface */
+struct gpiodev_ops {
+int (*get)(struct device *this, int gpio_no);
+void (*set)(struct device *this, int gpio_no, int val);
+int (*to_irq)(struct device *this, int gpio_no);
+};
+
+/* Generalized GPIO structure */
+
+struct gpio {
+ struct platform_device *gpio_dev;
+ int gpio_no;
+};
+
+/* API functions */
+
+static inline int gpiodev_get_value(struct gpio *gpio)
+{
+ struct gpiodev_ops *ops = gpio->gpio_dev->dev.platform_data;
+ return ops->get(>gpio_dev->dev, gpio->gpio_no);
+}
+static inline void gpiodev_set_value(struct gpio *gpio, int val)
+{
+ struct gpiodev_ops *ops = gpio->gpio_dev->dev.platform_data;
+ ops->set(>gpio_dev->dev, gpio->gpio_no, val);
+}
+static inline int gpiodev_to_irq(struct gpio *gpio)
+{
+ struct gpiodev_ops *ops = gpio->gpio_dev->dev.platform_data;
+ return ops->to_irq(>gpio_dev->dev, gpio->gpio_no);
+}
+
+#endif /* __GPIODEV_H */
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] GPIODEV API (extension to Generic GPIO API)
Hello Kernel lists, This is updated and reworked API previously proposed at http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback (suggestions to use established kernel terminology/naming convention and drop macros). There are also actual tested patches provided this time, not just pseudocode. So: Purpose: An extension to 2.6.21-introduced Generic GPIO API, to provide ability to handle (several) additional platform GPIO chips, in efficient manner. Design principles: 1. The new lightweight API is built on top of Generic GPIO API. Reason: there was previously a proposal to add such capabilities to Generic GPIO API from the start (thread at http://lkml.org/lkml/2007/1/1/87), but other requirements were given more priority at that time, like being able to perform constant optimization on Generic GPIO API calls, and reduce them to the direct platform GPIO registers access in this case. To not affect this beneficial trait, a new lightweight API is introduced, which uses the same high-level interface, but trades such constant optimizations for (runtime) extensibility and generalization to any GPIO-providing device (whereas Generic GPIO API as it is implemented now for few ARM architectures handles only GPIOs builtin to a CPU). 2. "World is not flat". The real system is structured as following: it is set of interconnected chips, and some chips have GPIO pins. The proposed API preserves this target domain model, and doesn't try to build abstraction on top of it, (like flattening this structured model so there were scalar GPIO number). Surprisingly (actually, by design), this solves few issues, inefficiencies, or hardcoded assumptions which, for example, "flat GPIO namespace" approach has. 3. What is discussed at the end of previous paragraph, achieved by using "smart", self-describing GPIO identifiers. These identifiers are vector (actually, 2-element, i.e. pair), and can be seen either as belonging to structured namespace, where at first level there're GPIO devices, and at the second - GPIO pins, IDs of which are consequently local to a given device. Or, as a simple 2D-coordinate, with GPIO chip as the first coordinate, and GPIO pin as the second. "Self-describedness" is achieved by using a reference (i.e. pointer) to GPIO device object as the first component, and defining a set of GPIO operations each such device can perform, with operations being accessible as method calls on device. Summing up, technical benefits of proposed solution are: Minimizes centralized code needed to manage GPIO devices. Actually, it doesn't minimize it, but eliminates it at all. From the patches which will follow, it is visible, that there whole 0 bytes of in-kernel bureaucracies which do superfluous things like adding or subtracting various magic "base" numbers, searching thru the lists (more often linearly than binarily), or at least using hashes with hardcoded capacity and bucket sizes. Structured namespace approach leads to better scalability - any number of GPIO devices can be present in system, and there're no hardcoded limit of any kind. "Smart" identifiers (== device method approach) leads to good and jitter-free performance/latency characteristics: there are no lookups of any kind per se, to find a device which will perform a request - it is implicitly encoded in GPIO identifiers on which API operates. The operation call is also as efficient as something extensible can get - that's indirect function call by pointer. Final note: The approach/pattern/paradigm discussed here can be reused for more things than just GPIO API, that's to the large part reason one this approach is being proposed and argued at all. Patches follow. -- Best regards, Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] GPIODEV API (extension to Generic GPIO API)
Hello Kernel lists, This is updated and reworked API previously proposed at http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback (suggestions to use established kernel terminology/naming convention and drop macros). There are also actual tested patches provided this time, not just pseudocode. So: Purpose: An extension to 2.6.21-introduced Generic GPIO API, to provide ability to handle (several) additional platform GPIO chips, in efficient manner. Design principles: 1. The new lightweight API is built on top of Generic GPIO API. Reason: there was previously a proposal to add such capabilities to Generic GPIO API from the start (thread at http://lkml.org/lkml/2007/1/1/87), but other requirements were given more priority at that time, like being able to perform constant optimization on Generic GPIO API calls, and reduce them to the direct platform GPIO registers access in this case. To not affect this beneficial trait, a new lightweight API is introduced, which uses the same high-level interface, but trades such constant optimizations for (runtime) extensibility and generalization to any GPIO-providing device (whereas Generic GPIO API as it is implemented now for few ARM architectures handles only GPIOs builtin to a CPU). 2. World is not flat. The real system is structured as following: it is set of interconnected chips, and some chips have GPIO pins. The proposed API preserves this target domain model, and doesn't try to build abstraction on top of it, (like flattening this structured model so there were scalar GPIO number). Surprisingly (actually, by design), this solves few issues, inefficiencies, or hardcoded assumptions which, for example, flat GPIO namespace approach has. 3. What is discussed at the end of previous paragraph, achieved by using smart, self-describing GPIO identifiers. These identifiers are vector (actually, 2-element, i.e. pair), and can be seen either as belonging to structured namespace, where at first level there're GPIO devices, and at the second - GPIO pins, IDs of which are consequently local to a given device. Or, as a simple 2D-coordinate, with GPIO chip as the first coordinate, and GPIO pin as the second. Self-describedness is achieved by using a reference (i.e. pointer) to GPIO device object as the first component, and defining a set of GPIO operations each such device can perform, with operations being accessible as method calls on device. Summing up, technical benefits of proposed solution are: Minimizes centralized code needed to manage GPIO devices. Actually, it doesn't minimize it, but eliminates it at all. From the patches which will follow, it is visible, that there whole 0 bytes of in-kernel bureaucracies which do superfluous things like adding or subtracting various magic base numbers, searching thru the lists (more often linearly than binarily), or at least using hashes with hardcoded capacity and bucket sizes. Structured namespace approach leads to better scalability - any number of GPIO devices can be present in system, and there're no hardcoded limit of any kind. Smart identifiers (== device method approach) leads to good and jitter-free performance/latency characteristics: there are no lookups of any kind per se, to find a device which will perform a request - it is implicitly encoded in GPIO identifiers on which API operates. The operation call is also as efficient as something extensible can get - that's indirect function call by pointer. Final note: The approach/pattern/paradigm discussed here can be reused for more things than just GPIO API, that's to the large part reason one this approach is being proposed and argued at all. Patches follow. -- Best regards, Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 1/3] gpiodev - API definitions
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO identifier (struct gpio).
2. Set of API calls for clients. This fully follow Generic GPIO API
naming and semantics, except that they have gpiodev prefix and
accept struct gpio instead of integer gpio identifiers.
Index: include/linux/gpiodev.h
===
RCS file: include/linux/gpiodev.h
diff -N include/linux/gpiodev.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ include/linux/gpiodev.h 10 Apr 2007 19:17:12 - 1.5
@@ -0,0 +1,43 @@
+#ifndef __GPIODEV_H
+#define __GPIODEV_H
+
+#include linux/device.h
+#include linux/platform_device.h
+#include asm/gpio.h
+
+/* Interface */
+
+/* This structure must be first member of device platform_data structure
+ of a device which provides gpiodev interface */
+struct gpiodev_ops {
+int (*get)(struct device *this, int gpio_no);
+void (*set)(struct device *this, int gpio_no, int val);
+int (*to_irq)(struct device *this, int gpio_no);
+};
+
+/* Generalized GPIO structure */
+
+struct gpio {
+ struct platform_device *gpio_dev;
+ int gpio_no;
+};
+
+/* API functions */
+
+static inline int gpiodev_get_value(struct gpio *gpio)
+{
+ struct gpiodev_ops *ops = gpio-gpio_dev-dev.platform_data;
+ return ops-get(gpio-gpio_dev-dev, gpio-gpio_no);
+}
+static inline void gpiodev_set_value(struct gpio *gpio, int val)
+{
+ struct gpiodev_ops *ops = gpio-gpio_dev-dev.platform_data;
+ ops-set(gpio-gpio_dev-dev, gpio-gpio_no, val);
+}
+static inline int gpiodev_to_irq(struct gpio *gpio)
+{
+ struct gpiodev_ops *ops = gpio-gpio_dev-dev.platform_data;
+ return ops-to_irq(gpio-gpio_dev-dev, gpio-gpio_no);
+}
+
+#endif /* __GPIODEV_H */
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 2/3] gpiodev - ARM PXA implementation
Hello linux-arm-kernel,
GPIODEV API: Support for ARM PXA2xx CPU. Implementation is based on
Generic GPIO API. Generally, GPIODEV implementation should be provided
by device driver. But CPU-builtin devices in the current code are
treated is special manner (arch devices), so this approach is
followed for GPIODEV too.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: arch/arm/mach-pxa/generic.c
===
RCS file: /cvs/linux/kernel26/arch/arm/mach-pxa/generic.c,v
retrieving revision 1.39
retrieving revision 1.41
diff -u -r1.39 -r1.41
--- arch/arm/mach-pxa/generic.c 24 Feb 2007 13:14:41 - 1.39
+++ arch/arm/mach-pxa/generic.c 10 Apr 2007 15:35:33 - 1.41
@@ -24,6 +24,7 @@
#include linux/ioport.h
#include linux/pm.h
#include linux/string.h
+#include linux/gpiodev.h
#include linux/sched.h
#include asm/cnt32_to_63.h
@@ -530,6 +531,41 @@
.id = -1,
};
+
+static int pxa_gpiodev_get_value(struct device *dev, int gpio)
+{
+ return __gpio_get_value(gpio);
+}
+
+static void pxa_gpiodev_set_value(struct device *dev, int gpio, int value)
+{
+ __gpio_set_value(gpio, value);
+}
+
+static int pxa_gpiodev_to_irq(struct device *dev, int gpio)
+{
+ return IRQ_GPIO(gpio);
+}
+
+
+struct pxagpio_platform_data {
+ struct gpiodev_ops gpiodev_ops;
+} pxagpio_platform_data = {
+ .gpiodev_ops = {
+ .get = pxa_gpiodev_get_value,
+ .set = pxa_gpiodev_set_value,
+ .to_irq = pxa_gpiodev_to_irq,
+ }
+};
+
+struct platform_device pxagpio_device = {
+ .name = pxa2xx-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = pxagpio_platform_data
+ }
+};
+
static struct platform_device *devices[] __initdata = {
pxamci_device,
udc_device,
@@ -541,6 +580,7 @@
i2c_device,
i2s_device,
pxartc_device,
+ pxagpio_device,
};
static int __init pxa_init(void)
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 3/3] gpiodev - ASIC3 SoC implementation (informal)
Hello linux-arm-kernel,
GPIODEV API: Support for ASIC3 SoC, found in several PDAs from HP and
HTC.
Note: ASIC3 driver is not yet in mainline (GPIODEV is one thing on
critical path to have it submitted), and itself is pretty packaged
System-on-Chip with many controllers, and thus big drivers. Patch
below shows snippets relevant to its GPIO controller, as a sample what
changes should be made to a generic driver for a GPIO-providing
device to make it GPIODEV-compliant. Full driver can be found at
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/soc/asic3_base.c?content-type=text/plainf=h
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: include/linux/soc/asic3_base.h
===
RCS file: include/linux/soc/asic3_base.h
diff -N include/linux/soc/asic3_base.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ include/linux/soc/asic3_base.h 10 Apr 2007 15:35:33 - 1.12
@@ -0,0 +1,98 @@
+#include linux/gpiodev.h
+
+/* Private defines - for internal use only */
+#define HDR_IPAQ_ASIC3_ACTION(ACTION,action,fn,FN) \
+u32 asic3_get_gpio_ ## action ## _ ## fn (struct device *dev); \
+void asic3_set_gpio_ ## action ## _ ## fn (struct device *dev, u32 bits, u32
val);
+
+#define HDR_IPAQ_ASIC3_FN(fn,FN) \
+ HDR_IPAQ_ASIC3_ACTION ( MASK,mask,fn,FN) \
+ HDR_IPAQ_ASIC3_ACTION ( DIR, dir, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( OUT, out, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( LEVELTRI, trigtype, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( RISING, rising, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( LEVEL, triglevel, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_MASK, sleepmask, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_OUT, sleepout, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( BATT_FAULT_OUT, battfaultout, fn, FN)
\
+ HDR_IPAQ_ASIC3_ACTION ( INT_STATUS, intstatus, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( ALT_FUNCTION, alt_fn, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( SLEEP_CONF, sleepconf, fn, FN) \
+ HDR_IPAQ_ASIC3_ACTION ( STATUS, status, fn, FN)
+
+#define ASIC3_GPIOA_IRQ_BASE 0
+#define ASIC3_GPIOB_IRQ_BASE 16
+#define ASIC3_GPIOC_IRQ_BASE 32
+#define ASIC3_GPIOD_IRQ_BASE 48
+#define ASIC3_LED0_IRQ 64
+#define ASIC3_LED1_IRQ 65
+#define ASIC3_LED2_IRQ 66
+#define ASIC3_SPI_IRQ 67
+#define ASIC3_SMBUS_IRQ68
+#define ASIC3_OWM_IRQ 69
+
+#define ASIC3_NR_GPIO_IRQS 64 /* 16 bits each GPIO A...D banks */
+#define ASIC3_NR_IRQS (ASIC3_OWM_IRQ + 1)
+
+/* Public API */
+
+extern int asic3_irq_base (struct device *dev);
+
+void asic3_write_register (struct device *dev, unsigned int reg, unsigned long
value);
+unsigned long asic3_read_register (struct device *dev, unsigned int reg);
+
+/* old clock api */
+extern void asic3_set_clock_sel (struct device *dev, unsigned long bits,
unsigned long val);
+extern u32 asic3_get_clock_cdex (struct device *dev);
+extern void asic3_set_clock_cdex (struct device *dev, unsigned long bits,
unsigned long val);
+
+extern void asic3_set_extcf_select (struct device *dev, unsigned long bits,
unsigned long val);
+extern void asic3_set_extcf_reset (struct device *dev, unsigned long bits,
unsigned long val);
+extern void asic3_set_sdhwctrl (struct device *dev, unsigned long bits,
unsigned long val);
+
+void asic3_set_led( struct device *dev, int led_num, int duty_time, int
cycle_time);
+
+extern int asic3_register_mmc (struct device *dev);
+extern int asic3_unregister_mmc (struct device *dev);
+
+/* Accessors for GPIO banks */
+HDR_IPAQ_ASIC3_FN(a, A)
+HDR_IPAQ_ASIC3_FN(b, B)
+HDR_IPAQ_ASIC3_FN(c, C)
+HDR_IPAQ_ASIC3_FN(d, D)
+
+#define _IPAQ_ASIC3_GPIO_BANK_A 0
+#define _IPAQ_ASIC3_GPIO_BANK_B 1
+#define _IPAQ_ASIC3_GPIO_BANK_C 2
+#define _IPAQ_ASIC3_GPIO_BANK_D 3
+
+#define ASIC3_GPIO_bit(gpio) (1 (gpio 0xf))
+
+extern int asic3_get_gpio_bit(struct device *dev, int gpio);
+extern void asic3_set_gpio_bit(struct device *dev, int gpio, int val);
+
+
+struct tmio_mmc_hwconfig;
+
+struct asic3_platform_data
+{
+ // Must be first member
+ struct gpiodev_ops gpiodev_ops;
+
+ struct {
+ u32 dir;
+ u32 init;
+ u32 sleep_mask;
+ u32 sleep_out;
+ u32 batt_fault_out;
+ u32 sleep_conf;
+ u32 alt_function;
+ } gpio_a, gpio_b, gpio_c, gpio_d;
+
+ unsigned long bus_shift;
+
+ struct platform_device **child_platform_devs;
+ int num_child_platform_devs;
+
+ struct tmio_mmc_hwconfig *tmio_mmc_hwconfig;
+};
Index: drivers/soc/asic3_base.c
===
RCS file: /cvs/linux
Re: is there any generic GPIO chip framework like IRQ chips?
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
Nobody who really wants to have such an implementation framework has yet
ponied up and done the work to make one.
Well, sorry if it wasn't made clear, but we (handhelds.org) made such
an implementation. It is in turn based on low-overhead and flexible
patterns of object-oriented virtual methods. It is presented here:
http://lkml.org/lkml/2007/3/27/63
There's a lot of precedent for how to abstract methods in kernel code,
and unfortunately that approach didn't follow *ANY* of it. Get rid of
the VTABLE() and METHOD() macros. Stop thinking in C++ for kernel code!
Fixed.
1. Extended API header (uses gpio_dev (to be renamed to gpiodev)
prefix instead of gpio; such API is intended to be used side by side
with your implementation, as the latter has important feature of
reducing to direct GPIo register access in case of constant GPIO#).
http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/include/linux/gpio_dev.h?rev=1.2content-type=text/x-cvsweb-markup
VTABLE() and METHOD() ... you were already told no way to such
crappage. That's makes reviewing the rest pointless...
Fixed. Thanks for not stopping on the first parse error ;-)
Now, translated to more traditional approaches, and looking
more like I was first thinking about rather than the IDR-based
thing in
http://lkml.org/lkml/2007/1/1/87
[]
/* defined by the platform using array, if/else/..., IDR, or whatever
*/
struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by platform you mean CPU architecture. So, well... It
indeed must be very flexible, scalable, maintainable, and completely
not error-prone to let each platform reimplement wheel in its own
special way. For example, say, ASIC3 appears in both PXA and S3Cxxx
devices. Suppose driver which uses ASIC3 works well on PXA, but acts up
on S3Cxxx. Reason? Just because PXA uses IDR for its gpio_to_yyy,
while S3Cxxx uses whatever.
But here's a point which made me to cleanup patches and resubmit
them again, and continue this discussion (because I really don't feel
like fighting against the tide) - I read Re: Any possible to split
the pxa-regs.h? thread, and see some fresh trend in it. So, let me
continue this and ask: how GPIO handling relates to CPU architecture
at all (and that's what I assume you mean by platform)? The answer:
it does not.
We for long time took for granted that the whole system world spins
around plastic package with label CPU. Apparently, that's wrong, it
spins only around the CPU core which happens to be in that plastic.
Anything else in that plastic is just that - external devices. So sorry,
why do we need to define external device access in terms of what CPU
controls them? Maybe it makes sense to define that access just in the same
way as for any other external device - using a driver and a framework
a driver should follow? (And yes, plain vanilla LDM is not enough here,
a minuscule extension needs to be applied.)
then you could do something like this (maybe passing private not yyy):
int gpio_get_value(unsigned gpio)
{
struct gpio_yyy *yyy = gpio_to_yyy(gpio);
return yyy-get(yyy, gpio - base);
^^^ this subtraction makes me wonder what
exactly it does here - anything useful, or ... ?
/* where get(yyy, offset) might look like:
* u32 mask = 1 offset;
* return mask __raw_readl(yyy-private +
GPIO_PIN_READ);
*/
}
[]
... of course, those two might also be wrapped to understand that
the first N gpios could become inlined accesses to the relevant
platform registers when gpio is constant ...
Why first N could be inlined? What if I need second N inlined?
Here, PXA GPIOs have really low-frequency stuff, while ASIC3 does
bitbanging, so that's what should be inlined. And on system X, GPIO
chips #1, #3, #4, #7 needs to be inlined, while the rest could be not.
So, why don't we handle this in following way: have two different
levels of API: one which is concerned with inlinability (as noone
disagrees this is important feature), and another - with generality
and extensibility? That's why gpiodev API proposed to be on top of
gpio API.
[]
Fair enough? You were making a few other implementation choices
too,
Yes, that's true. There're always some choices and compromises
among different requirements, but I and other handhelds.org developers
argue that the proposed gpiodev is more scalable.
especially for the gpiodev thingies which I dropped here
in the interest of having exactly ONE struct gpio_yyy per controller,
instead of one per GPIO,
This is not correct presentation. Comparing your per-contoller
struct's with my per-gpio structs are comparing apples and oranges.
GPIODEV just uses
Re: [RFC, PATCH 1/3] gpiodev - API definitions
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
it looks ok, but I have several questions:
1. why should we bind this to platform_device, what if the gpio device
is not actually a platform_device, say, a I2C device, a SPI device or
even a USB device?
Good point. That was handhelds.org-specific optimization, as we so
far mostly dealing with GPIO devices on platform bus, and could save
us writing pdev.dev. This must be changed to use struct device,
sure.
2. I still doubt the benefit of using of a structure for a gpio, isn't a gpio
number not enough?
Well, I replied to David's earlier post to LAKML after posting this,
and discussed both approach in more detail (and even more color). To
sum up, yes, we can use either structures for GPIOs, or scalar ints.
But both these approaches leads to some tradeoffs. Our argument is
that scalar (aka flat) approach leads to more tradeoffs - you need
to flatten your GPIO space first, and this is least evil, as indeed
this could be done using compile-time defines. But then you need to
unflatten it, and this happens at runtime, wasting cycles.
Using structure GPIO ids skips this flattening/unflattening
(maybe multiplexing/demultiplexing are better terms) phases. Trade off
is necessity to write:
.gpio = {gpio_device, GPIO_DEVICE_GPIO_1}
instead of:
#define BASE_FOR_GPIO_DEVICE_ON_MY_BOARD 1000
.gpio = BASE_FOR_GPIO_DEVICE_ON_MY_BOARD + GPIO_DEVICE_GPIO_1
IMHO, pretty acceptable syntactical tradeoff ;-)
3. If one is going to use a GPIO, he has to initialize a struct gpio
before that, how is he suppose to know the value for gpio-gpio_dev?
Yes, so the target usage of GPIODEV API is to write
device-independent driver. Such driver simply shouldn't care what
device is used for GPIO - it should be able to accept any, - and how
exactly GPIO ops are performed.
But something should care what actual GPIO device is being used. And
we know what's that - something which people call platform code, but
I better call old good machine definition file, to remove any
ambiguities. Such a definition is written for a specific machine, so
obviously you know what GPIO devices it has, and for what purpose pins
of them I used for. So, you have something like:
struct platform_device my_gpio_device = { .dev = {.name = asic_foo}};
struct some_driver_platform_data some_driver_pdata = {
...
.pullup = {my_gpio_device.dev, ASIC_FOO_GPIO_PULLUP},
...
}
Important thing to note here is that structured GPIO id's are still
constants! Link-time constant, not compile-time, as scalar id's would
be, but still there's zero overhead at runtime.
4. how can we optimize to a direct register access instruction (e.g.
to GPDR in PXA) for bit-banging operation (pardon me, I don't exactly
remember the name for such operation, maybe bit-banging)
Well, you should first decide what exactly you want. If you want to
do bit-banging on PXA, then well, - you don't need GPIODEV and its
polymorphic support at all! If you know GPIO# beforehand, just use
David's GPIO API - it will constant-optimize it to GPCR/GPSR access
rigth away.
If you need to support arbitrary GPIO#, you can get better
frequency/throughput by skipping GPIO API still, like in the following
pseudocode:
MASK = 1 GPIO#;
for (;count SIZE; count--) {
GPSR = MASK;
nop;
GPCR = MASK;
}
If you'd use GPIO API, it would recompute MASK on each call, wasting
your cycles.
But now it's completely different story if you have a need to
write a driver which will bang bits on any GPIO of any device,
including such devices which you can't imagine at the time of driver's
writing at all - that's the GPIODEV estate. Obviously, for such general
usage it doesn't make too much sense to speak about optimization for a one
tiny specific device out of infinity of its domain - it's purpose is
exactly generality, not optimality, and it's well known that these
notions are reciprocals.
If you still want super-optimal handling for PXA case, while being
able to still support anything else, solution is also known - have two
drivers, one fast and PXA-adhoc, another generic but slower, and use
extraneous logic to select which one to use.
Back to GPIODEV's traits, it's still offers best performance which
can be achieved for infinitely extendable solution (within bounds of
the interface defined, of course), because it uses best known solution
for such problem (and such solution is simple and fast) - indirect
function call, and all data needed for such call are available right
away due to the magic of structural GPIO id's.
In this regard, your implementation draft, which uses scalars and
looping to find out owning GPIO device/handler, pretty bad suited for
bit-banging at all: just consider that GPIO operation overhead in this
case is dependent on number of GPIO devices present. Add new one, and
your (supposedly) carefully tuned latencies and delay float.
David's code, which is essentially a simple
Re: [RFC] Virtual methods for devices and generalized GPIO support using it
Hello H., Wednesday, March 28, 2007, 7:32:57 PM, you wrote: > Paul Sokolovsky wrote: >> >> In this respect, VTABLE(), METHOD() macros serve the same purpose as >> container_of() and list_for_each() - they are besides offering (more) >> convenient syntax, also carry important annotattion and educational >> messages, like "it's ok, and encouraged to embed one structure into >> another - use it!" or "list manipulation is a trivial operation for kernel, >> and we want you to treat it as such and use in standard, easily >> distinguishable way". >> > You realize, right, that the Linux kernel already have a much cleaner > way to do vtables in the kernel, without this kind of macro crappage? > It's called an _ops table, and is used in a patternized way: foo->x_ops->func(foo, ...); > ... all over the kernel. We like it that way. Sure! I wrote it's nothing really new. And I hope it's clear why those macros appeared in the first place: with the type of structures the device virtual methods are intended to be used, there're always pretty comprehensive member selection and typecasting is required. In this regard, there were 3 choices: 1. Use long but explicit expressions, like ((struct dev_pdata*)pdev.dev->platform_device)->x_ops->func(dev) 2. Use temporary variables: struct dev_pdata *tmp = (struct dev_pdata*)pdev.dev->platform_device; tmp->x_ops->func(dev); 3. Introduce macros which would hide guts and would provide syntax more resembling usual function call (especially for folks who remember that preprocessor is unalienable part of C ;-) ). As I also noted in the original mail, macros are also nice device for in-place annotation - to emphasize the fact that this is not just a mundane case of pointer manipulation, but paradigmatic thing. By this criteria I happened to choose macros syntax. But it's still merely a syntax, and I don't pledge for it. If there's more movement towards using explicit low-level forms like 1) or 2) instead of introducing new syntactic pattern, then macro syntax can be considered to have fulfilled its introductory role and can be dropped. > -hpa -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Virtual methods for devices and generalized GPIO support using it
Hello H., Wednesday, March 28, 2007, 7:32:57 PM, you wrote: Paul Sokolovsky wrote: In this respect, VTABLE(), METHOD() macros serve the same purpose as container_of() and list_for_each() - they are besides offering (more) convenient syntax, also carry important annotattion and educational messages, like it's ok, and encouraged to embed one structure into another - use it! or list manipulation is a trivial operation for kernel, and we want you to treat it as such and use in standard, easily distinguishable way. You realize, right, that the Linux kernel already have a much cleaner way to do vtables in the kernel, without this kind of macro crappage? It's called an _ops table, and is used in a patternized way: foo-x_ops-func(foo, ...); ... all over the kernel. We like it that way. Sure! I wrote it's nothing really new. And I hope it's clear why those macros appeared in the first place: with the type of structures the device virtual methods are intended to be used, there're always pretty comprehensive member selection and typecasting is required. In this regard, there were 3 choices: 1. Use long but explicit expressions, like ((struct dev_pdata*)pdev.dev-platform_device)-x_ops-func(dev) 2. Use temporary variables: struct dev_pdata *tmp = (struct dev_pdata*)pdev.dev-platform_device; tmp-x_ops-func(dev); 3. Introduce macros which would hide guts and would provide syntax more resembling usual function call (especially for folks who remember that preprocessor is unalienable part of C ;-) ). As I also noted in the original mail, macros are also nice device for in-place annotation - to emphasize the fact that this is not just a mundane case of pointer manipulation, but paradigmatic thing. By this criteria I happened to choose macros syntax. But it's still merely a syntax, and I don't pledge for it. If there's more movement towards using explicit low-level forms like 1) or 2) instead of introducing new syntactic pattern, then macro syntax can be considered to have fulfilled its introductory role and can be dropped. -hpa -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Virtual methods for devices and generalized GPIO support using it
Hello LKML,
We, HandHelds.org, for quite some time are working on generilized support
for consumer handheld devices (with primary focus on ARM-based PocketPC's
ans smartphones). While we made big progress in many areas, we still
were no able to put all the part of riddle together, producing clean and
manageable for dozens of project machines (we have ~30 ports in our kernel,
with ~20 well, or sufficiuently, developed, and a hundred in queue).
One of the pressing problem we had is code duplication even to support
simple features, like USB connection support, RS232 port support, BT
support, etc. To the large part drivers for such features consist of
the inititialization of common architecture-provided code/drivers, and
activating machine-specific support hardware like transceivers, etc.
This activation most of the time is handled by turning on some GPIO
lines, but the problem that our target machine set has wild varying
GPIO architecture. Besides CPU-builtin GPIOs, almost every model has
GPIOs on some SoC-type peripheral controller or GPIO extender
(in turn ranging from latches on CPU bus to connected to I2C, etc.).
What we get is dozens of shim drivers, which for 30 template lines
have 2-3 lines of real content. Submitting them for inclusion would
treated like spamming kernel tree, right? ;-)
Recently, Generic GPIO framework was proposed, and merged into 2.6.21-rc,
which is big step forward. But its scope is still to provide common
GPIO API for different *architectures*, not devices. It makes it possible
to minipulate GPIOs on PXA, OMAP, S3C in the same way, but does not
allow other GPIO-providing devices to leverage this framework.
HandHelds.org developers draw attention to this and asked to extend
scope and solve all GPIO-related problems (see for example
http://lkml.org/lkml/2007/1/1/111), however, it was omitted from the first
round of Generic GPIO API.
So, I would like to propose a solution for GPIO extension problem, and
moreover, a pattern, or paradigm, to solve such kind of problem. This
latter aim is probably not less important than the specific aim of
solving GPIO namespace problem. I have to say from the start that proposed
solution is of course not new - vice versa, it is well known and proved
solution to solve polymorphism problems ("different things do something in
similar ways, or with similar outcome"). That's why I use words pattern and
paradigm - I'd like to propose to leverage this technique for Linux kernel
driver writing, and if that would be accepted, to shape it in such way that
it will be easily recognizable and people will not spend time "reinventing"
it, or hesitating if it's usable or not.
Well, idea is simple. For any device which provides GPIOs, we can define
standard GPIO operation. We can express them via specifying function
(method) signatures and describing semantics behind them. Minimal
operation set for GPIO would be:
int get(int gpio_no)
Get value of GPIO with number gpio_no, return 0 if it is not set,
non-zero if it set.
void set(int gpio_no, int val)
Set value of GPIO with number gpio_no: if val is non-zero, set it
high, otherwise, low.
In terms of object-oriented programming, this definition called Interface.
So, we define interface which GPIO-provding devices should implement, and
details of implementation will be different for different devices. As long
as they conform to interface, all we need to perform a GPIO operation is
reference to owning device and its local gpio number, that's all. Device
itself will handle actual operations, and in this respect, it must implement
interface using what in OOP called virtual methods.
That's all for idea. The rest is just peculiarity of implementation within
bounds of existing Linux Kernel infrastructure (LDM model first of all).
Proposed implementation is:
1. Virtual methods are represented by function pointers (which is standard).
2. Virtual methods for some interface are groupped to structure called VTABLE
(common name).
3. Methods are defined for device, so must be accessed using it. LDM uses
struct device to represent a device, so methods must be accessible using a
reference to struct device.
4. Relatively few devices will use virtual methods, so no talk about extending
struct device itself. Instead, existing means of struct device extension will
be used.
5. Methods are of course public notion of a device, so it is proposed to makes
them accessible via platform_data member (and nor for example, driver_data).
Thus, VTABLE will be just part of platform_data structure for a device,
together with other data specific for a device.
6. What will fill actual method pointers in VTABLE? It is proposed that - of
course - a driver both implements virtual methods and initializes VTABLE
structure. This is of course perfect fit with LDM paradigm - device
structures define actual device properties, and driver what implements
handling of device behavior. This holds true for
[RFC] Virtual methods for devices and generalized GPIO support using it
Hello LKML, We, HandHelds.org, for quite some time are working on generilized support for consumer handheld devices (with primary focus on ARM-based PocketPC's ans smartphones). While we made big progress in many areas, we still were no able to put all the part of riddle together, producing clean and manageable for dozens of project machines (we have ~30 ports in our kernel, with ~20 well, or sufficiuently, developed, and a hundred in queue). One of the pressing problem we had is code duplication even to support simple features, like USB connection support, RS232 port support, BT support, etc. To the large part drivers for such features consist of the inititialization of common architecture-provided code/drivers, and activating machine-specific support hardware like transceivers, etc. This activation most of the time is handled by turning on some GPIO lines, but the problem that our target machine set has wild varying GPIO architecture. Besides CPU-builtin GPIOs, almost every model has GPIOs on some SoC-type peripheral controller or GPIO extender (in turn ranging from latches on CPU bus to connected to I2C, etc.). What we get is dozens of shim drivers, which for 30 template lines have 2-3 lines of real content. Submitting them for inclusion would treated like spamming kernel tree, right? ;-) Recently, Generic GPIO framework was proposed, and merged into 2.6.21-rc, which is big step forward. But its scope is still to provide common GPIO API for different *architectures*, not devices. It makes it possible to minipulate GPIOs on PXA, OMAP, S3C in the same way, but does not allow other GPIO-providing devices to leverage this framework. HandHelds.org developers draw attention to this and asked to extend scope and solve all GPIO-related problems (see for example http://lkml.org/lkml/2007/1/1/111), however, it was omitted from the first round of Generic GPIO API. So, I would like to propose a solution for GPIO extension problem, and moreover, a pattern, or paradigm, to solve such kind of problem. This latter aim is probably not less important than the specific aim of solving GPIO namespace problem. I have to say from the start that proposed solution is of course not new - vice versa, it is well known and proved solution to solve polymorphism problems (different things do something in similar ways, or with similar outcome). That's why I use words pattern and paradigm - I'd like to propose to leverage this technique for Linux kernel driver writing, and if that would be accepted, to shape it in such way that it will be easily recognizable and people will not spend time reinventing it, or hesitating if it's usable or not. Well, idea is simple. For any device which provides GPIOs, we can define standard GPIO operation. We can express them via specifying function (method) signatures and describing semantics behind them. Minimal operation set for GPIO would be: int get(int gpio_no) Get value of GPIO with number gpio_no, return 0 if it is not set, non-zero if it set. void set(int gpio_no, int val) Set value of GPIO with number gpio_no: if val is non-zero, set it high, otherwise, low. In terms of object-oriented programming, this definition called Interface. So, we define interface which GPIO-provding devices should implement, and details of implementation will be different for different devices. As long as they conform to interface, all we need to perform a GPIO operation is reference to owning device and its local gpio number, that's all. Device itself will handle actual operations, and in this respect, it must implement interface using what in OOP called virtual methods. That's all for idea. The rest is just peculiarity of implementation within bounds of existing Linux Kernel infrastructure (LDM model first of all). Proposed implementation is: 1. Virtual methods are represented by function pointers (which is standard). 2. Virtual methods for some interface are groupped to structure called VTABLE (common name). 3. Methods are defined for device, so must be accessed using it. LDM uses struct device to represent a device, so methods must be accessible using a reference to struct device. 4. Relatively few devices will use virtual methods, so no talk about extending struct device itself. Instead, existing means of struct device extension will be used. 5. Methods are of course public notion of a device, so it is proposed to makes them accessible via platform_data member (and nor for example, driver_data). Thus, VTABLE will be just part of platform_data structure for a device, together with other data specific for a device. 6. What will fill actual method pointers in VTABLE? It is proposed that - of course - a driver both implements virtual methods and initializes VTABLE structure. This is of course perfect fit with LDM paradigm - device structures define actual device properties, and driver what implements handling of device behavior. This holds true for virtual
Re: passing function pointers through platform devices?
Hello NZG, Tuesday, March 6, 2007, 8:46:29 PM, you wrote: > I'm developing an SPI- bus >MMC/SD block driver translation layer. > As part of this layer the write protect and card detect lines need to be read. > The method for determining the state of these lines will be board specific. > Is it appropriate to pass a function pointer through a platform device > (declared in the mach initialization) to implement card_available and > write_protect function calls? > Or is there a cleaner way to do it? Apparently it must be appropriate, because that's pretty natural and clean - if you can pass data, why wouldn't you be able to pass methods? I assume your usecase is to pass board-specific code, defined in machine definition, down to a device driver. We (handhelds.org) go even further and recently tried passing function pointers in opposite direction - from device driver to client code which will use the device, via device's platform_data. That essentially implements virtual methods on devices, allowing device clients to perform operations on them without bothering to know how actually the operation is implemented, i.e. offers better functionality separation and code reuse which OOP offers. Either way, be assured that you're not the only one who puts Linux Driver Model under full use. > thank you, > NZG -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: passing function pointers through platform devices?
Hello NZG, Tuesday, March 6, 2007, 8:46:29 PM, you wrote: I'm developing an SPI- bus MMC/SD block driver translation layer. As part of this layer the write protect and card detect lines need to be read. The method for determining the state of these lines will be board specific. Is it appropriate to pass a function pointer through a platform device (declared in the mach initialization) to implement card_available and write_protect function calls? Or is there a cleaner way to do it? Apparently it must be appropriate, because that's pretty natural and clean - if you can pass data, why wouldn't you be able to pass methods? I assume your usecase is to pass board-specific code, defined in machine definition, down to a device driver. We (handhelds.org) go even further and recently tried passing function pointers in opposite direction - from device driver to client code which will use the device, via device's platform_data. That essentially implements virtual methods on devices, allowing device clients to perform operations on them without bothering to know how actually the operation is implemented, i.e. offers better functionality separation and code reuse which OOP offers. Either way, be assured that you're not the only one who puts Linux Driver Model under full use. thank you, NZG -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo, Thursday, February 22, 2007, 10:32:04 AM, you wrote: > On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote: k>> Why? It's the same, except that it already exists, generic one (not >> limited to pxafb), and requires 1 function (too bad that C doesn't >> support lambda's): > Ah, ok. >> I sent a bit of criticism for that too ;-). YMMV, but kernel >> solutions are just bound to be pretty simple and generic and lack >> any "niceties", which you'd likely want to do anyway eventually. For >> example, what if you'll want to implement "fade out" effect for >> keyboard backlight? Doing it in adhoc manner in kernel? Whereas with >> the LCD classdev, you can write generic "fade out" trigger and >> attach/detach it from userspace. > I agree. I just wish to add a backlight support for my LCD and > minikeypad. > What do you suggest to me in order to accomplish such task? Well, I write exactly to share experience and work towards having best practices for backlight, etc. control, reusable on wide range of embedded/handheld devices. We in handhelds.org codebase have attached patch* to make corgi_bl more suitable for general use. This patch was submitted to Richard (so, more votes needed ;-) ). Otherwise, snippet I pasted is from real machine implementation, HP iPaq h4000. As for keyboard backlight, another port we have, HTC Universal, has: normal indicator LEDs, keyboard backlight, flashlight, ring vibra. All of these are handled via Generic LED API: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/arch/arm/mach-pxa/htcuniversal/htcuniversal_leds.c?rev=1.6=text/x-cvsweb-markup To show that it is not an anomaly, but hopefully, a trend, here's vibra driver for the upcoming OpenMoko phone: http://wiki.openmoko.org/wiki/Neo1973_Hardware#Vibrator So, if you have freedom to add keyboard backlight control to your userspace, that would allow you to do many interesting things without disturbing the kernel. [*] Optimized for size, full one should patch of course. > Thanks for your suggestions, > Rodolfo -- Best regards, Paulmailto:[EMAIL PROTECTED] driver-corgi-bl-generalize.patch Description: Binary data
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo, Thursday, February 22, 2007, 10:32:04 AM, you wrote: On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote: k Why? It's the same, except that it already exists, generic one (not limited to pxafb), and requires 1 function (too bad that C doesn't support lambda's): Ah, ok. I sent a bit of criticism for that too ;-). YMMV, but kernel solutions are just bound to be pretty simple and generic and lack any niceties, which you'd likely want to do anyway eventually. For example, what if you'll want to implement fade out effect for keyboard backlight? Doing it in adhoc manner in kernel? Whereas with the LCD classdev, you can write generic fade out trigger and attach/detach it from userspace. I agree. I just wish to add a backlight support for my LCD and minikeypad. What do you suggest to me in order to accomplish such task? Well, I write exactly to share experience and work towards having best practices for backlight, etc. control, reusable on wide range of embedded/handheld devices. We in handhelds.org codebase have attached patch* to make corgi_bl more suitable for general use. This patch was submitted to Richard (so, more votes needed ;-) ). Otherwise, snippet I pasted is from real machine implementation, HP iPaq h4000. As for keyboard backlight, another port we have, HTC Universal, has: normal indicator LEDs, keyboard backlight, flashlight, ring vibra. All of these are handled via Generic LED API: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/arch/arm/mach-pxa/htcuniversal/htcuniversal_leds.c?rev=1.6content-type=text/x-cvsweb-markup To show that it is not an anomaly, but hopefully, a trend, here's vibra driver for the upcoming OpenMoko phone: http://wiki.openmoko.org/wiki/Neo1973_Hardware#Vibrator So, if you have freedom to add keyboard backlight control to your userspace, that would allow you to do many interesting things without disturbing the kernel. [*] Optimized for size, full one should patch asm/arch/sharpsl.h of course. Thanks for your suggestions, Rodolfo -- Best regards, Paulmailto:[EMAIL PROTECTED] driver-corgi-bl-generalize.patch Description: Binary data
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo,
Wednesday, February 21, 2007, 6:12:10 PM, you wrote:
> On Wed, Feb 21, 2007 at 06:00:37PM +0200, Paul Sokolovsky wrote:
>>
>> On the other hand, there's already
>> drivers/video/backlight/backlight.c which provides generic BL support,
>> implemented using notifier callback for FB core. Moreover, there's
> My patch _uses_ that support.
Sorry if I missed it in quick review, as I told, there's a bit much
code ;-I
>> corgi_bl.c driver which, contrary to its name is a generic driver for
>> embedded/PDA device backlight. It essentially subclassses pretty
>> abstract backlight.c, and provides good implementation for most BL
>> implementation. What you really need to do to use it, is to supply
>> single machine-dependent method, set_bl_intensity(). That method is
>> usually <10 lines.
> I see, but in this manner you need to make a complete file for each
> board, while with my patch you can just put few lines into machine's
> definition file (a struct and 2 functions).
Why? It's the same, except that it already exists, generic one (not
limited to pxafb), and requires 1 function (too bad that C doesn't
support lambda's):
==
static void h4000_set_bl_intensity(int intensity)
{
/* LCD brightness is driven by PWM0.
* We'll set the pre-scaler to 8, and the period to 1024, this
* means the backlight refresh rate will be 3686400/(8*1024) =
* 450 Hz which is quite enough.
*/
PWM_CTRL0 = 7;/* pre-scaler */
PWM_PWDUTY0 = intensity; /* duty cycle */
PWM_PERVAL0 = H4000_MAX_INTENSITY; /* period */
if (intensity > 0) {
pxa_set_cken(CKEN0_PWM0, 1);
asic3_set_gpio_out_b(_asic3.dev,
GPIOB_BACKLIGHT_POWER_ON, GPIOB_BACKLIGHT_POWER_ON);
} else {
pxa_set_cken(CKEN0_PWM0, 0);
asic3_set_gpio_out_b(_asic3.dev,
GPIOB_BACKLIGHT_POWER_ON, 0);
}
}
static struct corgibl_machinfo h4000_bl_machinfo = {
.default_intensity = H4000_MAX_INTENSITY / 4,
.limit_mask = 0x0fff,
.max_intensity = H4000_MAX_INTENSITY,
.set_bl_intensity = h4000_set_bl_intensity,
};
struct platform_device h4000_bl = {
.name = "corgi-bl",
.dev = {
.platform_data = _bl_machinfo,
},
};
==
>> With this in mind, adhoc backlight handlers in pxafb and few other
>> drivers are artifacts of older times. And it's sad they are tried to
>> be resurrected instead of being removed.
> IMHO, the actual backlight support is not so much, infact I'd like to
> generalize it to support also backlighted keyboards (or input
> devices). :)
I sent a bit of criticism for that too ;-). YMMV, but kernel
solutions are just bound to be pretty simple and generic and lack
any "niceties", which you'd likely want to do anyway eventually. For
example, what if you'll want to implement "fade out" effect for
keyboard backlight? Doing it in adhoc manner in kernel? Whereas with
the LCD classdev, you can write generic "fade out" trigger and
attach/detach it from userspace.
> Ciao,
> Rodolfo
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Advice on backlight support
Hello Rodolfo, Wednesday, February 21, 2007, 6:02:13 PM, you wrote: > Hello, > I'd like to add backlight support for input devices since my custom > board has a backlighted mini keyboard. There's already generic indicator API, currently mostly known as "[new] LED [classdev] API", even though it is already used for things like buzzers, vibrators, etc. Why wouldn't it be suitable for your case? LCD and LCD backlight are special cases, as they actually should track state of (abstract) FB device, and keeping their states in sync is pretty important for trivial PM and info accessibility, so worth doing on kernel level. As for things like "light up keyboard if key was pressed, then light down after timeout", or "light up backlight LCD on touchscreen touch, light down on timeout", that can be pretty well done in userspace, no? > It could be acceptable to move the code from drivers/video/backlight/ > to drivers/backlight/ renaming the "Backlight & LCD" name into > "Backlight" and adding two new entries "LCD" and, maybe, "Input" (or > something like that?). Yes, the fact that lcd.c (LCD power control) lives under backlight dir, is a bit confusing. But they still has close relation to FB, after all. > Thanks in advance, > Rodolfo -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo,
Wednesday, February 21, 2007, 4:53:53 PM, you wrote:
> Backlight control support for the PXA fram buffer.
Here're some comments: backlight support is already confusing
matter, and your patch IMHO makes it even more confusing for PXAFB.
Before even start with details, let's first think what backlight has
to do with framebuffer? The facts that the physical object implementing
the former is usually put in close proximity to the latter, and they mostly
should be powered on synchronously, probably don't yet mean that
each and every FB driver should include good chunk of code to support
doing BL in its own special way.
On the other hand, there's already
drivers/video/backlight/backlight.c which provides generic BL support,
implemented using notifier callback for FB core. Moreover, there's
corgi_bl.c driver which, contrary to its name is a generic driver for
embedded/PDA device backlight. It essentially subclassses pretty
abstract backlight.c, and provides good implementation for most BL
implementation. What you really need to do to use it, is to supply
single machine-dependent method, set_bl_intensity(). That method is
usually <10 lines.
With this in mind, adhoc backlight handlers in pxafb and few other
drivers are artifacts of older times. And it's sad they are tried to
be resurrected instead of being removed.
> Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
> ---
> Each platform should define the backlight properties in its own setup
> file in "linux/arch/arm/mach-pxa/" as follow:
>static int pxafb_bl_get_brightness(struct backlight_device *bl_dev)
>{
> return read_the_backlight_brightness();
>}
>static int pxafb_bl_update_status(struct backlight_device *bl_dev)
>{
>int perc, ret;
>if (bl_dev->props->power != FB_BLANK_UNBLANK ||
>bl_dev->props->fb_blank != FB_BLANK_UNBLANK)
>perc = 0;
>else
>perc = bl_dev->props->brightness;
> write_the_backlight_brightness(perc);
>return 0;
>}
>static struct backlight_properties wwpc1100_backlight_props = {
>.get_brightness = pxafb_bl_get_brightness,
>.update_status = pxafb_bl_update_status,
>.max_brightness = 100,
>};
>
> and then seting up the fb info as follow:
>wwpc1100_pxafb_info.modes = _modes;
>wwpc1100_pxafb_info.bl_props = _backlight_props;
>set_pxa_fb_info(_pxafb_info);
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo,
Wednesday, February 21, 2007, 4:53:53 PM, you wrote:
Backlight control support for the PXA fram buffer.
Here're some comments: backlight support is already confusing
matter, and your patch IMHO makes it even more confusing for PXAFB.
Before even start with details, let's first think what backlight has
to do with framebuffer? The facts that the physical object implementing
the former is usually put in close proximity to the latter, and they mostly
should be powered on synchronously, probably don't yet mean that
each and every FB driver should include good chunk of code to support
doing BL in its own special way.
On the other hand, there's already
drivers/video/backlight/backlight.c which provides generic BL support,
implemented using notifier callback for FB core. Moreover, there's
corgi_bl.c driver which, contrary to its name is a generic driver for
embedded/PDA device backlight. It essentially subclassses pretty
abstract backlight.c, and provides good implementation for most BL
implementation. What you really need to do to use it, is to supply
single machine-dependent method, set_bl_intensity(). That method is
usually 10 lines.
With this in mind, adhoc backlight handlers in pxafb and few other
drivers are artifacts of older times. And it's sad they are tried to
be resurrected instead of being removed.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
Each platform should define the backlight properties in its own setup
file in linux/arch/arm/mach-pxa/ as follow:
static int pxafb_bl_get_brightness(struct backlight_device *bl_dev)
{
return read_the_backlight_brightness();
}
static int pxafb_bl_update_status(struct backlight_device *bl_dev)
{
int perc, ret;
if (bl_dev-props-power != FB_BLANK_UNBLANK ||
bl_dev-props-fb_blank != FB_BLANK_UNBLANK)
perc = 0;
else
perc = bl_dev-props-brightness;
write_the_backlight_brightness(perc);
return 0;
}
static struct backlight_properties wwpc1100_backlight_props = {
.get_brightness = pxafb_bl_get_brightness,
.update_status = pxafb_bl_update_status,
.max_brightness = 100,
};
and then seting up the fb info as follow:
wwpc1100_pxafb_info.modes = special_modes;
wwpc1100_pxafb_info.bl_props = wwpc1100_backlight_props;
set_pxa_fb_info(wwpc1100_pxafb_info);
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Advice on backlight support
Hello Rodolfo, Wednesday, February 21, 2007, 6:02:13 PM, you wrote: Hello, I'd like to add backlight support for input devices since my custom board has a backlighted mini keyboard. There's already generic indicator API, currently mostly known as [new] LED [classdev] API, even though it is already used for things like buzzers, vibrators, etc. Why wouldn't it be suitable for your case? LCD and LCD backlight are special cases, as they actually should track state of (abstract) FB device, and keeping their states in sync is pretty important for trivial PM and info accessibility, so worth doing on kernel level. As for things like light up keyboard if key was pressed, then light down after timeout, or light up backlight LCD on touchscreen touch, light down on timeout, that can be pretty well done in userspace, no? It could be acceptable to move the code from drivers/video/backlight/ to drivers/backlight/ renaming the Backlight LCD name into Backlight and adding two new entries LCD and, maybe, Input (or something like that?). Yes, the fact that lcd.c (LCD power control) lives under backlight dir, is a bit confusing. But they still has close relation to FB, after all. Thanks in advance, Rodolfo -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PXAFB: Support for backlight control
Hello Rodolfo,
Wednesday, February 21, 2007, 6:12:10 PM, you wrote:
On Wed, Feb 21, 2007 at 06:00:37PM +0200, Paul Sokolovsky wrote:
On the other hand, there's already
drivers/video/backlight/backlight.c which provides generic BL support,
implemented using notifier callback for FB core. Moreover, there's
My patch _uses_ that support.
Sorry if I missed it in quick review, as I told, there's a bit much
code ;-I
corgi_bl.c driver which, contrary to its name is a generic driver for
embedded/PDA device backlight. It essentially subclassses pretty
abstract backlight.c, and provides good implementation for most BL
implementation. What you really need to do to use it, is to supply
single machine-dependent method, set_bl_intensity(). That method is
usually 10 lines.
I see, but in this manner you need to make a complete file for each
board, while with my patch you can just put few lines into machine's
definition file (a struct and 2 functions).
Why? It's the same, except that it already exists, generic one (not
limited to pxafb), and requires 1 function (too bad that C doesn't
support lambda's):
==
static void h4000_set_bl_intensity(int intensity)
{
/* LCD brightness is driven by PWM0.
* We'll set the pre-scaler to 8, and the period to 1024, this
* means the backlight refresh rate will be 3686400/(8*1024) =
* 450 Hz which is quite enough.
*/
PWM_CTRL0 = 7;/* pre-scaler */
PWM_PWDUTY0 = intensity; /* duty cycle */
PWM_PERVAL0 = H4000_MAX_INTENSITY; /* period */
if (intensity 0) {
pxa_set_cken(CKEN0_PWM0, 1);
asic3_set_gpio_out_b(h4000_asic3.dev,
GPIOB_BACKLIGHT_POWER_ON, GPIOB_BACKLIGHT_POWER_ON);
} else {
pxa_set_cken(CKEN0_PWM0, 0);
asic3_set_gpio_out_b(h4000_asic3.dev,
GPIOB_BACKLIGHT_POWER_ON, 0);
}
}
static struct corgibl_machinfo h4000_bl_machinfo = {
.default_intensity = H4000_MAX_INTENSITY / 4,
.limit_mask = 0x0fff,
.max_intensity = H4000_MAX_INTENSITY,
.set_bl_intensity = h4000_set_bl_intensity,
};
struct platform_device h4000_bl = {
.name = corgi-bl,
.dev = {
.platform_data = h4000_bl_machinfo,
},
};
==
With this in mind, adhoc backlight handlers in pxafb and few other
drivers are artifacts of older times. And it's sad they are tried to
be resurrected instead of being removed.
IMHO, the actual backlight support is not so much, infact I'd like to
generalize it to support also backlighted keyboards (or input
devices). :)
I sent a bit of criticism for that too ;-). YMMV, but kernel
solutions are just bound to be pretty simple and generic and lack
any niceties, which you'd likely want to do anyway eventually. For
example, what if you'll want to implement fade out effect for
keyboard backlight? Doing it in adhoc manner in kernel? Whereas with
the LCD classdev, you can write generic fade out trigger and
attach/detach it from userspace.
Ciao,
Rodolfo
--
Best regards,
Paulmailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello David, Tuesday, December 19, 2006, 2:59:11 AM, you wrote: > On Monday 18 December 2006 4:54 pm, David Brownell wrote: >> > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5=1.6=h >> >> That patch you applied looks right to me -- why don't you forward it >> to Alessandro as a bugfix for 2.6.20-rc2, and save me the effort? > Actually, correction: it'd be correct if you ripped out the buggy > calls to manage the irq wake mechanism. A later message will show > how those need to work. (The IRQ framework will give one helpful > hint when it warns about mismatched enable/disable calls ...) Do you mean enable_irq_wake()/disable_irq_wake() calls? In what way they are buggy? The only "bug" with them I see is that they are not implemented for PXA, which just once again reminds that mach-pxa is real misfit in ARM family (own DMA API instead of fitting with generic ARM one, no cpufreq support in mainline, and few other not implemented APIs). That's of course pretty sad, as apparently PXA was/still is the most popular CPU for consumer market (well, at least in "something like real computer" caregory) ;-(. But those calls are apparently still needed, even if you say that wakeup stuff should be handled in generic manner, as PM feature, and on device level. After all, what drivers will do to actually enable wakeup for a given device? I hope we don't speak about using CPU-specific registers in reusable device drivers for that. This is pretty interesting topic for us, and so far in handhelds.org ports we don't handle dynamic wakeup configuration at all, so I would eagerly expect your samples. In the meantime, I went and hacked .set_wake methods for PXA's irq_chips. And that's when I got idea why it might haven't been implemented at all - PXA27x's model of wakeup sources is a bit weird comparing with nice and clean PXA25x's ;-). It's still not the reason to give up on those calls at all - after all, even "least common denominator" implementation will give good value. I yet need to test what I've put together, though. > - Dave -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello David, Monday, December 18, 2006, 6:28:58 AM, you wrote: > On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote: >> Small battery-powered systems, like PDAs, need a way to be >> suspended most of the time and woken up just from time to time to >> process pending tasks. > Sounds like you're thinking of this from a userspace perspective... > Could you share some examples of such "pending tasks"? Well, the actual usecase, which triggered me to hack that, was a need to write a "burn out" test script for suspend/resume for a battery-powered ARM device (PDA), which would do suspend/resume cycle thousands of times. And wakeup alarm is obvious, if not only, source of automated resume events. Of course, I started by trying existing solutions - e.g. there's an "atd" implementation which uses /dev/rtc, but I found it having awful latency (>2s), then I tried to write simple C app to set alarm via ioctl(), just to find alarm IRQs are shutdown on its exit. But anyway, I'm that kind of guy who think that debugging and diagnostics are important things for *production* system, so such sysfs alarm support just as precious as /proc/interrupts and /proc/dma (ah, ARM Linux maintainer declined to fix broken /proc/dma support for ARM, I forgot ;-( ). [] >> Obvious way to achieve this is to use timer, or >> alarm, wakeup. Unfortunately, this matter is bit confusing in Linux. >> There's only one "good" "supported" way to set alarm - via ioctl() on >> an RTC device fd. Unfortunately, this alarm is not persistent - as soon >> as fd is closed, alarm id discharged. > I don't think that's true in general. Most RTCs don't even care > whether userspace did an open() or close(). I see the S3C one does, > and that explicitly leaves the alarm active. > But I see that only the SA1100/PXA and SH RTCs turn off all IRQs > after RTC_WKALM_* requests ... that's a distinct minority. Oh my! I couldn't even think this can be idiosyncrasy of specific implementation. Oh, what a world... ;-) > So judging implementations as votes ... only two implementations > that implement the RTC_WKALM_* call follow that rule, and most > don't. However, a few implementations ignore rtc_wkalrm.enabled, > or otherwise mistreat that flag (e.g. rtc-ds1553 doesn't disable > AIE when enabled==0), so it's clear there are some issues there. > My vote would be that closing the FD should not turn off the alarm. > It's supposed to be a one-shot deal anyway. I would agree with such behavior. But what's clear that the behavior, whatever it is, should be consistent across implementations, or its just a mess ;-(. > And also, that someone audits the drivers/rtc code to make sure that > alarm-capable drivers handle the rtc_wkalrm.enabled flag correctly; > your patch sort of presumes that will happen, anyway. Yes, I mentioned, that for PXA/SA, my patch becomes actually useful only after applying your patch (plus, with fixed TODO: here's what I applied to handhelds.org tree: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5=1.6=h ). That of course doesn't mean sysfs alarm support patch depends on rtc-sa1100.c patch in any way (it's just PXA/SA won't actually wake up, but sysfs patch for showing/storing alarm properties obviously doesn't depend on any specific implementation). > And hmm, it'd > be good to have rtctest.c (in Documentation/rtc.txt) test for that... > it doesn't actually use RTC_WKALM_* calls, so it's too easy for folk > to goof up their implementations. >> Formal part >> === >> >> Implement "alarm" attribute group for RTC classdevs. At this time, >> add "since_epoch", "wakeup_enabled", and "pending" attributes. First >> two support both read and write. > I think you shouldn't add this group unless the RTC has methods > to read and write the alarm; there are RTCs that don't have that > feature. > Also, I'd rather see a much simpler interface. Like a single > "alarm" attribute. It would display as the empty string unless > it was enabled, in which case the alarm time wouhd show. To > disable it, write an empty string; to enable an alarm, just write > a valid time (in the future). The other parameters aren't needed; > "wakeup" is PM infrastructure (/sys/devices/.../power/wakeup), > since it's easy to have an alarm that's not wakeup-capable. Yes, both of these are, or may be, true. That was really a draft, initial version. I probably don't have knowledge/resources to make it "right", but it would be nice if it prompted someone with more experience/resources to tweak in such support, as well as the problems outlined above... > - Dave -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello David, Monday, December 18, 2006, 6:28:58 AM, you wrote: On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote: Small battery-powered systems, like PDAs, need a way to be suspended most of the time and woken up just from time to time to process pending tasks. Sounds like you're thinking of this from a userspace perspective... Could you share some examples of such pending tasks? Well, the actual usecase, which triggered me to hack that, was a need to write a burn out test script for suspend/resume for a battery-powered ARM device (PDA), which would do suspend/resume cycle thousands of times. And wakeup alarm is obvious, if not only, source of automated resume events. Of course, I started by trying existing solutions - e.g. there's an atd implementation which uses /dev/rtc, but I found it having awful latency (2s), then I tried to write simple C app to set alarm via ioctl(), just to find alarm IRQs are shutdown on its exit. But anyway, I'm that kind of guy who think that debugging and diagnostics are important things for *production* system, so such sysfs alarm support just as precious as /proc/interrupts and /proc/dma (ah, ARM Linux maintainer declined to fix broken /proc/dma support for ARM, I forgot ;-( ). [] Obvious way to achieve this is to use timer, or alarm, wakeup. Unfortunately, this matter is bit confusing in Linux. There's only one good supported way to set alarm - via ioctl() on an RTC device fd. Unfortunately, this alarm is not persistent - as soon as fd is closed, alarm id discharged. I don't think that's true in general. Most RTCs don't even care whether userspace did an open() or close(). I see the S3C one does, and that explicitly leaves the alarm active. But I see that only the SA1100/PXA and SH RTCs turn off all IRQs after RTC_WKALM_* requests ... that's a distinct minority. Oh my! I couldn't even think this can be idiosyncrasy of specific implementation. Oh, what a world... ;-) So judging implementations as votes ... only two implementations that implement the RTC_WKALM_* call follow that rule, and most don't. However, a few implementations ignore rtc_wkalrm.enabled, or otherwise mistreat that flag (e.g. rtc-ds1553 doesn't disable AIE when enabled==0), so it's clear there are some issues there. My vote would be that closing the FD should not turn off the alarm. It's supposed to be a one-shot deal anyway. I would agree with such behavior. But what's clear that the behavior, whatever it is, should be consistent across implementations, or its just a mess ;-(. And also, that someone audits the drivers/rtc code to make sure that alarm-capable drivers handle the rtc_wkalrm.enabled flag correctly; your patch sort of presumes that will happen, anyway. Yes, I mentioned, that for PXA/SA, my patch becomes actually useful only after applying your patch (plus, with fixed TODO: here's what I applied to handhelds.org tree: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5r2=1.6f=h ). That of course doesn't mean sysfs alarm support patch depends on rtc-sa1100.c patch in any way (it's just PXA/SA won't actually wake up, but sysfs patch for showing/storing alarm properties obviously doesn't depend on any specific implementation). And hmm, it'd be good to have rtctest.c (in Documentation/rtc.txt) test for that... it doesn't actually use RTC_WKALM_* calls, so it's too easy for folk to goof up their implementations. Formal part === Implement alarm attribute group for RTC classdevs. At this time, add since_epoch, wakeup_enabled, and pending attributes. First two support both read and write. I think you shouldn't add this group unless the RTC has methods to read and write the alarm; there are RTCs that don't have that feature. Also, I'd rather see a much simpler interface. Like a single alarm attribute. It would display as the empty string unless it was enabled, in which case the alarm time wouhd show. To disable it, write an empty string; to enable an alarm, just write a valid time (in the future). The other parameters aren't needed; wakeup is PM infrastructure (/sys/devices/.../power/wakeup), since it's easy to have an alarm that's not wakeup-capable. Yes, both of these are, or may be, true. That was really a draft, initial version. I probably don't have knowledge/resources to make it right, but it would be nice if it prompted someone with more experience/resources to tweak in such support, as well as the problems outlined above... - Dave -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello David, Tuesday, December 19, 2006, 2:59:11 AM, you wrote: On Monday 18 December 2006 4:54 pm, David Brownell wrote: http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5r2=1.6f=h That patch you applied looks right to me -- why don't you forward it to Alessandro as a bugfix for 2.6.20-rc2, and save me the effort? Actually, correction: it'd be correct if you ripped out the buggy calls to manage the irq wake mechanism. A later message will show how those need to work. (The IRQ framework will give one helpful hint when it warns about mismatched enable/disable calls ...) Do you mean enable_irq_wake()/disable_irq_wake() calls? In what way they are buggy? The only bug with them I see is that they are not implemented for PXA, which just once again reminds that mach-pxa is real misfit in ARM family (own DMA API instead of fitting with generic ARM one, no cpufreq support in mainline, and few other not implemented APIs). That's of course pretty sad, as apparently PXA was/still is the most popular CPU for consumer market (well, at least in something like real computer caregory) ;-(. But those calls are apparently still needed, even if you say that wakeup stuff should be handled in generic manner, as PM feature, and on device level. After all, what drivers will do to actually enable wakeup for a given device? I hope we don't speak about using CPU-specific registers in reusable device drivers for that. This is pretty interesting topic for us, and so far in handhelds.org ports we don't handle dynamic wakeup configuration at all, so I would eagerly expect your samples. In the meantime, I went and hacked .set_wake methods for PXA's irq_chips. And that's when I got idea why it might haven't been implemented at all - PXA27x's model of wakeup sources is a bit weird comparing with nice and clean PXA25x's ;-). It's still not the reason to give up on those calls at all - after all, even least common denominator implementation will give good value. I yet need to test what I've put together, though. - Dave -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello linux-kernel,
Informal part
=
Small battery-powered systems, like PDAs, need a way to be
suspended most of the time and woken up just from time to time to
process pending tasks. Obvious way to achieve this is to use timer, or
alarm, wakeup. Unfortunately, this matter is bit confusing in Linux.
There's only one "good" "supported" way to set alarm - via ioctl() on
an RTC device fd. Unfortunately, this alarm is not persistent - as soon
as fd is closed, alarm id discharged. So, this calls for a daemon to
hold RTC fd all the time, IPC to it, etc. This may be just too
cumbersome for all tasks and for small devices, especially if we
talk solely about *wakeup* alarm.
In this respect, I found insightful communication between David
Brownell and Russell King:
http://lkml.org/lkml/2006/11/20/311
http://lkml.org/lkml/2006/11/20/326
http://lkml.org/lkml/2006/11/20/371
David's patch addresses exactly PDAs' need, so please count
another vote for it (except that I here have patch to address
his TODO, and which doesn't remove useful /proc data ;-) ).
What's left after this is a nice way to set a wakeup alarm. The
patch below is initial try to implement it.
Formal part
===
Implement "alarm" attribute group for RTC classdevs. At this time,
add "since_epoch", "wakeup_enabled", and "pending" attributes. First
two support both read and write.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: drivers/rtc/rtc-sysfs.c
===
RCS file: /cvs/linux/kernel26/drivers/rtc/rtc-sysfs.c,v
retrieving revision 1.3
diff -u -r1.3 rtc-sysfs.c
--- drivers/rtc/rtc-sysfs.c 17 Dec 2006 19:07:14 - 1.3
+++ drivers/rtc/rtc-sysfs.c 17 Dec 2006 19:09:49 -
@@ -66,6 +66,90 @@
}
static CLASS_DEVICE_ATTR(since_epoch, S_IRUGO, rtc_sysfs_show_since_epoch,
NULL);
+
+static ssize_t rtc_sysfs_show_alarm_since_epoch(struct class_device *dev, char
*buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, );
+ if (retval == 0) {
+ unsigned long time;
+ rtc_tm_to_time(, );
+ retval = sprintf(buf, "%lu\n", time);
+ }
+
+ return retval;
+}
+
+static ssize_t rtc_sysfs_store_alarm_since_epoch(struct class_device *dev,
const char *buf, size_t count)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ unsigned long time = simple_strtoul(buf, NULL, 0);
+
+ retval = rtc_read_alarm(dev, );
+ if (retval)
+ return retval;
+ rtc_time_to_tm(time, );
+ retval = rtc_set_alarm(dev, );
+ if (retval)
+ return retval;
+
+ return count;
+}
+/* Use sysfs attribute name consistent with clock's */
+struct class_device_attribute class_device_attr_alarm_since_epoch = \
+ __ATTR(since_epoch, 0644 ,rtc_sysfs_show_alarm_since_epoch,
rtc_sysfs_store_alarm_since_epoch);
+
+static ssize_t rtc_sysfs_show_alarm_wakeup_enabled(struct class_device *dev,
char *buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, );
+ if (retval == 0) {
+ retval = sprintf(buf, "%d\n", alrm.enabled);
+ }
+
+ return retval;
+}
+
+static ssize_t rtc_sysfs_store_alarm_wakeup_enabled(struct class_device *dev,
const char *buf, size_t count)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ unsigned long enabled = simple_strtoul(buf, NULL, 0);
+
+ retval = rtc_read_alarm(dev, );
+ if (retval)
+ return retval;
+ alrm.enabled = !!enabled;
+ retval = rtc_set_alarm(dev, );
+ if (retval)
+ return retval;
+
+ return count;
+}
+static CLASS_DEVICE_ATTR(wakeup_enabled, 0644,
rtc_sysfs_show_alarm_wakeup_enabled, rtc_sysfs_store_alarm_wakeup_enabled);
+
+static ssize_t rtc_sysfs_show_alarm_pending(struct class_device *dev, char
*buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, );
+ if (retval == 0) {
+ retval = sprintf(buf, "%d\n", alrm.pending);
+ }
+
+ return retval;
+}
+static CLASS_DEVICE_ATTR(pending, S_IRUGO, rtc_sysfs_show_alarm_pending, NULL);
+
+
static struct attribute *rtc_attrs[] = {
_device_attr_name.attr,
_device_attr_date.attr,
@@ -78,6 +162,19 @@
.attrs = rtc_attrs,
};
+static struct attribute *rtc_alarm_attrs[] = {
+ _device_attr_alarm_since_epoch.attr,
+ _device_attr_wakeup_enabled.attr,
+ _device_attr_pending.attr,
+ NULL,
+};
+
+static struct attribute_group rtc_alarm_attr_group = {
+ .name = "alarm",
+ .attrs = rtc_alarm_attrs,
+};
+
+
static int __devinit rtc_sysfs_add_device(struct class_device *class_dev,
stru
[PATCH] Random typo in drivers/rtc/Kconfig
Hello linux-kernel, Well, this was (at least) since 2.6.18, so I guess, someone should finally submit it patch for it. And yes, kbuild parses that, but that doesn't make it not typo, right? --- drivers/rtc/Kconfig 2 Dec 2006 02:18:35 - 1.3 +++ drivers/rtc/Kconfig 17 Dec 2006 18:56:29 - @@ -1,4 +1,4 @@ -\# +# # RTC class/drivers configuration # -- Best regards, Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Random typo in drivers/rtc/Kconfig
Hello linux-kernel, Well, this was (at least) since 2.6.18, so I guess, someone should finally submit it patch for it. And yes, kbuild parses that, but that doesn't make it not typo, right? --- drivers/rtc/Kconfig 2 Dec 2006 02:18:35 - 1.3 +++ drivers/rtc/Kconfig 17 Dec 2006 18:56:29 - @@ -1,4 +1,4 @@ -\# +# # RTC class/drivers configuration # -- Best regards, Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)
Hello linux-kernel,
Informal part
=
Small battery-powered systems, like PDAs, need a way to be
suspended most of the time and woken up just from time to time to
process pending tasks. Obvious way to achieve this is to use timer, or
alarm, wakeup. Unfortunately, this matter is bit confusing in Linux.
There's only one good supported way to set alarm - via ioctl() on
an RTC device fd. Unfortunately, this alarm is not persistent - as soon
as fd is closed, alarm id discharged. So, this calls for a daemon to
hold RTC fd all the time, IPC to it, etc. This may be just too
cumbersome for all tasks and for small devices, especially if we
talk solely about *wakeup* alarm.
In this respect, I found insightful communication between David
Brownell and Russell King:
http://lkml.org/lkml/2006/11/20/311
http://lkml.org/lkml/2006/11/20/326
http://lkml.org/lkml/2006/11/20/371
David's patch addresses exactly PDAs' need, so please count
another vote for it (except that I here have patch to address
his TODO, and which doesn't remove useful /proc data ;-) ).
What's left after this is a nice way to set a wakeup alarm. The
patch below is initial try to implement it.
Formal part
===
Implement alarm attribute group for RTC classdevs. At this time,
add since_epoch, wakeup_enabled, and pending attributes. First
two support both read and write.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: drivers/rtc/rtc-sysfs.c
===
RCS file: /cvs/linux/kernel26/drivers/rtc/rtc-sysfs.c,v
retrieving revision 1.3
diff -u -r1.3 rtc-sysfs.c
--- drivers/rtc/rtc-sysfs.c 17 Dec 2006 19:07:14 - 1.3
+++ drivers/rtc/rtc-sysfs.c 17 Dec 2006 19:09:49 -
@@ -66,6 +66,90 @@
}
static CLASS_DEVICE_ATTR(since_epoch, S_IRUGO, rtc_sysfs_show_since_epoch,
NULL);
+
+static ssize_t rtc_sysfs_show_alarm_since_epoch(struct class_device *dev, char
*buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, alrm);
+ if (retval == 0) {
+ unsigned long time;
+ rtc_tm_to_time(alrm.time, time);
+ retval = sprintf(buf, %lu\n, time);
+ }
+
+ return retval;
+}
+
+static ssize_t rtc_sysfs_store_alarm_since_epoch(struct class_device *dev,
const char *buf, size_t count)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ unsigned long time = simple_strtoul(buf, NULL, 0);
+
+ retval = rtc_read_alarm(dev, alrm);
+ if (retval)
+ return retval;
+ rtc_time_to_tm(time, alrm.time);
+ retval = rtc_set_alarm(dev, alrm);
+ if (retval)
+ return retval;
+
+ return count;
+}
+/* Use sysfs attribute name consistent with clock's */
+struct class_device_attribute class_device_attr_alarm_since_epoch = \
+ __ATTR(since_epoch, 0644 ,rtc_sysfs_show_alarm_since_epoch,
rtc_sysfs_store_alarm_since_epoch);
+
+static ssize_t rtc_sysfs_show_alarm_wakeup_enabled(struct class_device *dev,
char *buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, alrm);
+ if (retval == 0) {
+ retval = sprintf(buf, %d\n, alrm.enabled);
+ }
+
+ return retval;
+}
+
+static ssize_t rtc_sysfs_store_alarm_wakeup_enabled(struct class_device *dev,
const char *buf, size_t count)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ unsigned long enabled = simple_strtoul(buf, NULL, 0);
+
+ retval = rtc_read_alarm(dev, alrm);
+ if (retval)
+ return retval;
+ alrm.enabled = !!enabled;
+ retval = rtc_set_alarm(dev, alrm);
+ if (retval)
+ return retval;
+
+ return count;
+}
+static CLASS_DEVICE_ATTR(wakeup_enabled, 0644,
rtc_sysfs_show_alarm_wakeup_enabled, rtc_sysfs_store_alarm_wakeup_enabled);
+
+static ssize_t rtc_sysfs_show_alarm_pending(struct class_device *dev, char
*buf)
+{
+ ssize_t retval;
+ struct rtc_wkalrm alrm;
+
+ retval = rtc_read_alarm(dev, alrm);
+ if (retval == 0) {
+ retval = sprintf(buf, %d\n, alrm.pending);
+ }
+
+ return retval;
+}
+static CLASS_DEVICE_ATTR(pending, S_IRUGO, rtc_sysfs_show_alarm_pending, NULL);
+
+
static struct attribute *rtc_attrs[] = {
class_device_attr_name.attr,
class_device_attr_date.attr,
@@ -78,6 +162,19 @@
.attrs = rtc_attrs,
};
+static struct attribute *rtc_alarm_attrs[] = {
+ class_device_attr_alarm_since_epoch.attr,
+ class_device_attr_wakeup_enabled.attr,
+ class_device_attr_pending.attr,
+ NULL,
+};
+
+static struct attribute_group rtc_alarm_attr_group = {
+ .name = alarm,
+ .attrs = rtc_alarm_attrs,
+};
+
+
static int __devinit rtc_sysfs_add_device(struct class_device *class_dev,
struct class_interface *class_intf)
{
@@ -86,10 +183,19
Re[2]: More ARM binutils fuckage
Hello Lennert, Wednesday, December 6, 2006, 3:08:13 AM, you wrote: [] > (These > days I build all kernels in EABI mode with old-ABI compat.) I have > not run into any code generation issues with this compiler yet. I wonder, if OABI-compat is known to actually work on OABI userspace, I mean, on something real, like xserver-kdrive ;-). Because I'd really like to build single kernel for both old and new userspace too, but afraid to try that, fearing to be put down by another broken feature ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Convert pxaficp_ir.c to platform_driver
Hello linux-kernel,
drivers/ner/irda/pxaficp_ir.c was not converted to platform_driver,
which in 2.6.19 ( after commit
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=386415d88b1ae50304f9c61aa3e0db082fa90428;hp=bb84c89f94851161f387285d0a449b4a3f29f4df
) leads to random memory corruption, resume problems, etc. We
specifically face issues with HP iPaq hx4700 device, which has
nondeterministic resume problems depending on the changes to kernel
config options (not directly related to pxaficp_ir). More info on the
issue: http://lkml.org/lkml/2006/10/25/73 .
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/net/irda/pxaficp_ir.c 2 Dec 2006 02:18:04 - 1.3
+++ drivers/net/irda/pxaficp_ir.c 6 Dec 2006 02:00:32 -
@@ -704,9 +704,9 @@
return 0;
}
-static int pxa_irda_suspend(struct device *_dev, pm_message_t state)
+static int pxa_irda_suspend(struct platform_device *_dev, pm_message_t state)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -718,9 +718,9 @@
return 0;
}
-static int pxa_irda_resume(struct device *_dev)
+static int pxa_irda_resume(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev && netif_running(dev)) {
@@ -746,9 +746,8 @@
return io->head ? 0 : -ENOMEM;
}
-static int pxa_irda_probe(struct device *_dev)
+static int pxa_irda_probe(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(_dev);
struct net_device *dev;
struct pxa_irda *si;
unsigned int baudrate_mask;
@@ -822,9 +821,9 @@
return err;
}
-static int pxa_irda_remove(struct device *_dev)
+static int pxa_irda_remove(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
if (dev) {
struct pxa_irda *si = netdev_priv(dev);
@@ -840,9 +839,10 @@
return 0;
}
-static struct device_driver pxa_ir_driver = {
- .name = "pxa2xx-ir",
- .bus= _bus_type,
+static struct platform_driver pxa_ir_driver = {
+ .driver = {
+ .name = "pxa2xx-ir",
+ },
.probe = pxa_irda_probe,
.remove = pxa_irda_remove,
.suspend= pxa_irda_suspend,
@@ -851,12 +851,12 @@
static int __init pxa_irda_init(void)
{
- return driver_register(_ir_driver);
+ return platform_driver_register(_ir_driver);
}
static void __exit pxa_irda_exit(void)
{
- driver_unregister(_ir_driver);
+ platform_driver_unregister(_ir_driver);
}
module_init(pxa_irda_init);
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Convert pxaficp_ir.c to platform_driver
Hello linux-kernel,
drivers/ner/irda/pxaficp_ir.c was not converted to platform_driver,
which in 2.6.19 ( after commit
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=386415d88b1ae50304f9c61aa3e0db082fa90428;hp=bb84c89f94851161f387285d0a449b4a3f29f4df
) leads to random memory corruption, resume problems, etc. We
specifically face issues with HP iPaq hx4700 device, which has
nondeterministic resume problems depending on the changes to kernel
config options (not directly related to pxaficp_ir). More info on the
issue: http://lkml.org/lkml/2006/10/25/73 .
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/net/irda/pxaficp_ir.c 2 Dec 2006 02:18:04 - 1.3
+++ drivers/net/irda/pxaficp_ir.c 6 Dec 2006 02:00:32 -
@@ -704,9 +704,9 @@
return 0;
}
-static int pxa_irda_suspend(struct device *_dev, pm_message_t state)
+static int pxa_irda_suspend(struct platform_device *_dev, pm_message_t state)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev netif_running(dev)) {
@@ -718,9 +718,9 @@
return 0;
}
-static int pxa_irda_resume(struct device *_dev)
+static int pxa_irda_resume(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev netif_running(dev)) {
@@ -746,9 +746,8 @@
return io-head ? 0 : -ENOMEM;
}
-static int pxa_irda_probe(struct device *_dev)
+static int pxa_irda_probe(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(_dev);
struct net_device *dev;
struct pxa_irda *si;
unsigned int baudrate_mask;
@@ -822,9 +821,9 @@
return err;
}
-static int pxa_irda_remove(struct device *_dev)
+static int pxa_irda_remove(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
if (dev) {
struct pxa_irda *si = netdev_priv(dev);
@@ -840,9 +839,10 @@
return 0;
}
-static struct device_driver pxa_ir_driver = {
- .name = pxa2xx-ir,
- .bus= platform_bus_type,
+static struct platform_driver pxa_ir_driver = {
+ .driver = {
+ .name = pxa2xx-ir,
+ },
.probe = pxa_irda_probe,
.remove = pxa_irda_remove,
.suspend= pxa_irda_suspend,
@@ -851,12 +851,12 @@
static int __init pxa_irda_init(void)
{
- return driver_register(pxa_ir_driver);
+ return platform_driver_register(pxa_ir_driver);
}
static void __exit pxa_irda_exit(void)
{
- driver_unregister(pxa_ir_driver);
+ platform_driver_unregister(pxa_ir_driver);
}
module_init(pxa_irda_init);
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re[2]: More ARM binutils fuckage
Hello Lennert, Wednesday, December 6, 2006, 3:08:13 AM, you wrote: [] (These days I build all kernels in EABI mode with old-ABI compat.) I have not run into any code generation issues with this compiler yet. I wonder, if OABI-compat is known to actually work on OABI userspace, I mean, on something real, like xserver-kdrive ;-). Because I'd really like to build single kernel for both old and new userspace too, but afraid to try that, fearing to be put down by another broken feature ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: Where did find_bus() go in 2.6.18?
Hello Jiri, Monday, November 20, 2006, 1:45:51 AM, you wrote: > Paul Sokolovsky wrote: >> But alas, the commit message is not as good as some others are, and >> doesn't mention what should be used instead. So, if find_bus() is >> "unused", what should be used instead? > You should probably mention what for? Indeed, I'm sorry! Looking at find_bus()'s docstring: /** * find_bus - locate bus by name. * @name: name of bus. So well, I'd like to know exactly that - what function should be used instead of find_bus() to locate bus by name. > regards, -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Where did find_bus() go in 2.6.18?
Hello linux-kernel, We here at Handhelds.org upgrading our drivers to 2.6.18 and I just caught a case of find_bus() being undefined during link. Quickly traced this to http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5 But alas, the commit message is not as good as some others are, and doesn't mention what should be used instead. So, if find_bus() is "unused", what should be used instead? Thank you, -- Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Where did find_bus() go in 2.6.18?
Hello linux-kernel, We here at Handhelds.org upgrading our drivers to 2.6.18 and I just caught a case of find_bus() being undefined during link. Quickly traced this to http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5 But alas, the commit message is not as good as some others are, and doesn't mention what should be used instead. So, if find_bus() is unused, what should be used instead? Thank you, -- Paul mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: Where did find_bus() go in 2.6.18?
Hello Jiri, Monday, November 20, 2006, 1:45:51 AM, you wrote: Paul Sokolovsky wrote: But alas, the commit message is not as good as some others are, and doesn't mention what should be used instead. So, if find_bus() is unused, what should be used instead? You should probably mention what for? Indeed, I'm sorry! Looking at find_bus()'s docstring: /** * find_bus - locate bus by name. * @name: name of bus. So well, I'd like to know exactly that - what function should be used instead of find_bus() to locate bus by name. regards, -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
