Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5
On Wed, Dec 2, 2015 at 2:39 AM, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-drivers-4.5 > > for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36: > > pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 > +0900) OK I pulled this into the pinctrl tree, cheers! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add support for monitoring gpio switches
On Wed, Dec 16, 2015 at 11:11 AM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: >> Patches like that has however already been suggested, and I have NACKed >> them because the GPIO sysfs ABI is insane, and that is why I am >> refactoring >> the world to create a proper chardev ABI for GPIO instead. See: >> http://marc.info/?l=linux-gpio=144550276512673=2 > > I can certainly understand the rationale for the changes that you are > proposing, though do worry that it does make it a bit tougher to use from > scripting languages. The idea is to provide commandline tools in the kernel tools/gpio subdir to satisfy the needs of scripting. "lsgpio" today is just one example, nothing stops us from having a tool called just "gpio-sak" (GPIO swiss army knife) that will be tailored for scripting. > I see that the question of how to provide functionality > equivalent to the above was raised and no answer was forthcoming. Is there a > plan for supporting the identification of a GPIO line serving a specific > purpose? Yes by name. > What is the status of the mentioned patch series? They stubled into a few dozen architecture issues in the GPIO subsystem so I am busy refactoring the whole know universe :D But I still intend to persue the series. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Device tree binding documentation for gpio-switch
On Fri, Dec 11, 2015 at 3:06 PM, Rob Herring <robh...@kernel.org> wrote:
> On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij <linus.wall...@linaro.org>
> wrote:
>> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>> <martyn.we...@collabora.co.uk> wrote:
>>
>>> This patch adds documentation for the gpio-switch binding. This binding
>>> provides a mechanism to bind named links to gpio, with the primary
>>> purpose of enabling standardised access to switches that might be standard
>>> across a group of devices but implemented differently on each device.
>>>
>>> Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk>
>>
>> As mentioned in the comment to the second patch, this solves the
>> following generic problem:
>>
>> Expose a GPIO line to userspace using a specific name
>>
>> That means basically naming GPIO lines and marking them as
>> "not used by the operating system".
>>
>> This is something that has been proposed before, and postponed
>> because the kernel lacks the right infrastructure.
>
> That doesn't necessarily mean we can't define a binding.
Yeah that's true. just saying that the other stuff was not merged
for this reason, but then we can have a look at Markus' bindings
in parallell, Markus can you repost them to this audience? Only
the bindings I mean.
>> Markus Pargmann also did a series that add initial values to
>> hogs, which is the inverse usecase of this, where you want to
>> *output* something by default, then maybe also make it available
>> to userspace.
>>
>> So what we need to see here is a patch series that does all of these
>> things:
>>
>> - Name lines
>>
>> - Sets them to initial values
>>
>> - Mark them as read-only
>>
>> - Mark them as "not used by the operating system" so that they
>> can be default-exported to userspace.
>
> No! This should not be a DT property.
>
> Whether I want to control a GPIO in the kernel or userspace is not
> known and can change over time. It could simply depend on kernel
> config. There is also the case that a GPIO has no connection or kernel
> driver until some time later when a DT overlay for an expansion board
> is applied.
That's correct. So from a DT point of view, what really matters is
to give things a name, and the hogs and initvals syntax already
has a structure for this that is in use
(from Documentation/devicetree/bindings/gpio/gpio.txt):
qe_pio_a: gpio-controller@1400 {
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;
line_b {
gpio-hog;
gpios = <6 0>;
output-low;
line-name = "foo-bar-gpio";
};
};
Markus use this also for initial values. That could easily be used in
a budget version like this:
line_b {
/* Just naming */
gpios = <6 0>;
line-name = "foo-bar-gpio";
};
That could grow kind of big though. Or maybe not? How many
GPIO lines are actually properly named in a typical system?
The problem is that naming is usually imposed by consumers (they
are the ones who know how the line is used).
And then I do not mean naming it after the pin on the capsule
where it comes out as per the datasheet, but
naming it after the actual use.
Naming it after the hardware specs is something the operating
system can do, in Linux' case by the array char *names; inside the
struct gpio_chip and should not be part of the bindings IMO.
I would rather imagine this is something used in a top-level board
file naming it: "header-2-22" for the 22nd pin on some second header
on my BeagleBone Black or something like that. And those may not
be so vast in numbers so they could be named using this pattern.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct
On Thu, Dec 10, 2015 at 12:08 AM, Michael Welling <mwell...@ieee.org> wrote:
> On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
> ...
>> - ret = gpiochip_add(>gc);
>> + ret = gpiochip_add_data(gc, NULL);
>> if (ret) {
>
> gpiochip_add is still mentioned in the dev_err below.
I explicitly left text string updates aside, I am anyways going to have to go
over all drivers for a second refactoring with gpiodev_alloc() etc.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Device tree binding documentation for gpio-switch
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
<martyn.we...@collabora.co.uk> wrote:
> This patch adds documentation for the gpio-switch binding. This binding
> provides a mechanism to bind named links to gpio, with the primary
> purpose of enabling standardised access to switches that might be standard
> across a group of devices but implemented differently on each device.
>
> Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk>
As mentioned in the comment to the second patch, this solves the
following generic problem:
Expose a GPIO line to userspace using a specific name
That means basically naming GPIO lines and marking them as
"not used by the operating system".
This is something that has been proposed before, and postponed
because the kernel lacks the right infrastructure.
Markus Pargmann also did a series that add initial values to
hogs, which is the inverse usecase of this, where you want to
*output* something by default, then maybe also make it available
to userspace.
So what we need to see here is a patch series that does all of these
things:
- Name lines
- Sets them to initial values
- Mark them as read-only
- Mark them as "not used by the operating system" so that they
can be default-exported to userspace.
Making *USE* of this naming etc inside the Linux kernel
> +gpio-switch {
> +compatible = "gpio-switch";
> +
> +write-protect {
> +label = "write-protect";
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +read-only;
> +};
This should not need new structures and nodes like this. It should
be part of Documentation/devicetree/bindings/gpio/gpio.txt
and put directly in the gpiochip node.
Maybe as an extension of the existing hogs, but that has already
been tried.
While we can agree on a device tree binding, the kernel still needs
major refactoring to actually expose named GPIOs to userspace,
and that should be done using the new chardev, not with sysfs
links.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add support for monitoring gpio switches
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: > Select Chromebooks have gpio attached to switches used to cause the > firmware to enter alternative modes of operation and/or control other > device characteristics (such as write protection on flash devices). This > patch adds a driver that exposes a read-only interface to allow these > signals to be read from user space. > > This functionality has been generalised to provide support for any device > with device tree support which needs to identify a gpio as being used for a > specific task. > > Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk> If you want to do this thing, also propose a device tree binding document for "gpio-switch". But first (from Documentation/gpio/drivers-on-gpio.txt): - gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line can generate interrupts in response to a key press. Also supports debounce. - gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your GPIO line cannot generate interrupts, so it needs to be periodically polled by a timer. - extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an external connector status, such as a headset line for an audio driver or an HDMI connector. It will provide a better userspace sysfs interface than GPIO. So you mean none of these apply for this case? Second: what you want to do is export a number of GPIOs with certain names to userspace. This is something very generic and should be implemented as such, not as something Chromebook-specific. Patches like that has however already been suggested, and I have NACKed them because the GPIO sysfs ABI is insane, and that is why I am refactoring the world to create a proper chardev ABI for GPIO instead. See: http://marc.info/?l=linux-gpio=144550276512673=2 So for the moment, NACK on this, please participate in creating the *right* ABI for GPIO instead of trying to shoehorn stuff into the dying sysfs ABI. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] pinctrl: samsung: Remove unneded semicolon
On Wed, Sep 16, 2015 at 1:28 AM, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > It's not needed an is just creating a null statement, so remove it. > > Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> Patch applied with Krzysztof's Review-tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] Watchdog: Fix parent of watchdog_devices
On Tue, Aug 18, 2015 at 6:34 PM, Pratyush Anand pan...@redhat.com wrote: /sys/class/watchdog/watchdogn/device/modalias can help to identify the driver/module for a given watchdog node. However, many wdt devices does not set its parent and so, we do not see an entry for device in sysfs for such devices. This patch fixes parent of watchdog_device so that /sys/class/watchdog/watchdogn/device is populated. Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do not have any parent. Not sure, how we can we identify driver for these devices. Signed-off-by: Pratyush Anand pan...@redhat.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] pinctrl: kill off set_irq_flags usage
On Mon, Jul 27, 2015 at 10:55 PM, Rob Herring r...@kernel.org wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also modify IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring r...@kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Lee Jones l...@kernel.org Cc: Matthias Brugger matthias@gmail.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux-g...@vger.kernel.org Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- Thomas asked that this be merged thru subsystem trees instead of arm-soc, so please apply this to your tree. Patch applied, and thanks for driving this. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: pinctrl: Move Thomas Abraham to CREDITS
On Tue, Jul 28, 2015 at 10:21 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Thomas Abraham's Linaro email address bounces for several months. Also there were no replies for several emails sent on LKML to his Samsung address. Move his name to CREDITS. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org Link: http://lkml.org/lkml/2015/6/15/15 Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/2] pinctrl: samsung: don't truncate the last char
On Mon, Jun 22, 2015 at 5:12 PM, Dan Carpenter dan.carpen...@oracle.com wrote: We were allocating enough space because sizeof(-grp) and sizeof(-mux) are both equal to 5 but in the snprintf() we only allowed for 4 characters so the last 'p' and 'x' characters were truncated. The allocate and sprintf can be done in one step with the kasprintf(). Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Patch applied with Krzysztof's review tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Remove old unused defines
On Mon, Jun 15, 2015 at 6:54 AM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Since 9a2c1c3b91aa (pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes) the defines for GPIO group and function names are not used anywhere in the driver. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Inspired-by: Dan Carpenter dan.carpen...@oracle.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler hol...@ahsoftware.de wrote: And because you've said that problem space is a bit convoluted and I disagree, here's a summary from my point of view: 1. All the necessary information (dependencies between drivers) already exists at compile time. The set of dependencies between drivers might become smaller by configuration, but will not become larger. So there should be NO need to collect them at runtime, e.g. by instrumenting function calls. I think you arrived at the core of the crux here. When we look up a resource provided from another driver, e.g. from regulator_get(), clk_get(), pinctrl_get(), gpiod_get() etc - the dependency is resolved by looking in a cross-reference table for either a struct device* pointer or a string, an index, or both or all three. Examples: struct regulator *regulator_get(struct device *dev, const char *id); struct clk *clk_get(struct device *dev, const char *id); struct gpio_desc *__must_check __gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags); (...) (*_index() variants exist on some of the resource retrieveal functions.) struct device * is the device requesting the resource, con_id is the string name of the resource on the provider side. This is all solved by looking in cross reference tables. ONE way of resolving that cross reference is to look into the device tree or the ACPI table. But for the board file case, this is resolved at runtime by the cross reference table, registered with calls such as gpiod_add_lookup_table(). It is true that in the theoretical sense, all of this exist at compile time especially if you can parse something like a device tree and figure out what struct device * nodes will correspond to the struct device_node:s in it. For ACPI I guess a similar procedure is viable. Problem: this requires the kernel compile to know exactly *which* device tree or ACPI table it is going to boot on. The expressed goal of device tree and ACPI is to have *ONE* kernel booting several device trees. Here your approach stops short: you are suggesting instrumenting the kernel at compile time to one single device tree or ACPI table. But we never know really what device tree or ACPI table will be used. This just cannot be done at compile time for that reason alone. Example: in boot case (A) the regulator may be provided by regulator foo driver on an i2c bus. But in boot case (B) the very same regulator may be provided by regulator bar on an SPI bus. These are very real usecases, for example for drivers/net/ethernet/smsc/smsc911x.c, will get regulators from the most diverse places depending on what device tree is used. For board files, it is neither possible in theory: you need to compile the code to figure out the struct device * provider, and/or the string name of the providing device (.name field in struct device for the provider) to resolve dependencies at compile time. For the board file case, resolving dependencies at compile time will require a quite complex two-stage rocket: compile the code to get resources out, then recompile with known resources. I guess your suggested approach then need to introduce a special build tool to order the initcalls accordingly. Again this will fall short if you don't know at compile time exactly *which* board file will be executed. So the only practical way to solve this at compile time is to predict an initcall ordering sequence for all possible boot paths, compile in all of them, and choose the right one at boot. But the number of boot paths is equal to the number of device trees / ACPI tables or board files supported, and that space is uncontrolled and ordered infinite. Basically I think the root problem with your approach is that you assume we know what hardware we will boot on at compile time. We discarded that development path years ago. We have no clue, this is resolved at runtime. Alas, people still create super-optimized systems using exactly this knowledge, but it is not our main target here, it is a special optimization case. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.06.2015 um 14:30 schrieb Linus Walleij: Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system. IAnd what happens if you run into a deadlock? Do you print you've lost, try changing your kernel config in some output hidden by a splash-screen? ;) Sorry it sounds like a blanket argument, the fact that there are mutexes in the kernel makes it possible to deadlock, it doesn't mean we don't use mutexes. Some programming problems are just like such. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.06.2015 um 10:12 schrieb Linus Walleij: On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de wrote: You would end up with the same problem of deadlocks as currently, and you would still need something ugly like the defered probe brutforce to avoid them. Sorry I don't get that. Care to elaborate on why? Because loading/initializing on demand doesn't give you any solved order of drivers to initialize. And it can't because it has no idea about the requirements of other drivers. The reason why it might work better in the case of the tegra is that it might give you another initialization order than the one which is currently choosen, which, by luck, might be a better one. But maybe I missed something, I haven't looked at the patches at all. But just loading on demand, can't magically give you a working order of drivers to initialize. E.g. how do you choose the first driver to initialize? So the current patch set introduces dependencies (just for device tree) and Tomeu is working on a more generic dependency approach for any HW description. The first driver to initialize will be as usual the first one in the list for that initlevel, then walking up the initilevels. However if any driver runs into a resource roadblock it will postpone and wait for dependencies to probe first. Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de wrote: Am 10.06.2015 um 09:30 schrieb Linus Walleij: i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. You would end up with the same problem of deadlocks as currently, and you would still need something ugly like the defered probe brutforce to avoid them. Sorry I don't get that. Care to elaborate on why? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get - of_platform_device_ensure - probe() on the platform device that encloses the requested device node (i2c host) - i2c slave gets probed and the regulator registered - regulator_get returns the requested resource Yes. But only for device tree. The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. Unbind/remove() calls are the inverse usually yes. But also the [runtime] power up/down sequences for the devices tend to depend on a similar ordering or mostly the same. (Mentioned this before I think.) This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. Yes you are right. But what about ACPI, board files, Simple Firmware and future hardware description languages... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote: This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Deepest respect for your efforts! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] pinctrl: kill off set_irq_flags usage
On Tue, Jun 9, 2015 at 8:26 PM, Rob Herring r...@kernel.org wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also set IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring r...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Lee Jones l...@kernel.org Cc: Matthias Brugger matthias@gmail.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux-g...@vger.kernel.org Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/21] On-demand device registration
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by registering devices as they are referenced by other devices. This is pretty cool, but a too local solution to a global problem. Deferred probe and initcall reordering, silly as they may seem, does not require you to use device tree. The real solution, which I think I pointed out already when we added deferred probe, is to put dependency graphs in the drivers and have the kernel device driver core percolate dependecies by walking the graph on probing driver, removing driver (usually the inverse use case), [runtime] suspend and [runtime] resumeing a driver. Possibly the dependencies will even be different depending on use case. This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) So if this should be solved it should be solved in an abstract way in the device driver core available for all, then have calls calling out to DT, ACPI, possibly even PCI or USB (as these enumerate devices themselves) to obtain a certain dependency. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RFT: pinctrl: samsung: separate wakeup irqdomain
The Samsung pin control driver and subdrivers sometimes use both
an irqdomain for some IRQs and another irqdomain for wakeup irqs,
registering the first with a call to the per-SoC callback
.eint_gpio_init() and the second with a call to .eint_wkup_init()
however it seems both runpaths will assign the resulting irqdomain
to the per-bank bank.irq_domain member, making the second
(wakeup) irqdomain overwrite the first one.
I'm surprised this even works, and it seems that the S3C
per-domain domain data that seems to be used in part to work
around this bug by creating a local array with copies of the
irqdomain (!).
This patch mainly adds a new record to the GPIO/pin bank
for wakeups and use this in the .eint_wkup_init() callbacks
to pave the way for more cleanups.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Tomasz etc: I don't know if I'm just misunderstanding this,
can you look at it and tell me how badly I misunderstand
these Samsung wakeups, to me it is a complete mystery.
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 6 +++---
drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 6 +++---
drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 6 +++---
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index c8f83f96546c..6adf34e3cce6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -469,7 +469,7 @@ static void exynos_irq_demux_eint16_31(unsigned int irq,
struct irq_desc *desc)
+ b-eint_offset);
mask = readl(d-virt_base + b-irq_chip-eint_mask
+ b-eint_offset);
- exynos_irq_demux_eint(pend ~mask, b-irq_domain);
+ exynos_irq_demux_eint(pend ~mask, b-wkup_domain);
}
chained_irq_exit(chip, desc);
@@ -511,9 +511,9 @@ static int exynos_eint_wkup_init(struct
samsung_pinctrl_drv_data *d)
if (bank-eint_type != EINT_TYPE_WKUP)
continue;
- bank-irq_domain = irq_domain_add_linear(bank-of_node,
+ bank-wkup_domain = irq_domain_add_linear(bank-of_node,
bank-nr_pins, exynos_eint_irqd_ops, bank);
- if (!bank-irq_domain) {
+ if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index f1993f42114c..1dd1e5a0ed58 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -539,9 +539,9 @@ static int s3c24xx_eint_init(struct
samsung_pinctrl_drv_data *d)
ops = (bank-eint_offset == 0) ? s3c24xx_gpf_irq_ops
: s3c24xx_gpg_irq_ops;
- bank-irq_domain = irq_domain_add_linear(bank-of_node,
+ bank-wkup_domain = irq_domain_add_linear(bank-of_node,
bank-nr_pins, ops, ddata);
- if (!bank-irq_domain) {
+ if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
@@ -553,7 +553,7 @@ static int s3c24xx_eint_init(struct
samsung_pinctrl_drv_data *d)
break;
if (!(mask 1))
continue;
- eint_data-domains[irq] = bank-irq_domain;
+ eint_data-domains[irq] = bank-wkup_domain;
++irq;
}
}
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index 7756c1e9e763..9701424a8bea 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -757,9 +757,9 @@ static int s3c64xx_eint_eint0_init(struct
samsung_pinctrl_drv_data *d)
}
ddata-bank = bank;
- bank-irq_domain = irq_domain_add_linear(bank-of_node,
+ bank-wkup_domain = irq_domain_add_linear(bank-of_node,
nr_eints, s3c64xx_eint0_irqd_ops, ddata);
- if (!bank-irq_domain) {
+ if (!bank-wkup_domain) {
dev_err(dev, wkup irq domain add failed\n);
return -ENXIO;
}
@@ -769,7 +769,7 @@ static int s3c64xx_eint_eint0_init(struct
samsung_pinctrl_drv_data *d)
for (pin = 0; mask; ++pin, mask = 1) {
if (!(mask 1))
continue;
- data-domains[irq] = bank-irq_domain;
+ data-domains[irq] = bank-wkup_domain
Re: [PATCH] pinctrl: exynos: Remove eint_gpio_init call-back for exynos7 alive pinctrl block
On Sun, Mar 1, 2015 at 5:21 PM, Abhilash Kesavan a.kesa...@samsung.com wrote: The alive pin controller on exynos7 does not support external gpio interrupts. Hence, remove the eint_gpio_init call-back for it. This fixes the following error message seen during exynos7 boot-up: samsung-pinctrl 1058.pinctrl: irq number not available Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Patch applied with Tomasz ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: exynos: Remove eint_gpio_init call-back for exynos7 alive pinctrl block
On Sun, Mar 1, 2015 at 5:21 PM, Abhilash Kesavan a.kesa...@samsung.com wrote: The alive pin controller on exynos7 does not support external gpio interrupts. Hence, remove the eint_gpio_init call-back for it. This fixes the following error message seen during exynos7 boot-up: samsung-pinctrl 1058.pinctrl: irq number not available Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Tomasz, can you look at this patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] pinctrl: exynos: Add support for Exynos5433
On Tue, Feb 24, 2015 at 3:47 AM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi- functional input/output port pins and 135 memory port pins. There are 41 general port groups and 2 memory port groups. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Tomasz Figa tomasz.f...@gmail.com --- Changes from v3: - Rebase it on Linux 4.0-rc1 - Add acked messgae of Tomasz Figa Already merged v3. Thanks anyway! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] pinctrl: exynos: Add support for Exynos5433
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi- functional input/output port pins and 135 memory port pins. There are 41 general port groups and 2 memory port groups. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com --- Changes from v2: - Rebase it on v3.19-rc5 Patch applied with Tomasz ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] pinctrl: exynos: Add support for Exynos5433
On Wed, Jan 21, 2015 at 7:43 AM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi- functional input/output port pins and 135 memory port pins. There are 41 general port groups and 2 memory port groups. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com --- Changes from v2: - Rebase it on v3.19-rc5 Waiting for Tomasz to review this. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: exynos: Add AUDIO pin controller for exynos7
On Wed, Jan 14, 2015 at 3:27 PM, Tomasz Figa tomasz.f...@gmail.com wrote: 2015-01-14 20:40 GMT+09:00 Linus Walleij linus.wall...@linaro.org: On Fri, Dec 19, 2014 at 2:10 PM, Padmavathi Venna padm...@samsung.com wrote: Audio IPs on Exynos7 require gpios available in AUDIO pin controller block. So adding the AUDIO pinctrl support. Signed-off-by: Padmavathi Venna padm...@samsung.com (...) --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -181,6 +181,7 @@ Aliases for controllers compatible with samsung,exynos7-pinctrl: - pinctrl6: pin controller of FSYS0 block, - pinctrl7: pin controller of FSYS1 block, - pinctrl8: pin controller of BUS1 block, +- pinctrl9: pin controller of AUDIO block, This doesn't apply at all, the list has never been in the document merged upstream. I believe this patch depends on patch [1], which was mentioned in cover letter and which you seem to have applied two days ago. If it still doesn't apply, please let me know if I should collect the patches myself and prepare a pull request for you. [1] https://patchwork.kernel.org/patch/5467321/ It applied when I tried it now, sorry I must have screwed up or something :( Patch applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: exynos: Add AUDIO pin controller for exynos7
On Fri, Dec 19, 2014 at 2:10 PM, Padmavathi Venna padm...@samsung.com wrote: Audio IPs on Exynos7 require gpios available in AUDIO pin controller block. So adding the AUDIO pinctrl support. Signed-off-by: Padmavathi Venna padm...@samsung.com (...) --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -181,6 +181,7 @@ Aliases for controllers compatible with samsung,exynos7-pinctrl: - pinctrl6: pin controller of FSYS0 block, - pinctrl7: pin controller of FSYS1 block, - pinctrl8: pin controller of BUS1 block, +- pinctrl9: pin controller of AUDIO block, This doesn't apply at all, the list has never been in the document merged upstream. Please prepare this patch rebased on a *CLEAN* upstream tree and resend. Include Tomasz ACK on your repost. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote: USB and Power regulator on Exynos7 require gpios available in BUS1 pin controller block. So adding the BUS1 pinctrl support. Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org --- Changes since V2: - Added documentation on alias for BUS1 pin controller block. Patch applied with Tomasz ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Adding list of aliases for supported Exynos7 pin controller blocks. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 14/21] ARM: imx6: convert GPC to stacked domains
On Mon, Jan 12, 2015 at 7:26 PM, Marc Zyngier marc.zyng...@arm.com wrote: IMX6 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the fact that the GPC block is actually the first interrupt controller in the chain, kernels with this patch applied wont have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. Tested-by: Stefan Agner ste...@agner.ch Acked-by: Stefan Agner ste...@agner.ch Signed-off-by: Marc Zyngier marc.zyng...@arm.com (...) +static int imx_gpc_domain_alloc(struct irq_domain *domain, + unsigned int virq, Nutcase nitpick on this nice patch series: every time I see virq my OCD triggers, as I think the v in virq stand for virtual. These irqs are no more virtual than any other Linux irq numbers, hwirq is more to the point. I just refer to these as irq (sans v) in any code I write. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 05/15] gpio: move DT parsing code to separate functions
On Wed, Dec 10, 2014 at 4:48 PM, Andrzej Hajda a.ha...@samsung.com wrote: The patch moves Device Tree parsing logic to separate function. Signed-off-by: Andrzej Hajda a.ha...@samsung.com I think this patch need to be rebased on the GPIO devel branch, but looks like it makes things cleaner so can stand on its own merits. We moves stuff around a bit in the OF code though. Please remember to send this patch to the linux-gpio list and comaintainer Alexandre Courbot on reposts. (Cc-tags in the patch are good for this.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated
On Fri, Dec 5, 2014 at 12:00 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The audio subsystem on Exynos 5420 has separate clocks and GPIO. To operate properly on GPIOs the main block clock 'mau_epll' must be enabled. This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0) after introducing runtime PM to pl330 DMA driver. After that commit the 'mau_epll' was gated, because the amba clock was disabled and there were no more users of mau_epll. The system hang just before probing i2s0 because samsung_pinmux_setup() tried to access memory from audss block which was gated. Add a clock property to the pinctrl driver and enable the clock during GPIO setup. During normal GPIO operations (set, get, set_direction) the clock is not enabled. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tomasz, is this OK and should I apply it for fixes or next? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT on s3c24xx
On Thu, Dec 18, 2014 at 9:34 AM, Vasily Khoruzhick anars...@gmail.com wrote: Can I change pin function after gpio was requested? In low-power state (i.e. when display is disabled) it's gpio driving some level, and in active state it's some LCD controller pin (don't remember which one exactly) Please read the section named GPIO mode pitfalls in Documentation/pinctrl.txt very closely. Two ways: - You can use the GPIO and pin control interface to the same hardware in parallel. There is no blocking this since there is hardware out that that actually allow this. NOT RECOMMENDED. - If the GPIO mode mentioned is only about e.g. grounding the pins in a low power state and then not really about using them as GPIO, extend the pin controller to be able to e.g. ground the pins with PIN_CONFIG_OUTPUT or PIN_CONFIG_LOW_POWER_MODE if you use generic bindings. If the usecase is low power, the latter approach is recommended. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Mon, Dec 1, 2014 at 3:21 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij linus.wall...@linaro.org wrote: Apart from that, there are *again* a lot of Exynos patches flying around and I start to loose track of them. If they do not apply together and start to conflict I will just ask Tomasz to stack them and provide a pull request again. True, this merge cycle has surely got number of exynos7 related patches in flight, which are difficult to keep track of. Thanks for asking Tomasz. I will probably not take any more Exynos patches for this merge cycle and ask Tomasz to queue the Exynos pinctrl patches for v3.20 after v3.19 merge cycle is complete, so make sure to include Tomasz on reviews. Tomasz: OK? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 3/5] pinctrl: exynos: add exynos5410 SoC specific data
On Sat, Nov 22, 2014 at 11:26 PM, Andreas Färber afaer...@suse.de wrote:
From: Hakjoo Kim ruppi@hardkernel.com
Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
support for all platforms based on EXYNOS5410.
Signed-off-by: Hakjoo Kim ruppi@hardkernel.com
[AF: Rebased onto Exynos5260 and irq_chip consolidation]
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)
v1 - v2:
* Filled in Sob from Hakjoo Kim
Is this based on the pinctrl devel branch so I can apply it?
I'd like Tomasz ACK on it first though.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 3/5] pinctrl: exynos: Fix GPIO setup failure because domain clock being gated
On Wed, Nov 26, 2014 at 3:24 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The audio subsystem on Exynos 5420 has separate clocks and GPIO. To operate properly on GPIOs the main block clock 'mau_epll' must be enabled. This was observed on Peach Pi/Pit and Arndale Octa (after enabling i2s0) after introducing runtime PM to pl330 DMA driver. After that commit the 'mau_epll' was gated, because the amba clock was disabled and there were no more users of mau_epll. The system hang just before probing i2s0 because samsung_pinmux_setup() tried to access memory from audss block which was gated. Add a clock property to the pinctrl driver and enable the clock during GPIO setup. During normal GPIO operations (set, get, set_direction) the clock is not enabled. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Waiting for Tomasz to review this. Can this patch be applied in separation from the others? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam gautam.vi...@samsung.com wrote: USB and Power regulator on Exynos7 require gpios available in BUS1 pin controller block. So adding the BUS1 pinctrl support. Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org If the change looks good, will it be possible to pick it fo 3.19-rc1 ? That will really help enabling USB IP on exynos7. As you know the Exynos driver has a maintainer, Tomasz Figa, I will not merge patches without his ACK. Apart from that, there are *again* a lot of Exynos patches flying around and I start to loose track of them. If they do not apply together and start to conflict I will just ask Tomasz to stack them and provide a pull request again. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Samsung pinctrl patches for v3.19
On Sun, Nov 9, 2014 at 3:25 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Please consider the following pull request containing queued changes for pinctrl-samsung driver. Thanks, pulled! I'm sorry for all the delays in handling this. Things should get better from now on, though. IIUC you are a hobbyist maintainer now, and then I will tolerate a *lot* more than this, that is one of the privileges that comes with that role, haha :D Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] Add initial support for pinctrl on Exynos7
On Fri, Oct 24, 2014 at 4:33 PM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: On Fri, Oct 24, 2014 at 5:31 PM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Oct 20, 2014 at 4:01 PM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: Can you please pick this series up. Yes, sorry for the delay. I've applied patches 1,2,3,4. The patches to the DTS files should be taken through whatever tree funnels arm64 dts files. Thank you for applying my patches. However, this version (v5) was based on Tomasz's clean-up series (...) And Tomasz series had other problems. So now I took everything out and asked Tomasz to get a pull request for the stuff instead. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] Add initial support for pinctrl on Exynos7
On Mon, Oct 20, 2014 at 4:01 PM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: Can you please pick this series up. Yes, sorry for the delay. I've applied patches 1,2,3,4. The patches to the DTS files should be taken through whatever tree funnels arm64 dts files. I hope Tomasz can rebase his nice clean-up patches on top of this now. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/5] pinctrl: samsung: Data structure clean-up
On Wed, Oct 8, 2014 at 12:23 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This series intends to clean up data structures used by pinctrl-samsung driver. More specifically, it separates initial compile time constants from data used at runtime, allowing unused variant data to be dropped and selected structures constified to improve safety. Thanks! The patches missed the v3.18 merge window, but I have queued them up as the first thing to go into v3.19. I wrote somewhere else that this exploded somehow. I've merged Abhilash's patches so now this work needs to be rebased on top of his stuf... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Add initial support for pinctrl on Exynos7
On Mon, Oct 6, 2014 at 5:42 AM, Abhilash Kesavan kesavan.abhil...@gmail.com wrote: On Tue, Sep 30, 2014 at 8:00 PM, Abhilash Kesavan a.kesa...@samsung.com wrote: Changes since v3: - Changed variable name from exynos_wkup_irq_chip to irq_chip - Added acked-by tag from Tomasz Figa Changes since v2: - Added a .irq_chip field to the samsung_pin_bank struct - Consolidated the wakeup and gpio irqd_ops Changes since v1: - Marked the newly created irq_chip instances as __initdata - Used kmemdup to keep a copy of the irq_chip - Change the pinctrl name from sd0_rdqs to sd0_ds as per UM - Moved the pinctrl enablement for exynos7 into a separate patch - Added tested-by and reviewed-by tags from Thomas Abraham OK... Does this series look OK to you ? I'm waiting for review comments form Tomasz Figa. I have just applied his 5 refactoring patches as the first base for v3.19, I don't know if this stuff will fit nicely on top of these or not, expect to find out during review. Tomasz patches have priority since they have been in-flight for a while and he is listed as maintainer for this driver. So could you make sure to get Tomasz review tag and make sure that these patches work on top of his patches? His patches are on my devel branch in the pin control tree, but will not be pushed to linux-next until the merge window ends. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/5] pinctrl: samsung: Data structure clean-up
On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This series intends to clean up data structures used by pinctrl-samsung driver. More specifically, it separates initial compile time constants from data used at runtime, allowing unused variant data to be dropped and selected structures constified to improve safety. Thanks! The patches missed the v3.18 merge window, but I have queued them up as the first thing to go into v3.19. Now I need you to help me check the patch set from Abhilash so I know what to do about that, whenever you have some time... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] pinctrl: samsung: Data structure clean-up
On Sat, Sep 27, 2014 at 2:50 PM, Tomasz Figa tomasz.f...@gmail.com wrote: On 25.09.2014 09:49, Tomasz Figa wrote: On 25.09.2014 09:47, Linus Walleij wrote: On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This series intends to clean up data structures used by pinctrl-samsung driver. More specifically, it separates initial compile time constants from data used at runtime, allowing unused variant data to be dropped and selected structures constified to improve safety. I like the patch set, tried to apply it but patch 3/5 failed to apply to the devel branch for pinctrl. Can you rebase this on my devel branch, include Marek's Tested-by tag and resend, and I'll take it for v3.18. Sure. Will do that today evening. Probably clashed with some other changes queued in the meantime. Uhm. I went back home and forgot about this series until now. Sorry. I have rebased it on your devel branch, although it seems like this branch is missing [1], which in turn seems to be already present in your for-next branch and is going to cause a merge conflict with this series. Should I still proceed with posting the series based on devel? [1] f6a8249f9e55d pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs Bah I must have accidentally applied the patch to my for-next branch instead of devel, and then wiped it out of existence when I later reset the for-next branch to devel. Please resend all 5 rebased on devel. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] pinctrl: samsung: Data structure clean-up
On Tue, Sep 23, 2014 at 9:05 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This series intends to clean up data structures used by pinctrl-samsung driver. More specifically, it separates initial compile time constants from data used at runtime, allowing unused variant data to be dropped and selected structures constified to improve safety. I like the patch set, tried to apply it but patch 3/5 failed to apply to the devel branch for pinctrl. Can you rebase this on my devel branch, include Marek's Tested-by tag and resend, and I'll take it for v3.18. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] kbuild: remove unnecessary variable initializaions
On Tue, Sep 9, 2014 at 12:26 PM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Clearing obj-y, obj-m, obj-n, obj- in each Makefile is a useless habit. They are non-exported variables; therefore they are always empty whenever descending into each subdirectory. (Moreorver, obj-y and obj-m are also set to empty at the beginning of scripts/Makefile.build) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/5] pinctrl: exynos: Generalize the eint16_31 demux code
On Tue, Sep 23, 2014 at 10:16 AM, Abhilash Kesavan a.kesa...@samsung.com wrote: The function exynos_irq_demux_eint16_31 uses pre-defined offsets for external interrupt pending status and mask registers. So this function is not extensible for Exynos7 SoC which have these registers at different offsets. So generalize the exynos_irq_demux_eint16_31 function by using the pending/mask register offset values from the exynos_irq_chip structure. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Reviewed-by: Thomas Abraham thomas...@samsung.com Tested-by: Thomas Abraham thomas...@samsung.com Cc: Thomas Abraham thomas...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org I'm waiting for the maintainers to ACK these patches before I take them. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Tomasz has moved
On Tue, Aug 26, 2014 at 4:30 PM, Tomasz Figa t.f...@samsung.com wrote: I am leaving Samsung, so my current e-mail address is not going to work any longer. Replace it with my private one. In addition, Sylwester Nawrocki is being added as co-maintainer for Samsung clock drivers to take some of the responsibilities, as I will be doing my part in my spare time. Signed-off-by: Tomasz Figa t.f...@samsung.com OK I'm taking this patch through pinctrl fixes. Not much controversy here, Mike you need not worry about it. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile
On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Samsung Exynos7 is a ARM64bit processor. Which does not select the CONFIG_PLAT_SAMSUNG symbol. CONFIG_PINCTRL_SAMSUNG is being selected for both PLAT_SAMSUNG and ARCH_EXYNOS7 symbols. This patch modifes the pinctrl/Makefile to use CONFIG_PINCTRL_SAMSUNG symbol to compile the pinctrl/samsung/*.c Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Tomasz Figa t.f...@samsung.com Cc: linus.wall...@linaro.org Cc: Thomas Abraham thomas...@samsung.com Excellent catch, thanks, patch applied! I should use this pattern on more places in the Makefile, I was confused by logically thinking that Kconfig symbols used in Makefile cannot be from a Kconfig one level below. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
On Fri, Aug 8, 2014 at 6:48 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
From: Tomasz Figa t.f...@samsung.com
Currently after configuring a GPIO pin as an interrupt related pinmux
registers are changed, but there is no protection from calling
gpio_direction_*() in a badly written driver, which would cause the same
pinmux register to be reconfigured for regular input/output and this
disabling interrupt capability of the pin.
This patch addresses this issue by moving pinmux reconfiguration to
.irq_{request,release}_resources() callback of irq_chip and calling
gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.
Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
in addition to trigger configuration in a dedicated register, the pinmux
must be also reconfigured to GPIO interrupt, which is a different function
than normal GPIO input, although I/O-wise they both behave in the same way
and gpio_get_value() can be used on a pin configured as IRQ as well.
Such design implies subtleties such as gpio_direction_input() not having
to fail if a pin is already configured as an interrupt nor change the
configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
gpio_lock_as_irq() is only used to check that gpio_direction_output() is
not called, it's not used to prevent gpio_direction_input() to be called.
So this is not a complete solution for Samsung SoCs but it's definitely a
move in the right direction.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[javier: use request resources instead of startup and expand commit message]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
OK patch applied for fixes, sorry for missing to follow up on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting
I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c? Or else I'm not really following this... $SUBJECT is a bit confusing. On Sat, Aug 9, 2014 at 12:26 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Regardless of this though I think that both the patch to move the IRQ pinmux setup from .irq_set_type to the .irq_request_resources and the patch to to prevent any pinmux reconfiguration are good improvements to avoid future issues like the one we found here. I think someone should look into switching the Samsung/Exynos pinctrl driver to the gpiolib irqchip helpers, I looked at it but was scared by the special wkup chip and stuff I can't test. The irqchip helpers will atleast help out in flagging GPIO lines as used for IRQs so the core can keep track of stuff and show that properly in debugfs. The orthogonality compliance between GPIO and irqchip must however be solved in the driver itself, the core only helps out in blocking some abuse of the API. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
On Sat, Aug 9, 2014 at 1:48 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
From: Tomasz Figa t.f...@samsung.com
Currently after configuring a GPIO pin as an interrupt related pinmux
registers are changed, but there is no protection from calling
gpio_direction_*() in a badly written driver, which would cause the same
pinmux register to be reconfigured for regular input/output and this
disabling interrupt capability of the pin.
This patch addresses this issue by moving pinmux reconfiguration to
.irq_{request,release}_resources() callback of irq_chip and calling
gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.
Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
in addition to trigger configuration in a dedicated register, the pinmux
must be also reconfigured to GPIO interrupt, which is a different function
than normal GPIO input, although I/O-wise they both behave in the same way
and gpio_get_value() can be used on a pin configured as IRQ as well.
Such design implies subtleties such as gpio_direction_input() not having
to fail if a pin is already configured as an interrupt nor change the
configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
gpio_lock_as_irq() is only used to check that gpio_direction_output() is
not called, it's not used to prevent gpio_direction_input() to be called.
So this is not a complete solution for Samsung SoCs but it's definitely a
move in the right direction.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[javier: use request resources instead of startup and expand commit message]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This patch solves the issue explained in https://lkml.org/lkml/2014/8/8/461
Hm, this looks much better atleast, it is not possible to use the
irqchip helpers from gpiolib then, because that grabs the request/release
resource callbacks.
If I get some ACKs on this we can go for this solution.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/5] pinctrl: exynos: add exynos5410 SoC specific data
On Mon, Jul 28, 2014 at 2:18 PM, Andreas Färber afaer...@suse.de wrote: From: Hakjoo Kim ruppi@hardkernel.com Add Samsung EXYNOS5410 SoC specific data to enable pinctrl support for all platforms based on EXYNOS5410. Cc: Hakjoo Kim ruppi@hardkernel.com [AF: Rebased onto Exynos5260] I'm waiting for Tomasz to review this before applying. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 08/24] mfd: max77686: Add Dynamic Voltage Scaling (DVS) support
On Fri, Jul 4, 2014 at 10:24 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Some regulators on the MAX77686 PMIC have Dynamic Voltage Scaling
(DVS) support that allows output voltage to change dynamically.
For MAX77686, these regulators are Buck regulators 2, 3 and 4.
Each Buck output voltage is selected using a set of external
inputs: DVS1-3 and SELB2-4.
DVS registers can be used to configure the output voltages for each
Buck regulator and which one is active is controled by DVSx lines.
SELBx lines are used to control if individual Buck lines are ON or OFF.
This patch adds support to configure the DVSx and SELBx lines
from DT and to setup and read the GPIO lines connected to them.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
(...)
+#include linux/gpio/consumer.h
THANKS for using modern interfaces!
+static void max77686_dt_parse_dvs_gpio(struct device *dev)
+{
+ struct max77686_platform_data *pd = dev_get_platdata(dev);
+ int i;
+
+ /*
+* NOTE: we don't consider GPIO errors fatal; board may have some
lines
+* directly pulled high or low and thus doesn't specify them.
+*/
+ for (i = 0; i ARRAY_SIZE(pd-buck_gpio_dvs); i++)
+ pd-buck_gpio_dvs[i] =
+ devm_gpiod_get_index(dev, max77686,pmic-buck-dvs,
i);
+
+ for (i = 0; i ARRAY_SIZE(pd-buck_gpio_selb); i++)
+ pd-buck_gpio_selb[i] =
+ devm_gpiod_get_index(dev, max77686,pmic-buck-selb,
i);
+}
Rob Jones has a patch cooking that adds gpio_get_array() so this thing
merits also adding devm_gpiod_get_array() I think?
+/**
+ * max77686_setup_gpios() - init DVS-related GPIOs
+ * @dev: device whose platform data contains the dvs GPIOs information
+ *
+ * This function claims / initalizations GPIOs related to DVS if they are
+ * defined. This may have the effect of switching voltages if the
+ * pdata-buck_default_idx does not match the boot time state of pins.
+ */
+int max77686_setup_gpios(struct device *dev)
+{
+ struct max77686_platform_data *pd = dev_get_platdata(dev);
+ int buck_default_idx = pd-buck_default_idx;
+ int ret;
+ int i;
+
+ /* Set all SELB high to avoid glitching while DVS is changing */
+ for (i = 0; i ARRAY_SIZE(pd-buck_gpio_selb); i++) {
+ struct gpio_desc *gpio = pd-buck_gpio_selb[i];
+
+ /* OK if some GPIOs aren't defined */
+ if (IS_ERR(gpio))
+ continue;
+
+ ret = gpiod_direction_output_raw(gpio, 1);
Why does this have to be raw? Usually that is not to be used.
Apart from this it looks OK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] pinctrl: samsung: Group all drivers in a sub-dir
On Thu, Jul 10, 2014 at 2:03 PM, Sachin Kamat sachin.ka...@samsung.com wrote: Group all pin control drivers of Samsung platform together in a sub-directory for easy maintenance. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote:
One of remaining limitations of current pinctrl-samsung driver was
the inability to parse multiple pinmux/pinconf group nodes grouped
inside a single device tree node. It made defining groups of pins for
single purpose, but with different parameters very inconvenient.
This patch implements Tegra-like support for grouping multiple pinctrl
groups inside one device tree node, by completely changing the way
pin groups and functions are parsed from device tree. The code creating
pinctrl maps from DT nodes has been borrowed from pinctrl-tegra, while
the initial creation of groups and functions has been completely
rewritten with following assumptions:
- each group consists of just one pin and does not depend on data
from device tree,
- each function is represented by a device tree child node of the
pin controller, which in turn can contain multiple child nodes
for pins that need to have different configuration values.
Device Tree bindings are fully backwards compatible. New functionality
can be used by defining a new pinctrl group consisting of several child
nodes, as on following example:
sd4_bus8: sd4-bus-width8 {
part-1 {
samsung,pins = gpk0-3, gpk0-4,
gpk0-5, gpk0-6;
samsung,pin-function = 3;
samsung,pin-pud = 3;
samsung,pin-drv = 3;
};
part-2 {
samsung,pins = gpk1-3, gpk1-4,
gpk1-5, gpk1-6;
samsung,pin-function = 4;
samsung,pin-pud = 4;
samsung,pin-drv = 3;
};
};
Tested on Exynos4210-Trats board and a custom Exynos4212-based one.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Stephen Warren swar...@nvidia.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Patch applied.
(This decision is mainly based on trust, I got lost in the patch :-)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] pinctrl: samsung: Allow pin value to be initialized using pinfunc
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins, which is useful for pins that are not supposed to be used by any dedicated driver, but need certain board-specific setting. Signed-off-by: Tomasz Figa t.f...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Patch applied. It always makes me a little bit sad that we didn't get generic pin config in place before this driver but now we have to live with it. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add mask-tpm-reset to the device tree
On Thu, Jun 26, 2014 at 11:15 AM, Vikas Sajjan vikas.saj...@samsung.com wrote:
From: Doug Anderson diand...@chromium.org
The mask-tpm-reset GPIO is used by the kernel to prevent the TPM from
being reset across sleep/wake. If we don't set it to anything then
the TPM will be reset. U-Boot will detect this as invalid
and will reset the system on resume time. This GPIO can always be low
and not hurt anything. It will get pulled back high again during a
normal warm reset when it will default back to an input.
To properly preserve the TPM state across suspend/resume and to make
the chrome U-Boot happy, properly set the GPIO to mask the
reset to the TPM.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
(...)
+ /* We need GPX0_6 to be low at sleep time; just keep it low always */
+ mask_tpm_reset_regulator: mask-tpm-reset-regulator {
+ compatible = regulator-fixed;
No matter how the discussion ends up, regulator-fixed is wrong.
Either folding it into the TPM driver or using a separate reset driver
is fine with me.
So what about the generic delayed reset GPIO thing?
http://marc.info/?l=linux-kernelm=140309916607115w=2
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin houch...@gmail.com wrote: The Problem --- The reset signal on a hardware board is send either: - during machine initialization - during bus master's initialization I just thought about this a bit, since there isn't already a generic GPIO reset driver, just call this drivers/reset/reset-gpio.c and make the ability to deferral just a configuration detail of the GPIO reset driver. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] pinctrl: samsung: Decouple direction setting from pinctrl
On Wed, Jul 2, 2014 at 5:40 PM, Tomasz Figa t.f...@samsung.com wrote: This patch makes the pinctrl-samsung driver configure GPIO direction on its own, without using the pinctrl_gpio_direction_*() helpers. The rationale behind this change is as follows: - pinctrl-samsung does not need translation from GPIO namespace to pinctrl namespace to handle GPIO operations - GPIO chip and offset therein are enough to calculate necessary offsets and bit masks in constant time, - the pinctrl_gpio_direction_*() functions do not do anything useful other than translating the pin into pinctrl namespace and calling the .gpio_set_direction() from pinmux_ops of the controller, - the undesirable side effect of using those helpers is losing the ability to change GPIO direction in atomic context, because they explicitly use a mutex for synchronization, Results of this patch are: - fixed warnings about scheduling while atomic in code that needs to set GPIO direction in atomic context (e.g. interrupt handler), - reduced overhead of bitbanging drivers that use gpio_direction_*(), e.g. i2c-gpio. Signed-off-by: Tomasz Figa t.f...@samsung.com Well the cross-call function is actually mostly for the case when the pinctrl and GPIO drivers are in different files, or you combine two IP blocks arbitrarily. It's a bit messy anyway. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] pinctrl: samsung: Handle GPIO request and free using pinctrl helpers
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote: This patch adds .request() and .free() operations to gpio_chip of pinctrl-samsung driver, which call pinctrl request and free helpers to request and free pinctrl pin along with GPIO pin. Signed-off-by: Tomasz Figa t.f...@samsung.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] pinctrl: exynos: Consolidate irq_chips of GPIO and WKUP EINTs
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote: Handling of irq_chip operations for GPIO and WKUP external interrupts is mostly the same, with the difference being offset of registers. However currently the driver has all the code duplicated for both EINT types, which is undesirable, because changes in irq_chip operations have to be done to both instances of the same code. This patch fixes this by creating exynos_irq_chip struct that has normal irq_chip struct embedded and contain differences between particular EINT types, which are three register offsets. One instance of code is removed and the new structure is used instead to fetch necessary data instead of samsung_pin_ctrl struct used previously. While at it, the patch removes Exynos-specific fields from aforementioned structure to improve layering of the driver. Signed-off-by: Tomasz Figa t.f...@samsung.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
On Wed, Jul 2, 2014 at 5:41 PM, Tomasz Figa t.f...@samsung.com wrote: Currently after configuring a GPIO pin as an interrupt related pinmux registers are changed, but there is no protection from calling gpio_direction_*() in a badly written driver, which would cause the same pinmux register to be reconfigured for regular input/output and this disabling interrupt capability of the pin. This patch addresses this issue by moving pinmux reconfiguration to .irq_startup() callback of irq_chip and calling gpio_lock_as_irq() helper to prevent reconfiguration of pin direction. Signed-off-by: Tomasz Figa t.f...@samsung.com (...) + .irq_startup = exynos_irq_startup, + .irq_shutdown = exynos_irq_shutdown, I think you should be using the .irq_request_resources and .irq_release_resources callbacks instead. The reason is that startup and shutdown cannot really fail (ret code is unsigned...), so using the other callbacks is safer. Can you have a quick look at this before I apply any more of the Samsung patches? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote: On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin houch...@gmail.com wrote: The Problem --- The reset signal on a hardware board is send either: - during machine initialization - during bus master's initialization I just thought about this a bit, since there isn't already a generic GPIO reset driver, just call this drivers/reset/reset-gpio.c and make the ability to deferral just a configuration detail of the GPIO reset driver. Philipp has been working on one for quite some time. See http://www.spinics.net/lists/arm-kernel/msg321927.html However, it seems to progress slowly, and we don't seem to be able to reach a consensus here. If you ask me, having to set a few extra properties like this just advocates for a regular reset driver and DT node for the reset GPIO, but I'm pretty sure Philipp will feel otherwise :) Hm haha yeah let's fight it out :-) This is not my subsystem so I'm getting some popcorn. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/17] gpio: samsung: remove s5p64x0 related gpio codes
On Mon, Jun 30, 2014 at 11:32 PM, Kukjin Kim kgene@samsung.com wrote: This patch removes gpio codes for s5p6440 and s5p6450 SoCs. Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Linus Walleij linus.wall...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/17] gpio: samsung: remov s5pc100 related gpio codes
On Mon, Jun 30, 2014 at 11:32 PM, Kukjin Kim kgene@samsung.com wrote: This patch removes gpio codes for s5pc100 SoC. Signed-off-by: Kukjin Kim kgene@samsung.com Cc: Linus Walleij linus.wall...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback
On Wed, Jun 25, 2014 at 3:37 PM, Tomasz Figa t.f...@samsung.com wrote: For certain platforms (e.g. Exynos) it is necessary to read back some values from registers before they can be written (i.e. SMC calls that set multiple registers per call), so base address of L2C controller is needed for .write_sec operation. This patch adds base argument to .write_sec callback so that its implementation can also access registers directly. Signed-off-by: Tomasz Figa t.f...@samsung.com arch/arm/mach-ux500/cache-l2x0.c | 3 ++- In our case just changing the signature of the function I see so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pinctrl: exynos: Add driver data for Exynos3250
On Mon, Apr 14, 2014 at 3:45 AM, Chanwoo Choi cw00.c...@samsung.com wrote: From: Tomasz Figa t.f...@samsung.com This patch adds driver data (bank list and EINT layout) for Exynos3250 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional input/output ports. There are 23 general port groups. Changes from v1: - Add signed-off of sender - Post only separated patch for pinctrl from following patchset(v1) : https://lkml.org/lkml/2014/4/10/286 Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com This v2 patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/27] pinctrl: exynos: Add driver data for Exynos3250
On Thu, Apr 10, 2014 at 11:28 AM, Chanwoo Choi cw00.c...@samsung.com wrote: From: Tomasz Figa t.f...@samsung.com This patch adds driver data (bank list and EINT layout) for Exynos3250 to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional input/output ports. There are 23 general port groups. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Ugh can Tomasz send out his patches himself, I get confused... It was also sent two times, the second time with CC:s added. Tomasz, shall I merge this? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 49/75] ARM: l2c: fix register naming
On Fri, Mar 28, 2014 at 4:18 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: We have a mixture of different devices with different register layouts, but we group all the bits together in an opaque mess. Split them out into those which are L2C-310 specific and ones which refer to earlier devices. Provide full auxiliary control register definitions. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Linus Walleij linus.wall...@linaro.org For ux500. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] pinctrl: exynos: add exynos5260 SoC specific data
On Wed, Feb 5, 2014 at 7:21 AM, Rahul Sharma rahul.sha...@samsung.com wrote: From: Young-Gun Jang yg1004.j...@samsung.com Adds pinctrl support for all platforms based on EXYNOS5260 SoC. Acked-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: S5P[v210|c100|64x0]: Fix build error
On Wed, Jan 15, 2014 at 10:01 AM, Sachin Kamat sachin.ka...@linaro.org wrote: gpio-samsung.h header file introduced by commit 93177be0910c (ARM: S3C[24|64]xx: move includes back under mach/ scope) is required only by S3C[24|64]xx machines. Include them conditionally to avoid the following build errors for other machine configurations. drivers/gpio/gpio-samsung.c:35:31: fatal error: mach/gpio-samsung.h: No such file or directory arch/arm/plat-samsung/pm-gpio.c:22:31: fatal error: mach/gpio-samsung.h: No such file or directory Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Damned I couldn't get rid of the ifdefs anyway :-( Thanks Sachin, patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C[24|64]xx: move includes back under mach/ scope
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote: This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX || CONFIG_ARCH_S3C64XX. Currently generating build errors for s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on next-20140115. I noticed the same problem, but I think a better solution would be to do the same change for s5p that Linus has done for s3c, which is to move the nonstandard contents of mach/gpio.h to mach/gpio-samsung.h. Hm I just applied a fixup from Sachin adding #ifdefs back in but maybe I should try to fix it up like that instead. Just a minute... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C[24|64]xx: move includes back under mach/ scope
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote: diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c index c4efa1c2a5d1..a9f7a37c4173 100644 --- a/arch/arm/plat-samsung/pm-gpio.c +++ b/arch/arm/plat-samsung/pm-gpio.c @@ -19,12 +19,7 @@ #include linux/io.h #include linux/gpio.h -#ifdef CONFIG_ARCH_S3C24XX -#include linux/platform_data/gpio-samsung-s3c24xx.h -#endif -#ifdef CONFIG_ARCH_S3C64XX -#include linux/platform_data/gpio-samsung-s3c64xx.h -#endif +#include mach/gpio-samsung.h This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX || CONFIG_ARCH_S3C64XX. Currently generating build errors for s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on next-20140115. I noticed the same problem, but I think a better solution would be to do the same change for s5p that Linus has done for s3c, which is to move the nonstandard contents of mach/gpio.h to mach/gpio-samsung.h. When I look at it, the issue also exist in e.g. drivers/gpio/gpio-samsung.c which can be compiled (like for allyesconfig) when PLAT_SAMSUNG is set. And it is also set to y for ARCH_EXYNOS... which doesn't have any custom GPIO header. So this would involve something like creating an empty mach/gpio-samsung.h for Exynos which doesn't seem like the right thing to do. So I'm sticking with the #ifdef patch for now as it seems to be the lesser evil :-/ Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Wed, Jan 8, 2014 at 4:59 PM, Arnd Bergmann a...@arndb.de wrote: I've asked the mighty grep and it said that these are the files using the contents you moved around: drivers/gpio/gpio-samsung.c drivers/leds/leds-s3c24xx.c drivers/mmc/host/s3cmci.c sound/soc/samsung/h1940_uda1380.c sound/soc/samsung/neo1973_wm8753.c sound/soc/samsung/rx1950_uda1380.c sound/soc/samsung/s3c2412-i2s.c sound/soc/samsung/s3c24xx-i2s.c sound/soc/samsung/smartq_wm8987.c The symbols used in these drivers are: S3CGP.() S3C_GPIO_END S3C_GPIO_PULL_.* S3C_GPIO_SFN() s3c_gpio_cfgall_range() s3c_gpio_setpull() Hm I will look closer at these. Maybe I can even fix some to just pass GPIO thru platform data and end-of-story them. Targeting v3.15. But I guess you want me to move the linux/platform_data/gpio-s3c* back to mach/* before v3.14 so focusing on that now. (These patches cannot be just reverted as people have fixed other Samsung GPIO issues on top of them, so it needs to be done carefully.) I think it would be worthwhile to go ahead and make all inclusions of the plat/gpio-cfg.h file explicit, and remove it from mach/gpio.h, that part should be simple enough and helpful at the same time. plat/gpio-cfg.h is used by S5P as well, but I guess you've checked that. If I take it driver-by-driver it should be possible to get rid of it or most of it I think, reducing it to the arch/arm/mach-* folder. Certainly I should be attacking S3C and S5P simultaneously. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: s3c24xx: explicit dependency on plat/gpio-cfg.h
Previously the custom GPIO header for the S3C24xx would in turn
bring in the custom pin control implementation from
plat/gpio-cfg.h. This is not good as it mixes up two
subsystems and makes the dependencies hard to track. Make
the dependency explicit by explicitly including the pin
control header where needed.
Reported-by: Arnd Bergmann a...@arndb.de
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Heiko Stuebner he...@sntech.de
Cc: Mark Brown broo...@kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Maintainers: this builds on top of the previous patch moving
headers back to mach/*. This will also boil in linux-next,
ACKs appreciated.
---
arch/arm/mach-s3c24xx/h1940-bluetooth.c | 1 +
arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h | 2 --
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c24xx/pm-s3c2410.c| 1 +
arch/arm/mach-s3c24xx/setup-ts.c | 1 +
drivers/mmc/host/s3cmci.c | 1 +
6 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/h1940-bluetooth.c
b/arch/arm/mach-s3c24xx/h1940-bluetooth.c
index ff3afc163178..b4d14b864367 100644
--- a/arch/arm/mach-s3c24xx/h1940-bluetooth.c
+++ b/arch/arm/mach-s3c24xx/h1940-bluetooth.c
@@ -19,6 +19,7 @@
#include linux/gpio.h
#include linux/rfkill.h
+#include plat/gpio-cfg.h
#include mach/hardware.h
#include mach/regs-gpio.h
#include mach/gpio-samsung.h
diff --git a/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
b/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
index 79b3a0e44955..528fcdc4f63e 100644
--- a/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
+++ b/arch/arm/mach-s3c24xx/include/mach/gpio-samsung.h
@@ -93,8 +93,6 @@ enum s3c_gpio_number {
#define S3C2410_GPL(_nr) (S3C2410_GPIO_L_START + (_nr))
#define S3C2410_GPM(_nr) (S3C2410_GPIO_M_START + (_nr))
-#include plat/gpio-cfg.h
-
#ifdef CONFIG_CPU_S3C244X
#define S3C_GPIO_END (S3C2410_GPJ(0) + 32)
#elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c
b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 345d01aa3524..0a5456cda1bc 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -59,6 +59,7 @@
#include plat/pm.h
#include plat/regs-serial.h
#include plat/samsung-time.h
+#include plat/gpio-cfg.h
#include common.h
#include h1940.h
diff --git a/arch/arm/mach-s3c24xx/pm-s3c2410.c
b/arch/arm/mach-s3c24xx/pm-s3c2410.c
index 509b20b4ab3b..20e481d8a33a 100644
--- a/arch/arm/mach-s3c24xx/pm-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/pm-s3c2410.c
@@ -35,6 +35,7 @@
#include mach/regs-gpio.h
#include mach/gpio-samsung.h
+#include plat/gpio-cfg.h
#include plat/cpu.h
#include plat/pm.h
diff --git a/arch/arm/mach-s3c24xx/setup-ts.c b/arch/arm/mach-s3c24xx/setup-ts.c
index f61f02bdc52f..46466d20257e 100644
--- a/arch/arm/mach-s3c24xx/setup-ts.c
+++ b/arch/arm/mach-s3c24xx/setup-ts.c
@@ -15,6 +15,7 @@
struct platform_device; /* don't need the contents */
+#include plat/gpio-cfg.h
#include mach/hardware.h
#include mach/gpio-samsung.h
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index e34d499cb316..f23782683a7c 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -23,6 +23,7 @@
#include linux/irq.h
#include linux/io.h
+#include plat/gpio-cfg.h
#include mach/dma.h
#include mach/gpio-samsung.h
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Tue, Jan 7, 2014 at 8:52 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 07 January 2014, Linus Walleij wrote: It appears that these problems appear if you explicitly enable the DT board support, can't we just put that into the defconfig then, so we don't miss such things? I don't understand. I didn't enable it manually and I still get it on linux-next-20130107. Maybe you were still on the older linux-next that had not been updated for some time? No that's not the problem, I used the latest... but: (...) I just tried building with make allmodconfig KCONFIG_ALLCONFIG=allconfig, with the allconfig file containing a CONFIG_MACH_S3C2410=y statement. This caught a number of additionl problems, some related and some not. This was the problem, so making new build rules now to see if I can catch this. What is actually the bigger worry here is that the contents of the new file, while correctly moved out of mach/gpio.h also don't belong into include/linux/platform_data, because they don't define a pdata structure but rather the contents that are supposed to be passed from the platform code. I would much prefer if you could move the file back into mach-s3c24xx/ under a new name and keep it out of platform_data. Unfortunately it cannot live right under mach-s3c24xx because there are drivers here and there referring directly to the contents of this file. The only quick-fix option would be to move it back to mach/gpio-samsung-s3c24xx.h but the real solution is of course to augment all drivers to use gpio descriptors and add descriptor tables to the boardfiles. I'm a bit reluctant to do that as I'd prefer to be able to test such modifications on HW ... plus time may be better invested in DT migration (as I think is the conclusion of this thread eventually). I suspect that the only thing actually needed by the gpio driver is the number of GPIO lines per platform, and we can find another way to communicate that. A bit more: if you look in drivers/gpio/gpio-samsung.c you see bank base GPIO offset for each bank into the global scope *and* the number of GPIOs for each bank propagated from machine headers instead of using platform data. Again the proper solution (if the boardfiles are kept) is to switch to using a GPIO descriptor table. Or using DT. Most of the contents should be private to the mach-s3c code and not be visible to either the gpio driver or any drivers using the plat/gpio-cfg.h interface. Samsungs plat/gpio-cfg.h is basically a custom legacy pin control implementation. The real solution to getting rid of that file is to switch over to using pinctrl-[samsung|s3c24xx] which as Heiko describes mandates also using DT, and thus blocks attempts at using this path for fixing the legacy boardfiles. It's one of these situations where we end up with an all-or-nothing conversion path: either you change everything over to device tree or everything stays in two copies ... I'm trying to refactor the existing board files here maybe that is in vain :-/ as GPIO maintainer I want to get rid of mach/gpio.h. Note that on Exynos, the solution for the gpio driver dependencies was to scrap the driver and use pinctrl-exynos instead. I think the S3C driver is a different piece of hardware unfortunately. But exynos was using this driver before it moved to the new pinctrl driver. I was wrong about this, too much in my head. As Tomasz says, pinctrl-samsung can be used, but mandates that everything is moved over to device tree. Probably the best thing now that I have one problem less is to leave it to the S3C maintainers to complete their DT migration? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
On Tue, Jan 7, 2014 at 12:15 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 13 December 2013, Linus Walleij wrote: This isolates the custom S3C24xx GPIO definition table to linux/platform_data/gpio-samsung-s3x24xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff. The biggest this can ever be for the S3C24XX is CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512 is the absolute roof value on this platform. So we set the size of ARCH_NR_GPIO to this and the GPIOs array will fit any S3C24XX platform, as per pattern from other archs. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: linux-samsung-soc@vger.kernel.org Acked-by: Kukjin Kim kgene@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Tested-by: Heiko Stuebner he...@sntech.de Signed-off-by: Linus Walleij linus.wall...@linaro.org I'm getting build errors in linux-next for s3c2410_defconfig now because of this patch :( Hm. I just compiled this defconfig on linux-next: AS arch/arm/boot/compressed/lib1funcs.o AS arch/arm/boot/compressed/ashldi3.o AS arch/arm/boot/compressed/bswapsdi2.o CC arch/arm/boot/compressed/decompress.o CC arch/arm/boot/compressed/misc.o GZIParch/arm/boot/compressed/piggy.gzip AS arch/arm/boot/compressed/piggy.gzip.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready It appears that these problems appear if you explicitly enable the DT board support, can't we just put that into the defconfig then, so we don't miss such things? Two problems: * Some files that use functions or macros defined in this file fail to include it. I see drivers/leds/leds-s3c24xx.c I merged a patch fixing this by having that file explicitly include plat/gpip-cfg.h (it was already including it implicitly). and mach-osiris-dvs.c, It needs this: #include linux/platform_data/gpio-samsung-s3c24xx.h (I have sent a patch.) but there might be more that don't get built by default. Yeah implicit includes are a nightmare for refactoring... I'm trying to grep around for some symbols to see if I can find some lost cases. * The file includes plat/gpio-cfg.h, which is not a bug yet, but will be once we move s3c24xx to multiplatform, which would make it impossible to include this file from outside of arch/arm. Yes that needs to be a step for multiplatform enablement. My series only tries to make the problem smaller and remove the dependence on mach/gpio.h. All the mach/* and plat/* stuff needs to go away eventually ... Note that on Exynos, the solution for the gpio driver dependencies was to scrap the driver and use pinctrl-exynos instead. I think the S3C driver is a different piece of hardware unfortunately. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: Some GPIO line limits are incorrectly set which, for instance, does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt Patch applied with Kukjin's ACK and Heiko's review tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Fri, Dec 13, 2013 at 10:37 AM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Dec 13, 2013 at 10:24 AM, kg...@kernel.org wrote: José Miguel Gonçalves wrote: (..) Was this patch forgotten? Hi Jose, Sorry about missing your patch. It's my fault :( and as you know, at this moment the file will be removed by Linus' patch... Oh I can certainly rebase the patch onto my tree if I just get an ACK for it... Kukjin, can I have your ACK for this patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Fri, Dec 13, 2013 at 2:55 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: On 27-09-2013 15:17, Linus Walleij wrote: On Wed, Sep 11, 2013 at 10:46 AM, José Miguel Gonçalves jose.goncal...@inov.pt wrote: Some GPIO line limits are incorrectly set which, for instance, does not allow nRTS1 (GPH11) configuration on a S3C2416 chip. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- arch/arm/mach-s3c24xx/include/mach/gpio.h | 10 +- (...) Was this patch forgotten? Not by me, I just never got an ACK from the Samsung maintainers, so I can't apply it to the GPIO tree. Ben, Kukjin: can one of you ACK this so I can take it through the GPIO tree? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: s3c24xx: get rid of custom mach/gpio.h
On Fri, Dec 13, 2013 at 8:57 AM, Heiko Stübner he...@sntech.de wrote: I'm not the maintainer of s3c24xx, Maybe you should be. I have a hard time getting the generic Samsung maintainers' attention to S3C patches... but this looks nice ;-) Do you think you can test it on hardware? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C24XX: Fix configuration of gpio port sizes on S3C24XX.
On Fri, Dec 13, 2013 at 10:24 AM, kg...@kernel.org wrote: José Miguel Gonçalves wrote: (..) Was this patch forgotten? Hi Jose, Sorry about missing your patch. It's my fault :( and as you know, at this moment the file will be removed by Linus' patch... Oh I can certainly rebase the patch onto my tree if I just get an ACK for it... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: s3c24xx: get rid of custom mach/gpio.h
On Fri, Dec 13, 2013 at 11:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote: On Thursday 12 of December 2013 15:06:50 Linus Walleij wrote: [snip] arch/arm/mach-s3c64xx/include/mach/gpio.h | 93 - Hmm, shouldn't this (and other s3c64xx-related changes) be in patch 2/2? Hm yes, I wonder how I screwed this up... I'll move this to the other patch. Anyway, I've applied both, but unfortunately compilation for mach-s3c64xx (using s3c6400_defconfig) fails with following error: Trying to reproduce and fix this. Thanks! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v3] ARM: s3c24xx: get rid of custom mach/gpio.h
This isolates the custom S3C24xx GPIO definition table to linux/platform_data/gpio-samsung-s3x24xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff. The biggest this can ever be for the S3C24XX is CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512 is the absolute roof value on this platform. So we set the size of ARCH_NR_GPIO to this and the GPIOs array will fit any S3C24XX platform, as per pattern from other archs. Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: linux-samsung-soc@vger.kernel.org Acked-by: Kukjin Kim kgene@samsung.com Acked-by: Heiko Stuebner he...@sntech.de Tested-by: Heiko Stuebner he...@sntech.de Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v2-v3: - Move the movement of the S3C64XX gpio.h file out of this patch and into the follow-up patch where it belongs. ChangeLog v1-v2: - Added an #ifdef ARCH_S3C24XX around the header inclusion in drivers/gpio/gpio-samsung.c as we would otherwise have colliding definitions when compiling S3C64XX. - Rename inclusion guard in the header file. I will take this through the GPIO tree. --- arch/arm/Kconfig | 3 +- arch/arm/mach-s3c24xx/Kconfig | 21 arch/arm/mach-s3c24xx/common-smdk.c| 2 +- arch/arm/mach-s3c24xx/h1940-bluetooth.c| 1 + arch/arm/mach-s3c24xx/include/mach/gpio.h | 114 - arch/arm/mach-s3c24xx/mach-amlm5900.c | 1 + arch/arm/mach-s3c24xx/mach-anubis.c| 1 + arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 + arch/arm/mach-s3c24xx/mach-bast.c | 1 + arch/arm/mach-s3c24xx/mach-gta02.c | 1 + arch/arm/mach-s3c24xx/mach-h1940.c | 1 + arch/arm/mach-s3c24xx/mach-jive.c | 1 + arch/arm/mach-s3c24xx/mach-mini2440.c | 1 + arch/arm/mach-s3c24xx/mach-n30.c | 1 + arch/arm/mach-s3c24xx/mach-nexcoder.c | 1 + arch/arm/mach-s3c24xx/mach-osiris.c| 1 + arch/arm/mach-s3c24xx/mach-qt2410.c| 1 + arch/arm/mach-s3c24xx/mach-rx1950.c| 1 + arch/arm/mach-s3c24xx/mach-rx3715.c| 1 + arch/arm/mach-s3c24xx/mach-smdk2413.c | 1 + arch/arm/mach-s3c24xx/mach-smdk2416.c | 1 + arch/arm/mach-s3c24xx/mach-vr1000.c| 1 + arch/arm/mach-s3c24xx/pm-s3c2410.c | 1 + arch/arm/mach-s3c24xx/pm.c | 1 + arch/arm/mach-s3c24xx/s3c2410.c| 1 + arch/arm/mach-s3c24xx/s3c2416.c| 1 + arch/arm/mach-s3c24xx/s3c2440.c| 1 + arch/arm/mach-s3c24xx/s3c2442.c| 1 + arch/arm/mach-s3c24xx/s3c2443.c| 1 + arch/arm/mach-s3c24xx/setup-i2c.c | 1 + arch/arm/mach-s3c24xx/setup-sdhci-gpio.c | 1 + arch/arm/mach-s3c24xx/setup-ts.c | 1 + arch/arm/mach-s3c24xx/simtec-usb.c | 1 + arch/arm/plat-samsung/pm-gpio.c| 3 + arch/arm/plat-samsung/setup-camif.c| 1 + drivers/gpio/gpio-samsung.c| 3 + drivers/mmc/host/s3cmci.c | 1 + include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++ 38 files changed, 145 insertions(+), 138 deletions(-) delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7eee953..6a26bcb3a63a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -710,7 +710,6 @@ config ARCH_S3C24XX select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS select MULTI_IRQ_HANDLER - select NEED_MACH_GPIO_H select NEED_MACH_IO_H select SAMSUNG_ATAGS help @@ -1593,7 +1592,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 8f1d327e0cd1..d876431d64c0 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -180,27 +180,6 @@ config CPU_LLSERIAL_S3C2440
[PATCH 2/2 v2] ARM: s3c64xx: get rid of custom mach/gpio.h
This isolates the custom S3C64xx GPIO definition table to linux/platform_data/gpio-samsung-s3x64xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead roof the number of GPIOs for this platform: First sum up all the GPIO banks from A to Q: 187 GPIOs. Add the 16 board GPIOs and the roof for SAMSUNG_GPIO_EXTRA, 128, so in total maximum 187+16+128 = 331 GPIOs, so let's take the same roof as for S3C24XX: 512. This way we can do away with the GPIO calculation macros for GPIO_BOARD_START, BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS. Cc: Mark Brown broo...@kernel.org Cc: Tomasz Figa tomasz.f...@gmail.com Acked-by: Kukjin Kim kgene@samsung.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Move the movement of the actual gpio.h file into this patch after mistakenly having it end up in the S3C24xx patch. - Add a missing ifdef for the pm-gpio.c code in plat-samsung. This patch depends on ARM: s3c24xx: get rid of custom mach/gpio.h I will take this through the GPIO tree. --- arch/arm/Kconfig | 3 +- arch/arm/mach-s3c64xx/Kconfig | 3 - arch/arm/mach-s3c64xx/common.c | 1 + arch/arm/mach-s3c64xx/crag6410.h | 2 +- arch/arm/mach-s3c64xx/dev-audio.c | 1 + arch/arm/mach-s3c64xx/include/mach/gpio.h | 93 - arch/arm/mach-s3c64xx/mach-anw6410.c | 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + arch/arm/mach-s3c64xx/mach-hmt.c | 1 + arch/arm/mach-s3c64xx/mach-mini6410.c | 1 + arch/arm/mach-s3c64xx/mach-real6410.c | 1 + arch/arm/mach-s3c64xx/mach-smartq.c| 1 + arch/arm/mach-s3c64xx/mach-smartq5.c | 1 + arch/arm/mach-s3c64xx/mach-smartq7.c | 1 + arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 + arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 + arch/arm/mach-s3c64xx/pm.c | 1 + arch/arm/mach-s3c64xx/setup-fb-24bpp.c | 1 + arch/arm/mach-s3c64xx/setup-i2c0.c | 1 + arch/arm/mach-s3c64xx/setup-i2c1.c | 1 + arch/arm/mach-s3c64xx/setup-ide.c | 1 + arch/arm/mach-s3c64xx/setup-keypad.c | 1 + arch/arm/mach-s3c64xx/setup-sdhci-gpio.c | 1 + arch/arm/mach-s3c64xx/setup-spi.c | 1 + arch/arm/plat-samsung/pm-gpio.c| 3 + drivers/gpio/gpio-samsung.c| 3 + include/linux/platform_data/gpio-samsung-s3c64xx.h | 94 ++ 27 files changed, 122 insertions(+), 99 deletions(-) delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-samsung-s3c64xx.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6a26bcb3a63a..103437986684 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -732,7 +732,6 @@ config ARCH_S3C64XX select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_TCM - select NEED_MACH_GPIO_H select NO_IOPORT select PLAT_SAMSUNG select PM_GENERIC_DOMAINS @@ -1592,7 +1591,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index 2cb8dc55b50e..175f01501129 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -192,7 +192,6 @@ config SMDK6410_WM1190_EV1 select MFD_WM8350_I2C select REGULATOR select REGULATOR_WM8350 - select SAMSUNG_GPIO_EXTRA64 help The Wolfson Microelectronics 1190-EV1 is a WM835x based PMIC and audio daughtercard for the Samsung SMDK6410 reference @@ -208,7 +207,6 @@ config SMDK6410_WM1192_EV1 select MFD_WM831X_I2C select REGULATOR select REGULATOR_WM831X - select SAMSUNG_GPIO_EXTRA64 help The Wolfson Microelectronics 1192-EV1 is a WM831x based PMIC daughtercard for the Samsung SMDK6410 reference platform. @@ -294,7 +292,6 @@ config MACH_WLF_CRAGG_6410 select SAMSUNG_DEV_ADC select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM - select SAMSUNG_GPIO_EXTRA128 help Machine support for the Wolfson Cragganmore S3C6410 variant
[PATCH 1/2] ARM: s3c24xx: get rid of custom mach/gpio.h
This isolates the custom S3C24xx GPIO definition table to linux/platform_data/gpio-samsung-s3x24xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff. The biggest this can ever be for the S3C24XX is CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512 is the absolute roof value on this platform. So we set the size of ARCH_NR_GPIO to this and the GPIOs array will fit any S3C24XX platform, as per pattern from other archs. Cc: Heiko Stuebner he...@sntech.de Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Added an #ifdef ARCH_S3C24XX around the header inclusion in drivers/gpio/gpio-samsung.c as we would otherwise have colliding definitions when compiling S3C64XX. - Rename inclusion guard in the header file. If one of the maintainers give me an ACK for this I will take it through the GPIO tree. --- arch/arm/Kconfig | 3 +- arch/arm/mach-s3c24xx/Kconfig | 21 arch/arm/mach-s3c24xx/common-smdk.c| 2 +- arch/arm/mach-s3c24xx/h1940-bluetooth.c| 1 + arch/arm/mach-s3c24xx/include/mach/gpio.h | 114 - arch/arm/mach-s3c24xx/mach-amlm5900.c | 1 + arch/arm/mach-s3c24xx/mach-anubis.c| 1 + arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 + arch/arm/mach-s3c24xx/mach-bast.c | 1 + arch/arm/mach-s3c24xx/mach-gta02.c | 1 + arch/arm/mach-s3c24xx/mach-h1940.c | 1 + arch/arm/mach-s3c24xx/mach-jive.c | 1 + arch/arm/mach-s3c24xx/mach-mini2440.c | 1 + arch/arm/mach-s3c24xx/mach-n30.c | 1 + arch/arm/mach-s3c24xx/mach-nexcoder.c | 1 + arch/arm/mach-s3c24xx/mach-osiris.c| 1 + arch/arm/mach-s3c24xx/mach-qt2410.c| 1 + arch/arm/mach-s3c24xx/mach-rx1950.c| 1 + arch/arm/mach-s3c24xx/mach-rx3715.c| 1 + arch/arm/mach-s3c24xx/mach-smdk2413.c | 1 + arch/arm/mach-s3c24xx/mach-smdk2416.c | 1 + arch/arm/mach-s3c24xx/mach-vr1000.c| 1 + arch/arm/mach-s3c24xx/pm-s3c2410.c | 1 + arch/arm/mach-s3c24xx/pm.c | 1 + arch/arm/mach-s3c24xx/s3c2410.c| 1 + arch/arm/mach-s3c24xx/s3c2416.c| 1 + arch/arm/mach-s3c24xx/s3c2440.c| 1 + arch/arm/mach-s3c24xx/s3c2442.c| 1 + arch/arm/mach-s3c24xx/s3c2443.c| 1 + arch/arm/mach-s3c24xx/setup-i2c.c | 1 + arch/arm/mach-s3c24xx/setup-sdhci-gpio.c | 1 + arch/arm/mach-s3c24xx/setup-ts.c | 1 + arch/arm/mach-s3c24xx/simtec-usb.c | 1 + arch/arm/mach-s3c64xx/include/mach/gpio.h | 93 - arch/arm/plat-samsung/pm-gpio.c| 3 + arch/arm/plat-samsung/setup-camif.c| 1 + drivers/gpio/gpio-samsung.c| 3 + drivers/mmc/host/s3cmci.c | 1 + include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++ include/linux/platform_data/gpio-samsung-s3c64xx.h | 93 + 40 files changed, 238 insertions(+), 231 deletions(-) delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h delete mode 100644 arch/arm/mach-s3c64xx/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h create mode 100644 include/linux/platform_data/gpio-samsung-s3c64xx.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7eee953..6a26bcb3a63a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -710,7 +710,6 @@ config ARCH_S3C24XX select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS select MULTI_IRQ_HANDLER - select NEED_MACH_GPIO_H select NEED_MACH_IO_H select SAMSUNG_ATAGS help @@ -1593,7 +1592,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index
[PATCH 2/2] ARM: s3c64xx: get rid of custom mach/gpio.h
This isolates the custom S3C64xx GPIO definition table to linux/platform_data/gpio-samsung-s3x64xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead roof the number of GPIOs for this platform: First sum up all the GPIO banks from A to Q: 187 GPIOs. Add the 16 board GPIOs and the roof for SAMSUNG_GPIO_EXTRA, 128, so in total maximum 187+16+128 = 331 GPIOs, so let's take the same roof as for S3C24XX: 512. This way we can do away with the GPIO calculation macros for GPIO_BOARD_START, BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS. Cc: Kukjin Kim kgene@samsung.com Cc: Mark Brown broo...@kernel.org Cc: Tomasz Figa tomasz.f...@gmail.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- This patch depends on ARM: s3c24xx: get rid of custom mach/gpio.h If one of the maintainers give me an ACK for this I will take it through the GPIO tree. --- arch/arm/Kconfig | 3 +-- arch/arm/mach-s3c64xx/Kconfig | 3 --- arch/arm/mach-s3c64xx/common.c | 1 + arch/arm/mach-s3c64xx/crag6410.h | 2 +- arch/arm/mach-s3c64xx/dev-audio.c | 1 + arch/arm/mach-s3c64xx/mach-anw6410.c | 1 + arch/arm/mach-s3c64xx/mach-crag6410.c | 1 + arch/arm/mach-s3c64xx/mach-hmt.c | 1 + arch/arm/mach-s3c64xx/mach-mini6410.c | 1 + arch/arm/mach-s3c64xx/mach-real6410.c | 1 + arch/arm/mach-s3c64xx/mach-smartq.c| 1 + arch/arm/mach-s3c64xx/mach-smartq5.c | 1 + arch/arm/mach-s3c64xx/mach-smartq7.c | 1 + arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 + arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 + arch/arm/mach-s3c64xx/pm.c | 1 + arch/arm/mach-s3c64xx/setup-fb-24bpp.c | 1 + arch/arm/mach-s3c64xx/setup-i2c0.c | 1 + arch/arm/mach-s3c64xx/setup-i2c1.c | 1 + arch/arm/mach-s3c64xx/setup-ide.c | 1 + arch/arm/mach-s3c64xx/setup-keypad.c | 1 + arch/arm/mach-s3c64xx/setup-sdhci-gpio.c | 1 + arch/arm/mach-s3c64xx/setup-spi.c | 1 + drivers/gpio/gpio-samsung.c| 3 +++ include/linux/platform_data/gpio-samsung-s3c64xx.h | 9 + 25 files changed, 30 insertions(+), 10 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6a26bcb3a63a..103437986684 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -732,7 +732,6 @@ config ARCH_S3C64XX select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_TCM - select NEED_MACH_GPIO_H select NO_IOPORT select PLAT_SAMSUNG select PM_GENERIC_DOMAINS @@ -1592,7 +1591,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index 2cb8dc55b50e..175f01501129 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -192,7 +192,6 @@ config SMDK6410_WM1190_EV1 select MFD_WM8350_I2C select REGULATOR select REGULATOR_WM8350 - select SAMSUNG_GPIO_EXTRA64 help The Wolfson Microelectronics 1190-EV1 is a WM835x based PMIC and audio daughtercard for the Samsung SMDK6410 reference @@ -208,7 +207,6 @@ config SMDK6410_WM1192_EV1 select MFD_WM831X_I2C select REGULATOR select REGULATOR_WM831X - select SAMSUNG_GPIO_EXTRA64 help The Wolfson Microelectronics 1192-EV1 is a WM831x based PMIC daughtercard for the Samsung SMDK6410 reference platform. @@ -294,7 +292,6 @@ config MACH_WLF_CRAGG_6410 select SAMSUNG_DEV_ADC select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM - select SAMSUNG_GPIO_EXTRA128 help Machine support for the Wolfson Cragganmore S3C6410 variant. diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c index 7a3ce4c39e5f..64edda37bde3 100644 --- a/arch/arm/mach-s3c64xx/common.c +++ b/arch/arm/mach-s3c64xx/common.c @@ -32,6 +32,7 @@ #include linux/irq.h #include linux/gpio.h #include linux/irqchip/arm-vic.h +#include linux/platform_data/gpio-samsung-s3c64xx.h #include clocksource/samsung_pwm.h #include asm/mach/arch.h diff --git a/arch/arm/mach-s3c64xx/crag6410.h b/arch/arm/mach
Re: [PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa tomasz.f...@gmail.com wrote: This is actually quite a poor platform choice. As of today, the kernel is stuck with supporting just SMDK6440/6450 boards, which are proprietary development boards and it doesn't look like any further boards will show up in future. Kukjin has actually proposed removing support for this platform at all and I consider this reasonable. Kukjin, should we proceed with removal? Isn't Mark Brown using that platform for some various stuff? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
On Thu, Dec 12, 2013 at 10:22 PM, Tomasz Figa tomasz.f...@gmail.com wrote: 2013/12/12 Linus Walleij linus.wall...@linaro.org: On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa tomasz.f...@gmail.com wrote: This is actually quite a poor platform choice. As of today, the kernel is stuck with supporting just SMDK6440/6450 boards, which are proprietary development boards and it doesn't look like any further boards will show up in future. Kukjin has actually proposed removing support for this platform at all and I consider this reasonable. Kukjin, should we proceed with removal? Isn't Mark Brown using that platform for some various stuff? Not as far as I know. He's using Cragganmore board based on s3c6410, but this is a different platform (s3c64xx). A I see it now. So the S3C:s are actually in a lot of use and the S5P is one of those stepping stones to Exynos that never really was in any widespread use. Yeah I'm all for deleteing that :-) Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown broo...@kernel.org wrote: On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote: So a suggested patch to support weak hogs would be interesting to look at. Can you provide details on how you think this would work? Or should we be going and applying the default state to all devices on init without worrying about a driver appearing? That doesn't really work: if you have an unused device not in the DT you usually mark it disabled, and then the DT core doesn't even create a platform_device for this node. So doing this would involve parsing the tree and ... yuck. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Fri, Dec 6, 2013 at 12:54 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 12/03/2013 02:29 AM, Linus Walleij wrote: (skipped the conversation on weak hogs, we are on the same page here, just waiting for someone to start working on it ...) Related, I prefer to put /all/ static pinctrl configuration into the pinctrl device's default state (i.e. use a hog) rather than configuring the static pinctrl setup per device, for another reason too: If a particular IO controller's signals can be routed to n different (sets of) pins, then we need to do *both* of the following when setting up the pinmux: a) Configure the pins we want to host those signals to route to/from that particular IO controller. b) Configure any other pins that could route to/from that particular IO controller as some other function; either disabled, or routed to/from some different IO controller. That is so that the IO controller's RX/input signals are not connected from two different sets of pins at once, which would cause two things to driver them. Depending on HW, this could cause on of: 1) Multiple drivers - high power usage, or even Silicon damage. 2) Inconsistent configuration, with the wrong set of pins driving the IO controller's inputs, and hence the signals on the correct pins being ignored - hard to find bug. I'm following, I think what we need here is to think about additional behaviours and electronic constraints we can encode into the drivers and/or the pin tables to safeguard pin states from electronically unsound states. That is to say, I prefer the subsystem to be conscious about the electronic constraints and navigate around them or put up a road block, rather than trying ti avoid driving into the roadblocks by means of carefully crafted tables if you get the picture ... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: s3c24xx: get rid of custom mach/gpio.h
This isolates the custom S3C24xx GPIO definition table to linux/platform_data/gpio-samsung-s3x24xx.h as this is used in a few different places in the kernel, removing the need to depend on the implicit inclusion of mach/gpio.h from linux/gpio.h and thus getting rid of a few nasty cross-dependencies. We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff. The biggest this can ever be for the S3C24XX is CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512 is the absolute roof value on this platform. So we set the size of ARCH_NR_GPIO to this and the GPIOs array will fit any S3C24XX platform, as per pattern from other archs. Cc: Heiko Stuebner he...@sntech.de Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- If one of the maintainers give me an ACK for this I will take it through the GPIO tree. --- arch/arm/Kconfig | 3 +- arch/arm/mach-s3c24xx/Kconfig | 21 arch/arm/mach-s3c24xx/common-smdk.c| 2 +- arch/arm/mach-s3c24xx/h1940-bluetooth.c| 1 + arch/arm/mach-s3c24xx/include/mach/gpio.h | 114 - arch/arm/mach-s3c24xx/mach-amlm5900.c | 1 + arch/arm/mach-s3c24xx/mach-anubis.c| 1 + arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 + arch/arm/mach-s3c24xx/mach-bast.c | 1 + arch/arm/mach-s3c24xx/mach-gta02.c | 1 + arch/arm/mach-s3c24xx/mach-h1940.c | 1 + arch/arm/mach-s3c24xx/mach-jive.c | 1 + arch/arm/mach-s3c24xx/mach-mini2440.c | 1 + arch/arm/mach-s3c24xx/mach-n30.c | 1 + arch/arm/mach-s3c24xx/mach-nexcoder.c | 1 + arch/arm/mach-s3c24xx/mach-osiris.c| 1 + arch/arm/mach-s3c24xx/mach-qt2410.c| 1 + arch/arm/mach-s3c24xx/mach-rx1950.c| 1 + arch/arm/mach-s3c24xx/mach-rx3715.c| 1 + arch/arm/mach-s3c24xx/mach-smdk2413.c | 1 + arch/arm/mach-s3c24xx/mach-smdk2416.c | 1 + arch/arm/mach-s3c24xx/mach-vr1000.c| 1 + arch/arm/mach-s3c24xx/pm-s3c2410.c | 1 + arch/arm/mach-s3c24xx/pm.c | 1 + arch/arm/mach-s3c24xx/s3c2410.c| 1 + arch/arm/mach-s3c24xx/s3c2416.c| 1 + arch/arm/mach-s3c24xx/s3c2440.c| 1 + arch/arm/mach-s3c24xx/s3c2442.c| 1 + arch/arm/mach-s3c24xx/s3c2443.c| 1 + arch/arm/mach-s3c24xx/setup-i2c.c | 1 + arch/arm/mach-s3c24xx/setup-sdhci-gpio.c | 1 + arch/arm/mach-s3c24xx/setup-ts.c | 1 + arch/arm/mach-s3c24xx/simtec-usb.c | 1 + arch/arm/plat-samsung/pm-gpio.c| 1 + arch/arm/plat-samsung/setup-camif.c| 1 + drivers/gpio/gpio-samsung.c| 1 + drivers/mmc/host/s3cmci.c | 1 + include/linux/platform_data/gpio-samsung-s3c24xx.h | 106 +++ 38 files changed, 141 insertions(+), 138 deletions(-) delete mode 100644 arch/arm/mach-s3c24xx/include/mach/gpio.h create mode 100644 include/linux/platform_data/gpio-samsung-s3c24xx.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c1f1a7eee953..6a26bcb3a63a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -710,7 +710,6 @@ config ARCH_S3C24XX select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS select MULTI_IRQ_HANDLER - select NEED_MACH_GPIO_H select NEED_MACH_IO_H select SAMSUNG_ATAGS help @@ -1593,7 +1592,7 @@ config ARM_PSCI config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 8f1d327e0cd1..d876431d64c0 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -180,27 +180,6 @@ config CPU_LLSERIAL_S3C2440 Selected if there is an S3C2440 (or register compatible) serial low-level implementation needed -# gpio configurations - -config S3C24XX_GPIO_EXTRA - int - default 128 if S3C24XX_GPIO_EXTRA128 - default 64 if S3C24XX_GPIO_EXTRA64 - default 16 if ARCH_H1940 - default 0 - -config S3C24XX_GPIO_EXTRA64 - bool
Re: [PATCH] ARM: s3c24xx: get rid of custom mach/gpio.h
On Fri, Dec 6, 2013 at 10:31 AM, Linus Walleij linus.wall...@linaro.org wrote: This isolates the custom S3C24xx GPIO definition table to linux/platform_data/gpio-samsung-s3x24xx.h Maybe I'm too trigger happy. I'll send a combined series with S3C24xx, S3C64xx and maybe also S5P variants all fixed so you can see the overall idea here. Hold on. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Mon, Nov 25, 2013 at 9:01 PM, Kevin Bracey ke...@bracey.fi wrote: I've been working on extending the shmobile PFC driver to provide gpio-mode and implement PIN_CONFIG_OUTPUT as described by Documentation/pinctrl.txt, primarily to handle sleep states, but I have begun to wonder about the initial state problem, as discussed here. As far as I can see, we can't currently specify fallback states for pins, which is one of Tomasz' key requirements. That depends on what you mean with fallback states so let's hash this out. We can specify hog states, and we can specify default for a driver, but not default before/in absence of a driver or sleep in absence of a driver. Having a hog precludes any finer driver control, AFAICT. So the way it currently works is that hogs are usually used when there is no corresponding driver that can take care of the pins. If there are four SPI pins and no driver for that SPI block, a way to e.g. ground them is to do so using pinctrl hogs. Whenever a driver and a struct device * for this SPI block appears, it is wise to transfer control of these over to the device core, which will take any default state before doing probe() on the device driver, and then give you the option to use the nice pinctrl_pm* accessors to let the device core switch between default idle and sleep states if these are defined. Some of our existing pre-pinconf board files have a unused pins table which is used to claim and pull GPIOs. I've converted that to hog pinconf, but that only works because the table omits all pins used by drivers. And, unsurprisingly, that's been error-prone; if those tables originally covered all unused pins, they don't any more. I'd like confidence that we can get every pin into the correct state by having a fully-populated table containing all pins, that can be used regardless of which drivers start. I think what we're lacking is a weak hog. Whatever you call that. :) That would also specify the state to fallback to when a group is released (where we currently do pinmux_disable_setting). So I guess what you're after is a kind of hog that will be pushed aside and ignored if a struct device with an associated state appears that will use the same pin? It is true that we currently require the tables to be strict and not overlap like this, so ideally you should remove the hogs when you have a device driver, but you're actually describing an interesting case here: What if I have a driver for this IP block, and it was supposed to take care of a few pins, but I decide not to compile it into my kernel? Or if I have it as a module and only modprobe it later at runtime? So a suggested patch to support weak hogs would be interesting to look at. Can you provide details on how you think this would work? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote: IMHO a way to specify a default safe state of all pins (with lowest power consumption, without possibility of glitching external devices, etc.) would be really useful for Samsung platforms (and probably Renesas ones as Kevin wrote). I'm following :-) Now if we could see some more details and a patch, that would be great ... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote: On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. This is correspondant to the PIN_CONFIG_OUTPUT from include/linux/pinctrl/pinconf-generic.h I.e. driving a pin - any pin, even one that cannot do GPIO - high or low as default. One could argue that if you can drive the pin high/low using software then by definition it *is* GPIO. Even if it cannot trigger IRQs or anything. The rationale for having it in pinconf-generic is basically for use cases such that one of the the pin config states the device pass through may relate to what the documentation calls the GPIO mode fallacy - a state on the pins that is definately related to the use case of a certain device, but puts the pin in something the manual calls GPIO mode in order to save power. But from a use case point of view that is not GPIO, it is the typically the sleep state of a certain pin when used with a certain device. I'll see if I can think of some doc patch to make this more clear... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa t.f...@samsung.com wrote: Stephen: Is the lifetime of the string returned by of_property_read_string_index() really so short that you must copy the string? I'd be tempted just to store the pointer, although perhaps you need to get() the node so that's safe. Right. I have done it the copy-less way in other places, but missed this one. Thanks. So I guess I'm waiting for a new version of this patch, right? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Correct number of pins for s5pv210
On Tue, Sep 24, 2013 at 5:04 PM, Mateusz Krawczuk m.krawc...@partner.samsung.com wrote: Values of pins in table s5pv210 bank are incorrect. This patch correct values. Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Patch applied for fixes with the ACKs from Tomasz and Kukjin. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
