Re: [BUG] blocked task after exynos_drm_init
On Tue, Nov 18, 2014 at 12:29 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
[adding Kevin to cc list]
Hello Inki,
On Tue, Nov 18, 2014 at 11:52 AM, Inki Dae inki@samsung.com wrote:
On 2014년 11월 18일 19:42, Andrzej Hajda wrote:
On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
Hi,
On last next (next-20141104, next-20141105) booting locks after
initializing Exynos DRM (Trats2 board):
[2.028283] [drm] Initialized drm 1.1.0 20060810
[ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
[ 240.510825] Not tainted 3.18.0-rc3-next-20141105 #794
[ 240.516418] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
[ 240.524173] swapper/0 D c052534c 0 1 0 0x
[ 240.530527] [c052534c] (__schedule) from [c0525b34]
(schedule_preempt_disabled+0x14/0x20)
[ 240.539030] [c0525b34] (schedule_preempt_disabled) from [c0526d44]
(mutex_lock_nested+0x1c4/0x464)
[ 240.548320] [c0526d44] (mutex_lock_nested) from [c02be908]
(__driver_attach+0x48/0x98)
[ 240.556562] [c02be908] (__driver_attach) from [c02bcc00]
(bus_for_each_dev+0x54/0x88)
[ 240.564717] [c02bcc00] (bus_for_each_dev) from [c02bdce0]
(bus_add_driver+0xe4/0x200)
[ 240.572876] [c02bdce0] (bus_add_driver) from [c02bef94]
(driver_register+0x78/0xf4)
[ 240.580864] [c02bef94] (driver_register) from [c029e99c]
(exynos_drm_platform_probe+0x34/0x234)
[ 240.589890] [c029e99c] (exynos_drm_platform_probe) from [c02bfcf0]
(platform_drv_probe+0x48/0xa4)
[ 240.599090] [c02bfcf0] (platform_drv_probe) from [c02be680]
(driver_probe_device+0x13c/0x37c)
[ 240.607940] [c02be680] (driver_probe_device) from [c02be954]
(__driver_attach+0x94/0x98)
[ 240.616360] [c02be954] (__driver_attach) from [c02bcc00]
(bus_for_each_dev+0x54/0x88)
[ 240.624517] [c02bcc00] (bus_for_each_dev) from [c02bdce0]
(bus_add_driver+0xe4/0x200)
[ 240.632679] [c02bdce0] (bus_add_driver) from [c02bef94]
(driver_register+0x78/0xf4)
[ 240.640667] [c02bef94] (driver_register) from [c029e938]
(exynos_drm_init+0x70/0xa0)
[ 240.648739] [c029e938] (exynos_drm_init) from [c00089b0]
(do_one_initcall+0xac/0x1f0)
[ 240.656914] [c00089b0] (do_one_initcall) from [c074bd90]
(kernel_init_freeable+0x10c/0x1d8)
[ 240.665591] [c074bd90] (kernel_init_freeable) from [c051eabc]
(kernel_init+0x8/0xec)
[ 240.673661] [c051eabc] (kernel_init) from [c000f268]
(ret_from_fork+0x14/0x2c)
[ 240.681196] 3 locks held by swapper/0/1:
[ 240.685091] #0: (dev-mutex){..}, at: [c02be908]
__driver_attach+0x48/0x98
[ 240.692732] #1: (dev-mutex){..}, at: [c02be918]
__driver_attach+0x58/0x98
[ 240.700367] #2: (dev-mutex){..}, at: [c02be908]
__driver_attach+0x48/0x98
This is caused by patch moving platform devices to
/sys/devices/platform[1]. Since this patch registering platform
drivers/devices in probe of platform device causes deadlocks. I guess
now all driver registration should be moved to exynos_drm_init and it
seems better location for it IMHO.
Thanks. It might be a chance that we could separate sub drivers of
Exynos drm into independent modules so that they can be called
independently because if we move them to exynos_drm_init then the
deferred probe wouldn't work correctly.
I don't understand why registering the platform drivers in the
exynos_drm_init() will make deferred probing to not work correctly?
AFAICT it does not matter where the driver is registered since if the
driver probe function is called when the driver is attached and fails
with -EPROBE_DEFER, it will be added to the deferred list and the
probe function will be retried when other drivers are registered due
devices being added (e.g: by OF when matching a compatible string). Or
maybe I'm missing something here?
It's only by luck that it even worked before.
I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.
Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.
Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.
The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().
Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain
Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1
On Wed, Oct 1, 2014 at 4:12 PM, Daniel Drake dr...@endlessm.com wrote:
On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.
When we are getting the child node using for_each_available_child_of_node(),
which calls for of_get_next_available_child(). So
of_get_next_available_child()
does a of_node_put() on the prev node, in case we have siblings to the
child.
Can you see if the below change helps ?
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci-phy[phy_number] = phy;
- of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
This is on top of usb-next.
If you are testing on rc6 only, then probably you will have to cherrypick two
patches each for ehci-exynos and ohci-exynos:
usb: host: ehci-exynos: Remove unnecessary usb-phy support
usb: host: ohci-exynos: Remove unnecessary usb-phy support
I made the equivalent change to 3.17-rc7 (right now 3.17 is my main
interest), i.e. removed all of_node_put calls from
exynos_ehci_get_phy(). Same change is needed in exynos_ohci_get_phy().
Now the warnings are gone.
BTW, I think the warning only appeared when CONFIG_OF_SELFTEST=y
I didn't check the implementation details like you did, but I looked
at a few other users of for_each_available_child_of_node and it looks
like indeed you do not need to call of_node_put() on the children in
the normal case, or at least, nobody else does.
CONFIG_OF_SELFTEST enables CONFIG_OF_DYNAMIC, and reference counting
is only implemented when OF_DYNAMIC is enabled. That's probably why
selftest exposes the problem.
g.
--
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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote: On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as. One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware. Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed. As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary). Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :( As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. I posted a patch[0] earlier to do this for the clock framework in that other thread. The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver. Something similar could be done other frameworks. One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about. Agreed Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available. When simplefb
Re: Unable to boot mainline on snow chromebook since 3.15
On Wed, 10 Sep 2014 15:31:44 +0100, Mark Brown broo...@kernel.org wrote:
On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote:
On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
Well, lets see... We've got a real user complaining about a platform
that used to work on mainline, and no longer does. The only loophole
for ignoring breakage is if there nobody cares that it is broken. That
currently isn't the case. So even though it's based on a patch that
has DO NOT SUBMIT in large friendly letters on the front cover, it
doesn't change the situation that mainline has a regression.
Yeah, I'm with you on this Grant, it doesn't matter what the patch is
labelled as.
One way to deal with this could be to add a quirk at boot time --
looking for the simplefb and if found, modifies the regulators to keep
them on. That'd go in the kernel, not in firmware.
Well, we should also be fixing simplefb to manage the resources it uses
though that doesn't clean up after the broken DTs that are currently
deployed.
As well as the regulators we'll also need to fix the clocks. If we're
going to start adding these fixups perhaps we want to consider having a
wrapper stage that deals with rewriting DTs prior to trying to use them?
I'm not sure if it makes much difference but there's overlap with other
tools like the ATAGs conversion wrapper and building separately would
let the fixup code run early without directly going into the early init
code (which seems a bit scary).
We've already got a dt fixup hook in the machine struct, created for
exactly this reason. Fixing an incorrect DT provided by firmware:
arch/arm/include/asm/mach/arch.h:
struct machine_desc {
...
void (*dt_fixup)(void);
...
g.
--
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: Unable to boot mainline on snow chromebook since 3.15
On Wed, 10 Sep 2014 17:57:23 +0100, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 05:29:32PM +0100, Grant Likely wrote: What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit. It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency. I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints. g. -- 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: Unable to boot mainline on snow chromebook since 3.15
On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 06:06:46AM -0700, Olof Johansson wrote: On Mon, Sep 8, 2014 at 12:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as. One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware. Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed. As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary). Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :( As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. g. -- 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: Unable to boot mainline on snow chromebook since 3.15
On Wed, Sep 10, 2014 at 4:39 PM, Mark Brown broo...@kernel.org wrote: On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown broo...@kernel.org wrote: As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea? No, I don't think we can... there is a certain amount of firmware got things working for us, and we're going to use it for a while that is absolutely reasonable. simplefb is a good example, but there are certainly others. That bit is fine - I definitely think it's reasonable to have things like this where the device is initialized prior to the kernel starting and we use some simplified subset. What I think is a big problem here is that we're not being told what parts of the system state are relevant to this initialization (worse, we're being told things that are actively wrong for some of the resources). This seems inherently fragile. I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do. I think saying that it's a good idea to have an simplefb node without resource management is exactly the problem here - if we start from the assumption that this is a good idea we do get dragged down this path but it seems like we took a wrong turn going that way in the first place. It's not just regulators - we've got exactly the same problem with clocks on this system for example, they're also getting disabled because they seem unused and users have to pass in a kernel command line bodge to avoid that. We'd also have an issue if something decided to change the rates of some of the clocks, and power domains have the same problem (Ulf's patches to genericise their code has the same behaviour with regard to powering off unused domains, some of the existing implementations do that already). Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is. Right, I agree with what you're saying here but what I'm saying is that the way to ensure that the resources are protected is for the simplefb node to tell the kernel what resources are being used, otherwise it seems like we're just guessing and will fall over ourselves sooner or later. We can't use initcall hacks as these only work in cases where we will at some point hand over to a real driver and there seems to be a clear use case for using simplefb prior to that driver being written; even where we will hand over to a real driver we can't put a definite timescale on that happening since in the distro case it might be being loaded from disk at some point after userspace is running. What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit. I don't want to build knowledge of resource dependencies into the simple case. We'll simply frequently get it wrong. For example: A future kernel will have better PM and will turn off more devices which isn't accounted for in an older DT. g. -- 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. g. -- 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: Unable to boot mainline on snow chromebook since 3.15
On Mon, Sep 8, 2014 at 4:58 PM, Doug Anderson diand...@chromium.org wrote: Grant, On Mon, Sep 8, 2014 at 5:20 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux. I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on. Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform. In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a DO NOT SUBMIT patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c as I mentioned above. Is this really a device tree that we need to guarantee backward compatibility with? Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has DO NOT SUBMIT in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression. g. -- 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: [RESEND][PATCHv2 0/3] Fix for buggy u-boot memory banks
On Mon, 28 Jul 2014 11:56:42 -0700, Laura Abbott lau...@codeaurora.org wrote: On 7/26/2014 2:20 PM, Rob Herring wrote: On Tue, Jul 15, 2014 at 12:03 PM, Laura Abbott lau...@codeaurora.org wrote: Hi, This is a resend of the series to fix the uboot bug exposed by the removal of meminfo. I haven't gotten any acks though. Is the bug with ATAGs that get converted to DT in the decompressor or u-boot puts the wrong info in DT directly? I believe it's u-boot putting the wrong info in DT directly. See http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266782.html I've picked up this series with some very minor changes. I'll ask Linus to pull it into v3.16 as a last minute fix. g. -- 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/2] arm: Add back maximum bank limit
On Mon, Jun 30, 2014 at 7:03 PM, Laura Abbott lau...@codeaurora.org wrote: On 6/30/2014 3:43 AM, Grant Likely wrote: Instead of splitting early_init_dt_scan(), the call to early_init_dt_scan() could probably be moved after the of_flat_dt_match_machine() call. It's at least worth a try. Looking at the code I don't see anything obvious that requires the early_init_dt_scan() code to run first. of_flat_dt_match_machine - of_flat_dt_match which uses initial_boot_params which isn't set until early_init_dt_scan. I had the same thought about just rearranging but we still need something to be set before doing the scan, hence the split. Fair enough. Once you've got the mdesc pointer, you've could set the limit before doing the full scan. Or, better yet because this is a fix for broken data, you could call a dt_fixup hook on the mdesc. Then exynos is the only platform that needs special treatment. The best thing for exynos to do is fix the buggy data by clearing the bogus entries. Then there's no need to reintroduce early_init_dt_add_memory_arch() for ARM. The fixup hook does sound better. The flow would become setup_machine_fdt - early_init_dt_verify - of_flat_dt_match_machine - mdesc-dt_fixup - early_init_dt_scan_all I notice that powerpc already has a DT fixup infrastructure but I don't see any such thing for ARM. How much of that do you think could and should be leveraged for ARM? Not much. The PowerPC fixup infrastructure is based on having an OpenFirmware implementation and the fixups are performed by executing Forth commands in OFW before flattening the tree and killing OFW context. For ARM, any DT fixup hooks should directly use libfdt calls. g. -- 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/2] arm: Add back maximum bank limit
On Sun, 29 Jun 2014 12:06:24 -0700, Laura Abbott lau...@codeaurora.org wrote:
Commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
(ARM: 8025/1: Get rid of meminfo) dropped the upper bound on
the number of memory banks that can be added as there was no
technical need in the kernel. It turns out though, some bootloaders
(specifically the arndale-octa exynos boards) may pass invalid memory
information and rely on the kernel to not parse this data. This is a
bug in the bootloader but we still need to work around this.
Re-introduce a maximum bank limit per board to prevent invalid banks
from being passed to the kernel.
Reported-by: Tushar Behera trbli...@gmail.com
Signed-off-by: Laura Abbott lau...@codeaurora.org
Hi Laura,
This is more invasive than I'd like. I think it can be fixed more
elegantly. Some suggestions below...
---
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/265615.html
For those who did not see the discussion before
---
arch/arm/include/asm/mach/arch.h | 10 --
arch/arm/kernel/atags_parse.c| 1 +
arch/arm/kernel/devtree.c| 9 -
arch/arm/kernel/setup.c | 20
arch/arm/mach-exynos/exynos.c| 1 +
5 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/mach/arch.h
b/arch/arm/include/asm/mach/arch.h
index 060a75e..ebcc543 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -40,6 +40,8 @@ struct machine_desc {
unsigned intvideo_start;/* start of video RAM */
unsigned intvideo_end; /* end of video RAM */
+ unsigned intbank_limit; /* maximum number of memory
+ * banks to add */
unsigned char reserve_lp0 :1; /* never has lp0*/
unsigned char reserve_lp1 :1; /* never has lp1*/
unsigned char reserve_lp2 :1; /* never has lp2*/
@@ -76,6 +78,8 @@ extern const struct machine_desc __arch_info_begin[],
__arch_info_end[];
#define for_each_machine_desc(p) \
for (p = __arch_info_begin; p __arch_info_end; p++)
+extern void set_max_bank_limit(const struct machine_desc *mdesc);
+
/*
* Set of macros to define architecture features. This is built into
* a table by the linker.
@@ -85,7 +89,8 @@ static const struct machine_desc __mach_desc_##_type
\
__used \
__attribute__((__section__(.arch.info.init))) = { \
.nr = MACH_TYPE_##_type,\
- .name = _name,
+ .name = _name,\
+ .bank_limit = 12,
The hard limit of 12 seems entirely arbitrary. I don't like the idea of
reintroducing it. There shouldn't be any need for a default at all.
Leave it as zero, and the limit will only apply if a value has been set.
12 seems like an artificial limit. (more below)
#define MACHINE_END \
};
@@ -95,6 +100,7 @@ static const struct machine_desc __mach_desc_##_name
\
__used \
__attribute__((__section__(.arch.info.init))) = { \
.nr = ~0, \
- .name = _namestr,
+ .name = _namestr, \
+ .bank_limit = 12,
#endif
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 7807ef5..6b01d20 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -204,6 +204,7 @@ setup_machine_tags(phys_addr_t __atags_pointer, unsigned
int machine_nr)
dump_machine_table(); /* does not return */
}
+ set_max_bank_limit(mdesc);
Is there actually a bug on any atags booting? If this is firmly in the
realm of firmware workaround then I would drop the change from the atags
boot path.
if (__atags_pointer)
tags = phys_to_virt(__atags_pointer);
else if (mdesc-atag_offset)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index e94a157..04213ce 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -27,6 +27,10 @@
#include asm/mach/arch.h
#include asm/mach-types.h
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ arm_add_memory(base, size);
+}
#ifdef CONFIG_SMP
extern struct of_cpu_method __cpu_method_of_table[];
@@ -212,7 +216,7 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
mdesc_best = __mach_desc_GENERIC_DT;
#endif
- if (!dt_phys || !early_init_dt_scan(phys_to_virt(dt_phys)))
+ if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
return NULL;
Instead of splitting early_init_dt_scan(), the call to
early_init_dt_scan() could
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Tue, 29 Apr 2014 01:21:41 +0100, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Apr 29, 2014 at 09:02:27AM +0900, Simon Horman wrote: On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I would prefer if this patch was broken out into individual patches for each board or SoC file and that they were then picked up by their respective platform maintainers. Likewise for patch 66/97. Although it is only for shmobile I would prefer it broken out. Oh fuck that. Okay, I'm dropping the whole patch set right now and forgetting the whole damned thing. The L2 cache code can damned well stay as it is and remain an unmaintainable mess. FWIW, there are an awful lot of people, myself included, who do care that you've done this work. It is 100% okay for you to say no to requests to split things up because of the complexity of the series. I really hope you're reconsider and not give up on this series. g. -- 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: DT: fix gic interrupt controller documentation
On Thu, Mar 13, 2014 at 6:25 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Thu, Mar 13, 2014 at 11:44:33AM -0600, Stephen Warren wrote: On 03/13/2014 11:40 AM, Tim Harvey wrote: When using interrupt-maps, the size of a map entry is #address-cells + #interrupt-cells for the parent interrupt controller. For the ARM GIC address-cells should be 0 as this is not used. This patch fixes the example by correctly specifying #address-cells = 0. If the #address-cells property is required (well, or even optional...) in the node, shouldn't it be included in the list of required/optional properties above, and not solely included in the example? AFAIK, #address-cells = 0 is the same as not including a #address-cells at all. Omitting entirely is what other interrupt-controller bindings are doing, so I'd just drop mention of #address-cells completely. Correct. Just drop it. g. -- 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/4] Bugfix for of_match_node ordering
On Thu, Feb 20, 2014 at 8:39 AM, Sachin Kamat sachin.ka...@linaro.org wrote: Hi Grant, I observe the following boot failure with today's (next-20140220) linux-next tree on Exynos based boards with the default exynos_defconfig. Ugh, nested locking. that is not good. Kevin's patch looks correct and I'll merge it in. I'm a little disturbed though that you're the only one who has reported problems. Looking at what it does I would expect pretty much every SMP platform for freak out about this, but I've heard nothing from the powerpc guys. I'll merge in the fix of course, but I'd like to know what I'm missing. g. Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x900 [0.00] Linux version 3.14.0-rc3-next-20140220 (sachin@linaro) (gcc version 4.8.2 20130805 (prerelease) (crosstool-NG linaro-1. 13.1-4.8-2013.08 - Linaro GCC 2013.08) ) #1132 SMP PREEMPT Thu Feb 20 13:49:27 IST 2014 [0.00] CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Insignal Origen evaluation board based on Exynos4210 [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] CPU EXYNOS4210 (id 0x43210011) [0.00] On node 0 totalpages: 258048 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 190464 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 67584 pages, LIFO batch:15 [0.00] BUG: spinlock recursion on CPU#0, swapper/0 [0.00] lock: devtree_lock+0x0/0x10, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-rc3-next-20140220 #1132 [0.00] [c0013e9c] (unwind_backtrace) from [c0011250] (show_stack+0x10/0x14) [0.00] [c0011250] (show_stack) from [c0386740] (dump_stack+0x7c/0xbc) [0.00] [c0386740] (dump_stack) from [c005501c] (do_raw_spin_lock+0x188/0x18c) [0.00] [c005501c] (do_raw_spin_lock) from [c038b614] (_raw_spin_lock_irqsave+0x20/0x28) [0.00] [c038b614] (_raw_spin_lock_irqsave) from [c02de37c] (of_find_property+0x20/0x4c) [0.00] [c02de37c] (of_find_property) from [c02df110] (__of_device_is_compatible+0xb4/0x110) [0.00] [c02df110] (__of_device_is_compatible) from [c02df22c] (of_find_compatible_node+0x4c/0x7c) [0.00] [c02df22c] (of_find_compatible_node) from [c04cedf4] (exynos_firmware_init+0x18/0x7c) [0.00] [c04cedf4] (exynos_firmware_init) from [c04caef0] (setup_arch+0x860/0x898) [0.00] [c04caef0] (setup_arch) from [c04c7820] (start_kernel+0x80/0x3dc) [0.00] [c04c7820] (start_kernel) from [40008074] (0x40008074) [0.00] BUG: spinlock lockup suspected on CPU#0, swapper/0 [0.00] lock: devtree_lock+0x0/0x10, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-rc3-next-20140220 #1132 [0.00] [c0013e9c] (unwind_backtrace) from [c0011250] (show_stack+0x10/0x14) [0.00] [c0011250] (show_stack) from [c0386740] (dump_stack+0x7c/0xbc) [0.00] [c0386740] (dump_stack) from [c0054fac] (do_raw_spin_lock+0x118/0x18c) [0.00] [c0054fac] (do_raw_spin_lock) from [c038b614] (_raw_spin_lock_irqsave+0x20/0x28) [0.00] [c038b614] (_raw_spin_lock_irqsave) from [c02de37c] (of_find_property+0x20/0x4c) [0.00] [c02de37c] (of_find_property) from [c02df110] (__of_device_is_compatible+0xb4/0x110) [0.00] [c02df110] (__of_device_is_compatible) from [c02df22c] (of_find_compatible_node+0x4c/0x7c) [0.00] [c02df22c] (of_find_compatible_node) from [c04cedf4] (exynos_firmware_init+0x18/0x7c) [0.00] [c04cedf4] (exynos_firmware_init) from [c04caef0] (setup_arch+0x860/0x898) [0.00] [c04caef0] (setup_arch) from [c04c7820] (start_kernel+0x80/0x3dc) [0.00] [c04c7820] (start_kernel) from [40008074] (0x40008074) Regards, Sachin On 19 February 2014 19:44, Grant Likely grant.lik...@linaro.org wrote: Hi all, I've taken Kevin's latest rework and done even more rework on it. :-) I didn't quite like how it was looking so I rolled his scoring code directly into __of_device_is_compatible() so that the function always returns a score in a way that is still compatible with the existing users (ie. non-zero == successful match). This eliminates the need for a separate pscore argument and it also let me roll the type and name checks into the same function. I'm a lot happier with it overall and it makes for a slightly smaller number of lines of code changed. Please take a look and give it a spin. This is basically a bug fix so I'll need to push it out to Linus in the near future. Acks
Re: [PATCH v4 0/4] Bugfix for of_match_node ordering
On Thu, 20 Feb 2014 18:12:40 +0800, Kevin Hao haoke...@gmail.com wrote:
On Thu, Feb 20, 2014 at 02:09:08PM +0530, Sachin Kamat wrote:
Hi Grant,
I observe the following boot failure with today's (next-20140220) linux-next
tree on Exynos based boards with the default exynos_defconfig.
Does this help?
I've merged this in. I could get my unicore test platform to fail to
boot by turning on lock debugging. I'll leave that option on from now
one.
I've pushed this out to the following branch. Please test and report. It
will also be picked up by linux-next tomorrow.
git://git.secretlab.ca/git/linux devicetree/merge
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8a27fc907ab6..9cc893530b9a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -381,12 +381,16 @@ static int __of_device_is_compatible(const struct
device_node *device,
/* Compatible match has highest priority */
if (compat compat[0]) {
- of_property_for_each_string(device, compatible, prop, cp) {
+ prop = __of_find_property(device, compatible, NULL);
+ if (!prop)
+ return 0;
The above 2 lines are unnecessary. of_prop_next_string() will return
NULL if prop is NULL.
g.
+
+ for (cp = of_prop_next_string(prop, NULL); cp;
+ cp = of_prop_next_string(prop, cp), index++) {
if (of_compat_cmp(cp, compat, strlen(compat)) == 0) {
score = INT_MAX/2 - (index 2);
break;
}
- index++;
}
if (!score)
return 0;
Thanks,
Kevin
--
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 22/51] DMA-API: amba: get rid of separate dma_mask
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King rmk+ker...@arm.linux.org.uk wrote: AMBA Primecell devices always treat streaming and coherent DMA exactly the same, so there's no point in having the masks separated. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk for the drivers/of/platform.c portion: Acked-by: Grant Likely grant.lik...@linaro.org g. -- 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] i2c: move of helpers into the core
On Thu, 22 Aug 2013 18:00:14 +0200, Wolfram Sang w...@the-dreams.de wrote: I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Acked-by: Rob Herring rob.herr...@calxeda.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Wolfram Sang w...@the-dreams.de Acked-by: Grant Likely grant.lik...@linaro.org --- V2-V3: Was trying to be too smart by only fixing includes needed. Took a more general approach this time, converting of_i2c.h to i2c.h in case i2c.h was not already there. Otherwise remove it. Improved my build scripts and no build failures, no complaints from buildbot as well. Documentation/acpi/enumeration.txt |1 - arch/powerpc/platforms/44x/warp.c |1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c |1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |1 - drivers/gpu/host1x/drm/output.c |2 +- drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 109 +- drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +- drivers/media/platform/exynos4-is/fimc-is.c |2 +- drivers/media/platform/exynos4-is/media-dev.c |1 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- drivers/staging/imx-drm/imx-tve.c |2 +- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - sound/soc/fsl/imx-sgtl5000.c|2 +- sound/soc/fsl/imx-wm8962.c |2 +- 47 files changed, 138 insertions(+), 262 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c index 4cfa499..534574a 100644 --- a/arch/powerpc/platforms/44x/warp.c +++ b/arch/powerpc/platforms/44x/warp.c @@ -16,7 +16,6 @@ #include linux/interrupt.h #include linux/delay.h #include linux/of_gpio.h -#include linux/of_i2c.h #include linux/slab.h #include linux/export.h diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c index dfffaf0..a19f657 100644
Re: [PATCH] of: provide of_platform_unpopulate()
On Mon, 22 Jul 2013 16:16:07 -0500, Rob Herring robherri...@gmail.com wrote: On 07/21/2013 06:44 PM, Grant Likely wrote: On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring robherri...@gmail.com wrote: On 07/21/2013 09:42 AM, Rob Herring wrote: On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote: So I called of_platform_populate() on a device to get each child device probed and on rmmod and I need to reverse its doing. After a quick grep I did what others did as well and rmmod ended in: | Unable to handle kernel NULL pointer dereference at virtual address 0018 | PC is at release_resource+0x18/0x80 | Process rmmod (pid: 2005, stack limit = 0xedc30238) | [c003add0] (release_resource+0x18/0x80) from [c0300e08] (platform_device_del+0x78/0xac) | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] (platform_device_unregister+0xc/0x18) The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. Wouldn't the correct fix be to call insert_resource somehow? The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. BTW, it looks like Grant has attempted this already: Yup, things broke badly. Unfortunately the of_platform_device and platform_device history doesn't treat resources in the same way. I would like to merge the code, but I haven't been able to figure out a clean way to do it. Looks like we do need the unpopulate function. Was there more breakage than imx6 and amba devices? Your first version had a fallback case for powerpc. Couldn't we do just allow that for more than just powerpc? I'd much rather see some work-around within the core DT code with a warning to prevent more proliferation than putting this into drivers. It's tricky stuff. I've not figured out a solution I'm happy with. Trying to figure out when to apply a work around is hard because the resource reservation makes assumptions about the memory range layout that doesn't match the assumptions made by device tree code. One /possible/ option is to not add the resources to the devices at all when the device is registered and instead resolve them right at bind time. Jean Christophe proposed doing this already to solve a different problem; obtaining resources that require other drivers to be probed first. If the resources are resolved at .probe() time, then the resource registration problem should also go away. The downside to that approach is that it makes each deferred probe more expensive; potentially a *lot* more expensive depending on how much work the xlate functions have to do. It would be worth prototyping though to see how well it works. g. -- 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] of: provide of_platform_unpopulate()
On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring robherri...@gmail.com wrote: On 07/21/2013 09:42 AM, Rob Herring wrote: On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote: So I called of_platform_populate() on a device to get each child device probed and on rmmod and I need to reverse its doing. After a quick grep I did what others did as well and rmmod ended in: | Unable to handle kernel NULL pointer dereference at virtual address 0018 | PC is at release_resource+0x18/0x80 | Process rmmod (pid: 2005, stack limit = 0xedc30238) | [c003add0] (release_resource+0x18/0x80) from [c0300e08] (platform_device_del+0x78/0xac) | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] (platform_device_unregister+0xc/0x18) The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. Wouldn't the correct fix be to call insert_resource somehow? The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. BTW, it looks like Grant has attempted this already: Yup, things broke badly. Unfortunately the of_platform_device and platform_device history doesn't treat resources in the same way. I would like to merge the code, but I haven't been able to figure out a clean way to do it. Looks like we do need the unpopulate function. g. -- 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 9/9] ARM/dts: update device tree binding documentation for hdmi susbsystem
On Tue, 11 Jun 2013 19:41:31 +0530, Rahul Sharma rahul.sha...@samsung.com wrote: Update device tree binding documentation for hdmi subsystem with the clock information, phy property information and compatible strings for exynos5420. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Binding looks reasonable to me. I'll leave it to the video maintainers to say whether or not it is covers the right amount of configuration data. g. --- .../devicetree/bindings/video/exynos_hdmi.txt | 19 +++ .../devicetree/bindings/video/exynos_hdmiphy.txt| 10 -- .../devicetree/bindings/video/exynos_mixer.txt |7 +++ 3 files changed, 34 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 2ac01ca..e3c5853 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -4,6 +4,7 @@ Required properties: - compatible: value should be one among the following: 1) samsung,exynos4210-hdmi 2) samsung,exynos4212-hdmi + 3) samsung,exynos5420-hdmi - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -13,6 +14,20 @@ Required properties: c) pin function mode. d) optional flags and pull up/down. e) drive strength. +- clocks: list of clock IDs from SoC clock driver. + a) hdmi: It is required for gate operation on aclk_200_disp1 clock + which clocks the display1 block. + b) sclk_hdmi: It is required for gate operation on sclk_hdmi clock + which clocks hdmi IP. + c) sclk_pixel: Parent for mux mout_hdmi. + d) sclk_hdmiphy: Parent for mux mout_hdmi. + e) mout_hdmi: It is required by the driver to switch between the 2 + parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable + after configuration, parent is set to sclk_hdmiphy else + sclk_pixel. +- clock-names: aliases as per driver requirements for above clock IDs: + hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi. +- phy: this property holds the phandle for hdmiphy node. Example: @@ -21,4 +36,8 @@ Example: reg = 0x1453 0x10; interrupts = 0 95 0; hpd-gpio = gpx3 7 0xf 1 3; + clocks = clock 344, clock 136, clock 137, + clock 157, clock 1024; + clock-names = hdmi, sclk_hdmi, sclk_pixel, + sclk_hdmiphy, mout_hdmi; }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index fb688a6..e2b12ed 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt @@ -1,8 +1,14 @@ Device-Tree bindings for hdmiphy driver Required properties: -- compatible: value should be samsung,exynos4210-hdmiphy. -- reg: I2C address of the hdmiphy device. +- compatible: value should be one among the following + 1) Samsung,exynos4210-hdmiphy. + 2) Samsung,exynos5420-hdmiphy. + +- reg: it holds the physical address infomration for the hdmiphy device. + If it is a i2c device, reg holds the I2C address of the phy. For + platform bus mapped phy, reg property holds physical address as + well as size of the register region. Example: diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt index a8b063f..38e4e5c 100644 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt @@ -4,10 +4,15 @@ Required properties: - compatible: value should be: 1) samsung,exynos4210-mixer 2) samsung,exynos5250-mixer + 3) samsung,exynos5420-mixer - reg: physical base address of the mixer and length of memory mapped region. - interrupts: interrupt number to the cpu. +- clocks: list of clock IDs from SoC clock driver. + a) mixer: It is required for gate operation on aclk_200_disp1 clock + which clocks the display1 block. + b) sclk_hdmi: Parent for mux mout_mixer. Example: @@ -15,4 +20,6 @@ Example: compatible = samsung,exynos5250-mixer; reg = 0x1445 0x1; interrupts = 0 94 0; + clocks = clock 343, clock 136; + clock-names = mixer, sclk_hdmi; }; -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray andrew.mur...@arm.com wrote:
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture
specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
But comments below...
---
drivers/of/address.c | 67 ++
drivers/of/of_pci.c| 113
include/linux/of_address.h | 46 ++
3 files changed, 154 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..6eec70c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser);
of_pci_range_parser_init would be a clearer name
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
Similarly, of_pci_range_parser_one would be more consistent.
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..e5ab604 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include linux/export.h
#include linux/of.h
#include linux/of_pci.h
+#include linux/of_address.h
#include asm/prom.h
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Looks okay to me, and thank you very much for doing the legwork to merge the common code. Reviewed-by: Grant Likely grant.lik...@secretlab.ca -- 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: [REPOST PATCH] spi: s3c64xx: let device core setup the default pin configuration
On Mon, 15 Apr 2013 20:42:57 -0700, Doug Anderson diand...@chromium.org wrote: From: Thomas Abraham thomas.abra...@linaro.org With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org Applied, thanks. g. -- 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/4] spi: s3c64xx: add dma maxburst size initialization
On Fri, 22 Feb 2013 17:09:18 +0900, Boojin Kim boojin@samsung.com wrote:
This patch adds dma maxburst size initialization.
The maxburst should be set by MODE_CFGn.DMA_TYPE,
because the pl330 dma driver supports burst mode.
Signed-off-by: Hyeonkook Kim hk619@samsung.com
Hello Hyeonkook,
I applied this patch but then discovered that it relys on the previous
patches that you've posted. When patched depend on each other like this
please post them as a series with [PATCH x/4] in the subject line.
'git send-email' will format this correctly for you.
g.
---
drivers/spi/spi-s3c64xx.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index e862ab8..5e6cafe 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -287,10 +287,20 @@ static void prepare_dma(struct s3c64xx_spi_dma_data
*dma,
struct s3c64xx_spi_driver_data *sdd;
struct samsung_dma_prep info;
struct samsung_dma_config config;
+ void __iomem *regs;
+ unsigned int mode_cfg;
if (dma-direction == DMA_DEV_TO_MEM) {
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, rx_dma);
+
+ regs = sdd-regs;
+ mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG);
+ if (mode_cfg S3C64XX_SPI_MODE_4BURST)
+ config.maxburst = 4;
+ else
+ config.maxburst = 1;
+
config.direction = sdd-rx_dma.direction;
config.fifo = sdd-sfr_start + S3C64XX_SPI_RX_DATA;
config.width = sdd-cur_bpw / 8;
@@ -298,6 +308,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
} else {
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, tx_dma);
+
+ regs = sdd-regs;
+ mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG);
+ if (mode_cfg S3C64XX_SPI_MODE_4BURST)
+ config.maxburst = 4;
+ else
+ config.maxburst = 1;
+
config.direction = sdd-tx_dma.direction;
config.fifo = sdd-sfr_start + S3C64XX_SPI_TX_DATA;
config.width = sdd-cur_bpw / 8;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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/4] spi: s3c64xx: add dma maxburst size initialization
On Fri, 22 Feb 2013 17:09:18 +0900, Boojin Kim boojin@samsung.com wrote: This patch adds dma maxburst size initialization. The maxburst should be set by MODE_CFGn.DMA_TYPE, because the pl330 dma driver supports burst mode. Signed-off-by: Hyeonkook Kim hk619@samsung.com Applied, thanks. g. -- 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: moving dt binding documents for video devices to common place
On Wed, 06 Feb 2013 09:51:39 -0500, Rahul Sharma rahul.sha...@samsung.com wrote: Binding Documents for drm-devices are placed in Documentation/devicetree/bindings/drm/*. But these devices are common for v4l framework, hence moved to a common place at Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to associate them with exynos soc series. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Applied, thanks. A tip however, if you use the -M flag when posting patches it will show the files as moved instead of delete the old copy and create a new. It makes my life easier when that is done. g. -- 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 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
On Fri, 21 Dec 2012 10:13:50 -0800, Doug Anderson diand...@chromium.org wrote:
Vivek,
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
Hi all,
On Wed, Dec 19, 2012 at 7:20 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
CC: Doug Anderson
On Sat, Dec 15, 2012 at 12:53 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam
gautam.vi...@samsung.com wrote:
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 462e5ac..b3b9af1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -110,6 +110,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
samsung-i2s.1, NULL),
OF_DEV_AUXDATA(samsung,samsung-i2s, 0x12D7,
samsung-i2s.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-ehci, EXYNOS5_PA_EHCI,
+ s5p-ehci, NULL),
I'm assuming the above change is temporary. What is left to be done to
drop the auxdata in theses two patches?
Otherwise the patch looks fine.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Any more thought about this patch?
Or does this change seems fine?
I'm fairly certain we can just drop the OF_DEV_AUXDATA entry here. I
haven't been following this as closely as I should, but I know that
the comment for this table says that the whole purpose is to override
device names and that it should be temporary. We don't need to do any
overriding of device names here, do we?
When I drop this (and the ohci and phy) entries from my table I can
still boot and still can use USB. The big difference is what shows up
in dmesg
[1.605000] s5p-ehci s5p-ehci: S5P EHCI Host Controller
Becomes:
[1.55] s5p-ehci 1211.usb: S5P EHCI Host Controller
...and some sysfs paths change.
Right. Drop the AUXDATA then. :-)
g.
--
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] spi: remove check for bits_per_word on transfer from low level driver
On Thu, 20 Dec 2012 11:33:47 +0530, Laxman Dewangan ldewan...@nvidia.com
wrote:
On Wednesday 19 December 2012 09:54 PM, Grant Likely wrote:
On Tue, 18 Dec 2012 14:25:43 +0530, Laxman Dewanganldewan...@nvidia.com
wrote:
The spi core make sure that each transfer structure have the proper
setting for bits_per_word before calling low level transfer APIs.
Hence it is no more require to check again in low level driver for
this field whether this is set correct or not. Removing such code
from low level driver.
Signed-off-by: Laxman Dewanganldewan...@nvidia.com
[...]
*/
if (prev_speed_hz != speed_hz
@@ -316,9 +315,8 @@ static int txx9spi_transfer(struct spi_device *spi,
struct spi_message *m)
/* check each transfer's parameters */
list_for_each_entry (t,m-transfers, transfer_list) {
u32 speed_hz = t-speed_hz ? : spi-max_speed_hz;
- u8 bits_per_word = t-bits_per_word ? : spi-bits_per_word;
+ u8 bits_per_word = t-bits_per_word;
- bits_per_word = bits_per_word ? : 8;
Have you verified here that bits_per_word can never be '0' here? What is
the path that ensures spi-bits_per_word (and hence t-bits_per_word) is
set to 8 here?
Otherwise the patch looks good. Thanks for doing this work.
When we do the spi_add_device(), the spi_setup() get called.
In spi_setup, it make sure that spi-bits_per_word is not zero.
in spi_setup(spi.c)
if (!spi-bits_per_word)
spi-bits_per_word = 8;
Applied, thanks.
g.
--
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] i2c-core: Add gpio based bus arbitration implementation
On Fri, 14 Dec 2012 11:20:53 +0530, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
The arbitrator is a general purpose function which uses two GPIOs to
communicate with another device to claim/release a bus.
i2c_transfer()
if adapter-gpio_arbit
i2c_bus_claim();
__i2c_transfer();
i2c_bus_release();
Signed-off-by: Simon Glass s...@chromium.org
Cc: Grant Grundler grund...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Hi Naveen,
I'm not convinced on the design of this protocol. It won't scale beyond
2 bus masters and it seems very specific to the design of a specific
piece of hardware. I don't think it is mature enough to bake into the
core i2c infrastructure or bindings. Nor do I think it will handle other
busses properly.
I can see two alternatives here.
1) build in hooks for doing i2c bus claim/release, but don't put this
specific implementation into the core infrastructure
2) Create an i2c bridge driver. This would kind of be like an i2c
multiplexer, but it would only have one bus and it would include the
knowledge of how to use the GPIO lines for bus arbitration.
I think option 2 would be the cleanest option. It would be straight
forward to design a binding for it by placing a node between the i2c
bus and all the i2c clients. For example:
i2c@6000 {
compatible = acme,some-i2c-device;
#address-cells = 1;
#size-cells = 0;
i2c-bridge {
#address-cells = 1;
#size-cells = 0;
compatible = samaung,i2c-gpio-arbitrate;
bus-arbitration-gpios = gpf0 3 1 0 0, /* AP_CLAIM */
gpe0 4 0 3 0; /* EC_CLAIM */
bus-arbitration-slew-delay-us = 10;
bus-arbitration-wait-retry-us = 2000;
bus-arbitration-wait-free-us = 5;
i2c@52 {
// Normal i2c device
};
};
};
I don't know what the state of the i2c subsystem is with regard to
supporting i2c multiplexer devices, so there might be some changes
needed there, but I can't see it being particularly complex. It should
just be a device in the middle. Any i2c device that is a child of the
bridge would send transfers to the bridge, and the bridge would be
responsible to claim the bus and then pass the transfer through
unchanged.
That eliminates the problem of trying to design an arbitration scheme
that works for all.
g.
--
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 2/2] ASoC: SAMSUNG: Add DT support for i2s
On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna padm...@samsung.com
wrote:
Add support for device based discovery.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
.../devicetree/bindings/sound/samsung-i2s.txt | 75 +++
sound/soc/samsung/dma.c|1 +
sound/soc/samsung/dma.h|1 +
sound/soc/samsung/i2s.c| 233
4 files changed, 269 insertions(+), 41 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/samsung-i2s.txt
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
new file mode 100644
index 000..bff47b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -0,0 +1,75 @@
+* Samsung I2S controller
+
+Required SoC Specific Properties:
+
+- compatible : samsung,samsung-i2s
Isn't that kind of redundant? :-)
The format of the compatible strings should be vendor,part-number-i2s.
Please be specific about the part number that you're doing the binding
for. For example; use samsung,exynos4210-i2s instead of samsung,exynos-i2s.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+[PRELIMINARY: the dma channel allocation will change once there are
+official DMA bindings]
+
+- tx-dma-channel-secondary: The dma channel specifier for secondary tx
+ operations. The format of the dma specifier depends on the dma
+ controller.
+- tx-dma-channel: The dma channel specifier for tx operations. The format of
+ the dma specifier depends on the dma controller.
+- rx-dma-channel: The dma channel specifier for rx operations. The format of
+ the dma specifier depends on the dma controller.
+
+Optional SoC Specific Properties:
+
+- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel
+ support, this flag is enabled.
+- samsung,supports-rstclr: This flag should be set if I2S software reset bit
+ control is required. When this flag is set I2S software reset bit will be
+ enabled or disabled based on need.
+- samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA,
+ then this flag is enabled.
+- samsung,idma-addr: Internal DMA register base address of the audio
+ sub system(used in secondary sound source).
+
+Required Board Specific Properties:
+
+- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK
+ interface lines. The format of the gpio specifier depends on the gpio
+ controller.
+ The syntax of samsung gpio specifier is
+ [phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [mux function]
+ [flags and pull up/down]
+ [drive strength]
+
+Aliases:
+
+- All the I2S controller nodes are represented in the aliases node using
+ the following format 'i2s{n}' where n is a unique number for the alias.
Are the aliases actually being used now? If not, then drop this section.
I don't see any references in this patch.
Otherwise the binding looks good to me.
g.
--
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] spi: remove check for bits_per_word on transfer from low level driver
On Tue, 18 Dec 2012 14:25:43 +0530, Laxman Dewangan ldewan...@nvidia.com
wrote:
The spi core make sure that each transfer structure have the proper
setting for bits_per_word before calling low level transfer APIs.
Hence it is no more require to check again in low level driver for
this field whether this is set correct or not. Removing such code
from low level driver.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
[...]
diff --git a/drivers/spi/spi-txx9.c b/drivers/spi/spi-txx9.c
index d5a3cbb..550b5f4 100644
--- a/drivers/spi/spi-txx9.c
+++ b/drivers/spi/spi-txx9.c
@@ -189,9 +189,8 @@ static void txx9spi_work_one(struct txx9spi *c, struct
spi_message *m)
unsigned int len = t-len;
unsigned int wsize;
u32 speed_hz = t-speed_hz ? : spi-max_speed_hz;
- u8 bits_per_word = t-bits_per_word ? : spi-bits_per_word;
+ u8 bits_per_word = t-bits_per_word;
- bits_per_word = bits_per_word ? : 8;
wsize = bits_per_word 3; /* in bytes */
if (prev_speed_hz != speed_hz
@@ -316,9 +315,8 @@ static int txx9spi_transfer(struct spi_device *spi,
struct spi_message *m)
/* check each transfer's parameters */
list_for_each_entry (t, m-transfers, transfer_list) {
u32 speed_hz = t-speed_hz ? : spi-max_speed_hz;
- u8 bits_per_word = t-bits_per_word ? : spi-bits_per_word;
+ u8 bits_per_word = t-bits_per_word;
- bits_per_word = bits_per_word ? : 8;
Have you verified here that bits_per_word can never be '0' here? What is
the path that ensures spi-bits_per_word (and hence t-bits_per_word) is
set to 8 here?
Otherwise the patch looks good. Thanks for doing this work.
g.
--
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] gpio: samsung: remove exynos_gpio_cfg
On Fri, 14 Dec 2012 19:44:01 +0900, Joonyoung Shim jy0922.s...@samsung.com wrote: The exynos_gpio_cfg can be substituted to samsung_gpio_cfgs[8]. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com Hi Joonyoung, I need some help here. I don't understand what this patch is for or how it works. The commit text above doesn't give me enough information to evaluate the patch. What is the intent here? Why is samsung_gpio_cfgs[8] more correct than exynos_gpio_cfg? g. -- 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] i2c-core: Add gpio based bus arbitration implementation
On Wed, Dec 19, 2012 at 5:14 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Dec 19, 2012 at 12:32:01PM +, Grant Likely wrote: I'm not convinced on the design of this protocol. It won't scale beyond 2 bus masters and it seems very specific to the design of a specific piece of hardware. I don't think it is mature enough to bake into the I ought to point out that the original patch would've baked this into the Samsung I2C driver but I asked for it to be split out as it's nothing to do with the controller really and I'm sure I've seen it before. Indeed, baking it into the driver is also the wrong abstraction. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] i2c-core: Add gpio based bus arbitration implementation
On Thu, Dec 20, 2012 at 12:17 AM, Simon Glass s...@chromium.org wrote: On Wed, Dec 19, 2012 at 9:14 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Dec 19, 2012 at 12:32:01PM +, Grant Likely wrote: I'm not convinced on the design of this protocol. It won't scale beyond 2 bus masters and it seems very specific to the design of a specific piece of hardware. I don't think it is mature enough to bake into the I ought to point out that the original patch would've baked this into the Samsung I2C driver but I asked for it to be split out as it's nothing to do with the controller really and I'm sure I've seen it before. Grant your idea looks nice to me. I only worry if we should wait until we have a second user before going so far with it. But it is certainly a nice general solution. The scaling beyond two bus masters would require the code to be changed to check more input lines from other masters. Best avoided for now I think until we have a use for it. There is two parts to this; the design of the binding, and the implementation. Of the two, the binding is the most difficult to change, so it is important to get something we can live with long term sorted out now. The implementation can start somewhat naive, with a plan for how to extend it. Regarding the scaling to multiple devices, it is a much smaller issue (if an issue at all) if the arbitration back end is pluggable. Then it becomes easy to support hardware with a different arbitration protocol. If it gets baked into the core i2c code, then we've got a problem and a lot more scrutiny needs to be put into this specific protocol. g. -- 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/2] usb: exynos: Fix compatible strings used for device
On Thu, 13 Dec 2012 20:22:26 +0530, Vivek Gautam gautam.vi...@samsung.com wrote: Using chip specific compatible string as it should be. So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos which till now used a generic 'exynos' in their compatible strings. This goes as per the discussion happened in the thread for [PATCH v2] ARM: Exynos5250: Enabling dwc3-exynos driver available at: http://www.spinics.net/lists/linux-usb/msg74145.html Vivek Gautam (2): usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device usb: dwc3-exynos: Fix compatible strings for the device for both patches: Acked-by: Grant Likely grant.lik...@secretlab.ca drivers/usb/dwc3/dwc3-exynos.c |2 +- drivers/usb/host/ehci-s5p.c|2 +- drivers/usb/host/ohci-exynos.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.6.5 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam gautam.vi...@samsung.com
wrote:
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
5 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ehci for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 711b55f..f990086 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -218,4 +218,8 @@
i2s_2: i2s@12D7 {
status = disabled;
};
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 581e57a..584bb9a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -299,6 +299,12 @@
rx-dma-channel = pdma0 11; /* preliminary */
};
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index cbb2852..b2c662f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -201,6 +201,7 @@
#define EXYNOS4_PA_EHCI 0x1258
#define EXYNOS4_PA_OHCI 0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_EHCI 0x1211
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART 0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 462e5ac..b3b9af1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -110,6 +110,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
samsung-i2s.1, NULL),
OF_DEV_AUXDATA(samsung,samsung-i2s, 0x12D7,
samsung-i2s.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-ehci, EXYNOS5_PA_EHCI,
+ s5p-ehci, NULL),
I'm assuming the above change is temporary. What is left to be done to
drop the auxdata in theses two patches?
Otherwise the patch looks fine.
Acked-by: Grant Likely grant.lik...@secretlab.ca
--
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 RFC 01/12] s5p-csis: Add device tree support
On Tue, 11 Dec 2012 12:24:23 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hello Grant, On 12/11/2012 09:36 AM, Grant Likely wrote: On Mon, 10 Dec 2012 20:45:55 +0100, Sylwester Nawrocki s.nawro...@samsung.com wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC (camera host interface DMA engine and image processor). This patch adds support for instantiating the MIPI-CSIS devices from DT and parsing all SoC and board specific properties from device tree. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../bindings/media/soc/samsung-mipi-csis.txt | 82 +++ drivers/media/platform/s5p-fimc/mipi-csis.c| 155 +++- drivers/media/platform/s5p-fimc/mipi-csis.h|1 + 3 files changed, 202 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt new file mode 100644 index 000..f57cbdc --- /dev/null +++ b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt @@ -0,0 +1,82 @@ +Samsung S5P/EXYNOS SoC MIPI-CSI2 receiver (MIPI CSIS) +- + +Required properties: + +- compatible: samsung,s5pv210-csis for S5PV210 SoCs, + samsung,exynos4210-csis for Exynos4210 and later SoCs; +- reg : physical base address and size of the device memory mapped + registers; +- interrupts : should contain MIPI CSIS interrupt; the format of the + interrupt specifier depends on the interrupt controller; +- max-data-lanes : maximum number of data lanes supported (SoC specific); +- vddio-supply: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V); +- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V). + +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default + value when this property is not specified is 166 MHz; +- samsung,csis,wclk : CSI-2 wrapper clock selection. If this property is present + external clock from CMU will be used, if not bus clock will + be selected. + +The device node should contain one 'port' child node with one child 'endpoint' +node, as outlined in the common media bindings specification. See +Documentation/devicetree/bindings/media/v4l2.txt for details. The following are +properties specific to those nodes. (TODO: update the file path) + +port node +- + +- reg : (required) must be 2 for camera C input (CSIS0) or 3 for + camera D input (CSIS1); 'reg' has a very specific definition. If you're going to use a reg property here, then the parent nodes need to have #address-cells=1;#size-cells=0; properties to define the address specifier format. However since you're identifying port numbers that aren't really addresses I would suggest simply changing this property to something like 'port-num'. Otherwise the binding looks good. Thank you for the review. Indeed I should have said about #address-cells, #size-cells here. I thought using 'reg' was agreed during previous discussions on the mailing lists (e.g. [1]), so I just carried on with 'reg'. I should just have addressed the comments from Stephen and Rob, instead of just resending same version of the documentation. I'll try to take care of it in the next post. i.e. rename 'link' node to 'endpoint' and 'remote' phandle to 'remote-endpoint'. Could be. I can't remember what has been discussed from one day to the next. :-) If you've got #address/#size-cells in the binding, then reg is fine. If that's what you've already got, then just leave it. As long as the conventions are intact. g. -- 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/2] Add DT support for i2s
On Thu, 6 Dec 2012 13:11:42 +0900, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Dec 06, 2012 at 09:31:40AM +0530, Padma Venkat wrote: On Wed, Nov 28, 2012 at 4:17 PM, Padmavathi Venna padm...@samsung.com wrote: Padmavathi Venna (2): ASoC: Samsung: Get I2S src_clk from clock alias id. ASoC: SAMSUNG: Add DT support for i2s Any comments on DT support for i2s patch? If not when this patch can be pulled? Don't send contentless pings. I still don't really like what's going on with aliases here, I need to understand why things are structured the way they are to say something about that. Right. On a brief look, it appears that the binding is using aliases as a way to encode implementation specific details of the driver. g. -- 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] ARM: Exynos5250: Enabling dwc3-exynos driver
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -197,6 +197,7 @@
#define EXYNOS4_PA_EHCI 0x1258
#define EXYNOS4_PA_OHCI 0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_DRD 0x1200
#define EXYNOS5_PA_EHCI 0x1211
#define EXYNOS5_PA_OHCI 0x1212
#define EXYNOS4_PA_MFC 0x1340
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index c03f3dd..303 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -90,6 +90,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
s5p-ehci, NULL),
OF_DEV_AUXDATA(samsung,exynos-ohci, EXYNOS5_PA_OHCI,
exynos-ohci, NULL),
+ OF_DEV_AUXDATA(samsung,exynos-dwc3, EXYNOS5_PA_DRD,
+ exynos-dwc3, NULL),
{},
};
--
1.7.6.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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] ARM: Exynos5250: Enabling ehci-s5p driver
On Thu, 08 Nov 2012 12:24:24 +0530, Vivek Gautam gautam.vi...@samsung.com wrote: Adding EHCI device tree node for Exynos5250 along with the device base adress and gpio line for vbus. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Acked-by: Jingoo Han jg1@samsung.com --- .../devicetree/bindings/usb/exynos-usb.txt | 25 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++ arch/arm/boot/dts/exynos5250.dtsi |6 arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos5-dt.c |2 + 5 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt new file mode 100644 index 000..833f5cf --- /dev/null +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -0,0 +1,25 @@ +Samsung Exynos SoC USB controller + +The USB devices interface with USB controllers on Exynos SOCs. +The device node has following properties. + +EHCI +Required properties: + - compatible: should be samsung,exynos-ehci for USB 2.0 Ditto here. Please be specific in compatible strings. samsung,exynos5250-ehci Otherwise the binding looks fine to me. g. -- 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] spi: Change FIFO flush operation and spi channel off
On Wed, 23 May 2012 21:29:51 +0900, Kyoungil Kim ki0351@samsung.com wrote: Setting SW_RST does TX/RX FIFO flush. After FIFO flush, SW_RST should be cleared. The above setting and clearing SW_RST operation should be done after spi channel off. Signed-off-by: Kyoungil Kim ki0351@samsung.com Applied, thanks. g. --- drivers/spi/spi-s3c64xx.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c index 972a94c..293f097 100644 --- a/drivers/spi/spi-s3c64xx.c +++ b/drivers/spi/spi-s3c64xx.c @@ -191,6 +191,10 @@ static void flush_fifo(struct s3c64xx_spi_driver_data *sdd) writel(0, regs + S3C64XX_SPI_PACKET_CNT); val = readl(regs + S3C64XX_SPI_CH_CFG); + val = ~(S3C64XX_SPI_CH_RXCH_ON | S3C64XX_SPI_CH_TXCH_ON); + writel(val, regs + S3C64XX_SPI_CH_CFG); + + val = readl(regs + S3C64XX_SPI_CH_CFG); val |= S3C64XX_SPI_CH_SW_RST; val = ~S3C64XX_SPI_CH_HS_EN; writel(val, regs + S3C64XX_SPI_CH_CFG); @@ -224,10 +228,6 @@ static void flush_fifo(struct s3c64xx_spi_driver_data *sdd) val = readl(regs + S3C64XX_SPI_MODE_CFG); val = ~(S3C64XX_SPI_MODE_TXDMA_ON | S3C64XX_SPI_MODE_RXDMA_ON); writel(val, regs + S3C64XX_SPI_MODE_CFG); - - val = readl(regs + S3C64XX_SPI_CH_CFG); - val = ~(S3C64XX_SPI_CH_RXCH_ON | S3C64XX_SPI_CH_TXCH_ON); - writel(val, regs + S3C64XX_SPI_CH_CFG); } static void s3c64xx_spi_dmacb(void *data) -- 1.7.1 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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] spi: Keep chipselect assertion during one message
On Wed, 23 May 2012 21:34:06 +0900, Kyoungil Kim ki0351@samsung.com wrote: During all transfers in one message, the device will not be chagned. So we don't need to deassert chipselect during one message. Signed-off-by: Kyoungil Kim ki0351@samsung.com Applied, thanks. g. --- drivers/spi/spi-s3c64xx.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c index 972a94c..0f79f5b 100644 --- a/drivers/spi/spi-s3c64xx.c +++ b/drivers/spi/spi-s3c64xx.c @@ -745,8 +745,6 @@ static int s3c64xx_spi_transfer_one_message(struct spi_master *master, if (list_is_last(xfer-transfer_list, msg-transfers)) cs_toggle = 1; - else - disable_cs(sdd, spi); } msg-actual_length += xfer-len; -- 1.7.1 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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/3] gpio: exynos4: skip gpiolib registration if pinctrl driver is used
On Thu, 24 May 2012 05:17:37 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Pinctrl driver, when enabled, registers all the gpio pins and hence the
registration of gpio pins by this driver can be skipped.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/gpio/gpio-samsung.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 19d6fc0..34a9638 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2788,6 +2788,27 @@ static __init int samsung_gpiolib_init(void)
#ifdef CONFIG_CPU_EXYNOS4210
void __iomem *gpx_base;
+#ifdef CONFIG_OF
+ /*
+ * This gpio driver includes support for device tree support and
+ * there are platforms using it. In order to maintain
+ * compatibility with those platforms, and to allow non-dt
+ * Exynos4210 platforms to use this gpiolib support, a check
+ * is added to find out if there is a active pin-controller
+ * driver support available. If it is available, this gpiolib
+ * support is ignored and the gpiolib support available in
+ * pin-controller driver is used. This is a temporary check and
+ * will go away when all of the Exynos4210 platforms have
+ * switched to using device tree and the pin-ctrl driver.
+ */
+ struct device_node *pctrl_np;
+ const char *pctrl_compat = samsung,pinctrl-exynos4210;
+ pctrl_np = of_find_compatible_node(NULL, NULL, pctrl_compat);
+ if (pctrl_np)
+ if (of_device_is_available(pctrl_np))
+ return -ENODEV;
+#endif
+
/* gpio part1 */
gpio_base1 = ioremap(EXYNOS4_PA_GPIO1, SZ_4K);
if (gpio_base1 == NULL) {
--
1.6.6.rc2
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 01/10] spi: s3c64xx: remove unused S3C64XX_SPI_ST_TRLCNTZ macro
On Wed, 09 May 2012 03:34:45 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: The macro S3C64XX_SPI_ST_TRLCNTZ is not used and hence it is removed. Cc: Jaswinder Singh jaswinder.si...@linaro.org Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca Since this series has dependencies, I'm fine with it going via another tree. g. -- 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/10] spi: s3c64xx: move controller information into driver data
On Wed, 09 May 2012 03:34:46 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Platform data is used to specify controller hardware specific information
such as the tx/rx fifo level mask and bit offset of rx fifo level. Such
information is not suitable to be supplied from device tree. Instead,
it can be moved into the driver data and removed from platform data.
Cc: Jaswinder Singh jaswinder.si...@linaro.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/spi/spi-s3c64xx.c | 180
++---
1 files changed, 153 insertions(+), 27 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 6a3d51a..f6bc0e3 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -31,6 +31,8 @@
#include mach/dma.h
#include plat/s3c64xx-spi.h
+#define MAX_SPI_PORTS3
+
/* Registers and bit-fields */
#define S3C64XX_SPI_CH_CFG 0x00
@@ -113,9 +115,12 @@
#define S3C64XX_SPI_FBCLK_MSK(30)
-#define S3C64XX_SPI_ST_TX_DONE(v, i) (((v) (1 (i)-tx_st_done)) ? 1 : 0)
-#define TX_FIFO_LVL(v, i) (((v) 6) (i)-fifo_lvl_mask)
-#define RX_FIFO_LVL(v, i) (((v) (i)-rx_lvl_offset) (i)-fifo_lvl_mask)
+#define FIFO_LVL_MASK(i) ((i)-port_conf-fifo_lvl_mask[i-port_id])
+#define S3C64XX_SPI_ST_TX_DONE(v, i) (((v) \
+ (1 (i)-port_conf-tx_st_done)) ? 1 : 0)
+#define TX_FIFO_LVL(v, i) (((v) 6) FIFO_LVL_MASK(i))
+#define RX_FIFO_LVL(v, i) (((v) (i)-port_conf-rx_lvl_offset) \
+ FIFO_LVL_MASK(i))
#define S3C64XX_SPI_MAX_TRAILCNT 0x3ff
#define S3C64XX_SPI_TRAILCNT_OFF 19
@@ -134,6 +139,28 @@ struct s3c64xx_spi_dma_data {
};
/**
+ * struct s3c64xx_spi_info - SPI Controller hardware info
+ * @fifo_lvl_mask: Bit-mask for {TX|RX}_FIFO_LVL bits in SPI_STATUS register.
+ * @rx_lvl_offset: Bit offset of RX_FIFO_LVL bits in SPI_STATUS regiter.
+ * @tx_st_done: Bit offset of TX_DONE bit in SPI_STATUS regiter.
+ * @high_speed: True, if the controller supports HIGH_SPEED_EN bit.
+ * @clk_from_cmu: True, if the controller does not include a clock mux and
+ * prescaler unit.
+ *
+ * The Samsung s3c64xx SPI controller are used on various Samsung SoC's but
+ * differ in some aspects such as the size of the fifo and spi bus clock
+ * setup. Such differences are specified to the driver using this structure
+ * which is provided as driver data to the driver.
+ */
+struct s3c64xx_spi_port_config {
+ int fifo_lvl_mask[MAX_SPI_PORTS];
+ int rx_lvl_offset;
+ int tx_st_done;
+ boolhigh_speed;
+ boolclk_from_cmu;
+};
+
+/**
* struct s3c64xx_spi_driver_data - Runtime info holder for SPI driver.
* @clk: Pointer to the spi clock.
* @src_clk: Pointer to the clock used to generate SPI signals.
@@ -171,6 +198,8 @@ struct s3c64xx_spi_driver_data {
struct s3c64xx_spi_dma_data rx_dma;
struct s3c64xx_spi_dma_data tx_dma;
struct samsung_dma_ops *ops;
+ struct s3c64xx_spi_port_config *port_conf;
+ unsignedport_id;
};
static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
@@ -179,7 +208,6 @@ static struct s3c2410_dma_client s3c64xx_spi_dma_client =
{
static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
{
- struct s3c64xx_spi_info *sci = sdd-cntrlr_info;
void __iomem *regs = sdd-regs;
unsigned long loops;
u32 val;
@@ -195,7 +223,7 @@ static void flush_fifo(struct s3c64xx_spi_driver_data
*sdd)
loops = msecs_to_loops(1);
do {
val = readl(regs + S3C64XX_SPI_STATUS);
- } while (TX_FIFO_LVL(val, sci) loops--);
+ } while (TX_FIFO_LVL(val, sdd) loops--);
if (loops == 0)
dev_warn(sdd-pdev-dev, Timed out flushing TX FIFO\n);
@@ -204,7 +232,7 @@ static void flush_fifo(struct s3c64xx_spi_driver_data
*sdd)
loops = msecs_to_loops(1);
do {
val = readl(regs + S3C64XX_SPI_STATUS);
- if (RX_FIFO_LVL(val, sci))
+ if (RX_FIFO_LVL(val, sdd))
readl(regs + S3C64XX_SPI_RX_DATA);
else
break;
@@ -302,7 +330,6 @@ static void enable_datapath(struct
s3c64xx_spi_driver_data *sdd,
struct spi_device *spi,
struct spi_transfer *xfer, int dma_mode)
{
- struct s3c64xx_spi_info *sci = sdd-cntrlr_info;
void __iomem *regs = sdd-regs;
u32 modecfg, chcfg;
@@ -352,7 +379,7 @@ static void enable_datapath(struct
s3c64xx_spi_driver_data *sdd,
if (xfer-rx_buf != NULL) {
sdd-state |= RXBUSY;
- if (sci-high_speed sdd-cur_speed = 3000UL
+ if (sdd-port_conf-high_speed
Re: [PATCH 05/10] ARM: Samsung: Update the device names for spi clock lookup
On Sun, 13 May 2012 15:51:35 +0100, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, May 10, 2012 at 01:17:32AM +0800, Thomas Abraham wrote: On 9 May 2012 22:28, Mark Brown broo...@opensource.wolfsonmicro.com wrote: This means that bisection will be broken - anything with only one tree won't be able to load the SPI driver successfully until it's merged with the other which isn't ideal. Yes, we would have that problem until the two trees are merged. But I still prefer not to squash the two patches which already contain huge diff. I'd not say the diff is *that* big (and most of what's there is simple and repetitive), and bisection is a very useful tool. I know I frequently find it enormously painful trying to figure out breakage when large chunks of the history don't work usefully. I agree. Squash them! g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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 07/10] spi: s3c64xx: Remove the 'set_level' callback from controller data
On Wed, 09 May 2012 03:34:51 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
The set_level callback in the controller data, which is used to configure
the slave select line, cannot be supported when migrating the driver to
device tree based discovery. Since all the platforms currently use gpio
as the slave select line, this callback can be removed from the
controller data and replaced with call to gpio_set_value in the driver.
Cc: Jaswinder Singh jaswinder.si...@linaro.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |2 --
drivers/spi/spi-s3c64xx.c|8
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
index a733ce9..48a6495 100644
--- a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
+++ b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
@@ -18,7 +18,6 @@ struct platform_device;
* @fb_delay: Slave specific feedback delay.
*Refer to FB_CLK_SEL register definition in SPI chapter.
* @line: Custom 'identity' of the CS line.
- * @set_level: CS line control.
*
* This is per SPI-Slave Chipselect information.
* Allocate and initialize one in machine init code and make the
@@ -27,7 +26,6 @@ struct platform_device;
struct s3c64xx_spi_csinfo {
u8 fb_delay;
unsigned line;
- void (*set_level)(unsigned line_id, int lvl);
};
/**
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f6bc0e3..d84ce7f 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -406,14 +406,14 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd-tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd-tgl_spi-controller_data;
- cs-set_level(cs-line,
- spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line,
+ spi-mode SPI_CS_HIGH ? 0 : 1);
}
sdd-tgl_spi = NULL;
}
cs = spi-controller_data;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
}
static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -499,7 +499,7 @@ static inline void disable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd-tgl_spi == spi)
sdd-tgl_spi = NULL;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
}
static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
--
1.6.6.rc2
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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/6] spi: s3c64xx: add support for device tree
On Fri, 18 May 2012 15:03:27 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Changes since v1:
Heh, I really should look further down my inbox before I start
replying to old patches. I'll recheck this version of the changes,
but I'm still happy for this stuff to go via arm-soc or whatever
branch makes the most sense.
g.
- Incorporated changes suggested by Mark Brown
- Merged 2nd, 3rd and 5th patch into one single patch.
- Listed the order of gpios in the device tree support documentation.
- Switched to generic property names for chip select gpio line and
number of slave select lines.
- Moved the platform enablement patches for Exynos4 and Exynos5 into a
different patch series.
- Included Ack from Jaswinder Singh jaswinder.si...@linaro.org.
This patch series adds device tree based discovery support for Samsung's
s3c64xx compatible spi controller. This is mainly tested for Exynos4210
and Exynos5250 with onboard spi nor flash device.
Thomas Abraham (6):
spi: s3c64xx: remove unused S3C64XX_SPI_ST_TRLCNTZ macro
spi: s3c64xx: move controller information into driver data
ARM: Samsung: Remove pdev pointer paremeter from spi gpio setup functions
ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
spi: s3c64xx: Remove the 'set_level' callback from controller data
spi: s3c64xx: add device tree support
.../devicetree/bindings/spi/spi-samsung.txt| 113 +
arch/arm/mach-exynos/clock-exynos4.c | 18 +-
arch/arm/mach-exynos/setup-spi.c | 33 +--
arch/arm/mach-s3c24xx/clock-s3c2416.c |2 +-
arch/arm/mach-s3c24xx/clock-s3c2443.c |2 +-
arch/arm/mach-s3c24xx/common-s3c2443.c |4 +-
arch/arm/mach-s3c24xx/setup-spi.c | 10 +-
arch/arm/mach-s3c64xx/clock.c | 20 +-
arch/arm/mach-s3c64xx/mach-crag6410.c |2 +-
arch/arm/mach-s3c64xx/setup-spi.c | 19 +-
arch/arm/mach-s5p64x0/clock-s5p6440.c | 12 +-
arch/arm/mach-s5p64x0/clock-s5p6450.c | 12 +-
arch/arm/mach-s5p64x0/setup-spi.c | 21 +-
arch/arm/mach-s5pc100/clock.c | 30 +-
arch/arm/mach-s5pc100/setup-spi.c | 30 +--
arch/arm/mach-s5pv210/clock.c | 14 +-
arch/arm/mach-s5pv210/setup-spi.c | 21 +-
arch/arm/plat-samsung/devs.c | 50 +--
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 31 +-
drivers/spi/spi-s3c64xx.c | 467
+---
20 files changed, 611 insertions(+), 300 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-samsung.txt
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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] spi: s3c64xx: remove unused S3C64XX_SPI_ST_TRLCNTZ macro
On Fri, 18 May 2012 15:03:28 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: The macro S3C64XX_SPI_ST_TRLCNTZ is not used and hence it is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Jaswinder Singh jaswinder.si...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca --- drivers/spi/spi-s3c64xx.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c index 972a94c..6a3d51a 100644 --- a/drivers/spi/spi-s3c64xx.c +++ b/drivers/spi/spi-s3c64xx.c @@ -113,10 +113,6 @@ #define S3C64XX_SPI_FBCLK_MSK(30) -#define S3C64XX_SPI_ST_TRLCNTZ(v, i) v) (i)-rx_lvl_offset) \ - (((i)-fifo_lvl_mask + 1))) \ - ? 1 : 0) - #define S3C64XX_SPI_ST_TX_DONE(v, i) (((v) (1 (i)-tx_st_done)) ? 1 : 0) #define TX_FIFO_LVL(v, i) (((v) 6) (i)-fifo_lvl_mask) #define RX_FIFO_LVL(v, i) (((v) (i)-rx_lvl_offset) (i)-fifo_lvl_mask) -- 1.6.6.rc2 -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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 2/6] spi: s3c64xx: move controller information into driver data
On Fri, 18 May 2012 15:03:29 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Platform data is used to specify controller hardware specific information
such as the tx/rx fifo level mask and bit offset of rx fifo level. Such
information is not suitable to be supplied from device tree. Instead,
it can be moved into the driver data and removed from platform data.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Jaswinder Singh jaswinder.si...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-exynos/clock-exynos4.c | 18 +-
arch/arm/mach-exynos/setup-spi.c | 25 ---
arch/arm/mach-s3c24xx/clock-s3c2416.c|2 +-
arch/arm/mach-s3c24xx/clock-s3c2443.c|2 +-
arch/arm/mach-s3c24xx/common-s3c2443.c |4 +-
arch/arm/mach-s3c24xx/setup-spi.c|8 -
arch/arm/mach-s3c64xx/clock.c| 20 ++--
arch/arm/mach-s3c64xx/setup-spi.c| 13 --
arch/arm/mach-s5p64x0/clock-s5p6440.c| 12 +-
arch/arm/mach-s5p64x0/clock-s5p6450.c| 12 +-
arch/arm/mach-s5p64x0/setup-spi.c| 16 --
arch/arm/mach-s5pc100/clock.c| 30 ++--
arch/arm/mach-s5pc100/setup-spi.c| 22 ---
arch/arm/mach-s5pv210/clock.c| 14 +-
arch/arm/mach-s5pv210/setup-spi.c| 15 --
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 15 --
drivers/spi/spi-s3c64xx.c| 180
++
17 files changed, 210 insertions(+), 198 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index bcb7db4..10a46a9 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -586,17 +586,17 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 13),
}, {
.name = spi,
- .devname= s3c64xx-spi.0,
+ .devname= exynos4210-spi.0,
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1 16),
}, {
.name = spi,
- .devname= s3c64xx-spi.1,
+ .devname= exynos4210-spi.1,
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1 17),
}, {
.name = spi,
- .devname= s3c64xx-spi.2,
+ .devname= exynos4210-spi.2,
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1 18),
}, {
@@ -1245,7 +1245,7 @@ static struct clksrc_clk exynos4_clk_sclk_mmc3 = {
static struct clksrc_clk exynos4_clk_sclk_spi0 = {
.clk= {
.name = sclk_spi,
- .devname= s3c64xx-spi.0,
+ .devname= exynos4210-spi.0,
.enable = exynos4_clksrc_mask_peril1_ctrl,
.ctrlbit= (1 16),
},
@@ -1257,7 +1257,7 @@ static struct clksrc_clk exynos4_clk_sclk_spi0 = {
static struct clksrc_clk exynos4_clk_sclk_spi1 = {
.clk= {
.name = sclk_spi,
- .devname= s3c64xx-spi.1,
+ .devname= exynos4210-spi.1,
.enable = exynos4_clksrc_mask_peril1_ctrl,
.ctrlbit= (1 20),
},
@@ -1269,7 +1269,7 @@ static struct clksrc_clk exynos4_clk_sclk_spi1 = {
static struct clksrc_clk exynos4_clk_sclk_spi2 = {
.clk= {
.name = sclk_spi,
- .devname= s3c64xx-spi.2,
+ .devname= exynos4210-spi.2,
.enable = exynos4_clksrc_mask_peril1_ctrl,
.ctrlbit= (1 24),
},
@@ -1347,9 +1347,9 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(dma-pl330.0, apb_pclk, exynos4_clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, exynos4_clk_pdma1),
CLKDEV_INIT(dma-pl330.2, apb_pclk, exynos4_clk_mdma1),
- CLKDEV_INIT(s3c64xx-spi.0, spi_busclk0, exynos4_clk_sclk_spi0.clk),
- CLKDEV_INIT(s3c64xx-spi.1, spi_busclk0, exynos4_clk_sclk_spi1.clk),
- CLKDEV_INIT(s3c64xx-spi.2, spi_busclk0, exynos4_clk_sclk_spi2.clk),
+ CLKDEV_INIT(exynos4210-spi.0, spi_busclk0,
exynos4_clk_sclk_spi0.clk),
+ CLKDEV_INIT(exynos4210-spi.1, spi_busclk0,
exynos4_clk_sclk_spi1.clk),
+ CLKDEV_INIT(exynos4210-spi.2, spi_busclk0,
exynos4_clk_sclk_spi2.clk),
};
static int xtal_rate;
diff --git a/arch/arm/mach-exynos/setup-spi.c
b/arch/arm/mach-exynos/setup-spi.c
index 833ff40..a71ec4d 100644
--- a/arch/arm/mach-exynos/setup-spi.c
+++ b/arch/arm/mach-exynos/setup-spi.c
@@ -12,17 +12,8 @@
#include linux/platform_device.h
#include plat
Re: [PATCH v2 5/6] spi: s3c64xx: Remove the 'set_level' callback from controller data
On Fri, 18 May 2012 15:03:32 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
The set_level callback in the controller data, which is used to configure
the slave select line, cannot be supported when migrating the driver to
device tree based discovery. Since all the platforms currently use gpio
as the slave select line, this callback can be removed from the
controller data and replaced with call to gpio_set_value in the driver.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Jaswinder Singh jaswinder.si...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |2 --
drivers/spi/spi-s3c64xx.c|8
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
index a733ce9..48a6495 100644
--- a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
+++ b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
@@ -18,7 +18,6 @@ struct platform_device;
* @fb_delay: Slave specific feedback delay.
*Refer to FB_CLK_SEL register definition in SPI chapter.
* @line: Custom 'identity' of the CS line.
- * @set_level: CS line control.
*
* This is per SPI-Slave Chipselect information.
* Allocate and initialize one in machine init code and make the
@@ -27,7 +26,6 @@ struct platform_device;
struct s3c64xx_spi_csinfo {
u8 fb_delay;
unsigned line;
- void (*set_level)(unsigned line_id, int lvl);
};
/**
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f6bc0e3..d84ce7f 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -406,14 +406,14 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd-tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd-tgl_spi-controller_data;
- cs-set_level(cs-line,
- spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line,
+ spi-mode SPI_CS_HIGH ? 0 : 1);
}
sdd-tgl_spi = NULL;
}
cs = spi-controller_data;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
}
static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -499,7 +499,7 @@ static inline void disable_cs(struct
s3c64xx_spi_driver_data *sdd,
if (sdd-tgl_spi == spi)
sdd-tgl_spi = NULL;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
}
static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
--
1.6.6.rc2
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 6/6] spi: s3c64xx: add device tree support
On Fri, 18 May 2012 15:03:33 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add support for device based discovery.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Jaswinder Singh jaswinder.si...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
... but one nitpick below...
+#ifdef CONFIG_OF
+static const struct of_device_id s3c64xx_spi_dt_match[] = {
+ { .compatible = samsung,exynos4210-spi,
+ .data = (void *)EXYNOS4_SPI_PORT_CONFIG,
This looks completely backwards. EXYNOS4_SPI_PORT_CONFIG casts a
pointer to a kernel_ulong_t, and this casts it right back to a
pointer. The cast should be removed entirely from the macro, and the
platform_device_id table should have the cast from pointer to ulong.
g.
--
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/20] ARM: EXYNOS: add GPC4 bank instance
On Mon, 30 Apr 2012 12:14:16 -0700, Thomas Abraham thomas.abra...@linaro.org
wrote:
From: Sangsu Park sangsu4u.p...@samsung.com
Add GPC4 bank instance which is included in rev1 of EXYNOS5.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
[kgene@samsung.com: re-worked on top of v3.4-rc3]
Signed-off-by: Kukjin Kim kgene@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Should be merged with the rest of the series I think.
g.
---
arch/arm/mach-exynos/include/mach/gpio.h |9 ++---
arch/arm/mach-exynos/include/mach/irqs.h |2 +-
drivers/gpio/gpio-samsung.c | 11 ++-
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
b/arch/arm/mach-exynos/include/mach/gpio.h
index d7498af..eb24f1e 100644
--- a/arch/arm/mach-exynos/include/mach/gpio.h
+++ b/arch/arm/mach-exynos/include/mach/gpio.h
@@ -153,10 +153,11 @@ enum exynos4_gpio_number {
#define EXYNOS5_GPIO_B2_NR (4)
#define EXYNOS5_GPIO_B3_NR (4)
#define EXYNOS5_GPIO_C0_NR (7)
-#define EXYNOS5_GPIO_C1_NR (7)
+#define EXYNOS5_GPIO_C1_NR (4)
#define EXYNOS5_GPIO_C2_NR (7)
#define EXYNOS5_GPIO_C3_NR (7)
-#define EXYNOS5_GPIO_D0_NR (8)
+#define EXYNOS5_GPIO_C4_NR (7)
+#define EXYNOS5_GPIO_D0_NR (4)
#define EXYNOS5_GPIO_D1_NR (8)
#define EXYNOS5_GPIO_Y0_NR (6)
#define EXYNOS5_GPIO_Y1_NR (4)
@@ -199,7 +200,8 @@ enum exynos5_gpio_number {
EXYNOS5_GPIO_C1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C0),
EXYNOS5_GPIO_C2_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C1),
EXYNOS5_GPIO_C3_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C2),
- EXYNOS5_GPIO_D0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
+ EXYNOS5_GPIO_C4_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
+ EXYNOS5_GPIO_D0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C4),
EXYNOS5_GPIO_D1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D0),
EXYNOS5_GPIO_Y0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D1),
EXYNOS5_GPIO_Y1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_Y0),
@@ -242,6 +244,7 @@ enum exynos5_gpio_number {
#define EXYNOS5_GPC1(_nr)(EXYNOS5_GPIO_C1_START + (_nr))
#define EXYNOS5_GPC2(_nr)(EXYNOS5_GPIO_C2_START + (_nr))
#define EXYNOS5_GPC3(_nr)(EXYNOS5_GPIO_C3_START + (_nr))
+#define EXYNOS5_GPC4(_nr)(EXYNOS5_GPIO_C4_START + (_nr))
#define EXYNOS5_GPD0(_nr)(EXYNOS5_GPIO_D0_START + (_nr))
#define EXYNOS5_GPD1(_nr)(EXYNOS5_GPIO_D1_START + (_nr))
#define EXYNOS5_GPY0(_nr)(EXYNOS5_GPIO_Y0_START + (_nr))
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h
b/arch/arm/mach-exynos/include/mach/irqs.h
index ef52f61..ece5624 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -446,7 +446,7 @@
#define EXYNOS5_MAX_COMBINER_NR 32
-#define EXYNOS5_IRQ_GPIO1_NR_GROUPS 13
+#define EXYNOS5_IRQ_GPIO1_NR_GROUPS 14
#define EXYNOS5_IRQ_GPIO2_NR_GROUPS 9
#define EXYNOS5_IRQ_GPIO3_NR_GROUPS 5
#define EXYNOS5_IRQ_GPIO4_NR_GROUPS 1
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 19d6fc0..0a2087b 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2452,6 +2452,12 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
},
}, {
.chip = {
+ .base = EXYNOS5_GPC4(0),
+ .ngpio = EXYNOS5_GPIO_C4_NR,
+ .label = GPC4,
+ },
+ }, {
+ .chip = {
.base = EXYNOS5_GPD0(0),
.ngpio = EXYNOS5_GPIO_D0_NR,
.label = GPD0,
@@ -2874,8 +2880,11 @@ static __init int samsung_gpiolib_init(void)
goto err_ioremap1;
}
+ /* need to set base address for gpc4 */
+ exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
+
/* need to set base address for gpx */
- chip = exynos5_gpios_1[20];
+ chip = exynos5_gpios_1[21];
gpx_base = gpio_base1 + 0xC00;
for (i = 0; i 4; i++, chip++, gpx_base += 0x20)
chip-base = gpx_base;
--
1.7.5.4
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 15/20] ARM: Exynos: Add irq_domain support for gpio wakeup interrupts
On Mon, 30 Apr 2012 12:14:25 -0700, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add a irq_domain for all the 32 gpio external wakeup interrupt sources.
Since there are users of fixed linux irq numbers of the external wakeup
interrupts, the legacy mapping is used for the irq domain. The fixups
required to use irq domain based interrupt mapping is also included.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-exynos/common.c | 67
+
arch/arm/mach-exynos/include/mach/regs-gpio.h |4 +-
2 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 810f804..0d69412 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -752,6 +752,9 @@ static DEFINE_SPINLOCK(eint_lock);
static unsigned int eint0_15_data[16];
+#define EXYNOS_EINT_NR 32
+static struct irq_domain *irq_domain;
+
static inline int exynos4_irq_to_gpio(unsigned int irq)
{
if (irq IRQ_EINT(0))
@@ -842,9 +845,9 @@ static inline void exynos_irq_eint_mask(struct irq_data
*data)
u32 mask;
spin_lock(eint_lock);
- mask = __raw_readl(EINT_MASK(exynos_eint_base, data-irq));
- mask |= EINT_OFFSET_BIT(data-irq);
- __raw_writel(mask, EINT_MASK(exynos_eint_base, data-irq));
+ mask = __raw_readl(EINT_MASK(exynos_eint_base, data-hwirq));
+ mask |= EINT_OFFSET_BIT(data-hwirq);
+ __raw_writel(mask, EINT_MASK(exynos_eint_base, data-hwirq));
spin_unlock(eint_lock);
}
@@ -853,16 +856,16 @@ static void exynos_irq_eint_unmask(struct irq_data
*data)
u32 mask;
spin_lock(eint_lock);
- mask = __raw_readl(EINT_MASK(exynos_eint_base, data-irq));
- mask = ~(EINT_OFFSET_BIT(data-irq));
- __raw_writel(mask, EINT_MASK(exynos_eint_base, data-irq));
+ mask = __raw_readl(EINT_MASK(exynos_eint_base, data-hwirq));
+ mask = ~(EINT_OFFSET_BIT(data-hwirq));
+ __raw_writel(mask, EINT_MASK(exynos_eint_base, data-hwirq));
spin_unlock(eint_lock);
}
static inline void exynos_irq_eint_ack(struct irq_data *data)
{
- __raw_writel(EINT_OFFSET_BIT(data-irq),
- EINT_PEND(exynos_eint_base, data-irq));
+ __raw_writel(EINT_OFFSET_BIT(data-hwirq),
+ EINT_PEND(exynos_eint_base, data-hwirq));
}
static void exynos_irq_eint_maskack(struct irq_data *data)
@@ -873,7 +876,7 @@ static void exynos_irq_eint_maskack(struct irq_data *data)
static int exynos_irq_eint_set_type(struct irq_data *data, unsigned int type)
{
- int offs = EINT_OFFSET(data-irq);
+ int offs = data-hwirq;
int shift;
u32 ctrl, mask;
u32 newvalue = 0;
@@ -908,10 +911,10 @@ static int exynos_irq_eint_set_type(struct irq_data
*data, unsigned int type)
mask = 0x7 shift;
spin_lock(eint_lock);
- ctrl = __raw_readl(EINT_CON(exynos_eint_base, data-irq));
+ ctrl = __raw_readl(EINT_CON(exynos_eint_base, data-hwirq));
ctrl = ~mask;
ctrl |= newvalue shift;
- __raw_writel(ctrl, EINT_CON(exynos_eint_base, data-irq));
+ __raw_writel(ctrl, EINT_CON(exynos_eint_base, data-hwirq));
spin_unlock(eint_lock);
if (soc_is_exynos5250())
@@ -955,7 +958,7 @@ static inline void exynos_irq_demux_eint(unsigned int
start)
while (status) {
irq = fls(status) - 1;
- generic_handle_irq(irq + start);
+ generic_handle_irq(irq_find_mapping(irq_domain, irq + start));
status = ~(1 irq);
}
}
@@ -964,8 +967,8 @@ static void exynos_irq_demux_eint16_31(unsigned int irq,
struct irq_desc *desc)
{
struct irq_chip *chip = irq_get_chip(irq);
chained_irq_enter(chip, desc);
- exynos_irq_demux_eint(IRQ_EINT(16));
- exynos_irq_demux_eint(IRQ_EINT(24));
+ exynos_irq_demux_eint(16);
+ exynos_irq_demux_eint(24);
chained_irq_exit(chip, desc);
}
@@ -973,6 +976,7 @@ static void exynos_irq_eint0_15(unsigned int irq, struct
irq_desc *desc)
{
u32 *irq_data = irq_get_handler_data(irq);
struct irq_chip *chip = irq_get_chip(irq);
+ int eint_irq;
chained_irq_enter(chip, desc);
chip-irq_mask(desc-irq_data);
@@ -980,15 +984,28 @@ static void exynos_irq_eint0_15(unsigned int irq,
struct irq_desc *desc)
if (chip-irq_ack)
chip-irq_ack(desc-irq_data);
- generic_handle_irq(*irq_data);
+ eint_irq = irq_find_mapping(irq_domain, *irq_data);
+ generic_handle_irq(eint_irq);
chip-irq_unmask(desc-irq_data);
chained_irq_exit(chip, desc);
}
+static int exynos_eint_irq_domain_map(struct irq_domain *d, unsigned int irq
Re: [PATCH 17/20] ARM: Exynos: Add device tree support for gpio wakeup interrupt controller
On Mon, 30 Apr 2012 12:14:27 -0700, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add device tree support for gpio wakeup source interrupt controller
for Exynos platforms.
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/common.c | 92
+++--
1 files changed, 79 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 544f8b5..074508f 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -64,7 +64,8 @@ static void exynos4_init_clocks(int xtal);
static void exynos5_init_clocks(int xtal);
static void exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no);
static int exynos_init(void);
-static int exynos_init_irq_eint(void);
+static int exynos_init_irq_eint(struct device_node *np,
+ struct device_node *parent);
static struct cpu_table cpu_ids[] __initdata = {
{
@@ -589,6 +590,8 @@ static const struct of_device_id exynos4_dt_irq_match[] =
{
{ .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
{ .compatible = samsung,exynos4210-combiner,
.data = combiner_of_init, },
+ { .compatible = samsung,exynos5210-wakeup-eint-map,
+ .data = exynos_init_irq_eint, },
{},
};
#endif
@@ -606,8 +609,10 @@ void __init exynos4_init_irq(void)
of_irq_init(exynos4_dt_irq_match);
#endif
- if (!of_have_populated_dt())
+ if (!of_have_populated_dt()) {
combiner_init(S5P_VA_COMBINER_BASE, NULL);
+ exynos_init_irq_eint(NULL, NULL);
+ }
/*
* The parameters of s5p_init_irq() are for VIC init.
@@ -615,7 +620,6 @@ void __init exynos4_init_irq(void)
* uses GIC instead of VIC.
*/
s5p_init_irq(NULL, 0);
- exynos_init_irq_eint();
}
void __init exynos5_init_irq(void)
@@ -629,7 +633,6 @@ void __init exynos5_init_irq(void)
* uses GIC instead of VIC.
*/
s5p_init_irq(NULL, 0);
- exynos_init_irq_eint();
}
struct bus_type exynos_subsys = {
@@ -1002,17 +1005,72 @@ static int exynos_eint_irq_domain_map(struct
irq_domain *d, unsigned int irq,
return 0;
}
+#ifdef CONFIG_OF
+static int exynos_eint_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *controller, const u32 *intspec,
+ unsigned int intsize, unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ if (d-of_node != controller)
+ return -EINVAL;
+ if (intsize 2)
+ return -EINVAL;
+ *out_hwirq = intspec[0];
+
+ switch (intspec[1]) {
+ case S5P_IRQ_TYPE_LEVEL_LOW:
+ *out_type = IRQ_TYPE_LEVEL_LOW;
+ break;
+ case S5P_IRQ_TYPE_LEVEL_HIGH:
+ *out_type = IRQ_TYPE_LEVEL_HIGH;
+ break;
+ case S5P_IRQ_TYPE_EDGE_FALLING:
+ *out_type = IRQ_TYPE_EDGE_FALLING;
+ break;
+ case S5P_IRQ_TYPE_EDGE_RISING:
+ *out_type = IRQ_TYPE_EDGE_RISING;
+ break;
+ case S5P_IRQ_TYPE_EDGE_BOTH:
+ *out_type = IRQ_TYPE_EDGE_BOTH;
+ break;
+ };
+
+ return 0;
I'm recommending that new irq bindings use the Linux IRQ_TYPE_* values
just because it provides some commonality between irq controllers.
Using the S5P_IRQ_TYPE_ values doesn't make much sense when it only
gets immediately converted to another set of arbitrary values.
+}
+#else
+static int exynos_eint_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *controller, const u32 *intspec,
+ unsigned int intsize, unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ return -EINVAL;
+}
+#endif
+
static struct irq_domain_ops exynos_eint_irq_domain_ops = {
+ .xlate = exynos_eint_irq_domain_xlate,
.map = exynos_eint_irq_domain_map,
};
-static int __init exynos_init_irq_eint(void)
+static int __init exynos_init_irq_eint(struct device_node *eint_np,
+ struct device_node *parent)
{
- int irq, *src_int, irq_base;
+ int irq, *src_int, irq_base, irq_eint;
unsigned int paddr;
+ static unsigned int retry = 0;
+ static struct device_node *np;
- paddr = soc_is_exynos5250() ? EXYNOS5_PA_GPIO1 : EXYNOS4_PA_GPIO2;
- exynos_eint_base = ioremap(paddr, SZ_4K);
+ if (retry)
+ goto retry_init;
+
+ if (!eint_np) {
+ paddr = soc_is_exynos5250() ? EXYNOS5_PA_GPIO1 :
+ EXYNOS4_PA_GPIO2;
+ exynos_eint_base = ioremap(paddr, SZ_4K);
+ } else {
+ np = of_get_parent(eint_np);
+ exynos_eint_base = of_iomap(np, 0
RE: [PATCH 10/20] of/irq: fix interrupt parent lookup procedure
On Tue, 15 May 2012 17:29:14 +0900, Kukjin Kim kgene@samsung.com wrote:
Thomas Abraham wrote:
The interrupt parent lookup fails for a node that is a interrupt-controller
but does not have an explict interrupt-parent property and instead inherits
this property from the root node.
Consider the nodes listed below.
/ {
interrupt-parent = intc_level1;
intc_level1: interrupt-controller@xxx {
interrupt-controller;
#interrupt-cells = 3;
rest of the properties here;
};
intc_level2: interrupt-controller@yyy {
interrupt-controller;
#interrupt-cells = 2;
rest of the properties here;
};
};
The interrupt parent lookup for interrupt-controller@yyy fails. It inherits
the interrupt-parent property from the root node and the root node ('/')
specifies a 'interrupt-parent' property which represents the default
interrupt
root controller. But, the property '#interrupt-cells' might not be specified
in the root node.
In case a interrupt controller node does not include a 'interrupt-parent'
property but inherits that property from the root node, the check for
'interrupt-cells' property in the root node fails. Fix this removing the
check for 'interrupt-cells' property.
Hmmm... I dont see the bug... From your description above, I see the
following sequence.
First iteration:
child = ic@yyy;
cannot find interrupt-parent so take 'if' clause
p = of_get_parent(child); (root)
iteration continues because #interrupt-cells not found in 'p'(root)
Second iteration:
child = root;
found interrupt-parent, so take 'else' clause
p = of_find_node_by_phandle(); (ic@xxx)
iteration stops because #interrupt-cells is found in 'p'(ic@xxx)
What am I missing in my admittedly short look at the code?
g.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/of/irq.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9cf0060..a520363 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -66,14 +66,16 @@ struct device_node *of_irq_find_parent(struct
device_node *child)
if (parp == NULL)
p = of_get_parent(child);
else {
+ of_node_put(child);
if (of_irq_workarounds OF_IMAP_NO_PHANDLE)
p = of_node_get(of_irq_dflt_pic);
else
p = of_find_node_by_phandle(be32_to_cpup(parp));
+ return p;
}
of_node_put(child);
child = p;
- } while (p of_get_property(p, #interrupt-cells, NULL) == NULL);
+ } while (p);
This does break one use-case. Sometimes the interrupt-parent is the
same node when an
return p;
}
--
1.7.5.4
Hi Grant and Rob,
I'm ok on this and this patch and #11 patch in this series are required for
patches that add device tree based support for wakeup
interrupts on EXYNOS5250.
So could you have a look at this patch and let us know if this is okay or any
rework is required.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
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 10/20] of/irq: fix interrupt parent lookup procedure
On Tue, May 15, 2012 at 12:41 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Tue, 15 May 2012 17:29:14 +0900, Kukjin Kim kgene@samsung.com wrote:
Thomas Abraham wrote:
The interrupt parent lookup fails for a node that is a interrupt-controller
but does not have an explict interrupt-parent property and instead inherits
this property from the root node.
Consider the nodes listed below.
/ {
interrupt-parent = intc_level1;
intc_level1: interrupt-controller@xxx {
interrupt-controller;
#interrupt-cells = 3;
rest of the properties here;
};
intc_level2: interrupt-controller@yyy {
interrupt-controller;
#interrupt-cells = 2;
rest of the properties here;
};
};
The interrupt parent lookup for interrupt-controller@yyy fails. It inherits
the interrupt-parent property from the root node and the root node ('/')
specifies a 'interrupt-parent' property which represents the default
interrupt
root controller. But, the property '#interrupt-cells' might not be
specified
in the root node.
In case a interrupt controller node does not include a 'interrupt-parent'
property but inherits that property from the root node, the check for
'interrupt-cells' property in the root node fails. Fix this removing the
check for 'interrupt-cells' property.
Hmmm... I dont see the bug... From your description above, I see the
following sequence.
First iteration:
child = ic@yyy;
cannot find interrupt-parent so take 'if' clause
p = of_get_parent(child); (root)
iteration continues because #interrupt-cells not found in 'p'(root)
Second iteration:
child = root;
found interrupt-parent, so take 'else' clause
p = of_find_node_by_phandle(); (ic@xxx)
iteration stops because #interrupt-cells is found in 'p'(ic@xxx)
What am I missing in my admittedly short look at the code?
g.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/of/irq.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9cf0060..a520363 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -66,14 +66,16 @@ struct device_node *of_irq_find_parent(struct
device_node *child)
if (parp == NULL)
p = of_get_parent(child);
else {
+ of_node_put(child);
if (of_irq_workarounds OF_IMAP_NO_PHANDLE)
p = of_node_get(of_irq_dflt_pic);
else
p =
of_find_node_by_phandle(be32_to_cpup(parp));
+ return p;
}
of_node_put(child);
child = p;
- } while (p of_get_property(p, #interrupt-cells, NULL) == NULL);
+ } while (p);
This does break one use-case. Sometimes the interrupt-parent is the
same node when an
Oops, ignore this comment. I meant to delete it before sending.
g.
--
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] of/irq: add empty irq_of_parse_and_map() for non-dt builds
On Sun, 25 Mar 2012 20:32:49 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add a empty irq_of_parse_and_map() function that returns 0 for non-dt
builds and avoid having #ifdef CONFIG_OF around all calls to
irq_of_parse_and_map(). In addition to that, the irq_of_parse_and_map()
function declaration is made available only if CONFIG_OF_IRQ is defined,
which is the same config option that makes the irq_of_parse_and_map()
function definition available. While at it, fix a typo as well.
Suggested-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Oops, I applied the wrong one. I've applied this one now instead.
---
Changes since v1:
- Moved irq_of_parse_and_map() function declaration under CONFIG_OF_IRQ.
- Fix a minor typo in comments.
BTW; For patches submitted to me, keep the changelog above the s-o-b lines
so it gets included in the commit.
g.
include/linux/of_irq.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index d229ad3..11d57e4 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -10,14 +10,14 @@ struct of_irq;
#include linux/ioport.h
#include linux/of.h
+#if defined(CONFIG_OF_IRQ)
/*
- * irq_of_parse_and_map() is used ba all OF enabled platforms; but SPARC
+ * irq_of_parse_and_map() is used by all OF enabled platforms; but SPARC
* implements it differently. However, the prototype is the same for all,
* so declare it here regardless of the CONFIG_OF_IRQ setting.
*/
extern unsigned int irq_of_parse_and_map(struct device_node *node, int
index);
-#if defined(CONFIG_OF_IRQ)
/**
* of_irq - container for device_node/irq_specifier pair for an irq
controller
* @controller: pointer to interrupt controller device tree node
@@ -76,5 +76,11 @@ extern struct device_node *of_irq_find_parent(struct
device_node *child);
extern void of_irq_init(const struct of_device_id *matches);
#endif /* CONFIG_OF_IRQ */
+#else /* CONFIG_OF */
+static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
+ int index)
+{
+ return 0;
+}
#endif /* CONFIG_OF */
#endif /* __OF_IRQ_H */
--
1.6.6.rc2
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
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/2] regulator: add device tree support for max8997
On Sat, 24 Mar 2012 15:19:50 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: Add device tree based discovery support for max8997. Cc: MyungJoo Ham myungjoo@samsung.com Cc: Rajendra Nayak rna...@ti.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- .../devicetree/bindings/regulator/max8997-pmic.txt | 133 ++ drivers/mfd/max8997.c | 73 ++- drivers/regulator/max8997.c| 143 +++- include/linux/mfd/max8997-private.h|1 + include/linux/mfd/max8997.h|1 + 5 files changed, 347 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/max8997-pmic.txt diff --git a/Documentation/devicetree/bindings/regulator/max8997-pmic.txt b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt new file mode 100644 index 000..90a730b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt @@ -0,0 +1,133 @@ +* Maxim MAX8997 Voltage and Current Regulator + +The Maxim MAX8997 is a multi-function device which includes volatage and +current regulators, rtc, charger controller and other sub-blocks. It is +interfaced to the host controller using a i2c interface. Each sub-block is +addressed by the host system using different i2c slave address. This document +describes the bindings for 'pmic' sub-block of max8997. + +Required properties: +- compatible: Should be maxim,max8997-pmic. +- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. + +- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV) + units for buck1 when changing voltage using gpio dvs. Refer to [1] below + for additional information. + +- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) + units for buck2 when changing voltage using gpio dvs. Refer to [1] below + for additional information. + +- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV) + units for buck5 when changing voltage using gpio dvs. Refer to [1] below + for additional information. These are *really long* property names. Anything over 32 characters seems excessive to me. Other than that the binding looks good. g. -- 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 1/2] mfd: add irq domain support for max8997 interrupts
On Sat, 24 Mar 2012 15:19:49 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add irq domain support for max8997 interrupts. The reverse mapping method
used is linear mapping since the sub-drivers of max8997 such as regulator
and charger drivers can use the max8997 irq_domain to get the linux irq
number for max8997 interrupts. All uses of irq_base in platform data and
max8997 driver private data are removed.
Cc: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-exynos/mach-nuri.c|4 --
arch/arm/mach-exynos/mach-origen.c |1 -
drivers/mfd/max8997-irq.c | 61 --
drivers/mfd/max8997.c |1 -
include/linux/mfd/max8997-private.h |4 ++-
include/linux/mfd/max8997.h |1 -
6 files changed, 39 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 7ac81ce..b21d85d 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1077,12 +1077,8 @@ static struct platform_device nuri_max8903_device = {
static void __init nuri_power_init(void)
{
int gpio;
- int irq_base = IRQ_GPIO_END + 1;
int ta_en = 0;
- nuri_max8997_pdata.irq_base = irq_base;
- irq_base += MAX8997_IRQ_NR;
-
gpio = EXYNOS4_GPX0(7);
gpio_request(gpio, AP_PMIC_IRQ);
s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index 827cb99..d3b2e9d 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata
origen_max8997_pdata = {
.buck1_gpiodvs = false,
.buck2_gpiodvs = false,
.buck5_gpiodvs = false,
- .irq_base = IRQ_GPIO_END + 1,
.ignore_gpiodvs_side_effect = true,
.buck125_default_idx = 0x0,
diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
index 09274cf..00390a1 100644
--- a/drivers/mfd/max8997-irq.c
+++ b/drivers/mfd/max8997-irq.c
@@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
static const inline struct max8997_irq_data *
irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
{
- return max8997_irqs[irq - max8997-irq_base];
+ struct irq_data *data = irq_get_irq_data(irq);
+ return max8997_irqs[data-hwirq];
}
Haha, this is kind of bogus now. There are only two users of this
function, and *both* of them already have the irq_data pointer.
Instead of this, delete this function entirely and make each caller
derefernce max8997_irqs directly:
const struct max8997_irq_data *irq_data = max8997_irqs[data-hwirq];
Otherwise, looks good. After fixing you can add my:
Acked-by: Grant Likely grant.lik...@secretlab.ca
static void max8997_irq_mask(struct irq_data *data)
@@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
u8 irq_src;
int ret;
- int i;
+ int i, cur_irq;
ret = max8997_read_reg(max8997-i2c, MAX8997_REG_INTSRC, irq_src);
if (ret 0) {
@@ -269,8 +270,11 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
/* Report */
for (i = 0; i MAX8997_IRQ_NR; i++) {
- if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask)
- handle_nested_irq(max8997-irq_base + i);
+ if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask) {
+ cur_irq = irq_find_mapping(max8997-irq_domain, i);
+ if (cur_irq)
+ handle_nested_irq(cur_irq);
+ }
}
return IRQ_HANDLED;
@@ -278,26 +282,40 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
int max8997_irq_resume(struct max8997_dev *max8997)
{
- if (max8997-irq max8997-irq_base)
- max8997_irq_thread(max8997-irq_base, max8997);
+ if (max8997-irq max8997-irq_domain)
+ max8997_irq_thread(0, max8997);
+ return 0;
+}
+
+static int max8997_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ struct max8997_dev *max8997 = d-host_data;
+
+ irq_set_chip_data(irq, max8997);
+ irq_set_chip_and_handler(irq, max8997_irq_chip, handle_edge_irq);
+ irq_set_nested_thread(irq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(irq, IRQF_VALID);
+#else
+ irq_set_noprobe(irq);
+#endif
return 0;
}
+static struct irq_domain_ops max8997_irq_domain_ops = {
+ .map = max8997_irq_domain_map,
+};
+
int max8997_irq_init(struct max8997_dev *max8997)
{
+ struct irq_domain *domain;
int i;
- int
Re: Device node for a controller with two interrupt parents
On Fri, 23 Mar 2012 16:18:09 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Hi Grant,
On 21 March 2012 20:43, Grant Likely grant.lik...@secretlab.ca wrote:
Okay, so you're saying there are three important aspects to this
device:
1) it terminates interrupts from other devices (therefore needs an
 interrupt controller driver)
2) it passes some interrupts through untouched (interrupt controller
 driver doesn't need to touch them; it directly raises an irq on the
 gic or combiner)
3) It is able generate interrupt signals on it's own (independent of
 any attached devices)
