Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
On Fri, Mar 02, 2018 at 10:03:26AM +0100, Ulf Magnusson wrote: > On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote: > > 2018-02-22 6:39 GMT+09:00 Ulf Magnusson : > > > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote: > > >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann : > > >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada > > >> > wrote: > > >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann : > > >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada > > >> >>> wrote: > > >> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson : > > >> >> > > >> >> Let me clarify my concern. > > >> >> > > >> >> When we test the compiler flag, is there a case > > >> >> where a particular flag depends on -m{32,64} ? > > >> >> > > >> >> For example, is there a compiler that supports -fstack-protector > > >> >> for 64bit mode, but unsupports it for 32bit mode? > > >> >> > > >> >> $(cc-option -m32) -> y > > >> >> $(cc-option -m64) -> y > > >> >> $(cc-option -fstack-protector)-> y > > >> >> $(cc-option -m32 -fstack-protector) -> n > > >> >> $(cc-option -m64 -fstack-protector) -> y > > >> >> > > >> >> I guess this is unlikely to happen, > > >> >> but I am not whether it is zero possibility. > > >> >> > > >> >> If this could happen, > > >> >> $(cc-option ) must be evaluated together with > > >> >> correct bi-arch option (either -m32 or -m64). > > >> >> > > >> >> > > >> >> Currently, -m32/-m64 is specified in Makefile, > > >> >> but we are moving compiler tests to Kconfig > > >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig. > > >> > > > >> > I don't think it can happen for this particular combination (stack > > >> > protector > > >> > and word size), but I'm sure we'll eventually run into options that > > >> > need to be tested in combination. For the current CFLAGS_KERNEL > > >> > setting, we definitely have the case of needing the variables to be > > >> > evaluated in a specific order. > > >> > > > >> > > >> > > >> > > >> > > >> I was thinking of how we can handle complex cases > > >> in the current approach. > > >> > > >> > > >> > > >> (Case 1) > > >> > > >> Compiler flag -foo and -bar interacts, so > > >> we also need to check the combination of the two. > > >> > > >> > > >> config CC_HAS_FOO > > >> def_bool $(cc-option -foo) > > >> > > >> config CC_HAS_BAR > > >> def_bool $(cc-option -bar) > > >> > > >> config CC_HAS_FOO_WITH_BAR > > >> def_bool $(cc-option -foo -bar) > > >> > > >> > > >> > > >> (Case 2) > > >> Compiler flag -foo is sensitive to word-size. > > >> So, we need to test this option together with -m32/-m64. > > >> User can toggle CONFIG_64BIT, like i386/x86_64. > > >> > > >> > > >> config CC_NEEDS_M64 > > >> def_bool $(cc-option -m64) && 64BIT > > >> > > >> config CC_NEEDS_M32 > > >> def_bool $(cc-option -m32) && !64BIT > > >> > > >> config CC_HAS_FOO > > >> bool > > >> default $(cc-option -m64 -foo) if CC_NEEDS_M64 > > >> default $(cc-option -m32 -foo) if CC_NEEDS_M32 > > >> default $(cc-option -foo) > > >> > > >> > > >> > > >> (Case 3) > > >> Compiler flag -foo is sensitive to endian-ness. > > >> > > >> > > >> config CC_NEEDS_BIG_ENDIAN > > >> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN > > >> > > >> config CC_NEEDS_LITTLE_ENDIAN > > >> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN > > >> > > >> config CC_HAS_FOO > > >> bool > > >> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN > > >> default $(cc-option -mlittle-endian -foo) if > > >> CC_NEEDS_LITTLE_ENDIAN > > >> default $(cc-option -foo) > > >> > > >> > > >> > > >> > > >> Hmm, I think I can implement those somehow. > > >> But, I hope we do not have many instances like this... > > >> > > >> > > >> If you know more naive cases, please share your knowledge. > > >> > > >> Thanks! > > >> > > >> > > >> -- > > >> Best Regards > > >> Masahiro Yamada > > > > > > Would get pretty bad if a test needs to consider multiple symbols. > > > Exponential explosion there... > > > > > > > > > I thought some more about the implementation of dynamic (post-parsing) > > > functions to see how bad it would get with the current implementation. > > > > > > Some background on how things work now: > > > > > > 1. All expression operands in Kconfig are symbols. > > > > > > 2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets > > > you symbols with those strings as names and S_UNKNOWN type (because > > > they act like references to undefined symbols). > > > > > > 3. For "foo-$(fn foo)", you also get a symbol with that string as its > > > name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols) > > > > > > 4. Symbols with S_UNKNOWN type get their name as their string value, > > > and the tristate value n. > > > > > > So, if you do string expansion on the names of symbol
Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 21:44, Thierry Reding wrote: > On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote: >> Add PWM mode to pwm_config() function. The drivers which uses pwm_config() >> were adapted to this change. >> >> Signed-off-by: Claudiu Beznea >> --- >> arch/arm/mach-s3c24xx/mach-rx1950.c | 11 +-- >> drivers/bus/ts-nbus.c| 2 +- >> drivers/clk/clk-pwm.c| 3 ++- >> drivers/gpu/drm/i915/intel_panel.c | 17 ++--- >> drivers/hwmon/pwm-fan.c | 2 +- >> drivers/input/misc/max77693-haptic.c | 2 +- >> drivers/input/misc/max8997_haptic.c | 6 +- >> drivers/leds/leds-pwm.c | 5 - >> drivers/media/rc/ir-rx51.c | 5 - >> drivers/media/rc/pwm-ir-tx.c | 5 - >> drivers/video/backlight/lm3630a_bl.c | 4 +++- >> drivers/video/backlight/lp855x_bl.c | 4 +++- >> drivers/video/backlight/lp8788_bl.c | 5 - >> drivers/video/backlight/pwm_bl.c | 11 +-- >> drivers/video/fbdev/ssd1307fb.c | 3 ++- >> include/linux/pwm.h | 6 -- >> 16 files changed, 70 insertions(+), 21 deletions(-) > > I don't think it makes sense to leak mode support into the legacy API. > The pwm_config() function is considered legacy I missed this aspect. and should eventually go > away. As such it doesn't make sense to integrate a new feature such as > PWM modes into it. Agree. All users of pwm_config() assume normal mode, and > that's what pwm_config() should provide. Agree. > > Anyone that needs something other than normal mode should use the new > atomic PWM API. Agree. > > Thierry > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()
On 28.02.2018 22:04, Jani Nikula wrote: > On Wed, 28 Feb 2018, Thierry Reding wrote: >> Anyone that needs something other than normal mode should use the new >> atomic PWM API. > > At the risk of revealing my true ignorance, what is the new atomic PWM > API? Where? Examples of how one would convert old code over to the new > API? As far as I know, the old PWM core code uses config(), set_polarity(), enable(), disable() methods of driver, registered as pwm_ops: struct pwm_ops { int (*request)(struct pwm_chip *chip, struct pwm_device *pwm); void (*free)(struct pwm_chip *chip, struct pwm_device *pwm); int (*config)(struct pwm_chip *chip, struct pwm_device *pwm, int duty_ns, int period_ns); int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm, enum pwm_polarity polarity); int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_capture *result, unsigned long timeout); int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm); void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm); int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state); void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state); #ifdef CONFIG_DEBUG_FS void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s); #endif struct module *owner; }; to do settings on hardware. In order to so settings on a PWM the users should have been follow the below steps: ->config() ->set_polarity() ->enable() Moreover, if the PWM was previously enabled it should have been first disable and then to follow the above steps in order to apply a new settings on hardware. The driver should have been provide, at probe, all the above function: ->config(), ->set_polarity(), ->disable(), ->enable(), function that were used by PWM core. Now, having atomic PWM, the driver should provide one function to PWM core, which is ->apply() function. Every PWM has a state associated, which keeps the period, duty cycle, polarity and enable/disable status. The driver's ->apply() function takes as argument the state that should be applied and it takes care of applying this new state directly without asking user to call ->disable(), then ->config()/->set_polarity(), then ->enable() to apply new hardware settings. The PWM consumer could set a new state for PWM it uses, using pwm_apply_state(pwm, new_state); Regarding the models to switch on atomic PWM, on the controller side you can check for drivers that registers apply function at probe time. Regarding the PWM users, you can look for pwm_apply_state() (drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples). Thierry, please correct me if I'm wrong. Thank you, Claudiu Beznea > > BR, > Jani. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote: > 2018-02-22 6:39 GMT+09:00 Ulf Magnusson : > > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote: > >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann : > >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada > >> > wrote: > >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann : > >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada > >> >>> wrote: > >> 2018-02-20 0:18 GMT+09:00 Ulf Magnusson : > >> >> > >> >> Let me clarify my concern. > >> >> > >> >> When we test the compiler flag, is there a case > >> >> where a particular flag depends on -m{32,64} ? > >> >> > >> >> For example, is there a compiler that supports -fstack-protector > >> >> for 64bit mode, but unsupports it for 32bit mode? > >> >> > >> >> $(cc-option -m32) -> y > >> >> $(cc-option -m64) -> y > >> >> $(cc-option -fstack-protector)-> y > >> >> $(cc-option -m32 -fstack-protector) -> n > >> >> $(cc-option -m64 -fstack-protector) -> y > >> >> > >> >> I guess this is unlikely to happen, > >> >> but I am not whether it is zero possibility. > >> >> > >> >> If this could happen, > >> >> $(cc-option ) must be evaluated together with > >> >> correct bi-arch option (either -m32 or -m64). > >> >> > >> >> > >> >> Currently, -m32/-m64 is specified in Makefile, > >> >> but we are moving compiler tests to Kconfig > >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig. > >> > > >> > I don't think it can happen for this particular combination (stack > >> > protector > >> > and word size), but I'm sure we'll eventually run into options that > >> > need to be tested in combination. For the current CFLAGS_KERNEL > >> > setting, we definitely have the case of needing the variables to be > >> > evaluated in a specific order. > >> > > >> > >> > >> > >> > >> I was thinking of how we can handle complex cases > >> in the current approach. > >> > >> > >> > >> (Case 1) > >> > >> Compiler flag -foo and -bar interacts, so > >> we also need to check the combination of the two. > >> > >> > >> config CC_HAS_FOO > >> def_bool $(cc-option -foo) > >> > >> config CC_HAS_BAR > >> def_bool $(cc-option -bar) > >> > >> config CC_HAS_FOO_WITH_BAR > >> def_bool $(cc-option -foo -bar) > >> > >> > >> > >> (Case 2) > >> Compiler flag -foo is sensitive to word-size. > >> So, we need to test this option together with -m32/-m64. > >> User can toggle CONFIG_64BIT, like i386/x86_64. > >> > >> > >> config CC_NEEDS_M64 > >> def_bool $(cc-option -m64) && 64BIT > >> > >> config CC_NEEDS_M32 > >> def_bool $(cc-option -m32) && !64BIT > >> > >> config CC_HAS_FOO > >> bool > >> default $(cc-option -m64 -foo) if CC_NEEDS_M64 > >> default $(cc-option -m32 -foo) if CC_NEEDS_M32 > >> default $(cc-option -foo) > >> > >> > >> > >> (Case 3) > >> Compiler flag -foo is sensitive to endian-ness. > >> > >> > >> config CC_NEEDS_BIG_ENDIAN > >> def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN > >> > >> config CC_NEEDS_LITTLE_ENDIAN > >> def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN > >> > >> config CC_HAS_FOO > >> bool > >> default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN > >> default $(cc-option -mlittle-endian -foo) if > >> CC_NEEDS_LITTLE_ENDIAN > >> default $(cc-option -foo) > >> > >> > >> > >> > >> Hmm, I think I can implement those somehow. > >> But, I hope we do not have many instances like this... > >> > >> > >> If you know more naive cases, please share your knowledge. > >> > >> Thanks! > >> > >> > >> -- > >> Best Regards > >> Masahiro Yamada > > > > Would get pretty bad if a test needs to consider multiple symbols. > > Exponential explosion there... > > > > > > I thought some more about the implementation of dynamic (post-parsing) > > functions to see how bad it would get with the current implementation. > > > > Some background on how things work now: > > > > 1. All expression operands in Kconfig are symbols. > > > > 2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets > > you symbols with those strings as names and S_UNKNOWN type (because > > they act like references to undefined symbols). > > > > 3. For "foo-$(fn foo)", you also get a symbol with that string as its > > name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols) > > > > 4. Symbols with S_UNKNOWN type get their name as their string value, > > and the tristate value n. > > > > So, if you do string expansion on the names of symbols with S_UNKNOWN > > type in sym_calc_value(), you're almost there with the current > > implementation, except for the tristate case. > > > > Maybe you could set the tristate value of S_UNKNOWN symbols depending on > > the string value you end up with. Things are getting pretty confusing at > > that point. > > > > Could have something like S_DYNAMIC a
[PATCH] Documentation/sphinx: Fix Directive import error
The sphinx.util.compat Directive stuff was deprecated in the recent Sphinx version, and now we get a build error. Let's take a fallback to the newer one, from docutils.parsers.rst. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 Signed-off-by: Takashi Iwai --- I'm no expert of sphinx nor python, so something might be wrong. Please check it. --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -37,7 +37,10 @@ import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList from docutils.parsers.rst import directives -from sphinx.util.compat import Directive +try: +from sphinx.util.compat import Directive +except ImportError: +from docutils.parsers.rst import directives, Directive from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0' -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] HID: logitech-hidpp: document sysfs interface
Descriptions have been collected from git commit logs. Signed-off-by: Aishwarya Pant --- .../ABI/testing/sysfs-driver-hid-logitech-hidpp | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp new file mode 100644 index ..d8f831f2d6b5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp @@ -0,0 +1,19 @@ +What: /sys/bus/hid/drivers/logitech-hidpp-device//range +Date: Jan, 2016 +KernelVersion: 4.6 +Contact: linux-in...@vger.kernel.org +Description: + (RW) This attribute controls the amount of 'turn' permitted in + Logitech G920 wheel. Reading from the file shows the current + range of the steering wheel. Writing a value within the min and + max boundary sets the range of the wheel. + +What: /sys/bus/hid/drivers/logitech-hidpp-device//builtin_power_supply +Date: Apr, 2017 +KernelVersion: 4.12 +Contact: linux-in...@vger.kernel.org +Description: + Presence of this file indicates that HID++ driver is capable of + handling battery properties in the kernel. This way, upower can + add a udev rule to decide whether or not it should use the + internal unifying support or the generic kernel one. -- 2.16.2 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xfs: Change URL for the project in xfs.txt
The oss.sgi.com doesn't exist any more. Change it to current project URL, https://xfs.wiki.kernel.org/ Signed-off-by: Masanari Iida --- Documentation/filesystems/xfs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 3b9b5c149f32..4d9ff0a7f8e1 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive use of Btrees (directories, extents, free space) to aid both performance and scalability. -Refer to the documentation at http://oss.sgi.com/projects/xfs/ +Refer to the documentation at https://xfs.wiki.kernel.org/ for further details. This implementation is on-disk compatible with the IRIX version of XFS. -- 2.16.2.345.g7e31236f652a -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kernel-doc unbuildable with sphinx 1.7
Hi, in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built since that time: Running Sphinx v1.7.1 Extension error: Could not import extension kerneldoc (exception: cannot import name 'Directive') It is because sphinx.util.compat.* was removed from sphinx in 1.7 since it was deprecated for a long time: "sphinx.util.compat.%s is deprecated and will be removed " "in Sphinx 1.7, please use docutils' instead." Could you fix that up? python is not my favourite interpreter so fixing it myself is not feasible on my side. thanks, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-doc unbuildable with sphinx 1.7
On Fri, 2 Mar 2018 15:10:14 +0100 Jiri Slaby wrote: > in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built > since that time: > Running Sphinx v1.7.1 > > Extension error: > Could not import extension kerneldoc (exception: cannot import name > 'Directive') > > It is because sphinx.util.compat.* was removed from sphinx in 1.7 since > it was deprecated for a long time: > "sphinx.util.compat.%s is deprecated and will be removed " >"in Sphinx 1.7, please use docutils' instead." > > > Could you fix that up? python is not my favourite interpreter so fixing > it myself is not feasible on my side. I got a patch from Takashi this very morning for that problem; I guess I'll have to fast-track it Linusward. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-doc unbuildable with sphinx 1.7
On 03/02/2018, 03:34 PM, Jonathan Corbet wrote: > I got a patch from Takashi this very morning for that problem; I guess > I'll have to fast-track it Linusward. Oh, thanks! P.S.: Takashi, could you push it to our master & stable branches? -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-doc unbuildable with sphinx 1.7
On Fri, 02 Mar 2018 15:40:37 +0100, Jiri Slaby wrote: > > On 03/02/2018, 03:34 PM, Jonathan Corbet wrote: > > I got a patch from Takashi this very morning for that problem; I guess > > I'll have to fast-track it Linusward. > > Oh, thanks! > > P.S.: Takashi, could you push it to our master & stable branches? Sure, just waited for the feedback from Jon :) Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/sphinx: Fix Directive import error
On Fri, Mar 02, 2018 at 12:49:03PM +0100, Takashi Iwai wrote: > I'm no expert of sphinx nor python, so something might be wrong. > Please check it. I'm also not a pythonista, but ... > --- a/Documentation/sphinx/kerneldoc.py > +++ b/Documentation/sphinx/kerneldoc.py > @@ -37,7 +37,10 @@ import glob > from docutils import nodes, statemachine > from docutils.statemachine import ViewList > from docutils.parsers.rst import directives > -from sphinx.util.compat import Directive > +try: > +from sphinx.util.compat import Directive > +except ImportError: > +from docutils.parsers.rst import directives, Directive It seems to me the previous line already imported docutils.parsers.rst.directives, and we should probably prefer the newer parser even with Sphinx 1.6, so I would think this would work better: -from sphinx.util.compat import Directive +try: +from docutils.parsers.rst import Directive +except ImportError: +from sphinx.util.compat import Directive (it works on Debian with Sphinx 1.6.7) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel-doc unbuildable with sphinx 1.7
On Fri, 02 Mar 2018 15:44:45 +0100 Takashi Iwai wrote: > Sure, just waited for the feedback from Jon :) I want to try it with both old and new Sphinx, of course, but will have a hard time doing it today - on the road all day. But it looks reasonable at a first glance; I'll try to get it into -rc4 (and -stable, I guess) if I can. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/sphinx: Fix Directive import error
On Fri, 02 Mar 2018 15:50:55 +0100, Matthew Wilcox wrote: > > On Fri, Mar 02, 2018 at 12:49:03PM +0100, Takashi Iwai wrote: > > I'm no expert of sphinx nor python, so something might be wrong. > > Please check it. > > I'm also not a pythonista, but ... > > > --- a/Documentation/sphinx/kerneldoc.py > > +++ b/Documentation/sphinx/kerneldoc.py > > @@ -37,7 +37,10 @@ import glob > > from docutils import nodes, statemachine > > from docutils.statemachine import ViewList > > from docutils.parsers.rst import directives > > -from sphinx.util.compat import Directive > > +try: > > +from sphinx.util.compat import Directive > > +except ImportError: > > +from docutils.parsers.rst import directives, Directive > > It seems to me the previous line already imported > docutils.parsers.rst.directives, and we should probably prefer the newer > parser even with Sphinx 1.6, so I would think this would work better: > > -from sphinx.util.compat import Directive > +try: > +from docutils.parsers.rst import Directive > +except ImportError: > +from sphinx.util.compat import Directive > > (it works on Debian with Sphinx 1.6.7) Makes more sense, yes. Jon, would you like me resending the patch? Or it's trivial enough as you can fix in place. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/sphinx: Fix Directive import error
On Fri, 02 Mar 2018 15:55:06 +0100 Takashi Iwai wrote: > Jon, would you like me resending the patch? Or it's trivial enough as > you can fix in place. If you can resend that would be great - one less thing for me to have to squeeze in :) Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation/sphinx: Fix Directive import error
The sphinx.util.compat for Directive stuff was deprecated in the recent Sphinx version, and now we get a build error. Let's import from the new place, docutils.parsers.rst, while keeping the old sphinx.util.compat as fallback. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 Signed-off-by: Takashi Iwai --- v1->v2: Change the fallback order as Matthew suggested, the new one at first Documentation/sphinx/kerneldoc.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index 39aa9e8697cc..34396976eb0a 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -37,7 +37,10 @@ import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList from docutils.parsers.rst import directives -from sphinx.util.compat import Directive +try: +from docutils.parsers.rst import directives, Directive +except ImportError: +from sphinx.util.compat import Directive from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0' -- 2.16.2 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/sphinx: Fix Directive import error
On Fri, 02 Mar 2018, Takashi Iwai wrote: > The sphinx.util.compat for Directive stuff was deprecated in the > recent Sphinx version, and now we get a build error. > > Let's import from the new place, docutils.parsers.rst, while keeping > the old sphinx.util.compat as fallback. > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 > Signed-off-by: Takashi Iwai > --- > v1->v2: Change the fallback order as Matthew suggested, the new one at first So this crossed my mind as well... and then I thought it'll probably succeed on older Sphinx, and the fallback is not needed. The question is, are these equal? Can we just import from docutils.parsers.rst? I'm sorry I don't have the time to find the answers to these questions as well. :( BR, Jani. > > Documentation/sphinx/kerneldoc.py | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/sphinx/kerneldoc.py > b/Documentation/sphinx/kerneldoc.py > index 39aa9e8697cc..34396976eb0a 100644 > --- a/Documentation/sphinx/kerneldoc.py > +++ b/Documentation/sphinx/kerneldoc.py > @@ -37,7 +37,10 @@ import glob > from docutils import nodes, statemachine > from docutils.statemachine import ViewList > from docutils.parsers.rst import directives > -from sphinx.util.compat import Directive > +try: > +from docutils.parsers.rst import directives, Directive > +except ImportError: > +from sphinx.util.compat import Directive > from sphinx.ext.autodoc import AutodocReporter > > __version__ = '1.0' -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/sphinx: Fix Directive import error
On Fri, Mar 02, 2018 at 04:28:31PM +0100, Takashi Iwai wrote: > from docutils.parsers.rst import directives > -from sphinx.util.compat import Directive > +try: > +from docutils.parsers.rst import directives, Directive We also don't need 'directives' on this line as it was imported on the previous line. > +except ImportError: > +from sphinx.util.compat import Directive > from sphinx.ext.autodoc import AutodocReporter > > __version__ = '1.0' Here's what I tested on Debian: +++ b/Documentation/sphinx/kerneldoc.py @@ -37,7 +37,10 @@ import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList from docutils.parsers.rst import directives -from sphinx.util.compat import Directive +try: +from docutils.parsers.rst import Directive +except ImportError: +from sphinx.util.compat import Directive from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0' -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation/sphinx: Fix Directive import error
On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote: > On Fri, 02 Mar 2018, Takashi Iwai wrote: > > The sphinx.util.compat for Directive stuff was deprecated in the > > recent Sphinx version, and now we get a build error. > > > > Let's import from the new place, docutils.parsers.rst, while keeping > > the old sphinx.util.compat as fallback. > > > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 > > Signed-off-by: Takashi Iwai > > --- > > v1->v2: Change the fallback order as Matthew suggested, the new one at first > > So this crossed my mind as well... and then I thought it'll probably > succeed on older Sphinx, and the fallback is not needed. The question > is, are these equal? Can we just import from docutils.parsers.rst? I found a github page which implies that docutils.parsers.rst.Directive was added 12 years ago (!) so we're probably safe to rely on it: https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3 Again, I'm no pythonista, so I may have muddled this. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfs: Change URL for the project in xfs.txt
On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: > The oss.sgi.com doesn't exist any more. > Change it to current project URL, https://xfs.wiki.kernel.org/ > > Signed-off-by: Masanari Iida > --- > Documentation/filesystems/xfs.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/filesystems/xfs.txt > b/Documentation/filesystems/xfs.txt > index 3b9b5c149f32..4d9ff0a7f8e1 100644 > --- a/Documentation/filesystems/xfs.txt > +++ b/Documentation/filesystems/xfs.txt > @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive > use of > Btrees (directories, extents, free space) to aid both performance > and scalability. > > -Refer to the documentation at http://oss.sgi.com/projects/xfs/ > +Refer to the documentation at https://xfs.wiki.kernel.org/ > for further details. This implementation is on-disk compatible > with the IRIX version of XFS. Looks ok, Reviewed-by: Darrick J. Wong --D > > -- > 2.16.2.345.g7e31236f652a > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Input: trackpoint: document sysfs interface
Descriptions have been collected from git commit logs, code commits and the TrackPoint System Version 4.0 Engineering Specification. Signed-off-by: Aishwarya Pant --- .../ABI/testing/sysfs-devices-platform-trackpoint | 115 + 1 file changed, 115 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-trackpoint diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint new file mode 100644 index ..df11901a6b3d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint @@ -0,0 +1,115 @@ +What: /sys/devices/platform/i8042/.../sensitivity +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Trackpoint sensitivity. + +What: /sys/devices/platform/i8042/.../intertia +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Negative inertia factor. High values cause the cursor to + snap backward when the trackpoint is released. + +What: /sys/devices/platform/i8042/.../reach +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Backup range for z-axis press. + +What: /sys/devices/platform/i8042/.../draghys +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) The drag hysteresis controls how hard it is to drag with + z-axis pressed. + +What: /sys/devices/platform/i8042/.../mindrag +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Minimum amount of force needed to trigger dragging. + +What: /sys/devices/platform/i8042/.../speed +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Speed of the trackpoint cursor. + +What: /sys/devices/platform/i8042/.../thresh +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Minimum value for z-axis force required to trigger a press + or release, relative to the running average. + +What: /sys/devices/platform/i8042/.../upthresh +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) The offset from the running average required to generate a + select (click) on z-axis on release. + +What: /sys/devices/platform/i8042/.../ztime +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) This attribute determines how sharp a press has to be in + order to be recognized. + +What: /sys/devices/platform/i8042/.../jenks +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Minimum curvature in degrees required to generate a double + click without a release. + +What: /sys/devices/platform/i8042/.../skipback +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) When the skipback bit is set, backup cursor movement during + releases from drags will be suppressed. The default value for + this bit is 0. + +What: /sys/devices/platform/i8042/.../ext_dev +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Disable (0) or enable (1) external pointing device. + +What: /sys/devices/platform/i8042/.../press_to_select +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-in...@vger.kernel.org +Description: + (RW) Writing a value of 1 to this file will enable the Press to + Select functions like tapping the control stick to simulate a + left click, and writing 0 will disable it. + +What: /sys/devices/platform/i8042/.../drift_time +Date: Dec, 2014 +KernelVersion: 3.19 +Contact: linux-in...@vger.kernel.org +Description: + (RW) This parameter controls the period of time to test for a + ‘hands off’ condition (i.e. when no force is applied) before a + drift (noise) calibration occurs. + + IBM Trackpoints have a feature to compensate for drift by + recalibrating themselves periodically. By default, if for 0.5 + seconds there is no change in position, it's used as the new + zero. This duration is too low. Often, the calibration happens + when the trackpoint is in fact
Re: [PATCH v2] Documentation/sphinx: Fix Directive import error
On Fri, Mar 02, 2018 at 08:42:54AM -0800, Matthew Wilcox wrote: > On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote: > > On Fri, 02 Mar 2018, Takashi Iwai wrote: > > > The sphinx.util.compat for Directive stuff was deprecated in the > > > recent Sphinx version, and now we get a build error. > > > > > > Let's import from the new place, docutils.parsers.rst, while keeping > > > the old sphinx.util.compat as fallback. > > > > > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 > > > Signed-off-by: Takashi Iwai > > > --- > > > v1->v2: Change the fallback order as Matthew suggested, the new one at > > > first > > > > So this crossed my mind as well... and then I thought it'll probably > > succeed on older Sphinx, and the fallback is not needed. The question > > is, are these equal? Can we just import from docutils.parsers.rst? > > I found a github page which implies that docutils.parsers.rst.Directive > was added 12 years ago (!) so we're probably safe to rely on it: > > https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3 > > Again, I'm no pythonista, so I may have muddled this. I spent some time delving through the Sphinx codebase. The compat version was added so you could use Directive with docutils 0.4 onwards. docutils 0.5 onwards has Directive. So as long as we're comfortable mandating docutils from 2009, we're fine ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko wrote: > On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote: > > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko < andy.shevche...@gmail.com> > > wrote: > > "earlycon simply does not utilize the information". > > > > earlycon parses iotype, mapbase and baud (from options). However, it is > > hard-coded to assume that the clock used to generate the UART bitclock is > > always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs, > > it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz > > clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and > > uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is > > actually a set up in acpi_apd.c when there is an acpi match for "AMD0020", > > with a rate read from the .fixed_clk_rate param of the corresponding > > apd_device_desc. > > > > This patch attempts to add a way to inform earlycon about this clock. As > > noted above, the information is actually already in the kernel and used by > > 8250_dw - I would happy be to hear recommendations for wiring this data > > into earlycon that doesn't require adding another command line arg. > And it should not require that for sure! > I would look to this later. It's late here. I need to do a bit of > research for the answer. > > I see that support was also added recently to earlycon to let it use ACPI > > SPCR to choose a console and configure its parameters... but AFAICT, this > > path also doesn't allow specifying the uart clock. > Fix your firmware then. It should set console to 115200 like (almost) > everyone does. > Okay, configures a necessary IPs to feed UART with expected 1.8432M clock. The console is 115200 when it is enabled. However, the firmware does not always enable it by default. The problem is that the UART IP block has a fixed 48 MHz input clock, but earlycon assumes this clock is always 1843200. I looked a bit further, and I think this patch (or something similar) is still required to teach generic earlycon how to handle an explicit port->uartclk (ie, one that is not 1843200). The extended string can then be explicitly set on the kernel command line for this kind of hardware. In addition, we can add another patch with a new quirk detector in drivers/acpi/spcr.c:acpi_parse_spcr() to handle this hardware. acpi_parse_spcr() can then use the extended option string to pass in the appropriate UART clock to setup_eralycon(). This would again allow a user to just use the simple command line parameter "earlycon" if the device's firmware has a correctly confiured ACPI SPCR table. Thanks, -Dan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Documentation/sphinx: Fix Directive import error
From: Matthew Wilcox Sphinx 1.7 removed sphinx.util.compat.Directive so people who have upgraded cannot build the documentation. Switch to docutils.parsers.rst.Directive which has been available since docutils 0.5 released in 2009. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 Co-developed-by: Takashi Iwai Signed-off-by: Matthew Wilcox diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index 39aa9e8697cc..fbedcc39460b 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -36,8 +36,7 @@ import glob from docutils import nodes, statemachine from docutils.statemachine import ViewList -from docutils.parsers.rst import directives -from sphinx.util.compat import Directive +from docutils.parsers.rst import directives, Directive from sphinx.ext.autodoc import AutodocReporter __version__ = '1.0' -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] Documentation/sphinx: Fix Directive import error
On Fri, 02 Mar 2018, Matthew Wilcox wrote: > From: Matthew Wilcox > > Sphinx 1.7 removed sphinx.util.compat.Directive so people > who have upgraded cannot build the documentation. Switch to > docutils.parsers.rst.Directive which has been available since > docutils 0.5 released in 2009. > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694 > Co-developed-by: Takashi Iwai > Signed-off-by: Matthew Wilcox I think this is the best approach. FWIW, Acked-by: Jani Nikula > > diff --git a/Documentation/sphinx/kerneldoc.py > b/Documentation/sphinx/kerneldoc.py > index 39aa9e8697cc..fbedcc39460b 100644 > --- a/Documentation/sphinx/kerneldoc.py > +++ b/Documentation/sphinx/kerneldoc.py > @@ -36,8 +36,7 @@ import glob > > from docutils import nodes, statemachine > from docutils.statemachine import ViewList > -from docutils.parsers.rst import directives > -from sphinx.util.compat import Directive > +from docutils.parsers.rst import directives, Directive > from sphinx.ext.autodoc import AutodocReporter > > __version__ = '1.0' -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver
Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:07) > This driver manages the Generic Interface (GENI) firmware based Qualcomm > Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation > programmable module composed of multiple Serial Engines (SE) and supports > a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This > driver also enables managing the serial interface independent aspects of > Serial Engines. > > Signed-off-by: Karthikeyan Ramasubramanian > Signed-off-by: Sagar Dharia > Signed-off-by: Girish Mahadevan > --- > drivers/soc/qcom/Kconfig| 9 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qcom-geni-se.c | 971 > > include/linux/qcom-geni-se.h| 247 ++ > 4 files changed, 1228 insertions(+) > create mode 100644 drivers/soc/qcom/qcom-geni-se.c > create mode 100644 include/linux/qcom-geni-se.h > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > index e050eb8..cc460d0 100644 > --- a/drivers/soc/qcom/Kconfig > +++ b/drivers/soc/qcom/Kconfig > @@ -3,6 +3,15 @@ > # > menu "Qualcomm SoC drivers" > > +config QCOM_GENI_SE > + tristate "QCOM GENI Serial Engine Driver" > + depends on ARCH_QCOM Add || COMPILE_TEST? > + help > + This module is used to manage Generic Interface (GENI) firmware > based s/module/driver? > + Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This > + module is also used to manage the common aspects of multiple Serial s/module/driver? > + Engines present in the QUP. > + > config QCOM_GLINK_SSR > tristate "Qualcomm Glink SSR driver" > depends on RPMSG > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c > new file mode 100644 > index 000..61335b8 > --- /dev/null > +++ b/drivers/soc/qcom/qcom-geni-se.c > @@ -0,0 +1,971 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include #include > + > +/** > + * DOC: Overview > + * > + * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced > + * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper > + * controller. QUP Wrapper is designed to support various serial bus > protocols > + * like UART, SPI, I2C, I3C, etc. > + */ > + > +/** > + * DOC: Hardware description > + * > + * GENI based QUP is a highly-flexible and programmable module for supporting > + * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single > + * QUP module can provide upto 8 Serial Interfaces, using its internal > + * Serial Engines. The actual configuration is determined by the target > + * platform configuration. The protocol supported by each interface is > + * determined by the firmware loaded to the Serial Engine. Each SE consists > + * of a DMA Engine and GENI sub modules which enable Serial Engines to > + * support FIFO and DMA modes of operation. > + * > + * > + * +-+ > + * |QUP Wrapper | > + * | ++ | > + * --QUP & SE Clocks--> | Serial Engine N| +-IO--> > + * | | ...| | Interface > + * <---Clock Perf.+++---+| | > + * State Interface || Serial Engine 1|| | > + * |||| | > + * |||| | > + *||| | > + * ||++ | > + * ||| | > + * ||| | > + * <--SE IRQ--+++ | > + * | | > + * +-+ > + * > + * Figure 1: GENI based QUP Wrapper The code talks about primary and secondary sequencers, but this hardware description doesn't talk about it. Can you add some more information here about that aspect too? > + */ > + > +/** > + * DOC: Software description > + * > + * GENI SE Wrapper driver is structured into 2 parts: > + * > + * geni_wrapper represents QUP Wrapper controller. This part of the driver > + * manages QUP Wrapper information such as hardware version, clock > + * performance table that is common to all the internal Serial Engines. > + * > + * geni_se represents Serial Engine. This part of the driver manages Serial > + * Engine information such as
Re: [PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver
Hi Karthik, On Tue, Feb 27, 2018 at 5:38 PM, Karthikeyan Ramasubramanian wrote: > This driver manages the Generic Interface (GENI) firmware based Qualcomm > Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation > programmable module composed of multiple Serial Engines (SE) and supports > a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This > driver also enables managing the serial interface independent aspects of > Serial Engines. > > Signed-off-by: Karthikeyan Ramasubramanian > Signed-off-by: Sagar Dharia > Signed-off-by: Girish Mahadevan > --- > drivers/soc/qcom/Kconfig| 9 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qcom-geni-se.c | 971 > > include/linux/qcom-geni-se.h| 247 ++ > 4 files changed, 1228 insertions(+) > create mode 100644 drivers/soc/qcom/qcom-geni-se.c > create mode 100644 include/linux/qcom-geni-se.h > [...] > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c > new file mode 100644 > index 000..61335b8 > --- /dev/null > +++ b/drivers/soc/qcom/qcom-geni-se.c > + > +/** > + * geni_se_clk_tbl_get() - Get the clock table to program DFS > + * @se:Pointer to the concerned Serial Engine. > + * @tbl: Table in which the output is returned. > + * > + * This function is called by the protocol drivers to determine the different > + * clock frequencies supported by Serial Engine Core Clock. The protocol > + * drivers use the output to determine the clock frequency index to be > + * programmed into DFS. > + * > + * Return: number of valid performance levels in the table on success, > + *standard Linux error codes on failure. > + */ > +int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl) > +{ > + struct geni_wrapper *wrapper = se->wrapper; > + unsigned long freq = 0; > + int i; > + int ret = 0; > + > + mutex_lock(&wrapper->lock); > + if (wrapper->clk_perf_tbl) { > + *tbl = wrapper->clk_perf_tbl; > + ret = wrapper->num_clk_levels; > + goto out_unlock; > + } > + > + wrapper->clk_perf_tbl = kcalloc(MAX_CLK_PERF_LEVEL, > + sizeof(*wrapper->clk_perf_tbl), > + GFP_KERNEL); > + if (!wrapper->clk_perf_tbl) { > + ret = -ENOMEM; > + goto out_unlock; > + } > + > + for (i = 0; i < MAX_CLK_PERF_LEVEL; i++) { > + freq = clk_round_rate(se->clk, freq + 1); > + if (!freq || freq == wrapper->clk_perf_tbl[i - 1]) > + break; > + wrapper->clk_perf_tbl[i] = freq; > + } > + wrapper->num_clk_levels = i; > + *tbl = wrapper->clk_perf_tbl; > + ret = wrapper->num_clk_levels; > +out_unlock: > + mutex_unlock(&wrapper->lock); > + return ret; > +} > +EXPORT_SYMBOL(geni_se_clk_tbl_get); I think Bjorn had this feedback before, but if you did this work in probe you could remove the mutex altogether. > + wrapper->ahb_clks[0].id = m_ahb_clk; > + wrapper->ahb_clks[1].id = s_ahb_clk; > + ret = devm_clk_bulk_get(dev, NUM_AHB_CLKS, wrapper->ahb_clks); > + if (ret) { > + dev_err(dev, "Err getting AHB clks %d\n", ret); > + return ret; > + } > + > + mutex_init(&wrapper->lock); > + dev_set_drvdata(dev, wrapper); > + dev_dbg(dev, "GENI SE Driver probed\n"); > + return devm_of_platform_populate(dev); > +} > + > +static int geni_se_remove(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct geni_wrapper *wrapper = dev_get_drvdata(dev); > + > + kfree(wrapper->clk_perf_tbl); Maybe null out clk_perf_tbl for safety? > diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h > new file mode 100644 > index 000..4996de7 > --- /dev/null > +++ b/include/linux/qcom-geni-se.h [...] > +/* SE_DMA_RX_IRQ_STAT Register fields */ > +#define RX_DMA_DONEBIT(0) > +#define RX_EOT BIT(1) > +#define RX_SBE BIT(2) > +#define RX_RESET_DONE BIT(3) > +#define RX_FLUSH_DONE BIT(4) > +#define RX_GENI_GP_IRQ GENMASK(10, 5) > +#define RX_GENI_CANCEL_IRQ BIT(11) > +#define RX_GENI_GP_IRQ_EXT GENMASK(13, 12) > + > +#ifdef CONFIG_QCOM_GENI_SE I think this needs to be #if IS_ENABLED(CONFIG_QCOM_GENI_SE), since the function prototypes below won't light up if this is built as a module. Thanks, Evan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfs: Change URL for the project in xfs.txt
On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote: > On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: > > The oss.sgi.com doesn't exist any more. > > Change it to current project URL, https://xfs.wiki.kernel.org/ > > > > Signed-off-by: Masanari Iida > > --- > > Documentation/filesystems/xfs.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/filesystems/xfs.txt > > b/Documentation/filesystems/xfs.txt > > index 3b9b5c149f32..4d9ff0a7f8e1 100644 > > --- a/Documentation/filesystems/xfs.txt > > +++ b/Documentation/filesystems/xfs.txt > > @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive > > use of > > Btrees (directories, extents, free space) to aid both performance > > and scalability. > > > > -Refer to the documentation at http://oss.sgi.com/projects/xfs/ > > +Refer to the documentation at https://xfs.wiki.kernel.org/ Did I miss a memo? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfs: Change URL for the project in xfs.txt
On 3/2/18 3:57 PM, Dave Chinner wrote: > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote: >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: >>> The oss.sgi.com doesn't exist any more. >>> Change it to current project URL, https://xfs.wiki.kernel.org/ >>> >>> Signed-off-by: Masanari Iida >>> --- >>> Documentation/filesystems/xfs.txt | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/Documentation/filesystems/xfs.txt >>> b/Documentation/filesystems/xfs.txt >>> index 3b9b5c149f32..4d9ff0a7f8e1 100644 >>> --- a/Documentation/filesystems/xfs.txt >>> +++ b/Documentation/filesystems/xfs.txt >>> @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive >>> use of >>> Btrees (directories, extents, free space) to aid both performance >>> and scalability. >>> >>> -Refer to the documentation at http://oss.sgi.com/projects/xfs/ >>> +Refer to the documentation at https://xfs.wiki.kernel.org/ > > Did I miss a memo? About which part, the loss of oss.sgi or the addition of the kernel.org wiki? The kernel.org wiki is pretty bare though. OTOH xfs.org is a bit less official. We really need to resolve this issue. -Eric > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP
Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:09) > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 3682fd3..c6b1500 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1104,6 +1104,17 @@ config SERIAL_MSM_CONSOLE > select SERIAL_CORE_CONSOLE > select SERIAL_EARLYCON > > +config SERIAL_QCOM_GENI > + bool "QCOM on-chip GENI based serial port support" This can be tristate. > + depends on ARCH_QCOM || COMPILE_TEST ? > + depends on QCOM_GENI_SE > + select SERIAL_CORE This can stay. > + select SERIAL_CORE_CONSOLE > + select SERIAL_EARLYCON These two can go to a new config option, like SERIAL_QCOM_GENI_CONSOLE, and that would be bool. Please take a look at the existing SERIAL_MSM and SERIAL_MSM_CONSOLE setup to understand how to do it. > + help > + Serial driver for Qualcomm Technologies Inc's GENI based QUP > + hardware. > + > config SERIAL_VT8500 > bool "VIA VT8500 on-chip serial port support" > depends on ARCH_VT8500 > diff --git a/drivers/tty/serial/qcom_geni_serial.c > b/drivers/tty/serial/qcom_geni_serial.c > new file mode 100644 > index 000..8536b7d > --- /dev/null > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -0,0 +1,1181 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2017-2018, The Linux foundation. All rights reserved. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* UART specific GENI registers */ > +#define SE_UART_TX_TRANS_CFG 0x25c > +#define SE_UART_TX_WORD_LEN0x268 > +#define SE_UART_TX_STOP_BIT_LEN0x26c > +#define SE_UART_TX_TRANS_LEN 0x270 > +#define SE_UART_RX_TRANS_CFG 0x280 > +#define SE_UART_RX_WORD_LEN0x28c > +#define SE_UART_RX_STALE_CNT 0x294 > +#define SE_UART_TX_PARITY_CFG 0x2a4 > +#define SE_UART_RX_PARITY_CFG 0x2a8 > + > +/* SE_UART_TRANS_CFG */ > +#define UART_TX_PAR_EN BIT(0) > +#define UART_CTS_MASK BIT(1) > + > +/* SE_UART_TX_WORD_LEN */ > +#define TX_WORD_LEN_MSKGENMASK(9, 0) > + > +/* SE_UART_TX_STOP_BIT_LEN */ > +#define TX_STOP_BIT_LEN_MSKGENMASK(23, 0) > +#define TX_STOP_BIT_LEN_1 0 > +#define TX_STOP_BIT_LEN_1_51 > +#define TX_STOP_BIT_LEN_2 2 > + > +/* SE_UART_TX_TRANS_LEN */ > +#define TX_TRANS_LEN_MSK GENMASK(23, 0) > + > +/* SE_UART_RX_TRANS_CFG */ > +#define UART_RX_INS_STATUS_BIT BIT(2) > +#define UART_RX_PAR_EN BIT(3) > + > +/* SE_UART_RX_WORD_LEN */ > +#define RX_WORD_LEN_MASK GENMASK(9, 0) > + > +/* SE_UART_RX_STALE_CNT */ > +#define RX_STALE_CNT GENMASK(23, 0) > + > +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */ > +#define PAR_CALC_ENBIT(0) > +#define PAR_MODE_MSK GENMASK(2, 1) > +#define PAR_MODE_SHFT 1 > +#define PAR_EVEN 0x00 > +#define PAR_ODD0x01 > +#define PAR_SPACE 0x10 > +#define PAR_MARK 0x11 > + > +/* UART M_CMD OP codes */ > +#define UART_START_TX 0x1 > +#define UART_START_BREAK 0x4 > +#define UART_STOP_BREAK0x5 > +/* UART S_CMD OP codes */ > +#define UART_START_READ0x1 > +#define UART_PARAM 0x1 > + > +#define UART_OVERSAMPLING 32 > +#define STALE_TIMEOUT 16 > +#define DEFAULT_BITS_PER_CHAR 10 > +#define GENI_UART_CONS_PORTS 1 > +#define DEF_FIFO_DEPTH_WORDS 16 > +#define DEF_TX_WM 2 > +#define DEF_FIFO_WIDTH_BITS32 > +#define UART_CONSOLE_RX_WM 2 > + > +#ifdef CONFIG_CONSOLE_POLL > +#define RX_BYTES_PW 1 > +#else > +#define RX_BYTES_PW 4 > +#endif > + > +struct qcom_geni_serial_port { > + struct uart_port uport; > + struct geni_se se; > + char name[20]; > + u32 tx_fifo_depth; > + u32 tx_fifo_width; > + u32 rx_fifo_depth; > + u32 tx_wm; > + u32 rx_wm; > + u32 rx_rfr; > + int xfer_mode; Can this be an enum? > + bool port_setup; Maybe just 'setup'? Port is in the type already. > + int (*handle_rx)(struct uart_port *uport, > + u32 rx_bytes, bool drop_rx); s/rx_bytes/bytes/ s/drop_rx/drop/ > + unsigned int xmit_size; > + unsigned int cur_baud; s/cur// > + unsigned int tx_bytes_pw; > + unsigned int rx_bytes_pw; > +}; > + > +static const struct uart_ops qcom_geni_serial_pops; > +static struct uart_driver qcom_geni_console_driver; > +static int handle_rx_console(struct uart_port *uport, > + u32 rx_bytes, bool drop_rx); s/rx_bytes/bytes/ s/drop_rx/drop/ > +static unsigned int qcom_geni_serial_tx_empty(struct uart_port *port); > +static bool qcom_geni_serial_poll_bit(struct uart_port *uport, > +
Re: [PATCH] xfs: Change URL for the project in xfs.txt
On Fri, Mar 02, 2018 at 04:08:24PM -0600, Eric Sandeen wrote: > > > On 3/2/18 3:57 PM, Dave Chinner wrote: > > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote: > >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: > >>> The oss.sgi.com doesn't exist any more. > >>> Change it to current project URL, https://xfs.wiki.kernel.org/ > >>> > >>> Signed-off-by: Masanari Iida > >>> --- > >>> Documentation/filesystems/xfs.txt | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/Documentation/filesystems/xfs.txt > >>> b/Documentation/filesystems/xfs.txt > >>> index 3b9b5c149f32..4d9ff0a7f8e1 100644 > >>> --- a/Documentation/filesystems/xfs.txt > >>> +++ b/Documentation/filesystems/xfs.txt > >>> @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes > >>> extensive use of > >>> Btrees (directories, extents, free space) to aid both performance > >>> and scalability. > >>> > >>> -Refer to the documentation at http://oss.sgi.com/projects/xfs/ > >>> +Refer to the documentation at https://xfs.wiki.kernel.org/ > > > > Did I miss a memo? > > About which part, the loss of oss.sgi or the addition of the kernel.org wiki? > > The kernel.org wiki is pretty bare though. OTOH xfs.org is a bit less > official. We really need to resolve this issue. Moving everything to kernel.org wiki. As I mentioned on IRC, I'd much prefer we move away from wiki's to something we can edit locally, review via email, has proper revision control and a "publish" mechanism that pushes built documentation out to the public website. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] mux: add overview and add to driver-api docs
On 2017-12-21 23:11, Peter Rosin wrote: > On 2017-12-21 22:35, Jonathan Corbet wrote: >> On Tue, 12 Dec 2017 09:46:31 +0100 >> Peter Rosin wrote: >> >>> Changes since v1: >>> - added a short introductory paragraph to mux.rst >>> - added an entry in MAINTAINERS. >>> >>> I forgot to mention that this applies on top of linux-next, I suspect >>> there will be a trivial conflict with an SPDX conversion in mux/core.c >>> on Linus upstream. >> >> Sorry, I've had this just sitting here for a bit. Did you want me to take >> both patches through the docs tree? > > I think that's going to be easiest, thanks! Let me know if you want me > to rebase them to something w/o the SPDX change. Hi, Gentle ping... Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP
Hello Karthik, On Tue, Feb 27, 2018 at 5:38 PM, Karthikeyan Ramasubramanian wrote: > This driver supports GENI based UART Controller in the Qualcomm SOCs. The > Qualcomm Generic Interface (GENI) is a programmable module supporting a > wide range of serial interfaces including UART. This driver support console > operations using FIFO mode of transfer. > > Signed-off-by: Girish Mahadevan > Signed-off-by: Karthikeyan Ramasubramanian > Signed-off-by: Sagar Dharia > Signed-off-by: Doug Anderson > --- > drivers/tty/serial/Kconfig| 11 + > drivers/tty/serial/Makefile |1 + > drivers/tty/serial/qcom_geni_serial.c | 1181 > + > 3 files changed, 1193 insertions(+) > create mode 100644 drivers/tty/serial/qcom_geni_serial.c > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 3682fd3..c6b1500 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1104,6 +1104,17 @@ config SERIAL_MSM_CONSOLE > select SERIAL_CORE_CONSOLE > select SERIAL_EARLYCON > > +config SERIAL_QCOM_GENI > + bool "QCOM on-chip GENI based serial port support" > + depends on ARCH_QCOM > + depends on QCOM_GENI_SE My understanding is that this has to be "bool" because there's a console in there, and consoles cannot be built as modules. Stephen is suggesting splitting this option up into two, so you could have serial with or without the console. That's fine, and probably the preferred way. However, you do want to make sure that if serial (or what's soon to be serial+console) is enabled, that QCOM_GENI_SE has to be built =y, and not =m. I'd suggest "select QCOM_GENI_SE" in the new SERIAL_QCOM_GENI_CONSOLE (or whatever it's called). As it is now, if SERIAL_QCOM_GENI=y and QCOM_GENI_SE=m, there's a build failure. GENI_SE is allowed to be built as a module if serial is not enabled and I2C is built as a module. In order to keep the dependency arrows going in the same direction, you might want the I2C driver to "select QCOM_GENI_SE" as well, in order to upgrade GENI_SE to y if I2C is y. > diff --git a/drivers/tty/serial/qcom_geni_serial.c > b/drivers/tty/serial/qcom_geni_serial.c > new file mode 100644 > index 000..8536b7d > --- /dev/null > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -0,0 +1,1181 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2017-2018, The Linux foundation. All rights reserved. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* UART specific GENI registers */ > +#define SE_UART_TX_TRANS_CFG 0x25c > +#define SE_UART_TX_WORD_LEN0x268 > +#define SE_UART_TX_STOP_BIT_LEN0x26c > +#define SE_UART_TX_TRANS_LEN 0x270 > +#define SE_UART_RX_TRANS_CFG 0x280 > +#define SE_UART_RX_WORD_LEN0x28c > +#define SE_UART_RX_STALE_CNT 0x294 > +#define SE_UART_TX_PARITY_CFG 0x2a4 > +#define SE_UART_RX_PARITY_CFG 0x2a8 > + > +/* SE_UART_TRANS_CFG */ > +#define UART_TX_PAR_EN BIT(0) > +#define UART_CTS_MASK BIT(1) > + > +/* SE_UART_TX_WORD_LEN */ > +#define TX_WORD_LEN_MSKGENMASK(9, 0) > + > +/* SE_UART_TX_STOP_BIT_LEN */ > +#define TX_STOP_BIT_LEN_MSKGENMASK(23, 0) > +#define TX_STOP_BIT_LEN_1 0 > +#define TX_STOP_BIT_LEN_1_51 > +#define TX_STOP_BIT_LEN_2 2 > + > +/* SE_UART_TX_TRANS_LEN */ > +#define TX_TRANS_LEN_MSK GENMASK(23, 0) > + > +/* SE_UART_RX_TRANS_CFG */ > +#define UART_RX_INS_STATUS_BIT BIT(2) > +#define UART_RX_PAR_EN BIT(3) > + > +/* SE_UART_RX_WORD_LEN */ > +#define RX_WORD_LEN_MASK GENMASK(9, 0) > + > +/* SE_UART_RX_STALE_CNT */ > +#define RX_STALE_CNT GENMASK(23, 0) > + > +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */ > +#define PAR_CALC_ENBIT(0) > +#define PAR_MODE_MSK GENMASK(2, 1) > +#define PAR_MODE_SHFT 1 > +#define PAR_EVEN 0x00 > +#define PAR_ODD0x01 > +#define PAR_SPACE 0x10 > +#define PAR_MARK 0x11 > + > +/* UART M_CMD OP codes */ > +#define UART_START_TX 0x1 > +#define UART_START_BREAK 0x4 > +#define UART_STOP_BREAK0x5 > +/* UART S_CMD OP codes */ > +#define UART_START_READ0x1 > +#define UART_PARAM 0x1 > + > +#define UART_OVERSAMPLING 32 > +#define STALE_TIMEOUT 16 > +#define DEFAULT_BITS_PER_CHAR 10 > +#define GENI_UART_CONS_PORTS 1 > +#define DEF_FIFO_DEPTH_WORDS 16 > +#define DEF_TX_WM 2 > +#define DEF_FIFO_WIDTH_BITS32 > +#define UART_CONSOLE_RX_WM 2 > + > +#ifdef CONFIG_CONSOLE_POLL > +#define RX_BYTES_PW 1 > +#else > +#define RX_BYTES_PW 4 > +#endif This seems fishy to me. Does either setting work? If so, why not just have one value? > +static bool qcom_gen
Re: [PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver
On 3/2/2018 1:41 PM, Stephen Boyd wrote: Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:07) This driver manages the Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation programmable module composed of multiple Serial Engines (SE) and supports a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This driver also enables managing the serial interface independent aspects of Serial Engines. Signed-off-by: Karthikeyan Ramasubramanian Signed-off-by: Sagar Dharia Signed-off-by: Girish Mahadevan --- drivers/soc/qcom/Kconfig| 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom-geni-se.c | 971 include/linux/qcom-geni-se.h| 247 ++ 4 files changed, 1228 insertions(+) create mode 100644 drivers/soc/qcom/qcom-geni-se.c create mode 100644 include/linux/qcom-geni-se.h diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index e050eb8..cc460d0 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -3,6 +3,15 @@ # menu "Qualcomm SoC drivers" +config QCOM_GENI_SE + tristate "QCOM GENI Serial Engine Driver" + depends on ARCH_QCOM Add || COMPILE_TEST? Ok. + help + This module is used to manage Generic Interface (GENI) firmware based s/module/driver? + Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This + module is also used to manage the common aspects of multiple Serial s/module/driver? Ok. + Engines present in the QUP. + config QCOM_GLINK_SSR tristate "Qualcomm Glink SSR driver" depends on RPMSG diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c new file mode 100644 index 000..61335b8 --- /dev/null +++ b/drivers/soc/qcom/qcom-geni-se.c @@ -0,0 +1,971 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. + +#include +#include +#include +#include +#include +#include +#include +#include #include Ok + +/** + * DOC: Overview + * + * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced + * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper + * controller. QUP Wrapper is designed to support various serial bus protocols + * like UART, SPI, I2C, I3C, etc. + */ + +/** + * DOC: Hardware description + * + * GENI based QUP is a highly-flexible and programmable module for supporting + * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single + * QUP module can provide upto 8 Serial Interfaces, using its internal + * Serial Engines. The actual configuration is determined by the target + * platform configuration. The protocol supported by each interface is + * determined by the firmware loaded to the Serial Engine. Each SE consists + * of a DMA Engine and GENI sub modules which enable Serial Engines to + * support FIFO and DMA modes of operation. + * + * + * +-+ + * |QUP Wrapper | + * | ++ | + * --QUP & SE Clocks--> | Serial Engine N| +-IO--> + * | | ...| | Interface + * <---Clock Perf.+++---+| | + * State Interface || Serial Engine 1|| | + * |||| | + * |||| | + *||| | + * ||++ | + * ||| | + * ||| | + * <--SE IRQ--+++ | + * | | + * +-+ + * + * Figure 1: GENI based QUP Wrapper The code talks about primary and secondary sequencers, but this hardware description doesn't talk about it. Can you add some more information here about that aspect too? Ok. + */ + +/** + * DOC: Software description + * + * GENI SE Wrapper driver is structured into 2 parts: + * + * geni_wrapper represents QUP Wrapper controller. This part of the driver + * manages QUP Wrapper information such as hardware version, clock + * performance table that is common to all the internal Serial Engines. + * + * geni_se represents Serial Engine. This part of the driver manages Serial + * Engine information such as clocks, containing QUP Wrapper etc. This part Insert a comma here ^ Ok. + * of driver a