Do I understand correctly?
#1 is applicable but not #2 and #3 (if I have interpreted the above
correctly). The wakeup interrupt controller looks for an edge or level
on pins (which are connected to external devices) and generates a
interrupt (to gic or combiner) when the set condition on that pin is
found (edge or level).
Your patch above solves the problem for #2 above, but it breaks #1
because interrupts from external devices can no longer be terminated
on the wakeup controller node (they'll always get passed through).
Ok.
--- Possible solution 1 ---
If other devices *don't* use the wakeup node as their interrupt
parent, then you should be able to simply drop the
interrupt-controller property and make the other devices directly
reference the gic and combiner.
Other devices use wakeup node as interrupt controller. The wakeup
interrupt controller supports masking, unmasking and prioritization of
the wakeup interrupts. The interrupt-controller property can be
dropped but then of_irq_init() function cannot be used.
--- Possible solution 2 ---
Split the interrupt map into a separate node:
    wakeup_eint: interrupt-controller@1100 {
        compatible = samsung,exynos4210-wakeup-eint;
        reg = 0x1100 0x1000;
        interrupt-controller;
        #interrupt-cells = 1;
        interrupt-parent = wakeup_map;
        interrupts = 0 1 2 3 f 5 6 7 8 9 10 11 12 13 14 15
16;
        wakeup_map: interrupt-map {
            #interrupt-cells = 1;
            #address-cells = 0;
            interrupt-map = 0 gic 0 16 0,
                    1 gic 0 17 0,
                    2 gic 0 18 0,
                    3 gic 0 19 0,
                    4 gic 0 20 0,
                    5 gic 0 21 0,
                    6 gic 0 22 0,
                    7 gic 0 23 0,
                    8 gic 0 24 0,
                    9 gic 0 25 0,
                    10 gic 0 26 0,
                    11 gic 0 27 0,
                    12 gic 0 28 0,
                    13 gic 0 29 0,
                    14 gic 0 30 0,
                    15 gic 0 31 0,
                    16 combiner 2
4;
        };
    };
I have tested with this and it works but of_irq_init() function cannot
be used because 'wakeup_map' is set as interrupt parent and
'wakeup_map' is not a interrupt-controller. So of_irq_init() does not
invoke the initialization function for the wakeup node. If the machine
init code explicitly looks for this node and calls the corresponding
initialization function, it works fine.
That's a bug in of_irq_init() then. It should be fixed.
--- possible solution 3 ---
'interrupts' just isn't sufficient for some devices; add a binding for
a 'interrupts-multiparent' that can be used instead of 'interrupts'
and uses the format phandle specifier [phandle specifier [...]].
This would be the ideal case. In addition to this, the
interrupt-parent property handling should be modified to support
multiple parent phandles like parent1 [parent2] [parent3] .
This will be useful to extend the capability of of_irq_init() to
handle interrupt-controller node with multiple interrupt parents.
I'm not opposed to this solution since it is a more natural binding
for multiparented interrupt controllers, but I won't commit to it
without feedback and agreement from Mitch, Ben, David Gibson, etc.
Ok. For now, I will go ahead and use solution #2 which you and David
have suggested
Re: Device node for a controller with two interrupt parents
,
16 combiner 2 4;
};
};
--- possible solution 3 ---
'interrupts' just isn't sufficient for some devices; add a binding for
a 'interrupts-multiparent' that can be used instead of 'interrupts'
and uses the format phandle specifier [phandle specifier [...]].
I'm not opposed to this solution since it is a more natural binding
for multiparented interrupt controllers, but I won't commit to it
without feedback and agreement from Mitch, Ben, David Gibson, etc.
2. The of_irq_init() function (mainly used on the arm platforms) looks
for nodes with 'interrupt-controller' and initializes them with the
parents initialized first. In the Exynos4/5 case, the wakeup interrupt
has two interrupt parents and of_irq_init() function does not seem to
be consider this case. And hence, the wakeup interrupt controller is
being initialized, without the combiner being initialized.
The following are the interrupt-controller nodes, that I have been
testing with (slightly modified for testing)
gic:interrupt-controller@1049 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 0;
#size-cells = 0;
interrupt-controller;
cpu-offset = 0x8000;
reg = 0x1049 0x1000, 0x1048 0x100;
};
combiner:interrupt-controller@1044 {
compatible = samsung,exynos4210-combiner;
#interrupt-cells = 2;
interrupt-controller;
samsung,combiner-nr = 16;
reg = 0x1044 0x1000;
interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
0 4 0, 0 5 0, 0 6 0, 0 7 0,
0 8 0, 0 9 0, 0 10 0, 0 11 0,
0 12 0, 0 13 0, 0 14 0, 0 15 0;
};
wakeup_eint: interrupt-controller@1100 {
compatible = samsung,exynos4210-wakeup-eint;
reg = 0x1100 0x1000;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = wakeup_eint;
interrupts = 0x0, 0x1, 0x2, 0x3,
0x4, 0x5, 0x6, 0x7,
0x8, 0x9, 0xa, 0xb,
0xc, 0xd, 0xe, 0xf,
0x10;
#address-cells = 0;
#size-cells = 0;
interrupt-map = 0x0 gic 0 16 0,
0x1 gic 0 17 0,
0x2 gic 0 18 0,
0x3 gic 0 19 0,
0x4 gic 0 20 0,
0x5 gic 0 21 0,
0x6 gic 0 22 0,
0x7 gic 0 23 0,
0x8 gic 0 24 0,
0x9 gic 0 25 0,
0xa gic 0 26 0,
0xb gic 0 27 0,
0xc gic 0 28 0,
0xd gic 0 29 0,
0xe gic 0 30 0,
0xf gic 0 31 0,
0x10 combiner 2 4;
};
Thanks,
Thomas.
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
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] spi: s3c64xx: Fix build
On Wed, 14 Mar 2012 16:52:14 +, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
Commit 054ebc (spi: Compatibility with direction which is used in samsung
DMA operation) does not build as one hunk adds a brace to the first branch
of an if statement without adding at least the correspoding close. Remove
the unwanted brace.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Applied, thanks.
g.
---
drivers/spi/spi-s3c64xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index c40d118..3180100 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -264,7 +264,7 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
struct s3c64xx_spi_driver_data *sdd;
struct samsung_dma_prep_info info;
- if (dma-direction == DMA_DEV_TO_MEM) {
+ if (dma-direction == DMA_DEV_TO_MEM)
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, rx_dma);
else
--
1.7.9.1
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
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] regulator: add device tree support for max8997
On Tue, 13 Mar 2012 12:14:42 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: On 13 March 2012 09:13, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: Otherwise, the patch looks pretty good. Â (although seeing the decode function has got me thinking that we need a much better way of decoding the dt data). The parsing function looks huge since there is lot of data to pick up from the dt node. Oh, I understand that you have to do it this way; I just think the core code should make it a lot easier. :-) g. -- 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/3] gpio/samsung: use ioremap() for EXYNOS4 GPIOlib
On Thu, 16 Feb 2012 06:37:09 +0900, Kukjin Kim kgene@samsung.com wrote:
From: Sangsu Park sangsu4u.p...@samsung.com
This patch changes to use ioremap() for EXYNOS4210
so that we can drop the static mapping for EXYNOS
SoCs.
Note: Will be updated for all of Samsung GPIOlibs
to use ioremap() next time.
Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Kukjin Kim kgene@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Kukjin, I think you wanted to take this via your tree? I'm fine with that.
Let me know if you'd rather it go via the gpio tree.
g.
---
arch/arm/mach-exynos/common.c | 15
drivers/gpio/gpio-samsung.c | 48
+
2 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 63a2b04..618e7f3 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -172,21 +172,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_GPIO1,
- .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO1),
- .length = SZ_4K,
- .type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_GPIO2,
- .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO2),
- .length = SZ_4K,
- .type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_GPIO3,
- .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO3),
- .length = SZ_256,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
.length = SZ_4K,
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index d6cfdee7..4627787 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2331,7 +2331,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
.label = GPY6,
},
}, {
- .base = (S5P_VA_GPIO2 + 0xC00),
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(0),
.chip = {
@@ -2341,7 +2340,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
.to_irq = samsung_gpiolib_to_irq,
},
}, {
- .base = (S5P_VA_GPIO2 + 0xC20),
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(8),
.chip = {
@@ -2351,7 +2349,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
.to_irq = samsung_gpiolib_to_irq,
},
}, {
- .base = (S5P_VA_GPIO2 + 0xC40),
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(16),
.chip = {
@@ -2361,7 +2358,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
.to_irq = samsung_gpiolib_to_irq,
},
}, {
- .base = (S5P_VA_GPIO2 + 0xC60),
.config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(24),
.chip = {
@@ -2789,9 +2785,16 @@ static __init int samsung_gpiolib_init(void)
s5p_register_gpioint_bank(IRQ_GPIOINT, 0,
S5P_GPIOINT_GROUP_MAXNR);
#endif
} else if (soc_is_exynos4210()) {
- group = 0;
+#ifdef CONFIG_CPU_EXYNOS4210
+ void __iomem *gpx_base;
/* gpio part1 */
+ gpio_base1 = ioremap(EXYNOS4_PA_GPIO1, SZ_4K);
+ if (gpio_base1 == NULL) {
+ pr_err(unable to ioremap for gpio_base1\n);
+ goto err_ioremap1;
+ }
+
chip = exynos4_gpios_1;
nr_chips = ARRAY_SIZE(exynos4_gpios_1);
@@ -2800,14 +2803,25 @@ static __init int samsung_gpiolib_init(void)
chip-config = exynos_gpio_cfg;
chip-group = group++;
}
-#ifdef CONFIG_CPU_EXYNOS4210
exynos_gpiolib_attach_ofnode(chip,
EXYNOS4_PA_GPIO1, i * 0x20);
-#endif
}
- samsung_gpiolib_add_4bit_chips(exynos4_gpios_1, nr_chips,
S5P_VA_GPIO1);
+ samsung_gpiolib_add_4bit_chips(exynos4_gpios_1,
+nr_chips, gpio_base1);
/* gpio part2 */
+ gpio_base2 = ioremap(EXYNOS4_PA_GPIO2, SZ_4K);
+ if (gpio_base2 == NULL) {
+ pr_err(unable to ioremap for gpio_base2\n
Re: [PATCH v3 1/2] mfd: add irq domain support for max8997 interrupts
On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add irq domain support for max8997 interrupts. The reverse mapping method
used is linear mapping since the sub-drivers of max8997 such as regulator
and charger drivers can use the max8997 irq_domain to get the linux irq
number for max8997 interrupts. All uses of irq_base in platform data and
max8997 driver private data are removed.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/mach-nuri.c|4 --
arch/arm/mach-exynos/mach-origen.c |1 -
drivers/mfd/max8997-irq.c | 60 --
drivers/mfd/max8997.c |1 -
include/linux/mfd/max8997-private.h |4 ++-
include/linux/mfd/max8997.h |1 -
6 files changed, 38 insertions(+), 33 deletions(-)
Nice patch. Nice diffstat too. Some comments below, but I'm happy with where
this is at.
Acked-by: Grant Likely grant.lik...@secretlab.ca
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index a6b9162..1e9ba12 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1078,12 +1078,8 @@ static struct platform_device nuri_max8903_device = {
static void __init nuri_power_init(void)
{
int gpio;
- int irq_base = IRQ_GPIO_END + 1;
int ta_en = 0;
- nuri_max8997_pdata.irq_base = irq_base;
- irq_base += MAX8997_IRQ_NR;
-
gpio = EXYNOS4_GPX0(7);
gpio_request(gpio, AP_PMIC_IRQ);
s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index 02c242e..328dadb 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata
origen_max8997_pdata = {
.buck1_gpiodvs = false,
.buck2_gpiodvs = false,
.buck5_gpiodvs = false,
- .irq_base = IRQ_GPIO_END + 1,
.ignore_gpiodvs_side_effect = true,
.buck125_default_idx = 0x0,
diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
index 09274cf..3d8c9d1 100644
--- a/drivers/mfd/max8997-irq.c
+++ b/drivers/mfd/max8997-irq.c
@@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
static const inline struct max8997_irq_data *
irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
{
- return max8997_irqs[irq - max8997-irq_base];
+ struct irq_data *data = irq_get_irq_data(irq);
+ return max8997_irqs[data-hwirq];
Hahaha. The max8997_irqs table is kind of overdone when the group and mask
values
can be arithmetically derived from the hwirq number..
This change is fine, but the driver could use some refactoring. :-)
}
static void max8997_irq_mask(struct irq_data *data)
@@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
u8 irq_src;
int ret;
- int i;
+ int i, cur_irq;
ret = max8997_read_reg(max8997-i2c, MAX8997_REG_INTSRC, irq_src);
if (ret 0) {
@@ -269,8 +270,10 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
/* Report */
for (i = 0; i MAX8997_IRQ_NR; i++) {
- if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask)
- handle_nested_irq(max8997-irq_base + i);
+ if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask) {
+ cur_irq = irq_find_mapping(max8997-irq_domain, i);
+ handle_nested_irq(cur_irq);
+ }
Well, if you're using the linear mapping, then only actually allocated irqs will
have a mapping set up. So the driver could simply do:
for (i = 0; i MAX8997_IRQ_NR; i++) {
cur_irq = irq_find_mapping(max8997-irq_domain, i);
if (cur_irq)
handle_nested_irq(cur_irq);
}
}
return IRQ_HANDLED;
@@ -278,26 +281,40 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
int max8997_irq_resume(struct max8997_dev *max8997)
{
- if (max8997-irq max8997-irq_base)
- max8997_irq_thread(max8997-irq_base, max8997);
+ if (max8997-irq max8997-irq_domain)
+ max8997_irq_thread(0, max8997);
+ return 0;
+}
+
+static int max8997_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ struct max8997_dev *max8997 = d-host_data;
+
+ irq_set_chip_data(irq, max8997);
+ irq_set_chip_and_handler(irq, max8997_irq_chip, handle_edge_irq);
+ irq_set_nested_thread(irq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(irq, IRQF_VALID);
+#else
+ irq_set_noprobe(irq);
+#endif
return 0
Re: [PATCH v3 2/2] regulator: add device tree support for max8997
On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add device tree based discovery support for max8997.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/regulator/max8997-pmic.txt | 134 +++
drivers/mfd/max8997.c | 72 ++-
drivers/regulator/max8997.c| 139
+++-
include/linux/mfd/max8997.h|1 +
4 files changed, 344 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/max8997-pmic.txt
diff --git a/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
new file mode 100644
index 000..d282635
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
@@ -0,0 +1,134 @@
+* Maxim MAX8997 Voltage and Current Regulator
+
+The Maxim MAX8997 is a multi-function device which includes volatage and
+current regulators, rtc, charger controller and other sub-blocks. It is
+interfaced to the host controller using a i2c interface. Each sub-block is
+addressed by the host system using different i2c slave address. This document
+describes the bindings for 'pmic' sub-block of max8997.
+
+Required properties:
+- compatible: Should be maxim,max8997-pmic.
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+
+- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt
(uV)
+ units for buck1 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt
(uV)
+ units for buck2 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt
(uV)
+ units for buck5 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
+property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
+property should specify atleast one voltage level (which would be a
+safe operating voltage).
+
+If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
+property is specified, then all the eigth voltage values for the
+'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to
which
+ the interrupts from max8997 are delivered to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+ - First interrupt specifier is for 'irq1' interrupt.
+ - Second interrupt specifier is for 'alert' interrupt.
+- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
+- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
+- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
+
+Additional properties required if either of the optional properties are used:
+- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
+ multiple bucks, changing the voltage value of one of the bucks may affect
+ that of another buck, which is the side effect of the change (set_voltage).
+ Use this property to ignore such side effects and change the voltage.
+
+- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
+ the possible 8 options selectable by the dvs gpios. The value of this
+ property should be between 0 and 7. If not specified or if out of range,
the
+ default value of this property is set to 0.
+
+- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
+ for dvs. The format of the gpio specifier depends in the gpio controller.
+
+
+Regulators: The regulators of max8997 that have to be instantiated should be
+included in a sub-node named 'regulators'. Regulator nodes included in this
+sub-node should be of the format as below. Note: The 'n' in LDOn and BUCKn
+represents the LDO or BUCK number as per the datasheet of max8997.
+
+For LDO's:
+ LDOn {
+ standard regulator bindings here
+ };
+
+For BUCK's:
+ BUCKn {
+ standard regulator bindings here
+ };
+
+The bindings inside the regulator nodes use the standard regulator bindings
+which are documented elsewhere.
+
+Example:
+
+ max8997_pmic@66 {
+ compatible = maxim,max8997-pmic;
+ interrupt-parent = wakeup_eint;
+ reg = 0x66;
+ interrupts = 4 0, 3 0;
+
+ max8997
Re: [PATCH v4 2/2] ARM: Exynos: Add device tree support for interrupt combiner
On Tue, 21 Feb 2012 10:03:26 +0530, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add device tree based instantiation of the interrupt combiner controller.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
@@ -406,13 +432,33 @@ void __init combiner_init(void __iomem *combiner_base,
struct device_node *np)
for (i = 0; i MAX_COMBINER_NR; i++) {
combiner_init_one(i, combiner_base + (i 2) * 0x10);
- combiner_cascade_irq(i, IRQ_SPI(i));
+#ifdef CONFIG_OF
+ irq = np ? irq_of_parse_and_map(np, i) : IRQ_SPI(i);
+#else
+ irq = IRQ_SPI(i);
+#endif
Hmmm, the #ifdef is rather ugly. I'd rather have an empty
irq_of_parse_and_map() that always returns 0.
The patch series is fine, and you can add my acked-by, but please send
a follow-up patch to clean it up.
Acked-by: Grant Likely grant.lik...@secretlab.ca
--
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: Subject: [PATCH] MAINTAINERS: add maintainer entry for SAMSUNG EXYNOS DeviceTree
On Wed, 22 Feb 2012 07:49:18 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: On 22 February 2012 05:46, Kukjin Kim kgene@samsung.com wrote: Add Samsung EXYNOS DT maintainer Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kukjin Kim kgene@samsung.com ---  MAINTAINERS |  10 ++  1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9a648eb..5ac5aaf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1065,6 +1065,16 @@ S:    Maintained  F:   arch/arm/mach-s5p*/  F:   arch/arm/mach-exynos*/ +ARM/SAMSUNG EXYNOS DEVICE TREE +M:   Thomas Abraham thomas.abra...@linaro.org +M:   Kukjin Kim kgene@samsung.com +L:   devicetree-disc...@lists.ozlabs.org (moderated for non-subscribers) +L:   linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) +S:   Maintained +F:   arch/arm/boot/dts/exynos* +F:   arch/arm/mach-exynos/*dt.c +F:   Documentation/devicetree/*/*/*samsung* + Acked-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca -- 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] spi/s3c64xx: Convert to using core message queue
-actual_length = 0;
-
- list_add_tail(msg-queue, sdd-queue);
-
- queue_work(sdd-workqueue, sdd-work);
-
- spin_unlock_irqrestore(sdd-lock, flags);
return 0;
}
@@ -879,13 +833,6 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
}
}
- if (sdd-state SUSPND) {
- spin_unlock_irqrestore(sdd-lock, flags);
- dev_err(spi-dev,
- setup: SPI-%d not active!\n, spi-master-bus_num);
- return -ESHUTDOWN;
- }
-
spin_unlock_irqrestore(sdd-lock, flags);
if (spi-bits_per_word != 8
@@ -1073,7 +1020,9 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
master-bus_num = pdev-id;
master-setup = s3c64xx_spi_setup;
- master-transfer = s3c64xx_spi_transfer;
+ master-prepare_transfer_hardware = s3c64xx_spi_prepare_transfer;
+ master-transfer_one_message = s3c64xx_spi_transfer_one_message;
+ master-unprepare_transfer_hardware = s3c64xx_spi_unprepare_transfer;
master-num_chipselect = sci-num_cs;
master-dma_alignment = 8;
/* the spi-mode bits understood by this driver: */
@@ -1128,27 +1077,18 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
goto err6;
}
- sdd-workqueue = create_singlethread_workqueue(
- dev_name(master-dev.parent));
- if (sdd-workqueue == NULL) {
- dev_err(pdev-dev, Unable to create workqueue\n);
- ret = -ENOMEM;
- goto err7;
- }
-
/* Setup Deufult Mode */
s3c64xx_spi_hwinit(sdd, pdev-id);
spin_lock_init(sdd-lock);
init_completion(sdd-xfer_completion);
- INIT_WORK(sdd-work, s3c64xx_spi_work);
INIT_LIST_HEAD(sdd-queue);
ret = request_irq(irq, s3c64xx_spi_irq, 0, spi-s3c64xx, sdd);
if (ret != 0) {
dev_err(pdev-dev, Failed to request IRQ %d: %d\n,
irq, ret);
- goto err8;
+ goto err7;
}
writel(S3C64XX_SPI_INT_RX_OVERRUN_EN | S3C64XX_SPI_INT_RX_UNDERRUN_EN |
@@ -1158,7 +1098,7 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
if (spi_register_master(master)) {
dev_err(pdev-dev, cannot register SPI master\n);
ret = -EBUSY;
- goto err9;
+ goto err8;
}
dev_dbg(pdev-dev, Samsung SoC SPI Driver loaded for Bus SPI-%d
@@ -1172,10 +1112,8 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
return 0;
-err9:
- free_irq(irq, sdd);
err8:
- destroy_workqueue(sdd-workqueue);
+ free_irq(irq, sdd);
err7:
clk_disable(sdd-src_clk);
err6:
@@ -1201,25 +1139,15 @@ static int s3c64xx_spi_remove(struct platform_device
*pdev)
struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct resource *mem_res;
- unsigned long flags;
pm_runtime_disable(pdev-dev);
- spin_lock_irqsave(sdd-lock, flags);
- sdd-state |= SUSPND;
- spin_unlock_irqrestore(sdd-lock, flags);
-
- while (sdd-state SPIBUSY)
- msleep(10);
-
spi_unregister_master(master);
writel(0, sdd-regs + S3C64XX_SPI_INT_EN);
free_irq(platform_get_irq(pdev, 0), sdd);
- destroy_workqueue(sdd-workqueue);
-
clk_disable(sdd-src_clk);
clk_put(sdd-src_clk);
@@ -1243,14 +1171,8 @@ static int s3c64xx_spi_suspend(struct device *dev)
{
struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
- unsigned long flags;
-
- spin_lock_irqsave(sdd-lock, flags);
- sdd-state |= SUSPND;
- spin_unlock_irqrestore(sdd-lock, flags);
- while (sdd-state SPIBUSY)
- msleep(10);
+ spi_master_suspend(master);
/* Disable the clock */
clk_disable(sdd-src_clk);
@@ -1267,7 +1189,6 @@ static int s3c64xx_spi_resume(struct device *dev)
struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd-cntrlr_info;
- unsigned long flags;
sci-cfg_gpio(pdev);
@@ -1277,9 +1198,7 @@ static int s3c64xx_spi_resume(struct device *dev)
s3c64xx_spi_hwinit(sdd, pdev-id);
- spin_lock_irqsave(sdd-lock, flags);
- sdd-state = ~SUSPND;
- spin_unlock_irqrestore(sdd-lock, flags);
+ spi_master_resume(master);
return 0;
}
--
1.7.9.rc1
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
On Tue, Jan 31, 2012 at 11:26:16PM +0530, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/mmc/samsung-sdhci.txt | 70 +
drivers/mmc/host/sdhci-s3c.c | 148
+++-
2 files changed, 212 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
Looks okay to me on brief review.
Acked-by: Grant Likely grant.lik...@secretlab.ca
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000..8cbdd29
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,70 @@
+* Samsung's SDHCI Controller device tree bindings
+
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-sdhci: For controllers compatible with s3c6410 sdhci
+controller.
+ - samsung,exynos4210-sdhci: For controller compatible with Exynos4 sdhci
+controller.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+
+
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+ gpio specifier format depends on the gpio controller. Note: There is no
+ particular order in which the gpio's have to be listed.
+
+
+Optional Board Specific Properties:
+- samsung,sdhci-bus-width: Number of data lines connected to the controller.
+ Note: This excludes the clock,command and card detect lines. If this
property
+ is not specified, default value is 1.
+
+- samsung,cd-gpio-invert: If 'samsung,sdhci-cd-gpio' card detect method is
+ selected, this property can be optionally specified to invert the value of
+ external card detect gpio line.
+
+- One of the following properties for card detect type.
+ - samsung,sdhci-cd-internal: Card detect line from the card slot is
+connected to the card detect pad of the sdhci controller. A gpio is
+used for this connection (with possible pin function settings).
+ - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
+is used a card detect line. This gpio line is not connected to card
detect
+pad of the sdhci controller.
+ - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
+detect the presence of the card. (DEFAULT, if no card detect property
+is specified).
+ - samsung,sdhci-cd-permanent: There is no card detect line. The card is
+permanently connected to the sdhci controller.
+
+- gpio-cd: The gpio to be used as card detect line for
+ 'samsung,sdhci-cd-internal' or 'samsung,sdhci-cd-gpio' card detection
method.
+ The gpio specifier format depends on the gpio controller.
+
+Example:
+ sdhci@1253 {
+ compatible = samsung,exynos4210-sdhci;
+ reg = 0x1253 0x100;
+ interrupts = 139;
+ samsung,sdhci-bus-width = 4;
+ samsung,sdhci-cd-internal;
+ gpio-cd = gpk2 2 2 3 3;
+ gpios = gpk2 0 2 0 3, /* clock line */
+ gpk2 1 2 0 3, /* command line */
+ gpk2 3 2 3 3, /* data line 0 */
+ gpk2 4 2 3 3, /* data line 1 */
+ gpk2 5 2 3 3, /* data line 2 */
+ gpk2 6 2 3 3; /* data line 3 */
+ };
+
+ Note: This example shows both SoC specific and board specific properties
+ in a single device node. The properties can be actually be seperated
+ into SoC specific node and board specific node.
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 1760ba8..6159542 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -20,6 +20,8 @@
#include linux/io.h
#include linux/gpio.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/mmc/host.h
@@ -29,6 +31,8 @@
#include sdhci.h
#define MAX_BUS_CLK (4)
+/* Number of gpio's used is max data bus width + command and clock lines */
+#define NUM_GPIOS(x) (x + 2)
/**
* struct sdhci_s3c - S3C SDHCI instance
@@ -37,6 +41,7 @@
* @ioarea: The resource created when we claimed the IO area.
* @pdata: The platform data for this controller.
* @cur_clk: The index of the current bus clock.
+ * @gpios: List of gpio numbers parsed from device tree.
* @clk_io: The clock for the internal bus interface.
* @clk_bus: The clocks
Re: [PATCH 0/3] spi/s3c64xx diagnostic and PM updates
On Sat, Jan 21, 2012 at 03:13:41PM +, Mark Brown wrote: On Sat, Jan 21, 2012 at 07:27:23AM -0700, Grant Likely wrote: Pushed out to git://git.secretlab.ca/git/linux-2.6.git spi/merge. I'll ask Linus to pull in a couple of days after it has hit linux-next. Thanks. Obviously it'd be nice to get it into 3.3 but I don't see a huge rush and it did miss the merge window - it doesn't fix any bugs and without a bunch of other work in cpuidle that's not been done yet the power gains from the runtime PM are vanishingly small. Okay, I've moved it over to spi/next instead. It will be ready for the v3.4 merge window. g. -- 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] mmc: sdhci-s3c: Add device tree support
On Mon, Jan 30, 2012 at 10:51:11AM +0100, Heiko Stübner wrote:
Am Mittwoch, 2. November 2011, 21:36:03 schrieb Thomas Abraham:
Hi Thomas,
in patch 1/6:
+static struct platform_device_id sdhci_s3c_driver_ids[] = {
+ {
+ .name = s3c-sdhci,
+ .driver_data= (kernel_ulong_t)NULL,
+ },
+ {
+ .name = exynos4-sdhci,
+ .driver_data= EXYNOS4_SDHCI_DRV_DATA,
+ },
+};
+MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
and in patch 6/6:
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_s3c_dt_match[] = {
+ { .compatible = samsung,s3c6410-sdhci, },
+ { .compatible = samsung,exynos4210-sdhci,
+ .data = exynos4_sdhci_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
wouldn't it be better to keep the naming consistent between of and non-of?
I.e. s3c-sdhci vs. s3c6410-sdhci. Since the driver is used for all S3C SoCs
containing hsmmc controllers I think s3c-sdhci would be preferable here.
History has shown that future devices aren't always compatible with earlier
ones. Compatible strings are expected to be specific to an exact device to
reduce the possibility of new hardware breaking assumptions.
Instead, new hardware can either claim compatibility with older
compatible strings (the compatible property in the DT is a list), or
can have the new string added to the match table in the driver;
whichever option makes the most sense.
g.
--
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] spi: Add spi-s3c64xx driver dependency on ARCH_EXYNOS4
On Wed, Jan 25, 2012 at 05:20:59PM +0100, Sylwester Nawrocki wrote: The spi-s3c64xx driver is also used on Exynos4 so update the dependency to enable build on those platforms. Cc: Jaswinder Singh jassi.b...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Applied, thanks. --- drivers/spi/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 3f9a47e..a9f8faf 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -299,7 +299,7 @@ config SPI_S3C24XX_FIQ config SPI_S3C64XX tristate Samsung S3C64XX series type SPI - depends on (ARCH_S3C64XX || ARCH_S5P64X0) + depends on (ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS4) select S3C64XX_DMA if ARCH_S3C64XX help SPI driver for Samsung S3C64XX and newer SoCs. -- 1.7.8.3 -- 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/3] spi/s3c64xx diagnostic and PM updates
On Sat, Jan 21, 2012 at 6:23 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610: Linux 3.2 (2012-01-04 15:55:44 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi/s3c64xx Pushed out to git://git.secretlab.ca/git/linux-2.6.git spi/merge. I'll ask Linus to pull in a couple of days after it has hit linux-next. g. They've all been posted several times before but seem to have got dropped on the floor somewhere along the line. Mark Brown (3): spi/s3c64xx: Log error interrupts spi/s3c64xx: Convert to dev_pm_ops spi/s3c64xx: Implement runtime PM support drivers/spi/spi-s3c64xx.c | 115 1 files changed, 104 insertions(+), 11 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] mmc: Add OF bindings support for mmc host controller capabilities
On Mon, Nov 07, 2011 at 07:51:26PM +0530, Thomas Abraham wrote: On 5 November 2011 01:27, Olof Johansson o...@lixom.net wrote: On Thu, Nov 03, 2011 at 02:06:02AM +0530, Thomas Abraham wrote: Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- .../devicetree/bindings/mmc/linux-mmc-host.txt | 13 drivers/mmc/core/host.c | 31 include/linux/mmc/host.h | 1 + 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt diff --git a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file mode 100644 index 000..714b2b1 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt @@ -0,0 +1,13 @@ +* Linux MMC Host Controller Capabilities + +The following bindings can be used in a device node to specify any board +specific mmc host controller capabilities. + +- linux,mmc_cap_4_bit_data - Host can do 4-bit transfers +- linux,mmc_cap_mmc_highspeed - Host can do MMC high-speed timing +- linux,mmc_cap_sd_highspeed - Host can do SD high-speed timing +- linux,mmc_cap_needs_poll - Host needs polling for card detection +- linux,mmc_cap_8_bit_data - Host can do 8-bit transfer +- linux,mmc_cap_disable - Host can be disabled and re-enabled to save power +- linux,mmc_cap_nonremovable - Host is connected to nonremovable media +- linux,mmc_cap_erase - Host allows erase/trim commands linux-prefixed properties are a big red flag. The device tree should describe the hardware, not what linux does with the hardware. The vendor-prefixes documentation for device tree bindings includes 'linux' as an option. And I was trying to encode the linux specific host controller capabilities using the above bindings. See previous comments about support-8bit for encoding exactly the same hardware capability in a linux-agnostic way. What the sdhci driver chooses to do with it is up to the driver, and in some cases it means it will set the capabilities flag. Same goes for the other properties. It should not go in as it is implemented in this patch, it needs to be fixed up. Ok. I will remove all these linux specific bindings and replace with a more generic ones. Bindings will be defined for all the linux defined host capabilities. Non-linux platforms can add additional bindings as required. A function to parse such properties from a controller device node could actually be shared among all the mmc/sd host controller drivers in linux. I will redo this patch and submit again. Thanks Olof for your review and comments. This patch appears to be conceptually wrong. Many of these properties are merely static capabilities of each individual device which the driver should already have knowledge of, and be setting the capability bits appropriately on its own. So, you /don't/ want to simply create a 1:1 list between the current linux capability bits (which are subject to change) and the device tree properties (which ideally must not be changed after they are defined). What you need to do is figure out which properties are required to describe the hardware about things that the driver wouldn't already know. For example, 'polling' is something the driver would already know because it is an aspect of the specific device, but 'nonremovable' is a physical characteristic of some boards. 'disable' and the speed timings are also something I would expect the driver to know about and what to set itself. So, only define properties for things that the device-specific driver cannot know for itself; or are the sort of parameters that a multi-device driver is already using for differentiation (ie. appears in pdata instead of directly set by the driver). You should be able to justify the need for each property that gets defined. g. -- 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 4/9] serial: samsung: remove struct 's3c24xx_uart_clksrc' and all uses of it
On Mon, Oct 10, 2011 at 03:38:00PM +0530, Thomas Abraham wrote: With clkdev based clock lookup added to samsung serial driver, the use of 'struct s3c24xx_uart_clksrc' to supply clock names in platform data is removed from all the Samsung platform code. Cc: Ben Dooks ben-li...@fluff.org Cc: Ramax Lo rama...@gmail.com Cc: Vasily Khoruzhick anars...@gmail.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- arch/arm/mach-exynos4/init.c | 15 +-- arch/arm/mach-s3c2410/mach-bast.c| 22 --- arch/arm/mach-s3c2410/mach-vr1000.c | 24 - arch/arm/mach-s3c2440/mach-anubis.c | 22 +-- arch/arm/mach-s3c2440/mach-at2440evb.c | 22 +-- arch/arm/mach-s3c2440/mach-osiris.c | 24 ++--- arch/arm/mach-s3c2440/mach-rx1950.c | 18 ++-- arch/arm/mach-s3c2440/mach-rx3715.c | 19 ++--- arch/arm/mach-s5p64x0/init.c | 31 -- arch/arm/mach-s5pv210/init.c | 19 - arch/arm/plat-samsung/include/plat/regs-serial.h | 23 drivers/tty/serial/samsung.h |1 - 12 files changed, 14 insertions(+), 226 deletions(-) Nice diffstat. :-) g. -- 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 9/9] serial: samsung: add device tree support
On Mon, Oct 10, 2011 at 03:38:05PM +0530, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's uart controller.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
.../devicetree/bindings/serial/samsung_uart.txt| 14
drivers/tty/serial/samsung.c | 36 ++-
2 files changed, 48 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/samsung_uart.txt
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.txt
b/Documentation/devicetree/bindings/serial/samsung_uart.txt
new file mode 100644
index 000..2c8a17c
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.txt
@@ -0,0 +1,14 @@
+* Samsung's UART Controller
+
+The Samsung's UART controller is used for interfacing SoC with serial
communicaion
+devices.
+
+Required properties:
+- compatible: should be
+ - samsung,exynos4210-uart, for UART's compatible with Exynos4210 uart
ports.
+
+- reg: base physical address of the controller and length of memory mapped
+ region.
+
+- interrupts: interrupt number to the cpu. The interrupt specifier format
depends
+ on the interrupt controller parent.
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index c89987b..efe3756 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -42,6 +42,7 @@
#include linux/delay.h
#include linux/clk.h
#include linux/cpufreq.h
+#include linux/of.h
#include asm/irq.h
@@ -1163,10 +1164,26 @@ static ssize_t s3c24xx_serial_show_clksrc(struct
device *dev,
static DEVICE_ATTR(clock_source, S_IRUGO, s3c24xx_serial_show_clksrc, NULL);
+
/* Device driver serial port probe */
+static const struct of_device_id s3c24xx_uart_dt_match[];
static int probe_index;
+static inline struct s3c24xx_serial_drv_data *s3c24xx_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(s3c24xx_uart_dt_match, pdev-dev.of_node);
+ return (struct s3c24xx_serial_drv_data *)match-data;
+ }
+#endif
+ return (struct s3c24xx_serial_drv_data *)
+ platform_get_device_id(pdev)-driver_data;
+}
+
static int s3c24xx_serial_probe(struct platform_device *pdev)
{
struct s3c24xx_uart_port *ourport;
@@ -1176,8 +1193,11 @@ static int s3c24xx_serial_probe(struct platform_device
*pdev)
ourport = s3c24xx_serial_ports[probe_index];
- ourport-drv_data = (struct s3c24xx_serial_drv_data *)
- platform_get_device_id(pdev)-driver_data;
+ ourport-drv_data = s3c24xx_get_driver_data(pdev);
+ if (!ourport-drv_data) {
+ dev_err(pdev-dev, could not find driver data\n);
+ return -ENODEV;
+ }
ourport-info = ourport-drv_data-info;
ourport-cfg = (pdev-dev.platform_data) ?
@@ -1626,6 +1646,17 @@ static struct platform_device_id
s3c24xx_serial_driver_ids[] = {
};
MODULE_DEVICE_TABLE(platform, s3c24xx_serial_driver_ids);
+#ifdef CONFIG_OF
+static const struct of_device_id s3c24xx_uart_dt_match[] = {
+ { .compatible = samsung,exynos4210-uart,
+ .data = exynos4210_serial_drv_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
+#else
+#define s3c24xx_uart_dt_match NULL
+#endif
+
static struct platform_driver samsung_serial_driver = {
.probe = s3c24xx_serial_probe,
.remove = __devexit_p(s3c24xx_serial_remove),
@@ -1634,6 +1665,7 @@ static struct platform_driver samsung_serial_driver = {
.name = samsung-uart,
.owner = THIS_MODULE,
.pm = SERIAL_SAMSUNG_PM_OPS,
+ .of_match_table = s3c24xx_uart_dt_match,
},
};
--
1.6.6.rc2
--
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] ARM: Samsung: Move timer irq numbers to end of linux irq space
On Fri, Oct 21, 2011 at 06:56:52PM +0900, Kukjin Kim wrote: Changhwan Youn wrote: Hi Thomas, All UART_IRQ_RXD, TXD, ERR of Samsung's platforms are also statically mapped to linux irq numbers 16 to 31. These interrupts also need proper handling. Best regards, Changhwan Youn Hi all, Hmm, I'd like to apply Thomas' device tree series for EXYNOS4 and Samsung stuff for upcoming merge window but there are still some comments on some stuff and that should be fixed before applying. In addition I need to keep the ordering to apply them to avoid conflicts. But as you know, v3.1 is now close at hand and we don't have enough time for it now :( I will leave tomorrow morning (KST) for KS. I will talk to Grant Likely about this in Prague :) One of the goals I have for the hacking summit is to get as much of the outstanding DT patches queued up and into linux-next. g. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. On 10/10/2011 03:11 AM, Thomas Abraham wrote: All of Samsung's s5p platforms have timer irqs statically mapped from linux irq numbers 11 to 15. These timer irqs are moved to end of the statically mapped linux irq space and the hardware irqs, which were statically mapped starting from 32 is moved to start from 0. The NR_IRQS macro is consolidated for all the s5p platforms in this process. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- arch/arm/mach-exynos4/include/mach/entry-macro.S |1 - arch/arm/mach-exynos4/include/mach/irqs.h|3 +-- arch/arm/mach-s5p64x0/include/mach/irqs.h|4 +--- arch/arm/mach-s5pc100/include/mach/irqs.h|3 +-- arch/arm/mach-s5pv210/include/mach/irqs.h|3 +-- arch/arm/plat-samsung/include/plat/irqs.h|7 +-- 6 files changed, 9 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-exynos4/include/mach/entry-macro.S b/arch/arm/mach- exynos4/include/mach/entry-macro.S index 4c9adbd..5c4fbcc 100644 --- a/arch/arm/mach-exynos4/include/mach/entry-macro.S +++ b/arch/arm/mach-exynos4/include/mach/entry-macro.S @@ -72,7 +72,6 @@ cmpcc \irqnr, \irqnr cmpne \irqnr, \tmp cmpcs \irqnr, \irqnr - addne \irqnr, \irqnr, #32 .endm diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach- exynos4/include/mach/irqs.h index dfd4b7e..43087c3 100644 --- a/arch/arm/mach-exynos4/include/mach/irqs.h +++ b/arch/arm/mach-exynos4/include/mach/irqs.h @@ -163,7 +163,6 @@ #define IRQ_GPIO2_NR_GROUPS 9 #define IRQ_GPIO_END (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT) -/* Set the default NR_IRQS */ -#define NR_IRQS (IRQ_GPIO_END + 64) +#define IRQ_TIMER_BASE (IRQ_GPIO_END + 64) #endif /* __ASM_ARCH_IRQS_H */ diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach- s5p64x0/include/mach/irqs.h index 53982db..bea73cc 100644 --- a/arch/arm/mach-s5p64x0/include/mach/irqs.h +++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h @@ -141,8 +141,6 @@ #define IRQ_EINT_GROUP(grp, x) (IRQ_EINT_GROUP##grp##_BASE + (x)) -/* Set the default NR_IRQS */ - -#define NR_IRQS (IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1) +#define IRQ_TIMER_BASE (IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1) #endif /* __ASM_ARCH_IRQS_H */ diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach- s5pc100/include/mach/irqs.h index d2eb475..3a9d300 100644 --- a/arch/arm/mach-s5pc100/include/mach/irqs.h +++ b/arch/arm/mach-s5pc100/include/mach/irqs.h @@ -104,8 +104,7 @@ #define S5P_GPIOINT_BASE (IRQ_EINT(31) + 1) #define S5P_GPIOINT_GROUP_MAXNR 21 -/* Set the default NR_IRQS */ -#define NR_IRQS (IRQ_EINT(31) + S5P_GPIOINT_COUNT + 1) +#define IRQ_TIMER_BASE (IRQ_EINT(31) + S5P_GPIOINT_COUNT + 1) /* Compatibility */ #define IRQ_LCD_FIFO IRQ_LCD0 diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach- s5pv210/include/mach/irqs.h index 5e0de3a..df3173a 100644 --- a/arch/arm/mach-s5pv210/include/mach/irqs.h +++ b/arch/arm/mach-s5pv210/include/mach/irqs.h @@ -125,8 +125,7 @@ #define S5P_GPIOINT_BASE (IRQ_EINT(31) + 1) #define S5P_GPIOINT_GROUP_MAXNR 22 -/* Set the default NR_IRQS */ -#define NR_IRQS (IRQ_EINT(31) + S5P_GPIOINT_COUNT + 1) +#define IRQ_TIMER_BASE (IRQ_EINT(31) + S5P_GPIOINT_COUNT + 1) /* Compatibility */ #define IRQ_LCD_FIFO IRQ_LCD0 diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat- samsung/include/plat/irqs.h index 08d1a7e..b8918b3 100644 --- a/arch
Re: [PATCH 1/2] ARM: Samsung: Add Exynos4 device tree enabled board file
On Tue, Oct 11, 2011 at 07:43:15PM +0530, Thomas Abraham wrote: Add a new Exynos4 compatible device tree enabled board file. Boards based on the Exynos4 family of SoC's can use this as the machine/board file. When using this machine fike, a corresponding device tree blob which describes the board's properties should be supplied at boot time to the kernel. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca --- .../devicetree/bindings/arm/insignal-boards.txt|8 ++ .../devicetree/bindings/arm/samsung-boards.txt |8 ++ arch/arm/mach-exynos4/Kconfig | 14 +++ arch/arm/mach-exynos4/Makefile |2 + arch/arm/mach-exynos4/mach-exynos4-dt.c| 85 5 files changed, 117 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt create mode 100644 Documentation/devicetree/bindings/arm/samsung-boards.txt create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c diff --git a/Documentation/devicetree/bindings/arm/insignal-boards.txt b/Documentation/devicetree/bindings/arm/insignal-boards.txt new file mode 100644 index 000..524c3dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/insignal-boards.txt @@ -0,0 +1,8 @@ +* Insignal's Exynos4210 based Origen evaluation board + +Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC. + +Required root node properties: +- compatible = should be one or more of the following. +(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board. +(b) samsung,exynos4210 - for boards based on Exynos4210 SoC. diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt new file mode 100644 index 000..0bf68be --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt @@ -0,0 +1,8 @@ +* Samsung's Exynos4210 based SMDKV310 evaluation board + +SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC. + +Required root node properties: +- compatible = should be one or more of the following. +(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board. +(b) samsung,exynos4210 - for boards based on Exynos4210 SoC. diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index 0c5888a..39dc135 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -304,6 +304,20 @@ config MACH_SMDK4412 help Machine support for Samsung SMDK4412 +comment Flattened Device Tree based board for Exynos4 based SoC + +config MACH_EXYNOS4_DT + bool Samsung Exynos4 Machine using device tree + select CPU_EXYNOS4210 + select USE_OF + select ARM_AMBA + select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD + help + Machine support for Samsung Exynos4 machine with device tree enabled. + Select this if a fdt blob is available for the Exynos4 SoC based board. + Note: This is under development and not all peripherals can be supported + with this machine file. + endmenu comment Configuration for HSMMC bus width diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile index 8066538..4e302cb 100644 --- a/arch/arm/mach-exynos4/Makefile +++ b/arch/arm/mach-exynos4/Makefile @@ -37,6 +37,8 @@ obj-$(CONFIG_MACH_ORIGEN) += mach-origen.o obj-$(CONFIG_MACH_SMDK4212) += mach-smdk4x12.o obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o +obj-$(CONFIG_MACH_EXYNOS4_DT)+= mach-exynos4-dt.o + # device support obj-y+= dev-audio.o diff --git a/arch/arm/mach-exynos4/mach-exynos4-dt.c b/arch/arm/mach-exynos4/mach-exynos4-dt.c new file mode 100644 index 000..85fa027 --- /dev/null +++ b/arch/arm/mach-exynos4/mach-exynos4-dt.c @@ -0,0 +1,85 @@ +/* + * Samsung's Exynos4210 flattened device tree enabled machine + * + * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * Copyright (c) 2010-2011 Linaro Ltd. + * www.linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include linux/of_platform.h +#include linux/serial_core.h + +#include asm/mach/arch.h +#include mach/map.h + +#include plat/cpu.h +#include plat/regs-serial.h +#include plat/exynos4.h + +/* + * The following lookup table is used to override device names when devices + * are registered from device tree. This is temporarily added to enable + * device tree support addition for the Exynos4 architecture. + * + * For drivers that require platform data to be provided from the machine + * file
Re: [PATCH 2/2] ARM: dts: Add intial dts file for Exynos4210 SoC, SMDKV310 and Origen board
On Tue, Oct 11, 2011 at 07:43:16PM +0530, Thomas Abraham wrote:
Add initial dts file for Exynos4210 SoC. This dts file describes the SoC
specific devices and properties. Along with this, add dts file for Samsung's
SMDKV310 board and Insignal's Origen board which uses the Exynos4210 dts file
and extends it to describe the board specific properties.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/exynos4210-origen.dts | 137 ++
arch/arm/boot/dts/exynos4210-smdkv310.dts | 182 +
arch/arm/boot/dts/exynos4210.dtsi | 403
+
3 files changed, 722 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4210-origen.dts
create mode 100644 arch/arm/boot/dts/exynos4210-smdkv310.dts
create mode 100644 arch/arm/boot/dts/exynos4210.dtsi
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
new file mode 100644
index 000..b8c4763
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -0,0 +1,137 @@
+/*
+ * Samsung's Exynos4210 based Origen board device tree source
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Device tree source file for Insignal's Origen board which is based on
+ * Samsung's Exynos4210 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ exynos4210.dtsi
+
+/ {
+ model = Insignal Origen evaluation board based on Exynos4210;
+ compatible = insignal,origen, samsung,exynos4210;
+
+ memory {
+ reg = 0x4000 0x4000;
+ };
+
+ chosen {
+ bootargs =root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc;
+ };
+
+ sdhci@1253 {
+ samsung,sdhci-bus-width = 4;
+ linux,mmc_cap_4_bit_data;
+ samsung,sdhci-cd-internal;
+ gpio-cd = gpk2 2 2 3 3;
+ gpios = gpk2 0 2 0 3,
+ gpk2 1 2 0 3,
+ gpk2 3 2 3 3,
+ gpk2 4 2 3 3,
+ gpk2 5 2 3 3,
+ gpk2 6 2 3 3;
+ };
+
+ sdhci@1251 {
+ samsung,sdhci-bus-width = 4;
+ linux,mmc_cap_4_bit_data;
+ samsung,sdhci-cd-internal;
+ gpio-cd = gpk0 2 2 3 3;
+ gpios = gpk0 0 2 0 3,
+ gpk0 1 2 0 3,
+ gpk0 3 2 3 3,
+ gpk0 4 2 3 3,
+ gpk0 5 2 3 3,
+ gpk0 6 2 3 3;
+ };
+
+ gpio_keys {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ up {
+ label = Up;
+ gpios = gpx2 0 0 0 2;
+ linux,code = 103;
+ };
+
+ down {
+ label = Down;
+ gpios = gpx2 1 0 0 2;
+ linux,code = 108;
+ };
+
+ back {
+ label = Back;
+ gpios = gpx1 7 0 0 2;
+ linux,code = 158;
+ };
+
+ home {
+ label = Home;
+ gpios = gpx1 6 0 0 2;
+ linux,code = 102;
+ };
+
+ menu {
+ label = Menu;
+ gpios = gpx1 5 0 0 2;
+ linux,code = 139;
+ };
+ };
+
+ keypad@100A {
+ status = disabled;
+ };
+
+ sdhci@1252 {
+ status = disabled;
+ };
+
+ sdhci@1254 {
+ status = disabled;
+ };
+
+ i2c@1386 {
+ status = disabled;
+ };
+
+ i2c@1387 {
+ status = disabled;
+ };
+
+ i2c@1388 {
+ status = disabled;
+ };
+
+ i2c@1389 {
+ status = disabled;
+ };
+
+ i2c@138A {
+ status = disabled;
+ };
+
+ i2c@138B {
+ status = disabled;
+ };
+
+ i2c@138C {
+ status = disabled;
+ };
+
+ i2c@138D {
+ status = disabled;
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
new file mode 100644
index 000..27afc8e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -0,0 +1,182 @@
+/*
+ * Samsung's Exynos4210 based SMDKV310 board device tree source
+ *
+ * Copyright
Re: [PATCH] rtc: rtc-s3c: Add device tree support
On Tue, Oct 11, 2011 at 07:48:07PM +0900, Kukjin Kim wrote:
Thomas Abraham wrote:
On 3 September 2011 21:19, Thomas Abraham thomas.abra...@linaro.org
wrote:
Add device tree based discovery support for Samsung's rtc controller.
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 20
drivers/rtc/rtc-s3c.c | 21
-
2 files changed, 40 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/s3c-rtc.txt
Ping. Any comments for this patch? If this looks fine, can this be
considered for 3.2 merge via the Samsung kernel tree.
(Cc'ed Alessandro Zummo who is RTC Subsystem maintainer)
I'm ok with this, so if this can be got the ack from Grant and Alessandro,
will take this.
Acked-by: Grant Likely grant.lik...@secretlab.ca
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
new file mode 100644
index 000..90ec45f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -0,0 +1,20 @@
+* Samsung's S3C Real Time Clock controller
+
+Required properties:
+- compatible: should be one of the following.
+ * samsung,s3c2410-rtc - for controllers compatible with s3c2410
rtc.
+ * samsung,s3c6410-rtc - for controllers compatible with s3c6410
rtc.
+- reg: physical base address of the controller and length of memory
mapped
+ region.
+- interrupts: Two interrupt numbers to the cpu should be specified.
First
+ interrupt number is the rtc alarm interupt and second interrupt
number
+ is the rtc tick interrupt. The number of cells representing a
interrupt
+ depends on the parent interrupt controller.
+
+Example:
+
+ rtc@1007 {
+ compatible = samsung,s3c6410-rtc;
+ reg = 0x1007 0x100;
+ interrupts = 44 0 45 0;
+ };
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4e7c04e..29f928c 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -25,6 +25,7 @@
#include linux/clk.h
#include linux/log2.h
#include linux/slab.h
+#include linux/of.h
#include mach/hardware.h
#include asm/uaccess.h
@@ -481,7 +482,13 @@ static int __devinit s3c_rtc_probe(struct
platform_device *pdev)
goto err_nortc;
}
- s3c_rtc_cpu_type = platform_get_device_id(pdev)-driver_data;
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node)
+ s3c_rtc_cpu_type = of_device_is_compatible(pdev-
dev.of_node,
+ samsung,s3c6410-rtc) ? TYPE_S3C64XX :
TYPE_S3C2410;
+ else
+#endif
+ s3c_rtc_cpu_type =
platform_get_device_id(pdev)-driver_data;
/* Check RTC Time */
@@ -603,6 +610,17 @@ static int s3c_rtc_resume(struct platform_device
*pdev)
#define s3c_rtc_resume NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id s3c_rtc_dt_match[] = {
+ { .compatible = samsung,s3c2410-rtc },
^^^
+ { .compatible = samsung,s3c6410-rtc },
^^^
+ {},
^^^
should be Tab?
+};
+MODULE_DEVICE_TABLE(of, s3c_rtc_dt_match);
+#else
+#define s3c_rtc_dt_match NULL
+#endif
+
static struct platform_device_id s3c_rtc_driver_ids[] = {
{
.name = s3c2410-rtc,
@@ -625,6 +643,7 @@ static struct platform_driver s3c_rtc_driver = {
.driver = {
.name = s3c-rtc,
.owner = THIS_MODULE,
+ .of_match_table = s3c_rtc_dt_match,
^^^
Same as above...
But I know, Thomas' original patch has no problem...probably when ping,
happened above.
},
};
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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] gpio: exynos4: Add device tree support
On Wed, Oct 12, 2011 at 10:33:48PM +0900, Kukjin Kim wrote: Thomas Abraham wrote: As gpio chips get registered, a device tree node which represents the gpio chip is searched and attached to it. A translate function is also provided to convert the gpio specifier into actual platform settings for pin function selection, pull up/down and driver strength settings. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Hi Thomas, You got some comments from Rob, so could you please address from him? Others, looks ok to me. And I need to get the ack from Grant to upstream via Samsung tree for upcoming merge window. Grant, is this ok for you? Yes, go ahead and merge it with my: Acked-by: Grant Likely grant.lik...@secretlab.ca g. -- 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] gpio: exynos4: Add device tree support
On Wed, Oct 12, 2011 at 09:45:25PM +0530, Thomas Abraham wrote: On 12 October 2011 20:41, Rob Herring robherri...@gmail.com wrote: On 10/11/2011 11:06 AM, Thomas Abraham wrote: On 11 October 2011 21:00, Rob Herring robherri...@gmail.com wrote: On 10/11/2011 10:19 AM, Thomas Abraham wrote: Hi Rob, On 11 October 2011 20:41, Rob Herring robherri...@gmail.com wrote: Thomas, On 10/11/2011 03:16 AM, Thomas Abraham wrote: As gpio chips get registered, a device tree node which represents the gpio chip is searched and attached to it. A translate function is also provided to convert the gpio specifier into actual platform settings for pin function selection, pull up/down and driver strength settings. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- This patch is based on the latest consolidated Samsung GPIO driver available in the following tree: https://github.com/kgene/linux-samsung.git branch: for-next .../devicetree/bindings/gpio/gpio-samsung.txt | 30 +++ drivers/gpio/gpio-samsung.c | 53 2 files changed, 83 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt new file mode 100644 index 000..883faeb --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt @@ -0,0 +1,30 @@ +Samsung Exynos4 GPIO Controller + +Required properties: +- compatible: Format of compatible property value should be + samsung,exynos4-gpio-controller_name. Example: For GPA0 controller, the + compatible property value should be samsung,exynos4-gpio-gpa0. Isn't gpa0 an instance of the h/w, not a version? GPA0 is a instance of the gpio controller. There are several such instances and there could be differences in those instances such as the number of GPIO lines managed by that gpio controller instance. That doesn't seem like a reason to have different compatible strings. Does that affect the programming model of the controller? Unused lines whether at the board level or SOC level shouldn't really matter. No, that does not affect the programming of the controller. The reason for the instance name extension in compatible string is to match the gpio_chip with a gpio controller node. When matched, the of_node pointer of the gpio_chip is set to point to that controller node. This might not be the best possible implementation but the device tree support code in this patch is dictated by the structure of the existing gpio driver code. As you suggested previously, I will look at reworking the gpio driver a little later but for now, there was a need for working gpio dt solution to make progress on dt support for other controllers. Linux should provide clues about what's needed in a binding, but the binding should not be defined based on current Linux code. Doing the binding one way and changing it later is not a good plan. Ok. When starting on this, two compatible values where used for the gpio controllers, one was samsung,exynos4-gpio and another was samsung,exynos4-gpio-ctrl_name. And when the gpio dt support would mature, the second compatible value could be dropped. Non-linux platforms could always use the generic samsung,exynos4-gpio compatible value to match. I moved to using only samsung,exynos4-gpio-ctrl_name just before sending this patch because I was not sure of the right approach. I think you need to convert all users of gpio over as well so you can move to dynamic gpio_chip creation and gpio numbering. Or maybe you can match based on base address? This is going to be a common problem as gpio is converted over to DT. Perhaps Grant or others have suggestions on the approach to use. Yes, I agree with you about the dynamic gpio_chip creation and gpio numbering. Probably, I should have focussed more on this before moving to dt support for other controllers. But matching based on base address is still an option if that is better than matching with compatible values as defined currently. The 'struct samsung_gpio_chip' which encapsulates 'struct gpio_chip' has information about the base address of the gpio controller. The match of gpio device node with 'struct gpio_chip' can be quickly moved over to base address matching. Would this be better than the current approach? That's what I would do. g. -- 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/3] ARM: Exynos4: Add support for dt irq specifier to linux virq conversion
On Mon, Oct 10, 2011 at 01:41:29PM +0530, Thomas Abraham wrote:
Add support for conversion of device tree interrupt specifier to linux
virq domain for GIC and Interrupt combiner controllers.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/irq/samsung-combiner.txt | 24 ++
arch/arm/mach-exynos4/cpu.c| 20 -
arch/arm/mach-exynos4/irq-combiner.c | 45
3 files changed, 88 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/irq/samsung-combiner.txt
diff --git a/Documentation/devicetree/bindings/irq/samsung-combiner.txt
b/Documentation/devicetree/bindings/irq/samsung-combiner.txt
new file mode 100644
index 000..b7d5c30
--- /dev/null
+++ b/Documentation/devicetree/bindings/irq/samsung-combiner.txt
@@ -0,0 +1,24 @@
+* Exynos4 Interrupt Combiner Controller
+
+Samsung's Exynos4 architecture includes a interrupt combiner which
+can combine interrupt sources as a group and provide a single
+interrupt request for the group. The interrupt request from each
+group are connected to a parent interrupt controller, which is GIC
+in case of Exynos4.
+
+Required properties:
+- compatible: should be samsung,exynos4-combiner.
+- interrupt-cells: should be 2. The meaning of the cells are
+* First Cell: Combiner Group Number.
+* Second Cell: Interrupt within the group.
+- reg: Base address and size of interrupt combiner registers.
+- interrupt-controller: Identifies the node as an interrupt controller.
+
+Example:
+
+ combiner: interrupt-controller@1044 {
+ compatible = samsung,exynos4-combiner;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ reg = 0x1044 0x200;
+ };
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 358624d..776e8d4 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,8 @@
#include linux/sched.h
#include linux/sysdev.h
+#include linux/of.h
+#include linux/of_irq.h
#include asm/mach/map.h
#include asm/mach/irq.h
@@ -38,6 +40,8 @@ unsigned int gic_bank_offset __read_mostly;
extern int combiner_init(unsigned int combiner_nr, void __iomem *base,
unsigned int irq_start);
extern void combiner_cascade_irq(unsigned int combiner_nr, unsigned int irq);
+extern void combiner_init_dt(struct device_node *node,
+ struct device_node *parent);
/* Initial IO mappings */
static struct map_desc exynos4_iodesc[] __initdata = {
@@ -229,13 +233,27 @@ static void exynos4_gic_irq_fix_base(struct irq_data *d)
(gic_bank_offset * smp_processor_id());
}
+#ifdef CONFIG_OF
+static const struct of_device_id exynos4_dt_irq_match[] = {
+ { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+ { .compatible = samsung,exynos4-combiner, .data = combiner_init_dt, },
+ {},
+};
+#endif
+
void __init exynos4_init_irq(void)
{
int irq;
gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
- gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+#ifdef CONFIG_OF
+ if (of_have_populated_dt())
+ of_irq_init(exynos4_dt_irq_match);
+ else
+#endif
With the proper empty implementations of of_have_populated_dt() and
of_irq_init(), the #ifdef block here should probably be removed.
+ gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+
gic_arch_extn.irq_eoi = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_unmask = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_mask = exynos4_gic_irq_fix_base;
diff --git a/arch/arm/mach-exynos4/irq-combiner.c
b/arch/arm/mach-exynos4/irq-combiner.c
index 5a2758a..198bd0d 100644
--- a/arch/arm/mach-exynos4/irq-combiner.c
+++ b/arch/arm/mach-exynos4/irq-combiner.c
@@ -12,7 +12,12 @@
* published by the Free Software Foundation.
*/
+#include linux/errno.h
#include linux/io.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/irqdomain.h
+#include linux/slab.h
#include asm/mach/irq.h
@@ -122,3 +127,43 @@ void __init combiner_init(unsigned int combiner_nr, void
__iomem *base,
set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
}
}
+
+#ifdef CONFIG_OF
+/* Translate dt irq specifier to linux virq for interrupt combiner
controller */
+static int exynos4_irq_domain_combiner_dt_translate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ if (d-of_node != controller)
+ return -EINVAL;
+ if (intsize 2)
+ return -EINVAL;
+
+ *out_hwirq = COMBINER_IRQ(intspec[0], intspec[1]);
+ *out_type =
Re: [PATCH 2/3] ARM: Exynos4: Add ioremap interceptor for statically remapped regions
On Wed, Oct 12, 2011 at 9:28 PM, Thomas Abraham thomas.abra...@linaro.org wrote: On 12 October 2011 22:00, Thomas Abraham thomas.abra...@linaro.org wrote: On 12 October 2011 21:43, Rob Herring robherri...@gmail.com wrote: On 10/10/2011 03:11 AM, Thomas Abraham wrote: ioremap() request for statically remapped regions are intercepted and the statically assigned virtual address is returned. For requests for which there are no statically remapped regions, the requests are let through. Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- arch/arm/mach-exynos4/cpu.c | 16 arch/arm/mach-exynos4/include/mach/io.h | 4 2 files changed, 20 insertions(+), 0 deletions(-) You won't need this with Nico's vmalloc.h clean-up series. It does exactly this but generically for all platforms. Ok. Thanks for your suggestion. I will move to using Nico's patches. From Nico's reply to his pull request of vmalloc cleanup series, it looks like that pull request has been withdrawn (hope I am not missing anything here). Without Nico's series, and gic dt support for exynos4 support requiring this patch, all other workarounds to replace this patch does not seem be correct. So is it acceptable to retain this patch and later rework/drop the exynos4 specific ioremap along with Nico's vmalloc patch series when it is merged. I would say yes, but I don't get to make the decision here. g. -- 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: [RESEND][PATCH] gpio/samsung: Fix incorrect gpio pull up/down callback for Exynos4
[] = {
},
}, {
.base = (S5P_VA_GPIO2 + 0xC60),
- .config = samsung_gpio_cfgs[3],
+ .config = samsung_gpio_cfgs[9],
.irq_base = IRQ_EINT(24),
.chip = {
.base = EXYNOS4_GPX3(0),
--
1.6.6.rc2
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/7] SPI: S3C64XX: Use bus clocks created using clkdev
On Fri, Sep 23, 2011 at 05:23:41PM +0530, Padmavathi Venna wrote:
This patch modifies the driver to stop depending on the
clock names being passed from platform and switch over
to lookup clocks generic names using clkdev
Signed-off-by: Padmavathi Venna padm...@samsung.com
Looks okay to me.
Acked-by: Grant Likely grant.lik...@secretlab.ca
This series I imagine should go in via the arm-soc tree.
g.
---
drivers/spi/spi-s3c64xx.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 019a716..dcf7e10 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -971,6 +971,7 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
struct s3c64xx_spi_info *sci;
struct spi_master *master;
int ret;
+ char clk_name[16];
if (pdev-id 0) {
dev_err(pdev-dev,
@@ -984,11 +985,6 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
}
sci = pdev-dev.platform_data;
- if (!sci-src_clk_name) {
- dev_err(pdev-dev,
- Board init must call s3c64xx_spi_set_info()\n);
- return -EINVAL;
- }
/* Check for availability of necessary resource */
@@ -1073,17 +1069,17 @@ static int __init s3c64xx_spi_probe(struct
platform_device *pdev)
goto err4;
}
- sdd-src_clk = clk_get(pdev-dev, sci-src_clk_name);
+ sprintf(clk_name, spi_busclk%d, sci-src_clk_nr);
+ sdd-src_clk = clk_get(pdev-dev, clk_name);
if (IS_ERR(sdd-src_clk)) {
dev_err(pdev-dev,
- Unable to acquire clock '%s'\n, sci-src_clk_name);
+ Unable to acquire clock '%s'\n, clk_name);
ret = PTR_ERR(sdd-src_clk);
goto err5;
}
if (clk_enable(sdd-src_clk)) {
- dev_err(pdev-dev, Couldn't enable clock '%s'\n,
- sci-src_clk_name);
+ dev_err(pdev-dev, Couldn't enable clock '%s'\n, clk_name);
ret = -EBUSY;
goto err6;
}
--
1.7.4.4
--
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] GPIO: Samsung: correct pin configuration for S5PC100/S5PC110/Exynos4
On Fri, Sep 23, 2011 at 01:38:50PM +0200, Marek Szyprowski wrote:
Commit 1b39d5f2cc introduced new common gpio driver for all Samsung GPIO
SoCs. The new driver use wrong configuration setup for all gpio pins on
S5PC100 and S5PV210 SoCs and external interrupt lines on Exynos4 SoCs.
This patch fixes this issue.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/gpio/gpio-samsung.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index cdffb0c..b6be77a 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -1862,7 +1862,7 @@ static struct samsung_gpio_chip s5pc100_gpios_4bit[] = {
* Followings are the gpio banks in S5PV210/S5PC110
*
* The 'config' member when left to NULL, is initialized to the default
- * structure samsung_gpio_cfgs[4] in the init function below.
+ * structure samsung_gpio_cfgs[3] in the init function below.
*
* The 'base' member is also initialized in the init function below.
* Note: The initialization of 'base' member of samsung_gpio_chip structure
@@ -2083,7 +2083,7 @@ static struct samsung_gpio_chip s5pv210_gpios_4bit[] = {
* Followings are the gpio banks in EXYNOS4210
*
* The 'config' member when left to NULL, is initialized to the default
- * structure samsung_gpio_cfgs[4] in the init function below.
+ * structure samsung_gpio_cfgs[3] in the init function below.
*
* The 'base' member is also initialized in the init function below.
* Note: The initialization of 'base' member of samsung_gpio_chip structure
@@ -2249,49 +2249,49 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
.label = GPL2,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY0(0),
.ngpio = EXYNOS4_GPIO_Y0_NR,
.label = GPY0,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY1(0),
.ngpio = EXYNOS4_GPIO_Y1_NR,
.label = GPY1,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY2(0),
.ngpio = EXYNOS4_GPIO_Y2_NR,
.label = GPY2,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY3(0),
.ngpio = EXYNOS4_GPIO_Y3_NR,
.label = GPY3,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY4(0),
.ngpio = EXYNOS4_GPIO_Y4_NR,
.label = GPY4,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY5(0),
.ngpio = EXYNOS4_GPIO_Y5_NR,
.label = GPY5,
},
}, {
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[0],
.chip = {
.base = EXYNOS4_GPY6(0),
.ngpio = EXYNOS4_GPIO_Y6_NR,
@@ -2299,7 +2299,7 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
},
}, {
.base = (S5P_VA_GPIO2 + 0xC00),
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[3],
.irq_base = IRQ_EINT(0),
.chip = {
.base = EXYNOS4_GPX0(0),
@@ -2309,7 +2309,7 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
},
}, {
.base = (S5P_VA_GPIO2 + 0xC20),
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[3],
.irq_base = IRQ_EINT(8),
.chip = {
.base = EXYNOS4_GPX1(0),
@@ -2319,7 +2319,7 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
},
}, {
.base = (S5P_VA_GPIO2 + 0xC40),
- .config = samsung_gpio_cfgs[4],
+ .config = samsung_gpio_cfgs[3],
.irq_base = IRQ_EINT(16),
.chip = {
.base = EXYNOS4_GPX2(0
Re: [PATCH] GPIO: Samsung: fix broken configuration for Exynos4 GPIO banks
On Thu, Sep 22, 2011 at 12:02:39PM +0200, Marek Szyprowski wrote:
Commit 1b39d5f2cc introduced new common gpio driver for all Samsung GPIO
SoCs. The new driver doesn't work correctly on Samsung Exynos4 SoC. It
fails to set configuration for all but external interrupt pins. This
patch fixes this issue.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/gpio/gpio-samsung.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 36f3675..be13580 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -446,6 +446,8 @@ static struct samsung_gpio_cfg s3c24xx_gpiocfg_banka = {
static struct samsung_gpio_cfg exynos4_gpio_cfg = {
.set_pull = exynos4_gpio_setpull,
.get_pull = exynos4_gpio_getpull,
+ .set_config = samsung_gpio_setcfg_4bit,
+ .get_config = samsung_gpio_getcfg_4bit,
};
static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
--
1.7.1.569.g6f426
--
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 1/2] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
On Mon, Sep 19, 2011 at 03:49:12PM +0530, Thomas Abraham wrote: For platforms using device tree, the static keypad device instances are not required and SAMSUNG_DEV_KEYPAD is not selected. Since, samsung keypad driver has dependency on SAMSUNG_DEV_KEYPAD config option, the driver is left out of the compilation for dt enabled platforms. An additional config option 'HAVE_SAMSUNG_KEYPAD' is added which the device tree based platforms can select. This config option is added as an alternative dependency for keypad driver. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- drivers/input/keyboard/Kconfig |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index b4dee9d..7c322a3 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -423,9 +423,16 @@ config KEYBOARD_PMIC8XXX To compile this driver as a module, choose M here: the module will be called pmic8xxx-keypad. +config HAVE_SAMSUNG_KEYPAD + bool + help + This will include Samsung Keypad controller driver support. If you + want to include Samsung Keypad support for any machine, kindly + select this in the respective mach-/Kconfig file. + config KEYBOARD_SAMSUNG tristate Samsung keypad support - depends on SAMSUNG_DEV_KEYPAD + depends on SAMSUNG_DEV_KEYPAD || HAVE_SAMSUNG_KEYPAD It would be better to modify SAMSUNG_DEV_KEYPAD to select HAVE_SAMSUNG_KEYPAD and then make KEYBOARD_SAMSUNG only depend on HAVE_SAMSUNG_KEYPAD instead of both. g. -- 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] input: samsung-keypad: Add device tree support
On Mon, Sep 19, 2011 at 03:49:13PM +0530, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Donghwa Lee dh09@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
A few things to fix below, but you can add my acked-by when you've
addressed them.
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++
drivers/input/keyboard/samsung-keypad.c| 179
++--
2 files changed, 255 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt
b/Documentation/devicetree/bindings/input/samsung-keypad.txt
new file mode 100644
index 000..ce3e394
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -0,0 +1,88 @@
+* Samsung's Keypad Controller device tree bindings
+
+Samsung's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-keypad: For controllers compatible with s3c6410 keypad
+controller.
+ - samsung,s5pv210-keypad: For controllers compatible with s5pv210 keypad
+controller.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+- samsung,keypad-num-rows: Number of row lines connected to the keypad
+ controller.
+
+- samsung,keypad-num-columns: Number of column lines connected to the
+ keypad controller.
+
+- row-gpios: List of gpios used as row lines. The gpio specifier for
+ this property depends on the gpio controller to which these row lines
+ are connected.
+
+- col-gpios: List of gpios used as column lines. The gpio specifier for
+ this property depends on the gpio controller to which these column
+ lines are connected.
+
+- Keys represented as child nodes: Each key connected to the keypad
+ controller is represented as a child node to the keypad controller
+ device node and should include the following properties.
+ - keypad,row: the row number to which the key is connected.
+ - keypad,column: the column number to which the key is connected.
+ - linux,code: the key-code to be reported when the key is pressed
+and released.
+
+Optional Properties specific to linux:
+- linux,keypad-no-autorepeat: do no enable autorepeat feature.
+- linux,keypad-wakeup: use any event on keypad as wakeup event.
+
+
+Example:
+ keypad@100A {
+ compatible = samsung,s5pv210-keypad;
+ reg = 0x100A 0x100;
+ interrupts = 173;
+ samsung,keypad-num-rows = 2;
+ samsung,keypad-num-columns = 8;
+ linux,input-no-autorepeat;
+ linux,input-wakeup;
+
+ row-gpios = gpx2 0 3 3 0
+ gpx2 1 3 3 0;
+
+ col-gpios = gpx1 0 3 0 0
+ gpx1 1 3 0 0
+ gpx1 2 3 0 0
+ gpx1 3 3 0 0
+ gpx1 4 3 0 0
+ gpx1 5 3 0 0
+ gpx1 6 3 0 0
+ gpx1 7 3 0 0;
+
+ key_1 {
+ keypad,row = 0;
+ keypad,column = 3;
+ linux,code = 2;
+ };
+
+ key_2 {
+ keypad,row = 0;
+ keypad,column = 4;
+ linux,code = 3;
+ };
+
+ key_3 {
+ keypad,row = 0;
+ keypad,column = 5;
+ linux,code = 4;
+ };
+ };
Binding looks okay to me.
diff --git a/drivers/input/keyboard/samsung-keypad.c
b/drivers/input/keyboard/samsung-keypad.c
index f689f49..2a477bc 100644
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@ -21,6 +21,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/sched.h
#include plat/keypad.h
@@ -68,31 +70,26 @@ struct samsung_keypad {
wait_queue_head_t wait;
bool stopped;
int irq;
+ enum samsung_keypad_type type;
unsigned int row_shift;
unsigned int rows;
unsigned int cols;
unsigned int row_state[SAMSUNG_MAX_COLS];
+#ifdef CONFIG_OF
+ int row_gpios[SAMSUNG_MAX_ROWS];
+
Re: [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote: Since gpio-samsung.c can replace old Samsung GPIO drivers, this patch removes them. Cc: Ben Dooks ben-li...@fluff.org Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kukjin Kim kgene@samsung.com Removing this code before adding the new code means it is not bisectable. I'll squash the two patches together when I pick them up.. g. --- arch/arm/plat-samsung/Makefile |2 - arch/arm/plat-samsung/gpio-config.c | 431 - arch/arm/plat-samsung/gpio.c| 167 drivers/gpio/Kconfig| 28 -- drivers/gpio/Makefile |9 - drivers/gpio/gpio-exynos4.c | 385 -- drivers/gpio/gpio-plat-samsung.c| 205 -- drivers/gpio/gpio-s3c24xx.c | 283 --- drivers/gpio/gpio-s3c64xx.c | 289 drivers/gpio/gpio-s5p64x0.c | 510 --- drivers/gpio/gpio-s5pc100.c | 354 drivers/gpio/gpio-s5pv210.c | 287 12 files changed, 0 insertions(+), 2950 deletions(-) delete mode 100644 arch/arm/plat-samsung/gpio-config.c delete mode 100644 arch/arm/plat-samsung/gpio.c delete mode 100644 drivers/gpio/gpio-exynos4.c delete mode 100644 drivers/gpio/gpio-plat-samsung.c delete mode 100644 drivers/gpio/gpio-s3c24xx.c delete mode 100644 drivers/gpio/gpio-s3c64xx.c delete mode 100644 drivers/gpio/gpio-s5p64x0.c delete mode 100644 drivers/gpio/gpio-s5pc100.c delete mode 100644 drivers/gpio/gpio-s5pv210.c -- 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/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/
On Mon, Sep 19, 2011 at 08:13:12PM +0900, Kukjin Kim wrote: Kukjin Kim wrote: (snip)... Hi Grant, I didn't get any comments on this series, gpio-samsung patches for consolidation of Samsung gpiolib. Please let me know whether this is ok to you or not. And I think, if you're ok, this should be sent to upstream via both gpio tree and arm(samsung) tree to avoid conflicts... As a note, following is its status... Kukjin Kim (9): ARM: SAMSUNG: Move map header file into plat-samsung gpio/s3c24xx: move gpio driver into drivers/gpio/ gpio/s3c64xx: move gpio driver into drivers/gpio/ gpio/s5p64x0: move gpio driver into drivers/gpio/ gpio/samsung: Remove useless old Samsung related GPIO drivers gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs ARM: SAMSUNG: Update the name of regarding Samsung GPIO ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs Merge branch 'next/topic-plat-samsung-1' into next/topic-gpio-samsung Actually, even though I said I would pick it up, you've already got it in a tree, so you can go ahead and merge it with my ack. I don't see any major risk of conflicts for the next merge window, so there is no need to merge it in the gpio tree also. g. arch/arm/Kconfig |3 - arch/arm/mach-exynos4/include/mach/pm-core.h |2 +- arch/arm/mach-s3c2410/Kconfig |7 - arch/arm/mach-s3c2410/Makefile |1 - arch/arm/mach-s3c2410/include/mach/gpio-fns.h | 99 +- arch/arm/mach-s3c2410/include/mach/gpio-track.h|6 +- arch/arm/mach-s3c2410/include/mach/map.h | 52 +- arch/arm/mach-s3c2410/include/mach/pm-core.h |2 +- arch/arm/mach-s3c2410/s3c2410.c|4 +- arch/arm/mach-s3c2412/Kconfig |1 - arch/arm/mach-s3c2412/Makefile |1 - arch/arm/mach-s3c2412/gpio.c |2 +- arch/arm/mach-s3c2416/Kconfig |1 - arch/arm/mach-s3c2416/s3c2416.c|4 +- arch/arm/mach-s3c2440/Kconfig |4 - arch/arm/mach-s3c2440/s3c2440.c|4 +- arch/arm/mach-s3c2440/s3c2442.c|4 +- arch/arm/mach-s3c2443/Kconfig |1 - arch/arm/mach-s3c2443/s3c2443.c|4 +- arch/arm/mach-s3c64xx/Makefile |1 - arch/arm/mach-s3c64xx/gpiolib.c| 290 --- arch/arm/mach-s3c64xx/include/mach/map.h |9 +- arch/arm/mach-s3c64xx/include/mach/pm-core.h |2 +- arch/arm/mach-s5p64x0/Makefile |2 +- arch/arm/mach-s5p64x0/gpiolib.c| 511 arch/arm/mach-s5pv210/include/mach/pm-core.h |2 +- arch/arm/plat-s3c24xx/Kconfig |1 - arch/arm/plat-s3c24xx/Makefile |2 - arch/arm/plat-s3c24xx/gpio.c | 96 - arch/arm/plat-s3c24xx/gpiolib.c| 229 -- arch/arm/plat-s3c24xx/include/plat/map.h | 100 - arch/arm/plat-s5p/Kconfig |3 - arch/arm/plat-s5p/irq-gpioint.c| 10 +- arch/arm/plat-samsung/Kconfig | 27 - arch/arm/plat-samsung/Makefile |2 - arch/arm/plat-samsung/gpio-config.c| 431 arch/arm/plat-samsung/gpio.c | 167 -- .../plat-samsung/include/plat/gpio-cfg-helpers.h | 172 +- arch/arm/plat-samsung/include/plat/gpio-cfg.h | 34 +- arch/arm/plat-samsung/include/plat/gpio-core.h | 97 +- arch/arm/plat-samsung/include/plat/gpio-fns.h | 98 + arch/arm/plat-samsung/include/plat/map-s3c.h | 84 + .../include/plat/map-s5p.h |6 +- arch/arm/plat-samsung/include/plat/pm.h| 10 +- arch/arm/plat-samsung/pm-gpio.c| 72 +- arch/arm/plat-samsung/pm.c |6 +- drivers/gpio/Kconfig | 16 - drivers/gpio/Makefile |7 +- drivers/gpio/gpio-exynos4.c| 385 --- drivers/gpio/gpio-plat-samsung.c | 205 -- drivers/gpio/gpio-s5pc100.c| 354 --- drivers/gpio/gpio-s5pv210.c| 287 --- drivers/gpio/gpio-samsung.c| 2686 53 files changed, 3072 insertions(+), 3534 deletions(-) delete mode 100644 arch/arm/mach-s3c64xx/gpiolib.c delete mode 100644 arch/arm/mach-s5p64x0/gpiolib.c delete mode 100644 arch/arm/plat-s3c24xx/gpio.c delete mode 100644 arch/arm/plat-s3c24xx/gpiolib.c delete mode 100644 arch/arm/plat-s3c24xx/include/plat/map.h delete mode 100644
Re: [PATCH 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
On Tue, Aug 30, 2011 at 09:27:27PM +0900, Kukjin Kim wrote: This patch adds support for Samsung GPIOs with one gpio driver. Actually there are drivers/gpio-s3c24xx.c, gpio-s3c64xx.c, gpio-s5p64x0.c, gpio-s5pc100.c, gpio-s5pv210.c, gpio-exynos4.c, gpio-plat-samsung.c, plat-samsung/gpio-config.c and gpio.c to support each Samsung SoCs before. Basically, the gpio-samsung.c has been made by their merging and removing duplicated definitions. Note: gpio-samsung.c includes some SoC dependent codes and it will be replaced next time. Cc: Ben Dooks ben-li...@fluff.org Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kukjin Kim kgene@samsung.com --- drivers/gpio/Makefile |1 + drivers/gpio/gpio-samsung.c | 2686 +++ 2 files changed, 2687 insertions(+), 0 deletions(-) create mode 100644 drivers/gpio/gpio-samsung.c It's a big driver file, but I'll go ahead and pick this up without too much review because at least it is all in the same place now. I'll expect further cleanup in future patches. g. -- 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/2] input: samsung-keypad: Add device tree support
On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Donghwa Lee dh09@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++
drivers/input/keyboard/samsung-keypad.c| 177
++--
2 files changed, 253 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt
b/Documentation/devicetree/bindings/input/samsung-keypad.txt
new file mode 100644
index 000..e1c7237
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -0,0 +1,88 @@
+* Samsung's Keypad Controller device tree bindings
+
+Samsung's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - samsung,s3c6410-keypad: For controllers compatible with s3c6410 keypad
+controller.
+ - samsung,s5pv210-keypad: For controllers compatible with s5pv210 keypad
+controller.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+- samsung,keypad-num-rows: Number of row lines connected to the keypad
+ controller.
+
+- samsung,keypad-num-columns: Number of column lines connected to the
+ keypad controller.
+
+- row-gpios: List of gpios used as row lines. The gpio specifier for
+ this property depends on the gpio controller to which these row lines
+ are connected.
+
+- col-gpios: List of gpios used as column lines. The gpio specifier for
+ this property depends on the gpio controller to which these column
+ lines are connected.
I know we've got overlapping terminology here. When you say GPIOs
here, does it refer to the pin multiplexing feature of the samsung
parts, and thus how the keypad controller IO is routed to the pins?
Or does the driver manipulate GPIO lines manually?
If it is pin multiplexing, then using the GPIO binding seems rather
odd. It may be entirely appropriate, but it will need to play well
with the pinmux stuff that linusw is working on.
+
+- Keys represented as child nodes: Each key connected to the keypad
+ controller is represented as a child node to the keypad controller
+ device node and should include the following properties.
+ - keypad,row: the row number to which the key is connected.
+ - keypad,column: the column number to which the key is connected.
+ - keypad,key-code: the key-code to be reported when the key is pressed
+and released.
What defines the meanings of the key codes?
+
+Optional Properties specific to linux:
+- linux,keypad-no-autorepeat: do no enable autorepeat feature.
+- linux,keypad-wakeup: use any event on keypad as wakeup event.
Is this really a linux-specific feature?
+
+
+Example:
+ keypad@100A {
+ compatible = samsung,s5pv210-keypad;
+ reg = 0x100A 0x100;
+ interrupts = 173;
+ samsung,keypad-num-rows = 2;
+ samsung,keypad-num-columns = 8;
+ linux,input-no-autorepeat;
+ linux,input-wakeup;
+
+ row-gpios = gpx2 0 3 3 0
+ gpx2 1 3 3 0;
+
+ col-gpios = gpx1 0 3 0 0
+ gpx1 1 3 0 0
+ gpx1 2 3 0 0
+ gpx1 3 3 0 0
+ gpx1 4 3 0 0
+ gpx1 5 3 0 0
+ gpx1 6 3 0 0
+ gpx1 7 3 0 0;
+
+ key_1 {
+ keypad,row = 0;
+ keypad,column = 3;
+ keypad,key-code = 2;
+ };
+
+ key_2 {
+ keypad,row = 0;
+ keypad,column = 4;
+ keypad,key-code = 3;
+ };
+
+ key_3 {
+ keypad,row = 0;
+ keypad,column = 5;
+ keypad,key-code = 4;
+ };
+ };
diff --git a/drivers/input/keyboard/samsung-keypad.c
b/drivers/input/keyboard/samsung-keypad.c
index f689f49..cf01a56 100644
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@ -21,6 +21,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include
Re: [PATCH v3 4/6] DMA: PL330: Add device tree support
On Mon, Sep 12, 2011 at 11:59:23PM +0530, Thomas Abraham wrote:
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Boojin Kim boojin@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Reviewed-by: Rob Herring rob.herr...@calxeda.com
---
.../devicetree/bindings/dma/arm-pl330.txt | 29 +
drivers/dma/pl330.c| 33 +--
2 files changed, 58 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..05b007d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,29 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should include both arm,pl330 and arm,primecell.
+ - reg: physical base address of the controller and length of memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,pl330, arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma request id];
+
+ where 'dma request id' is the dma request number which is connected
+ to the client controller.
+
+ Example: tx-dma-channel = pdma0 12;
Looks good to me. You may want to specify that the property name
should be in the form: name-dma-channel just to enforce a bit of
convention on the users.
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 992bf82..7a4ebf1 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -19,6 +19,7 @@
#include linux/amba/pl330.h
#include linux/pm_runtime.h
#include linux/scatterlist.h
+#include linux/of.h
#define NR_DEFAULT_DESC 16
@@ -277,6 +278,20 @@ bool pl330_filter(struct dma_chan *chan, void *param)
if (chan-device-dev-driver != pl330_driver.drv)
return false;
+#ifdef CONFIG_OF
+ if (chan-device-dev-of_node) {
+ const __be32 *prop_value;
+ phandle phandle;
+ struct device_node *node;
+
+ prop_value = ((struct property *)param)-value;
+ phandle = be32_to_cpup(prop_value++);
+ node = of_find_node_by_phandle(phandle);
+ return ((chan-private == node)
+ (chan-chan_id == be32_to_cpup(prop_value)));
Don't open code this. There is already a function to decode a phandle
property. of_parse_phandle() should do the trick.
Otherwise looks good to me.
g.
+ }
+#endif
+
peri_id = chan-private;
return *peri_id == (unsigned)param;
}
@@ -855,12 +870,17 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
INIT_LIST_HEAD(pd-channels);
/* Initialize channel parameters */
- num_chan = max(pdat ? pdat-nr_valid_peri : 0, (u8)pi-pcfg.num_chan);
+ num_chan = max(pdat ? pdat-nr_valid_peri : (u8)pi-pcfg.num_peri,
+ (u8)pi-pcfg.num_chan);
pdmac-peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
for (i = 0; i num_chan; i++) {
pch = pdmac-peripherals[i];
- pch-chan.private = pdat ? pdat-peri_id[i] : NULL;
+ if (!adev-dev.of_node)
+ pch-chan.private = pdat ? pdat-peri_id[i] : NULL;
+ else
+ pch-chan.private = adev-dev.of_node;
+
INIT_LIST_HEAD(pch-work_list);
spin_lock_init(pch-lock);
pch-pl330_chid = NULL;
@@ -874,10 +894,15 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
}
pd-dev = adev-dev;
- if (pdat)
+ if
Re: [PATCH v3 6/6] ARM: EXYNOS4: Limit usage of pl330 device instance to non-dt build
On Mon, Sep 12, 2011 at 11:59:25PM +0530, Thomas Abraham wrote:
The pl330 device instances and associated platform data is required only
for non-device-tree builds. With device tree enabled, the data about the
platform is obtained from the device tree. For images that include both
dt and non-dt platforms, an addditional check is added to ensure that
static amba device registrations is applicable to only non-dt platforms.
Cc: Kukjin Kim kgene@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
diff --git a/arch/arm/mach-exynos4/dma.c b/arch/arm/mach-exynos4/dma.c
index c3c0d17..3203a31 100644
--- a/arch/arm/mach-exynos4/dma.c
+++ b/arch/arm/mach-exynos4/dma.c
@@ -24,6 +24,7 @@
#include linux/dma-mapping.h
#include linux/amba/bus.h
#include linux/amba/pl330.h
+#include linux/of.h
#include asm/irq.h
#include plat/devs.h
@@ -138,6 +139,11 @@ struct amba_device exynos4_device_pdma1 = {
static int __init exynos4_dma_init(void)
{
+#ifdef CONFIG_OF
+ if (of_have_populated_dt())
+ return 0;
+#endif
+
Drop the #ifdef. of_have_populated_dt() has an empty stub for
!CONFIG_OF. Otherwise looks good to me. Well done not breaking
non-DT support when CONFIG_OF is enabled. :-)
The other patches in this series look good to me too.
g.
--
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/2] input: samsung-keypad: Add device tree support
On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote: Hi Grant, On 14 September 2011 21:41, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote: Add device tree based discovery support for Samsung's keypad controller. Cc: Joonyoung Shim jy0922.s...@samsung.com Cc: Donghwa Lee dh09@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- .../devicetree/bindings/input/samsung-keypad.txt | 88 ++ drivers/input/keyboard/samsung-keypad.c | 177 ++-- 2 files changed, 253 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt new file mode 100644 index 000..e1c7237 --- /dev/null +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt @@ -0,0 +1,88 @@ +* Samsung's Keypad Controller device tree bindings + +Samsung's Keypad controller is used to interface a SoC with a matrix-type +keypad device. The keypad controller supports multiple row and column lines. +A key can be placed at each intersection of a unique row and a unique column. +The keypad controller can sense a key-press and key-release and report the +event using a interrupt to the cpu. + +Required SoC Specific Properties: +- compatible: should be one of the following + - samsung,s3c6410-keypad: For controllers compatible with s3c6410 keypad + controller. + - samsung,s5pv210-keypad: For controllers compatible with s5pv210 keypad + controller. + +- reg: physical base address of the controller and length of memory mapped + region. + +- interrupts: The interrupt number to the cpu. + +Required Board Specific Properties: +- samsung,keypad-num-rows: Number of row lines connected to the keypad + controller. + +- samsung,keypad-num-columns: Number of column lines connected to the + keypad controller. + +- row-gpios: List of gpios used as row lines. The gpio specifier for + this property depends on the gpio controller to which these row lines + are connected. + +- col-gpios: List of gpios used as column lines. The gpio specifier for + this property depends on the gpio controller to which these column + lines are connected. I know we've got overlapping terminology here. When you say GPIOs here, does it refer to the pin multiplexing feature of the samsung parts, and thus how the keypad controller IO is routed to the pins? Or does the driver manipulate GPIO lines manually? It is intended to mean gpio and not the pinmux. But the way the gpio specifier is specified in the dts file, it includes information about both gpio number and the pin-control details. For instance, if 'gpa0' is a gpio controller (which includes pin-control functionality as well in the hardware), then the gpio specifier for the keypad would be as below. row-gpios = gpa0 0 3 3 0, gpa0 1 3 3 0; The syntax for the gpio specifier is [phandle of gpio controller] [pin number within the gpio controller] [mux function] [pull up/down] [drive strength] The keypad driver does not know or use the mux function, pull up/down and drive strength details. The driver would call of_get_gpio to get the linux gpio number and then do a gpio_request on that gpio number. The gpio dt support manges the pin-mux and other settings transparently for the keypad driver. So even though the gpio specifier format changes, the dt support code for the driver does not change. The driver does not manipulate the gpios directly. It just requests for the gpio number and makes a note of the number to free it when the driver unbinds. If it is pin multiplexing, then using the GPIO binding seems rather odd. It may be entirely appropriate, but it will need to play well with the pinmux stuff that linusw is working on. When pinmux/pin-ctrl functionality which linusw is developing is used for this driver, it would be a extension to this patch. The driver would request for the gpio and then use the pin-ctrl subsystem api to setup the pin-control. In that case, the gpio-specifier would change but that change would be break anything which this patch does. + +- Keys represented as child nodes: Each key connected to the keypad + controller is represented as a child node to the keypad controller + device node and should include the following properties. + - keypad,row: the row number to which the key is connected. + - keypad,column: the column number to which the key is connected. + - keypad,key-code: the key-code to be reported when the key is pressed + and released. What defines the meanings of the key codes? The key-code could be any value which the system would want the keypad
