* [PATCH V9 5/6] stm dummy: Mark dummy_stm_packet() with notrace
From: Chunyan Zhang @ 2016-11-21 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479715043-6534-1-git-send-email-zhang.chunyan@linaro.org>
If CONFIG_STM_SOURCE_FTRACE is selected, Function trace data can be
writen to sink via STM, all functions that related to writing data
packets to STM should be marked 'notrace' to avoid being traced by
Ftrace, otherwise the program would stall into an endless loop.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
drivers/hwtracing/stm/dummy_stm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/stm/dummy_stm.c b/drivers/hwtracing/stm/dummy_stm.c
index a86612d..c5f94ca 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -21,7 +21,7 @@
#include <linux/slab.h>
#include <linux/stm.h>
-static ssize_t
+static ssize_t notrace
dummy_stm_packet(struct stm_data *stm_data, unsigned int master,
unsigned int channel, unsigned int packet, unsigned int flags,
unsigned int size, const unsigned char *payload)
--
2.7.4
^ permalink raw reply related
* [PATCH V9 6/6] stm: Mark the functions of writing STM with notrace
From: Chunyan Zhang @ 2016-11-21 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479715043-6534-1-git-send-email-zhang.chunyan@linaro.org>
If CONFIG_STM_SOURCE_FTRACE is selected, Function trace data can be
writen to sink via STM, all functions that related to writing data
packets to STM should be marked 'notrace' to avoid being traced by
Ftrace, otherwise the program would stall into an endless loop.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
drivers/hwtracing/stm/core.c | 7 ++++---
include/linux/stm.h | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 51f81d6..37d3bcb 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -425,7 +425,7 @@ static int stm_file_assign(struct stm_file *stmf, char *id, unsigned int width)
return ret;
}
-static ssize_t stm_write(struct stm_data *data, unsigned int master,
+static ssize_t notrace stm_write(struct stm_data *data, unsigned int master,
unsigned int channel, const char *buf, size_t count)
{
unsigned int flags = STP_PACKET_TIMESTAMPED;
@@ -1121,8 +1121,9 @@ void stm_source_unregister_device(struct stm_source_data *data)
}
EXPORT_SYMBOL_GPL(stm_source_unregister_device);
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
- const char *buf, size_t count)
+int notrace stm_source_write(struct stm_source_data *data,
+ unsigned int chan,
+ const char *buf, size_t count)
{
struct stm_source_device *src = data->src;
struct stm_device *stm;
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 8369d8a..210ff22 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -133,7 +133,7 @@ int stm_source_register_device(struct device *parent,
struct stm_source_data *data);
void stm_source_unregister_device(struct stm_source_data *data);
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
- const char *buf, size_t count);
+int notrace stm_source_write(struct stm_source_data *data, unsigned int chan,
+ const char *buf, size_t count);
#endif /* _STM_H_ */
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Tero Kristo @ 2016-11-21 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLtSs6ifnMdEOsfXpGoWnmXuGAx83+ziB9yU+zurvob+A@mail.gmail.com>
On 18/11/16 19:20, Rob Herring wrote:
> On Mon, Oct 31, 2016 at 7:50 AM, Tero Kristo <t-kristo@ti.com> wrote:
>> On 30/10/16 22:41, Rob Herring wrote:
>>>
>>> On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
>>>>
>>>> Add a clock implementation, TI SCI clock, that will hook to the common
>>>> clock framework, and allow each clock to be controlled via TI SCI
>>>> protocol.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> .../devicetree/bindings/clock/ti,sci-clk.txt | 37
>>>> ++++++++++++++++++++++
>>>> MAINTAINERS | 1 +
>>>> 2 files changed, 38 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>> b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>> new file mode 100644
>>>> index 0000000..bfc3ca4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>> @@ -0,0 +1,37 @@
>>>> +Texas Instruments TI-SCI Clocks
>>>> +===============================
>>>> +
>>>> +All clocks on Texas Instruments' SoCs that contain a System Controller,
>>>> +are only controlled by this entity. Communication between a host
>>>> processor
>>>> +running an OS and the System Controller happens through a protocol known
>>>> +as TI-SCI[1]. This clock implementation plugs into the common clock
>>>> +framework and makes use of the TI-SCI protocol on clock API requests.
>>>> +
>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>> +
>>>> +Required properties:
>>>> +-------------------
>>>> +- compatible: Must be "ti,k2g-sci-clk"
>>>> +- #clock-cells: Shall be 2.
>>>> + In clock consumers, this cell represents the device ID and clock ID
>>>> + exposed by the PM firmware. The assignments can be found in the header
>>>> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
>>>> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
>>>> + is the SoC involved, for example 'k2g'.
>>>> +
>>>> +Examples:
>>>> +--------
>>>> +
>>>> +pmmc: pmmc {
>>>> + compatible = "ti,k2g-sci";
>>>> +
>>>> + k2g_clks: k2g_clks {
>>>
>>>
>>> Use "clocks" for node name instead.
>>>
>>>> + compatible = "ti,k2g-sci-clk";
>>>
>>>
>>> I'm starting to think all these child nodes for SCI are pointless. Is
>>> there any reason why the parent node can't be the clock provider (along
>>> with all the other providers it acks as)?
>>
>>
>> I believe the only reason to keep them separate is to have kernel side of
>> things modular. If we have separate nodes, the drivers can be probed
>> separately.
>>
>> If not, we need to build one huge blob with all the features in it, so the
>> main driver can probe everything in one go, with annoying back-and-forth
>> callbacks in place (assuming we still want to keep stuff somehow modular.)
>
> Since when is DT the only way to create a device? The main driver can
> create devices for all the sub-functions like clocks. This is the same
> as MFDs which have been done both ways.
Yes obviously this can be done, my main point was that it will require
building some sort of infra within the driver to handle this. With
separate nodes, none of this is going to be needed. Also, we will lose
any kind of configurability via DT if we don't have separate nodes; now
we can select the available clocks / genpds via the compatible string of
the clocks/genpd nodes themselves (this isn't clearly evident as of now
as we only support a grand total of one device, which is k2g-evm.)
Otherwise we need to probe against the main node and add a separate
compatible string for every device, and carry this information to the
sibling devices also somehow. It is just so much simpler if we can just
keep separate nodes for them.
Also, plenty of things are doing this kind of stuff already in
DT/kernel, having a parent node in place and sub-functions added
separately for ease of use, with apparently no visible point for having
the nodes within the DT.
-Tero
^ permalink raw reply
* [GIT PULL 1/10] mailbox: Add Tegra HSP driver
From: Thierry Reding @ 2016-11-21 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119022742.GK2543@localhost>
On Fri, Nov 18, 2016 at 06:27:42PM -0800, Olof Johansson wrote:
> Hi,
>
> On Fri, Nov 18, 2016 at 05:17:10PM +0100, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> >
> > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-mailbox
> >
> > for you to fetch changes up to 68050eb6c611527232fe5574c7306e97e47499ef:
> >
> > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells() (2016-11-18 14:32:13 +0100)
> >
> > Thanks,
> > Thierry
> >
> > ----------------------------------------------------------------
> > mailbox: Add Tegra HSP driver
> >
> > This contains the device tree bindings and a driver for the Tegra HSP, a
> > hardware block that provides hardware synchronization primitives and is
> > the foundation for inter-processor communication between CPU and BPMP.
> >
> > ----------------------------------------------------------------
> > Dan Carpenter (1):
> > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
> >
> > Joseph Lo (2):
> > soc/tegra: Add Tegra186 support
>
> I don't think you really needed to merge this in here, since all you need it
> for is to fulfill the kconfig dependency and enable the driver, right? That'd
> happen when the driver and soc branch is merged at the toplevel anyway.
The reason I did this is that I wanted each branch to be buildable as a
way to confirm that the dependencies are correct. In order to do that I
need the Kconfig symbol to enable the driver.
I suppose there are other ways I could've done that, though. Maybe in
the future new SoC Kconfig symbols should just be introduced way ahead
of time, so that they're already in a release or two before actual code
starts to emerge.
> Anyhow, no damage done, I've merged this in. I would say that it'd be a little
> more logical to send the SoC branch before the driver branch given this
> dependency though.
The reason that the SoC branch was sent after is because only the first
commit in that branch was pulled into the mailbox branch.
In retrospect, I think perhaps a better approach would've been to have a
separate branch with only the Kconfig symbol addition and pull that in
where needed.
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/84d12034/attachment.sig>
^ permalink raw reply
* [GIT PULL 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Thierry Reding @ 2016-11-21 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119024021.GT2543@localhost>
On Fri, Nov 18, 2016 at 06:40:21PM -0800, Olof Johansson wrote:
> On Fri, Nov 18, 2016 at 05:17:18PM +0100, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> >
> > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-arm64-dt
> >
> > for you to fetch changes up to cc13b4fa4ac780cec6c21b64a39ab2950e95e8f6:
> >
> > arm64: tegra: Add NVIDIA P2771 board support (2016-11-18 14:35:53 +0100)
> >
> > Thanks,
> > Thierry
> >
> > ----------------------------------------------------------------
> > arm64: tegra: Device tree changes for v4.10-rc1
> >
> > This adds initial support for Tegra186, the P3310 processor module as
> > well as the P2771 development board. Not much is functional, but there
> > is enough to boot to an initial ramdisk with debug serial output.
> >
> > ----------------------------------------------------------------
> > Dan Carpenter (1):
> > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
> >
> > Joseph Lo (6):
> > soc/tegra: Add Tegra186 support
> > dt-bindings: mailbox: Add Tegra HSP binding
> > dt-bindings: firmware: Add bindings for Tegra BPMP
> > arm64: tegra: Add Tegra186 support
> > arm64: tegra: Add NVIDIA P3310 processor module support
> > arm64: tegra: Add NVIDIA P2771 board support
> >
> > Stephen Warren (2):
> > dt-bindings: Add power domains to Tegra BPMP firmware
> > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
> >
> > Thierry Reding (12):
> > Merge branch 'for-4.10/soc' into for-4.10/mailbox
> > mailbox: Add Tegra HSP driver
> > Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> > firmware: tegra: Add IVC library
> > firmware: tegra: Add BPMP support
> > Merge branch 'for-4.10/firmware' into for-4.10/arm64/dt
> > arm64: tegra: Add CPU nodes for Tegra186
> > arm64: tegra: Add serial ports on Tegra186
> > arm64: tegra: Add I2C controllers on Tegra186
> > arm64: tegra: Add SDHCI controllers on Tegra186
> > arm64: tegra: Add GPIO controllers on Tegra186
> > arm64: tegra: Enable PSCI on P3310
>
> The drivers->dt dependency here is annoying. Any chance you can respin without
> it?
>
> We've been encouraging people to consider using numerical clock/gpio/reset
> numbers on initial submission to avoid these dependencies on dt-bindings
> includes, and then follow up with a move to the symbolic names between -rc1 and
> -rc2. Mind doing the same here?
Yes, I can do that. Would it be acceptable to have a dt-bindings->dt
dependency? Stephen's already done a good job of avoiding this kind of
dependency by getting the bindings, and hence dt-bindings headers,
merged ahead of Linux kernel support because he had already gotten the
bindings reviewed and finalized during his work on U-Boot.
I've been told in the past that it's not necessary to strictly split DT
bindings patches from driver patches, but I suppose if a dt-bindings->dt
is acceptable, then splitting things up more strictly would actually be
the preferable solution here because it also avoids the slight churn of
converting to symbolic values later on.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/ca5e5c61/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL 2/10] firmware: Add Tegra IVC and BPMP support
From: Thierry Reding @ 2016-11-21 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119023138.GL2543@localhost>
On Fri, Nov 18, 2016 at 06:31:38PM -0800, Olof Johansson wrote:
> On Fri, Nov 18, 2016 at 05:17:11PM +0100, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> >
> > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-firmware
> >
> > for you to fetch changes up to b704ed8095ee91af5f3f7343bb3be23aae1cb26d:
> >
> > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP (2016-11-18 14:33:44 +0100)
> >
> > Thanks,
> > Thierry
> >
> > ----------------------------------------------------------------
> > firmware: Add Tegra IVC and BPMP support
> >
> > IVC is an inter-processor communication protocol that uses shared memory
> > to exchange data between processors. The BPMP driver makes use of this
> > to communicate with the Boot and Power Management Processor (BPMP) and
> > uses an additional hardware synchronization primitive from the HSP block
> > to signal availability of new data (doorbell).
> >
> > Firmware running on the BPMP implements a number of services such as the
> > control of clocks and resets within the system, or the ability to ungate
> > or gate power partitions.
> >
> > ----------------------------------------------------------------
> > Dan Carpenter (1):
> > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
> >
> > Joseph Lo (3):
> > soc/tegra: Add Tegra186 support
> > dt-bindings: mailbox: Add Tegra HSP binding
> > dt-bindings: firmware: Add bindings for Tegra BPMP
> >
> > Stephen Warren (2):
> > dt-bindings: Add power domains to Tegra BPMP firmware
> > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
> >
> > Thierry Reding (5):
> > Merge branch 'for-4.10/soc' into for-4.10/mailbox
> > mailbox: Add Tegra HSP driver
> > Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> > firmware: tegra: Add IVC library
> > firmware: tegra: Add BPMP support
>
> Hi,
>
> Again the format of the pull request here is a little confusing, since it's
> a cumulative shotlog and diffstat, while you already sent the bulk of this
> as part of the driver branch (1/10). It'd have been better to use that branch
> as the base when you generate the pull request since that's the delta we see
> when we merge it in.
In the past there had been occasions where it hadn't been clear what a
given branch was going to pull in as additional dependencies, so adding
the complete shortlog seemed like a good way to document this in a more
explicit way.
If you prefer working things out yourself I can tweak the scripts to
generate the pull requests on top of their respective dependencies.
> Also, I can't seem to find the key you use to sign these tags with, it isn't
> uploaded on pgp.mit.edu. Can you remedy that please, and get it signed as
> needed?
Works for me:
http://pgp.mit.edu/pks/lookup?op=get&search=0xDD23ACD77F3EB3A1
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/a9fa1298/attachment.sig>
^ permalink raw reply
* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: Sekhar Nori @ 2016-11-21 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <946d60bc-ac14-7934-c1b3-e2de03831459@lechnology.com>
On Sunday 20 November 2016 10:31 PM, David Lechner wrote:
> On 11/20/2016 06:59 AM, Sekhar Nori wrote:
>> On Saturday 19 November 2016 10:11 AM, David Lechner wrote:
>>> @@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device
>>> *spi)
>>> if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
>>> spicfg->wdelay = (u8)prop;
>>> spi->controller_data = spicfg;
>>> + /* Use DMA for device if master supports it */
>>> + if (dspi->dma_rx)
>>
>> This should be
>>
>> if (!(IS_ERR(dpsi->dma_rx) || IS_ERR(dspi->dma_tx))
>
>
> There is the following code in davinci_spi_probe():
>
> ret = davinci_spi_request_dma(dspi);
> if (ret == -EPROBE_DEFER) {
> goto free_clk;
> } else if (ret) {
> dev_info(&pdev->dev, "DMA is not supported (%d)\n", ret);
> dspi->dma_rx = NULL;
> dspi->dma_tx = NULL;
> }
>
> So, I does not look like it is possible to get anything other than NULL
> or a valid pointer for dpsi->dma_rx and that checking dpsi->dma_tx is
> not necessary.
>
> So, I think if (dspi->dma_rx) is sufficient. In fact the same check is
> used during unwinding if the probe function fails.
You are right, I see it now. Setting dma_rx to NULL overriding the error
value is confusing since dma_request_chan() itself does not use NULL as
an error value.
I think it is better to fix the existing code to remove the NULL
overwrite and use IS_ERR() instead. You should probably wait for some
feedback from the SPI maintainer though.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Gabriele Paoloni @ 2016-11-21 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118175404.GI25762@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: 18 November 2016 17:54
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> Subject: Re: [PATCH] PCI: Add information about describing PCI in ACPI
>
> On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > > -----Original Message-----
> > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > Sent: 17 November 2016 18:00
>
> > > +Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms
> for
> > > +reserving address space! The static tables are for things the OS
> > > +needs to know early in boot, before it can parse the ACPI
> namespace.
> > > +If a new table is defined, an old OS needs to operate correctly
> even
> > > +though it ignores the table. _CRS allows that because it is
> generic
> > > +and understood by the old OS; a static table does not.
> >
> > Right so if my understanding is correct you are saying that resources
> > described in the MCFG table should also be declared in PNP0C02
> devices
> > so that the PNP driver can reserve these resources.
>
> Yes.
>
> > On the other side the PCI Root bridge driver should not reserve such
> > resources.
> >
> > Well if my understanding is correct I think we have a problem here:
> > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
> >
> > As you can see pci_ecam_create() will conflict with the pnp driver
> > as it will try to reserve the resources from the MCFG table...
> >
> > Maybe we need to rework pci_ecam_create() ?
>
> I think it's OK as it is.
>
> The pnp/system.c driver does try to reserve PNP0C02 resources, and it
> marks them as "not busy". That way they appear in /proc/iomem and
> won't be allocated for anything else, but they can still be requested
> by drivers, e.g., pci/ecam.c, which will mark them "busy".
>
> This is analogous to what the PCI core does in pci_claim_resource().
> This is really a function of the ACPI/PNP *core*, which should reserve
> all _CRS resources for all devices (not just PNP0C02 devices). But
> it's done by pnp/system.c, and only for PNP0C02, because there's a
> bunch of historical baggage there.
>
> You'll also notice that in this case, things are out of order:
> logically the pnp/system.c reservation should happen first, but in
> fact the pci/ecam.c request happens *before* the pnp/system.c one.
> That means the pnp/system.c one might fail and complain "[mem ...]
> could not be reserved".
Correct me if I am wrong...
So currently we are relying on the fact that pci_ecam_create() is called
before the pnp driver.
If the pnp driver came first we would end up in pci_ecam_create() failing
here:
http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L76
I am not sure but it seems to me like a bit weak condition to rely on...
what about removing the error condition in pci_ecam_create() and logging
just a dev_info()?
Thanks
Gab
>
> Bjorn
^ permalink raw reply
* [PATCH v3 2/6] iio: adc: Add support for STM32 ADC core
From: Fabrice Gasnier @ 2016-11-21 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09b63f8e-20c8-532e-2d97-2faa6dfe7538@kernel.org>
On 11/19/2016 01:17 PM, Jonathan Cameron wrote:
> On 15/11/16 15:30, Fabrice Gasnier wrote:
>> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
>> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
>> resources like clock prescaler, common interrupt line and analog
>> reference voltage.
>> This core driver basically manages shared resources.
>>
>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> There is nothing in here that demands selecting a fixed regulator.
> I've also switched the select regulator over to depends on inline with
> other drivers in IIO that have a hard dependency on regulators.
> Other than that which showed up during build tests, looks good to me.
> Shout if I've broken anything with this change.
Hi Jonathan, All,
First many thanks.
This is not a big deal. Only thing is: I think patch 4 of this series
(on stm32_defconfig) need to be updated
to accommodate this change. E.g. :
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
Shall I send a new version of this series (all patches), including your
changes, with updated defconfig as well ?
Or only updated patch on defconfig is enough ?
Please advise,
Fabrice
>
> Applied to the togreg branch of iio.git and pushed out as testing for
> the autobuilders to play with it.
>
> Thanks,
>
> Jonathan
>> ---
>> drivers/iio/adc/Kconfig | 13 ++
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/stm32-adc-core.c | 303 +++++++++++++++++++++++++++++++++++++++
>> drivers/iio/adc/stm32-adc-core.h | 52 +++++++
>> 4 files changed, 369 insertions(+)
>> create mode 100644 drivers/iio/adc/stm32-adc-core.c
>> create mode 100644 drivers/iio/adc/stm32-adc-core.h
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 7edcf32..ff30239 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -419,6 +419,19 @@ config ROCKCHIP_SARADC
>> To compile this driver as a module, choose M here: the
>> module will be called rockchip_saradc.
>>
>> +config STM32_ADC_CORE
>> + tristate "STMicroelectronics STM32 adc core"
>> + depends on ARCH_STM32 || COMPILE_TEST
>> + depends on OF
>> + select REGULATOR
>> + select REGULATOR_FIXED_VOLTAGE
>> + help
>> + Select this option to enable the core driver for STMicroelectronics
>> + STM32 analog-to-digital converter (ADC).
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called stm32-adc-core.
>> +
>> config STX104
>> tristate "Apex Embedded Systems STX104 driver"
>> depends on X86 && ISA_BUS_API
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 7a40c04..a1e8f44 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> obj-$(CONFIG_STX104) += stx104.o
>> +obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>> obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>> obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>> new file mode 100644
>> index 0000000..4214b0c
>> --- /dev/null
>> +++ b/drivers/iio/adc/stm32-adc-core.c
>> @@ -0,0 +1,303 @@
>> +/*
>> + * This file is part of STM32 ADC driver
>> + *
>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>> + *
>> + * Inspired from: fsl-imx25-tsadc
>> + *
>> + * License type: GPLv2
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>> + * See the GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/irqchip/chained_irq.h>
>> +#include <linux/irqdesc.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/slab.h>
>> +
>> +#include "stm32-adc-core.h"
>> +
>> +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
>> +#define STM32F4_ADC_CSR (STM32_ADCX_COMN_OFFSET + 0x00)
>> +#define STM32F4_ADC_CCR (STM32_ADCX_COMN_OFFSET + 0x04)
>> +
>> +/* STM32F4_ADC_CSR - bit fields */
>> +#define STM32F4_EOC3 BIT(17)
>> +#define STM32F4_EOC2 BIT(9)
>> +#define STM32F4_EOC1 BIT(1)
>> +
>> +/* STM32F4_ADC_CCR - bit fields */
>> +#define STM32F4_ADC_ADCPRE_SHIFT 16
>> +#define STM32F4_ADC_ADCPRE_MASK GENMASK(17, 16)
>> +
>> +/* STM32 F4 maximum analog clock rate (from datasheet) */
>> +#define STM32F4_ADC_MAX_CLK_RATE 36000000
>> +
>> +/**
>> + * struct stm32_adc_priv - stm32 ADC core private data
>> + * @irq: irq for ADC block
>> + * @domain: irq domain reference
>> + * @aclk: clock reference for the analog circuitry
>> + * @vref: regulator reference
>> + * @common: common data for all ADC instances
>> + */
>> +struct stm32_adc_priv {
>> + int irq;
>> + struct irq_domain *domain;
>> + struct clk *aclk;
>> + struct regulator *vref;
>> + struct stm32_adc_common common;
>> +};
>> +
>> +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
>> +{
>> + return container_of(com, struct stm32_adc_priv, common);
>> +}
>> +
>> +/* STM32F4 ADC internal common clock prescaler division ratios */
>> +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>> +
>> +/**
>> + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
>> + * @priv: stm32 ADC core private data
>> + * Select clock prescaler used for analog conversions, before using ADC.
>> + */
>> +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
>> + struct stm32_adc_priv *priv)
>> +{
>> + unsigned long rate;
>> + u32 val;
>> + int i;
>> +
>> + rate = clk_get_rate(priv->aclk);
>> + for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
>> + if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
>> + break;
>> + }
>> + if (i >= ARRAY_SIZE(stm32f4_pclk_div))
>> + return -EINVAL;
>> +
>> + val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>> + val &= ~STM32F4_ADC_ADCPRE_MASK;
>> + val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>> + writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>> +
>> + dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>> + rate / (stm32f4_pclk_div[i] * 1000));
>> +
>> + return 0;
>> +}
>> +
>> +/* ADC common interrupt for all instances */
>> +static void stm32_adc_irq_handler(struct irq_desc *desc)
>> +{
>> + struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + u32 status;
>> +
>> + chained_irq_enter(chip, desc);
>> + status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
>> +
>> + if (status & STM32F4_EOC1)
>> + generic_handle_irq(irq_find_mapping(priv->domain, 0));
>> +
>> + if (status & STM32F4_EOC2)
>> + generic_handle_irq(irq_find_mapping(priv->domain, 1));
>> +
>> + if (status & STM32F4_EOC3)
>> + generic_handle_irq(irq_find_mapping(priv->domain, 2));
>> +
>> + chained_irq_exit(chip, desc);
>> +};
>> +
>> +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
>> + irq_hw_number_t hwirq)
>> +{
>> + irq_set_chip_data(irq, d->host_data);
>> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
>> +
>> + return 0;
>> +}
>> +
>> +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> + irq_set_chip_and_handler(irq, NULL, NULL);
>> + irq_set_chip_data(irq, NULL);
>> +}
>> +
>> +static const struct irq_domain_ops stm32_adc_domain_ops = {
>> + .map = stm32_adc_domain_map,
>> + .unmap = stm32_adc_domain_unmap,
>> + .xlate = irq_domain_xlate_onecell,
>> +};
>> +
>> +static int stm32_adc_irq_probe(struct platform_device *pdev,
>> + struct stm32_adc_priv *priv)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> +
>> + priv->irq = platform_get_irq(pdev, 0);
>> + if (priv->irq < 0) {
>> + dev_err(&pdev->dev, "failed to get irq\n");
>> + return priv->irq;
>> + }
>> +
>> + priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
>> + &stm32_adc_domain_ops,
>> + priv);
>> + if (!priv->domain) {
>> + dev_err(&pdev->dev, "Failed to add irq domain\n");
>> + return -ENOMEM;
>> + }
>> +
>> + irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
>> + irq_set_handler_data(priv->irq, priv);
>> +
>> + return 0;
>> +}
>> +
>> +static void stm32_adc_irq_remove(struct platform_device *pdev,
>> + struct stm32_adc_priv *priv)
>> +{
>> + int hwirq;
>> +
>> + for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
>> + irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
>> + irq_domain_remove(priv->domain);
>> + irq_set_chained_handler(priv->irq, NULL);
>> +}
>> +
>> +static int stm32_adc_probe(struct platform_device *pdev)
>> +{
>> + struct stm32_adc_priv *priv;
>> + struct device_node *np = pdev->dev.of_node;
>> + struct resource *res;
>> + int ret;
>> +
>> + if (!pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->common.base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(priv->common.base))
>> + return PTR_ERR(priv->common.base);
>> +
>> + priv->vref = devm_regulator_get(&pdev->dev, "vref");
>> + if (IS_ERR(priv->vref)) {
>> + ret = PTR_ERR(priv->vref);
>> + dev_err(&pdev->dev, "vref get failed, %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = regulator_enable(priv->vref);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "vref enable failed\n");
>> + return ret;
>> + }
>> +
>> + ret = regulator_get_voltage(priv->vref);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
>> + goto err_regulator_disable;
>> + }
>> + priv->common.vref_mv = ret / 1000;
>> + dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
>> +
>> + priv->aclk = devm_clk_get(&pdev->dev, "adc");
>> + if (IS_ERR(priv->aclk)) {
>> + ret = PTR_ERR(priv->aclk);
>> + dev_err(&pdev->dev, "Can't get 'adc' clock\n");
>> + goto err_regulator_disable;
>> + }
>> +
>> + ret = clk_prepare_enable(priv->aclk);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "adc clk enable failed\n");
>> + goto err_regulator_disable;
>> + }
>> +
>> + ret = stm32f4_adc_clk_sel(pdev, priv);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "adc clk selection failed\n");
>> + goto err_clk_disable;
>> + }
>> +
>> + ret = stm32_adc_irq_probe(pdev, priv);
>> + if (ret < 0)
>> + goto err_clk_disable;
>> +
>> + platform_set_drvdata(pdev, &priv->common);
>> +
>> + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "failed to populate DT children\n");
>> + goto err_irq_remove;
>> + }
>> +
>> + return 0;
>> +
>> +err_irq_remove:
>> + stm32_adc_irq_remove(pdev, priv);
>> +
>> +err_clk_disable:
>> + clk_disable_unprepare(priv->aclk);
>> +
>> +err_regulator_disable:
>> + regulator_disable(priv->vref);
>> +
>> + return ret;
>> +}
>> +
>> +static int stm32_adc_remove(struct platform_device *pdev)
>> +{
>> + struct stm32_adc_common *common = platform_get_drvdata(pdev);
>> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
>> +
>> + of_platform_depopulate(&pdev->dev);
>> + stm32_adc_irq_remove(pdev, priv);
>> + clk_disable_unprepare(priv->aclk);
>> + regulator_disable(priv->vref);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id stm32_adc_of_match[] = {
>> + { .compatible = "st,stm32f4-adc-core" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
>> +
>> +static struct platform_driver stm32_adc_driver = {
>> + .probe = stm32_adc_probe,
>> + .remove = stm32_adc_remove,
>> + .driver = {
>> + .name = "stm32-adc-core",
>> + .of_match_table = stm32_adc_of_match,
>> + },
>> +};
>> +module_platform_driver(stm32_adc_driver);
>> +
>> +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier@st.com>");
>> +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC core driver");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_ALIAS("platform:stm32-adc-core");
>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>> new file mode 100644
>> index 0000000..081fa5f
>> --- /dev/null
>> +++ b/drivers/iio/adc/stm32-adc-core.h
>> @@ -0,0 +1,52 @@
>> +/*
>> + * This file is part of STM32 ADC driver
>> + *
>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>> + *
>> + * License type: GPLv2
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>> + * See the GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __STM32_ADC_H
>> +#define __STM32_ADC_H
>> +
>> +/*
>> + * STM32 - ADC global register map
>> + * ________________________________________________________
>> + * | Offset | Register |
>> + * --------------------------------------------------------
>> + * | 0x000 | Master ADC1 |
>> + * --------------------------------------------------------
>> + * | 0x100 | Slave ADC2 |
>> + * --------------------------------------------------------
>> + * | 0x200 | Slave ADC3 |
>> + * --------------------------------------------------------
>> + * | 0x300 | Master & Slave common regs |
>> + * --------------------------------------------------------
>> + */
>> +#define STM32_ADC_MAX_ADCS 3
>> +#define STM32_ADCX_COMN_OFFSET 0x300
>> +
>> +/**
>> + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>> + * @base: control registers base cpu addr
>> + * @vref_mv: vref voltage (mv)
>> + */
>> +struct stm32_adc_common {
>> + void __iomem *base;
>> + int vref_mv;
>> +};
>> +
>> +#endif
>>
^ permalink raw reply
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Ben Dooks @ 2016-11-21 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22GyRwywcxdO4Gp67d8TfpjfNzaE0z25=WW9GWibjGkDuQ@mail.gmail.com>
On 21/11/16 06:01, Tomasz Figa wrote:
> 2016-11-18 17:46 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> Maybe add a paragraph about the specific problem:
>>
>> "On s3c24xx, the PWM counter is only 16 bit wide, and with the
>> typical 12MHz input clock that overflows every 5.5ms. This works
>> with HZ=200 or higher but not with HZ=100 which needs a 10ms
>> interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
>> the counter is 32 bits and does not have this problem.
>> The new samsung_pwm_timer driver solves the problem by scaling
>> the input clock by a factor of 50 on s3c24xx, which makes it
>> less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
>> fewer wakeups".
>
> One thing to correct here is that the typical clock is PCLK, which is
> derived from one of the PLLs and AFAIR is between 33-66 MHz on
> s3c24xx. Technically you can drive the PWM block from an external
> clock (12 MHz for some board-file based boards), but for simplicity
> this functionality was omitted in the new PWM timer driver used for DT
> boards (which worked fine with the PWM driven by PCLK).
Given it was a clock mux option, that would not have been difficult to
acheive. However these platforms are now so old people don't care, I
think all my pre-armv7 stuff is now in a box.
The use of the 12MHz input was to give something to run PWM timers from
that wasn't interrupted by cpu frequency scaling as PCLK generally is
half HCLK which is divided down from the core CPU clock.
(Later devices had multiple PLL sources so you didn't have to have the
CPU fed from the same clock as the peripherals)
> Also I'm wondering if the divisor we use right now for 16-bit timers
> isn't too small, since it gives us a really short wraparound time,
> which means getting more timer interrupts for longer intervals, kind
> of defeating the benefit of tickless mode. However, AFAICT it doesn't
> affect the HZ problem.
The original implementation was to go for the best accuracy from the
timer at the expense of 200 irqs per second instead of the usual 100.
> Best regards.
> Tomasz
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH] mtd: nand: tango: Use nand_to_mtd() instead of directly accessing chip->mtd
From: Boris Brezillon @ 2016-11-21 9:03 UTC (permalink / raw)
To: linux-arm-kernel
The nand_to_mtd() helper is here to hide internal mtd_info <-> nand_chip
association and ease future refactors.
Make use of this helper instead of directly accessing chip->mtd.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/mtd/nand/tango_nand.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
index 7ed35348993e..ec87516b87f5 100644
--- a/drivers/mtd/nand/tango_nand.c
+++ b/drivers/mtd/nand/tango_nand.c
@@ -171,6 +171,7 @@ static void tango_select_chip(struct mtd_info *mtd, int idx)
*/
static int check_erased_page(struct nand_chip *chip, u8 *buf)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
u8 *meta = chip->oob_poi + BBM_SIZE;
u8 *ecc = chip->oob_poi + BBM_SIZE + METADATA_SIZE;
const int ecc_size = chip->ecc.bytes;
@@ -183,7 +184,7 @@ static int check_erased_page(struct nand_chip *chip, u8 *buf)
meta, meta_len,
chip->ecc.strength);
if (res < 0)
- chip->mtd.ecc_stats.failed++;
+ mtd->ecc_stats.failed++;
bitflips = max(res, bitflips);
buf += pkt_size;
@@ -300,26 +301,30 @@ static int tango_write_page(struct mtd_info *mtd, struct nand_chip *chip,
static void aux_read(struct nand_chip *chip, u8 **buf, int len, int *pos)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
*pos += len;
if (!*buf) {
/* skip over "len" bytes */
- chip->cmdfunc(&chip->mtd, NAND_CMD_RNDOUT, *pos, -1);
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, *pos, -1);
} else {
- tango_read_buf(&chip->mtd, *buf, len);
+ tango_read_buf(mtd, *buf, len);
*buf += len;
}
}
static void aux_write(struct nand_chip *chip, const u8 **buf, int len, int *pos)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
*pos += len;
if (!*buf) {
/* skip over "len" bytes */
- chip->cmdfunc(&chip->mtd, NAND_CMD_SEQIN, *pos, -1);
+ chip->cmdfunc(mtd, NAND_CMD_SEQIN, *pos, -1);
} else {
- tango_write_buf(&chip->mtd, *buf, len);
+ tango_write_buf(mtd, *buf, len);
*buf += len;
}
}
@@ -345,8 +350,9 @@ static void aux_write(struct nand_chip *chip, const u8 **buf, int len, int *pos)
*/
static void raw_read(struct nand_chip *chip, u8 *buf, u8 *oob)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
u8 *oob_orig = oob;
- const int page_size = chip->mtd.writesize;
+ const int page_size = mtd->writesize;
const int ecc_size = chip->ecc.bytes;
const int pkt_size = chip->ecc.size;
int pos = 0; /* position within physical page */
@@ -371,8 +377,9 @@ static void raw_read(struct nand_chip *chip, u8 *buf, u8 *oob)
static void raw_write(struct nand_chip *chip, const u8 *buf, const u8 *oob)
{
+ struct mtd_info *mtd = nand_to_mtd(chip);
const u8 *oob_orig = oob;
- const int page_size = chip->mtd.writesize;
+ const int page_size = mtd->writesize;
const int ecc_size = chip->ecc.bytes;
const int pkt_size = chip->ecc.size;
int pos = 0; /* position within physical page */
@@ -522,7 +529,7 @@ static int chip_init(struct device *dev, struct device_node *np)
chip = &tchip->nand_chip;
ecc = &chip->ecc;
- mtd = &chip->mtd;
+ mtd = nand_to_mtd(chip);
chip->read_byte = tango_read_byte;
chip->write_buf = tango_write_buf;
@@ -584,7 +591,7 @@ static int tango_nand_remove(struct platform_device *pdev)
for (cs = 0; cs < MAX_CS; ++cs) {
if (nfc->chips[cs])
- nand_release(&nfc->chips[cs]->nand_chip.mtd);
+ nand_release(nand_to_mtd(&nfc->chips[cs]->nand_chip));
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Russell King - ARM Linux @ 2016-11-21 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d67d8100-c8bf-d353-2225-e3b869a1c90d@codethink.co.uk>
On Mon, Nov 21, 2016 at 08:59:06AM +0000, Ben Dooks wrote:
> On 21/11/16 06:01, Tomasz Figa wrote:
> >2016-11-18 17:46 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> >>Maybe add a paragraph about the specific problem:
> >>
> >>"On s3c24xx, the PWM counter is only 16 bit wide, and with the
> >>typical 12MHz input clock that overflows every 5.5ms. This works
> >>with HZ=200 or higher but not with HZ=100 which needs a 10ms
> >>interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
> >>the counter is 32 bits and does not have this problem.
> >>The new samsung_pwm_timer driver solves the problem by scaling
> >>the input clock by a factor of 50 on s3c24xx, which makes it
> >>less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
> >>fewer wakeups".
> >
> >One thing to correct here is that the typical clock is PCLK, which is
> >derived from one of the PLLs and AFAIR is between 33-66 MHz on
> >s3c24xx. Technically you can drive the PWM block from an external
> >clock (12 MHz for some board-file based boards), but for simplicity
> >this functionality was omitted in the new PWM timer driver used for DT
> >boards (which worked fine with the PWM driven by PCLK).
>
> Given it was a clock mux option, that would not have been difficult to
> acheive. However these platforms are now so old people don't care, I
> think all my pre-armv7 stuff is now in a box.
However, there are still s3c2410 machines running out there... so we
should do our best not to break them.
> The use of the 12MHz input was to give something to run PWM timers from
> that wasn't interrupted by cpu frequency scaling as PCLK generally is
> half HCLK which is divided down from the core CPU clock.
...
> The original implementation was to go for the best accuracy from the
> timer at the expense of 200 irqs per second instead of the usual 100.
This sounds like a good enough reason not to switch away from using 200Hz
and the 12MHz input.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [kvm-unit-tests PATCH v9 2/3] arm: pmu: Check cycle count increases
From: Andrew Jones @ 2016-11-21 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479528942-21866-3-git-send-email-wei@redhat.com>
On Fri, Nov 18, 2016 at 10:15:41PM -0600, Wei Huang wrote:
> From: Christopher Covington <cov@codeaurora.org>
>
> Ensure that reads of the PMCCNTR_EL0 are monotonically increasing,
> even for the smallest delta of two subsequent reads.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arm/pmu.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 156 insertions(+)
>
> diff --git a/arm/pmu.c b/arm/pmu.c
> index 9d9c53b..fa87de4 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -15,6 +15,9 @@
> #include "libcflat.h"
> #include "asm/barrier.h"
>
> +#define PMU_PMCR_E (1 << 0)
> +#define PMU_PMCR_C (1 << 2)
> +#define PMU_PMCR_LC (1 << 6)
> #define PMU_PMCR_N_SHIFT 11
> #define PMU_PMCR_N_MASK 0x1f
> #define PMU_PMCR_ID_SHIFT 16
> @@ -22,6 +25,14 @@
> #define PMU_PMCR_IMP_SHIFT 24
> #define PMU_PMCR_IMP_MASK 0xff
>
> +#define ID_DFR0_PERFMON_SHIFT 24
> +#define ID_DFR0_PERFMON_MASK 0xf
> +
> +#define PMU_CYCLE_IDX 31
> +
> +#define NR_SAMPLES 10
> +
> +static unsigned int pmu_version;
> #if defined(__arm__)
> static inline uint32_t pmcr_read(void)
> {
> @@ -30,6 +41,69 @@ static inline uint32_t pmcr_read(void)
> asm volatile("mrc p15, 0, %0, c9, c12, 0" : "=r" (ret));
> return ret;
> }
> +
> +static inline void pmcr_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r" (value));
> + isb();
> +}
> +
> +static inline void pmselr_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 5" : : "r" (value));
> + isb();
> +}
> +
> +static inline void pmxevtyper_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c13, 1" : : "r" (value));
> +}
> +
> +static inline uint64_t pmccntr_read(void)
> +{
> + uint32_t lo, hi = 0;
> +
> + if (pmu_version == 0x3)
> + asm volatile("mrrc p15, 0, %0, %1, c9" : "=r" (lo), "=r" (hi));
> + else
> + asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r" (lo));
This is fine for this single test, but I was actually thinking we'd
implement both the 32-bit and 64-bit accessors separately, allowing
us to add an additional test that tries both on AArch32 (PMUv3). I.e.
report_prefix_push("pmccntr");
report("32-bit read", pmccntr_read() != 0); /* test mrc access */
if (pmu_version == 0x3) {
u64 cntr64 = pmccntr_read64(); /* test mrrc access */
report("64-bit read", (cntr64 >> 32) == 0 && (u32)cntr64 != 0);
} else {
report_skip("64-bit read, PMUv3 required");
}
We can refactor when we add that test later though.
> +
> + return ((uint64_t)hi << 32) | lo;
> +}
> +
> +static inline void pmccntr_write(uint64_t value)
> +{
> + uint32_t lo, hi;
> +
> + lo = value & 0xffffffff;
> + hi = (value >> 32) & 0xffffffff;
> +
> + if (pmu_version == 0x3)
> + asm volatile("mcrr p15, 0, %0, %1, c9" : : "r" (lo), "r" (hi));
> + else
> + asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (lo));
> +}
> +
> +static inline void pmcntenset_write(uint32_t value)
> +{
> + asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r" (value));
> +}
> +
> +/* PMCCFILTR is an obsolete name for PMXEVTYPER31 in ARMv7 */
> +static inline void pmccfiltr_write(uint32_t value)
> +{
> + pmselr_write(PMU_CYCLE_IDX);
> + pmxevtyper_write(value);
> + isb();
> +}
> +
> +static inline uint32_t id_dfr0_read(void)
> +{
> + uint32_t val;
> +
> + asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
> + return val;
> +}
> #elif defined(__aarch64__)
> static inline uint32_t pmcr_read(void)
> {
> @@ -38,6 +112,44 @@ static inline uint32_t pmcr_read(void)
> asm volatile("mrs %0, pmcr_el0" : "=r" (ret));
> return ret;
> }
> +
> +static inline void pmcr_write(uint32_t value)
> +{
> + asm volatile("msr pmcr_el0, %0" : : "r" (value));
> + isb();
> +}
> +
> +static inline uint64_t pmccntr_read(void)
> +{
> + uint64_t cycles;
> +
> + asm volatile("mrs %0, pmccntr_el0" : "=r" (cycles));
> + return cycles;
> +}
> +
> +static inline void pmccntr_write(uint64_t value)
> +{
> + asm volatile("msr pmccntr_el0, %0" : : "r" (value));
> +}
> +
> +static inline void pmcntenset_write(uint32_t value)
> +{
> + asm volatile("msr pmcntenset_el0, %0" : : "r" (value));
> +}
> +
> +static inline void pmccfiltr_write(uint32_t value)
> +{
> + asm volatile("msr pmccfiltr_el0, %0" : : "r" (value));
> + isb();
> +}
> +
> +static inline uint32_t id_dfr0_read(void)
> +{
> + uint32_t id;
> +
> + asm volatile("mrs %0, id_dfr0_el1" : "=r" (id));
> + return id;
> +}
> #endif
>
> /*
> @@ -64,11 +176,55 @@ static bool check_pmcr(void)
> return ((pmcr >> PMU_PMCR_IMP_SHIFT) & PMU_PMCR_IMP_MASK) != 0;
> }
>
> +/*
> + * Ensure that the cycle counter progresses between back-to-back reads.
> + */
> +static bool check_cycles_increase(void)
> +{
> + bool success = true;
> +
> + pmccntr_write(0);
> + pmcr_write(pmcr_read() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E);
> +
> + for (int i = 0; i < NR_SAMPLES; i++) {
> + uint64_t a, b;
> +
> + a = pmccntr_read();
> + b = pmccntr_read();
> +
> + if (a >= b) {
> + printf("Read %"PRId64" then %"PRId64".\n", a, b);
> + success = false;
> + break;
> + }
> + }
> +
> + pmcr_write(pmcr_read() & ~PMU_PMCR_E);
> +
> + return success;
> +}
> +
> +void pmu_init(void)
> +{
> + uint32_t dfr0;
> +
> + /* probe pmu version */
> + dfr0 = id_dfr0_read();
> + pmu_version = (dfr0 >> ID_DFR0_PERFMON_SHIFT) & ID_DFR0_PERFMON_MASK;
> + printf("PMU version: %d\n", pmu_version);
> +
> + /* init for PMU event access, right now only care about cycle count */
> + pmcntenset_write(1 << PMU_CYCLE_IDX);
> + pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
These last two register writes are specific to the cycle count test, so
I don't think they belong in a common pmu_init function. I'd keep them
at the top of check_cycles_increase.
> +}
> +
> int main(void)
> {
> report_prefix_push("pmu");
>
> + pmu_init();
> report("Control register", check_pmcr());
> + report("Monotonically increasing cycle count", check_cycles_increase());
>
> return report_summary();
> }
> --
> 1.8.3.1
>
Thanks,
drew
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Yao Yuan @ 2016-11-21 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0701MB21302252988A38FE2A393FE4FEB50@AM4PR0701MB2130.eurprd07.prod.outlook.com>
On Thu, Nov 21, 2016 at 03:15 PM +0800, Krzeminski, Marcin (Nokia - PL/Wroclaw) wrote:
> > -----Original Message-----
> > From: Yao Yuan [mailto:yao.yuan at nxp.com]
> > Sent: Monday, November 21, 2016 7:28 AM
> > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > <marcin.krzeminski@nokia.com>; Han Xu <xhnjupt@gmail.com>
> > Cc: David Woodhouse <dwmw2@infradead.org>; linux-
> > kernel at vger.kernel.org; linux-mtd at lists.infradead.org;
> > han.xu at freescale.com; Brian Norris <computersforpeace@gmail.com>;
> > jagannadh.teki at gmail.com; linux-arm-kernel at lists.infradead.org;
> > Cyrille Pitchen <cyrille.pitchen@atmel.com>
> > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > family flash
> >
> > On Thu, Nov 18, 2016 at 07:00 PM +0000, Krzeminski, Marcin (Nokia -
> > PL/Wroclaw) wrote:
> > > > -----Original Message-----
> > > > From: Yao Yuan [mailto:yao.yuan at nxp.com]
> > > > Sent: Friday, November 18, 2016 5:20 AM
> > > > To: Krzeminski, Marcin (Nokia - PL/Wroclaw)
> > > > <marcin.krzeminski@nokia.com>; Han Xu <xhnjupt@gmail.com>
> > > > Cc: David Woodhouse <dwmw2@infradead.org>; linux-
> > > > kernel at vger.kernel.org; linux-mtd at lists.infradead.org;
> > > > han.xu at freescale.com; Brian Norris <computersforpeace@gmail.com>;
> > > > jagannadh.teki at gmail.com; linux-arm-kernel at lists.infradead.org
> > > > Subject: RE: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S
> > > > family flash
> > > >
> > > > On Thu, Nov 17, 2016 at 10:14:55AM +0000, Krzeminski, Marcin
> > > > (Nokia
> > > > -
> > > > PL/Wroclaw) wrote:
> > > > > > On Thu, Nov 17, 2016 at 06:50:55AM +0000, Krzeminski, Marcin
> > > > > > (Nokia
> > > > > > -
> > > > > > PL/Wroclaw) wrote:
> > > > > > > > > > On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui
> > > > > > > > > > <B56489@freescale.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > From: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > > > > > > >
> > > > > > > > > > > With the physical sectors combination, S25FS-S
> > > > > > > > > > > family flash requires some special operations for
> > > > > > > > > > > read/write
> > functions.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/mtd/spi-nor/spi-nor.c | 56
> > > > > > > > > > > +++++++++++++++++++++++++++++++++++++++++++
> > > > > > > > > > > 1 file changed, 56 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > b/drivers/mtd/spi-nor/spi-nor.c index
> > > > > > > > > > > d0fc165..495d0bb
> > > > > > > > > > > 100644
> > > > > > > > > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > > > > > > > > @@ -39,6 +39,10 @@
> > > > > > > > > > >
> > > > > > > > > > > #define SPI_NOR_MAX_ID_LEN 6
> > > > > > > > > > > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > > > > > > > > > > +/* Added for S25FS-S family flash */
> > > > > > > > > > > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > > > > > > > > > > +#define CR3V_4KB_ERASE_UNABLE 0x8 #define
> > > > > > > > > > > +SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> > > > > > > > > > >
> > > > > > > > > > > struct flash_info {
> > > > > > > > > > > char *name;
> > > > > > > > > > > @@ -78,6 +82,7 @@ struct flash_info { };
> > > > > > > > > > >
> > > > > > > > > > > #define JEDEC_MFR(info) ((info)->id[0])
> > > > > > > > > > > +#define EXT_JEDEC(info) ((info)->id[5])
> > > > > > > > > > >
> > > > > > > > > > > static const struct flash_info
> > > > > > > > > > > *spi_nor_match_id(const char *name);
> > > > > > > > > > >
> > > > > > > > > > > @@ -899,6 +904,7 @@ static const struct flash_info
> > > > spi_nor_ids[] = {
> > > > > > > > > > > */
> > > > > > > > > > > { "s25sl032p", INFO(0x010215, 0x4d00, 64 *
> > > > > > > > > > > 1024, 64,
> > > > > > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > > > { "s25sl064p", INFO(0x010216, 0x4d00, 64 *
> > > > > > > > > > > 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> > },
> > > > > > > > > > > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64
> > > > > > > > > > > + * 1024, 512, 0)},
> > > > > > > > > > > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 *
> > > > > > > > > > > 1024, 128,
> > 0) },
> > > > > > > > > > > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 *
> > > > > > > > > > > 1024, 512,
> > > > > > > > > > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > > > > > > > > > > { "s25fl512s", INFO(0x010220, 0x4d00, 256 *
> > > > > > > > > > > 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> > },
> > > @@
> > > > > > > > > > > -
> > > > 1036,6
> > > > > > > > +1042,50
> > > > > > > > > > @@ static const struct flash_info
> > > > > > > > > > *spi_nor_read_id(struct spi_nor
> > > > > > > > > > *nor)
> > > > > > > > > > > return ERR_PTR(-ENODEV); }
> > > > > > > > > > >
> > > > > > > > > > > +/*
> > > > > > > > > > > + * The S25FS-S family physical sectors may be
> > > > > > > > > > > +configured as a
> > > > > > > > > > > + * hybrid combination of eight 4-kB parameter
> > > > > > > > > > > +sectors
> > > > > > > > > > > + * at the top or bottom of the address space with
> > > > > > > > > > > +all
> > > > > > > > > > > + * but one of the remaining sectors being uniform size.
> > > > > > > > > > > + * The Parameter Sector Erase commands (20h or 21h)
> > > > > > > > > > > +must
> > > > > > > > > > > + * be used to erase the 4-kB parameter sectors individually.
> > > > > > > > > > > + * The Sector (uniform sector) Erase commands (D8h
> > > > > > > > > > > +or
> > > > > > > > > > > +DCh)
> > > > > > > > > > > + * must be used to erase any of the remaining
> > > > > > > > > > > + * sectors, including the portion of highest or
> > > > > > > > > > > +lowest address
> > > > > > > > > > > + * sector that is not overlaid by the parameter sectors.
> > > > > > > > > > > + * The uniform sector erase command has no effect
> > > > > > > > > > > +on parameter
> > > > > > > > > > sectors.
> > > > > > > > > > > + */
> > > > > > > > > > > +static int spansion_s25fs_disable_4kb_erase(struct
> > > > > > > > > > > +spi_nor
> > > > *nor) {
> > > > > > > > > > > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > > > > > > > > > > + u8 cr3v = 0x0;
> > > > > > > > > > > + int ret = 0x0;
> > > > > > > > > > > +
> > > > > > > > > > > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > > > > > > > > > > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > > > > > > > > > > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > > > > > > > > > > +
> > > > > > > > > > > + ret = nor->read_reg(nor,
> > > > > > > > > > > + SPINOR_OP_SPANSION_RDAR,
> > > > > > &cr3v, 1);
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > > > > > > > > > > + return 0;
> > > > > > > > > > > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > > > > > > > > > > + nor->program_opcode =
> > SPINOR_OP_SPANSION_WRAR;
> > > > > > > > > > > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > > > > > > > > > > +
> > > > > > > > > > > + ret = nor->read_reg(nor,
> > > > > > > > > > > + SPINOR_OP_SPANSION_RDAR,
> > > > > > &cr3v, 1);
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > > > > > > > > > > + return -EPERM;
> > > > > > > > > > > +
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > static int spi_nor_read(struct mtd_info *mtd,
> > > > > > > > > > > loff_t from, size_t
> > > > > > len,
> > > > > > > > > > > size_t *retlen, u_char *buf)
> > > > > > > > > > > { @@
> > > > > > > > > > > -1361,6
> > > > > > > > > > > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor,
> > > > > > > > > > > +const char *name,
> > > > > > > > > > enum read_mode mode)
> > > > > > > > > > > spi_nor_wait_till_ready(nor);
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > + if (EXT_JEDEC(info) ==
> > > > > > > > > > > + SPINOR_S25FS_FAMILY_EXT_JEDEC)
> > > > {
> > > > > > > > > > > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + }
> > > > > > > > > > > +
> > > > > > > > > > > if (!mtd->name)
> > > > > > > > > > > mtd->name = dev_name(dev);
> > > > > > > > > > > mtd->priv = nor;
> > > > > > > > > > > --
> > > > > > > > > > > 2.1.0.27.g96db324
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > Hi Brian, I will ack this change but still feel it's
> > > > > > > > > > kind of hacking
> > code.
> > > > > > > > > >
> > > > > > > > > > Acked-by: Han xu <han.xu@nxp.com>
> > > > > > > > >
> > > > > > > > > I am new on the list so I am not sure if this topic has
> > > > > > > > > been
> > discussed.
> > > > > > > > > Generally our product functionality relay on those 4KiB sectors.
> > > > > > > > > I know that this hack is already in u-boot, but if you
> > > > > > > > > mainstream this you will force users of those 4KiB
> > > > > > > > > sectors to do hack the
> > > > > hack...
> > > > > > > > > I believe the proper solution here is to use erase
> > > > > > > > > regions functionality, I send and RFS about that some time ago.
> > > > > > > >
> > > > > > > > Do you mind to send me a link for reference?
> > > > > > > >
> > > > > > > Han,
> > > > > > >
> > > > > > > Sorry, It seem I have not posted erase region changes (only
> > > > > > > those regarding DUAL/QUAD I/O).
> > > > > > > Generally, in this flash you need to create 3 erase regions
> > > > > > > (because in FS-S family support only 4KiB erase on
> > > > > > > parameters sector -
> > > > eg.
> > > > > > > 1.2.2.4 in
> > > > > > S25FS512S).
> > > > > > > In my case regions are:
> > > > > > > 1. 0-32KiB (8*4KiB) - 4K_ERASE (0x20/0x21) 2. 32 - 256 -
> > > > > > > SE_CMD
> > > > > > (0xd8/0xdc) 3.
> > > > > > > Rest of the flash SE_CMD (0xd8/0xdc)
> > > > > > >
> > > > > > > To erase whole flash you can also use CHIP_ERASE_CMD
> > > > > > > (0x60/0xC7) command, you just need to add one more mtd
> > > > > > > partition that will cover
> > > > > > whole flash.
> > > > > > >
> > > > > >
> > > > > > Hi Krzeminski,
> > > > > >
> > > > > > Do you think is there any great advantages for enable 4KB?
> > > > > > Because for NXP(Freescale) QSPI controller, there is only
> > > > > > support max to 16 groups command.
> > > > > >
> > > > > > So It's hard to give 3 groups command just for erase
> > > > > > (0x21,0xdc and
> > 0xc7).
> > > > > > So we have to disable the 4kb erase and only use 256kbytes in
> > > > > > this
> > patch.
> > > > > >
> > > > > Yes, if you disable parameters sector in spi-nor framework you
> > > > > will disable it for all spi-nor clients not only for NXP QSPI controller.
> > > > > There are users (at least me) that relay on parameters sector
> > functionality.
> > > > This patch will brake it.
> > > > >
> > > > > Thanks,
> > > >
> > > > Hi Krzeminski,
> > > >
> > > > Get it.
> > > > So do you think how about that I add a flag in dts to select it?
> > > > The user want's disable 4kb, he can add the flag.
> > > >
> > > > In spi-nor.c:
> > > > if (of_property_read_bool(np, "spi-nor, disable-4kb")) {
> > > > spansion_s25fs_disable_4kb_erase();
> > > > }
> > > > else
> > > > ...
> > > >
> > > > In dts:
> > > >
> > > > &qspi {
> > > > num-cs = <2>;
> > > > bus-num = <0>;
> > > > status = "okay";
> > > >
> > > > qflash0: s25fs512s at 0 {
> > > > compatible = "spansion, s25fs512s";
> > > > spi-nor, disable-4kb
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > spi-max-frequency = <20000000>;
> > > > reg = <0>;
> > > > };
> > > >
> > > > I think it should be a better way.
> > > >
> > > > How about your think?
> > >
> > > This looks much better - at least for me.
> > > There are some parameters in JESD216 standard regarding parameters
> > > sector, but unfortunately I have not investigated that. You can take
> > > a look at Cyrille series, that adds support for JESD216 standard.
> > >
> >
> > Ok, I will resend v4 for add this.
> >
> > BTW, the 4-kytes block for S25FS is just only the first 8 blocks, the
> > other block is 256kytes.
> > Do out SPI-NOR support erase those specific combination?
> >
> > If not, do you have any plan for add it?
> > It seems I can't fine the support in spi-nor.
> >
> Those erase regions are solution for such flash, current upstream version does
> not have this. My solution is not universal, so probably I will not add it.
>
Ok, Get it.
We will not use the specific 4kb combination mode for S25FS also.
So I will add the patch to disable 4kb for S25FS. But I will add a flag in dts that
the user can do the choice.
Thanks.
^ permalink raw reply
* [PATCH] mfd: twl-core: export twl_get_regmap
From: Lee Jones @ 2016-11-21 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKP5S=3quz8f1H0xnaffJ35L8qSOpSkBEGS8GsNhB5F=v3DoBg@mail.gmail.com>
On Sun, 20 Nov 2016, Nicolae Rosia wrote:
> On Fri, Nov 18, 2016 at 8:55 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Sat, 12 Nov 2016, Nicolae Rosia wrote:
> >
> >> We want to get rid of global twl_i2c_{write/read}.
> >> As a first step, allow clients to get the regmap and write directly
> >
> > What's stopping you from passing it through device data?
> >
> Could you elaborate a bit?
> The regmaps are stored in struct twl_client [0], stored in struct
> twl_private [1], both structs are defined in the source file, not in
> header.
> I could however just fix the problem by reworking the struct, exposing
> it and use mfd_add_device as real mfd drivers do.
Woah! Thanks for prompting me to read this driver. It's a bit of a
mess isn't it? I think it would be best to convert it to use the MFD
API, yes.
It's common place to pass shared resources such as 'regmap' though
device data. You can find many examples of *__set_drvdata throughout
the kernel.
> [0] http://lxr.free-electrons.com/source/drivers/mfd/twl-core.c#L152
> [1] http://lxr.free-electrons.com/source/drivers/mfd/twl-core.c#L163
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Russell King - ARM Linux @ 2016-11-21 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22GyRwywcxdO4Gp67d8TfpjfNzaE0z25=WW9GWibjGkDuQ@mail.gmail.com>
On Mon, Nov 21, 2016 at 03:01:57PM +0900, Tomasz Figa wrote:
> One thing to correct here is that the typical clock is PCLK, which is
> derived from one of the PLLs and AFAIR is between 33-66 MHz on
> s3c24xx. Technically you can drive the PWM block from an external
> clock (12 MHz for some board-file based boards), but for simplicity
> this functionality was omitted in the new PWM timer driver used for DT
> boards (which worked fine with the PWM driven by PCLK).
So that's a knowingly-made regression for s3c24xx then. Pretty
disgusting developer behavior to do that, IMHO.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Geert Uytterhoeven @ 2016-11-21 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119012836.GA2543@localhost>
Hi Olof,
On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>> * Basic support for r8a7745 SoC
>>
>> ----------------------------------------------------------------
>> Sergei Shtylyov (2):
>> ARM: shmobile: r8a7745: basic SoC support
>> ARM: shmobile: document SK-RZG1E board
>
> Hi,
>
> Is there a reason you're adding a config option per SoC?
>
> I think you'd be better off not adding these config options, and just adding
> support for the SoCs through compatibles (and adding the drivers to defconfigs,
> etc).
Yes there is a reason: kernel size.
The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
supported SoC.
Note that RZ/A1 (r7s72100) is used on some boards with its internal RAM
(10 MiB) only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] mfd: twl-core: export twl_get_regmap
From: Russell King - ARM Linux @ 2016-11-21 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121092339.GA32509@dell>
On Mon, Nov 21, 2016 at 09:23:39AM +0000, Lee Jones wrote:
> It's common place to pass shared resources such as 'regmap' though
> device data. You can find many examples of *__set_drvdata throughout
> the kernel.
Passing data between drivers using *_set_drvdata() is a layering
violation:
1. Driver data is supposed to be driver private data associated with
the currently bound driver.
2. The driver data pointer is NULL'd when the driver unbinds from the
device. See __device_release_driver() and the
dev_set_drvdata(dev, NULL).
3. It will break with CONFIG_DEBUG_TEST_DRIVER_REMOVE enabled for a
similar reason to (2).
So, do not pass data between drivers using *_set_drvdata() - any
examples in the kernel already are founded on bad practice, are
fragile, and are already broken for some kernel configurations.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [kvm-unit-tests PATCH v9 3/3] arm: pmu: Add CPI checking
From: Andrew Jones @ 2016-11-21 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479528942-21866-4-git-send-email-wei@redhat.com>
On Fri, Nov 18, 2016 at 10:15:42PM -0600, Wei Huang wrote:
> From: Christopher Covington <cov@codeaurora.org>
>
> Calculate the numbers of cycles per instruction (CPI) implied by ARM
> PMU cycle counter values. The code includes a strict checking facility
> intended for the -icount option in TCG mode in the configuration file.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arm/pmu.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
> arm/unittests.cfg | 14 +++++++
> 2 files changed, 124 insertions(+), 1 deletion(-)
>
> diff --git a/arm/pmu.c b/arm/pmu.c
> index fa87de4..b36c4fb 100644
> --- a/arm/pmu.c
> +++ b/arm/pmu.c
> @@ -104,6 +104,25 @@ static inline uint32_t id_dfr0_read(void)
> asm volatile("mrc p15, 0, %0, c0, c1, 2" : "=r" (val));
> return val;
> }
> +
> +/*
> + * Extra instructions inserted by the compiler would be difficult to compensate
> + * for, so hand assemble everything between, and including, the PMCR accesses
> + * to start and stop counting.
> + */
> +static inline void loop(int i, uint32_t pmcr)
Thought you were going to rename this function.
> +{
> + asm volatile(
> + " mcr p15, 0, %[pmcr], c9, c12, 0\n"
> + " isb\n"
> + "1: subs %[i], %[i], #1\n"
> + " bgt 1b\n"
> + " mcr p15, 0, %[z], c9, c12, 0\n"
> + " isb\n"
> + : [i] "+r" (i)
> + : [pmcr] "r" (pmcr), [z] "r" (0)
> + : "cc");
> +}
> #elif defined(__aarch64__)
> static inline uint32_t pmcr_read(void)
> {
> @@ -150,6 +169,25 @@ static inline uint32_t id_dfr0_read(void)
> asm volatile("mrs %0, id_dfr0_el1" : "=r" (id));
> return id;
> }
> +
> +/*
> + * Extra instructions inserted by the compiler would be difficult to compensate
> + * for, so hand assemble everything between, and including, the PMCR accesses
> + * to start and stop counting.
> + */
> +static inline void loop(int i, uint32_t pmcr)
> +{
> + asm volatile(
> + " msr pmcr_el0, %[pmcr]\n"
> + " isb\n"
> + "1: subs %[i], %[i], #1\n"
> + " b.gt 1b\n"
> + " msr pmcr_el0, xzr\n"
> + " isb\n"
> + : [i] "+r" (i)
> + : [pmcr] "r" (pmcr)
> + : "cc");
> +}
> #endif
>
> /*
> @@ -204,6 +242,71 @@ static bool check_cycles_increase(void)
> return success;
> }
>
> +/*
> + * Execute a known number of guest instructions. Only odd instruction counts
> + * greater than or equal to 3 are supported by the in-line assembly code. The
> + * control register (PMCR_EL0) is initialized with the provided value (allowing
> + * for example for the cycle counter or event counters to be reset). At the end
> + * of the exact instruction loop, zero is written to PMCR_EL0 to disable
> + * counting, allowing the cycle counter or event counters to be read at the
> + * leisure of the calling code.
> + */
> +static void measure_instrs(int num, uint32_t pmcr)
> +{
> + int i = (num - 1) / 2;
> +
> + assert(num >= 3 && ((num - 1) % 2 == 0));
> + loop(i, pmcr);
> +}
> +
> +/*
> + * Measure cycle counts for various known instruction counts. Ensure that the
> + * cycle counter progresses (similar to check_cycles_increase() but with more
> + * instructions and using reset and stop controls). If supplied a positive,
> + * nonzero CPI parameter, also strictly check that every measurement matches
> + * it. Strict CPI checking is used to test -icount mode.
> + */
> +static bool check_cpi(int cpi)
> +{
> + uint32_t pmcr = pmcr_read() | PMU_PMCR_LC | PMU_PMCR_C | PMU_PMCR_E;
> +
> + if (cpi > 0)
> + printf("Checking for CPI=%d.\n", cpi);
> + printf("instrs : cycles0 cycles1 ...\n");
> +
> + for (unsigned int i = 3; i < 300; i += 32) {
> + uint64_t avg, sum = 0;
> +
> + printf("%d :", i);
> + for (int j = 0; j < NR_SAMPLES; j++) {
> + uint64_t cycles;
> +
> + pmccntr_write(0);
> + measure_instrs(i, pmcr);
> + cycles = pmccntr_read();
> + printf(" %"PRId64"", cycles);
> +
> + /*
> + * The cycles taken by the loop above should fit in
> + * 32 bits easily. We check the upper 32 bits of the
> + * cycle counter to make sure there is no supprise.
> + */
> + if (!cycles || (cpi > 0 && cycles != i * cpi) ||
> + (cycles & 0xffffffff00000000)) {
(cycles >> 32) != 0 would look better.
> + printf("\n");
We have 3 cases where we return false here. How about doing the tests
separately and adding descriptive print statements for each?
if (!cycles) {
printf("\ncycles not incrementing!\n");
return false;
} else if (cpi > 0 && cycles != i * cpi) {
...
} else if ((cycles >> 32) != 0) {
...
}
> + return false;
> + }
> +
> + sum += cycles;
> + }
> + avg = sum / NR_SAMPLES;
> + printf(" sum=%"PRId64" avg=%"PRId64" avg_ipc=%"PRId64" "
> + "avg_cpi=%"PRId64"\n", sum, avg, i / avg, avg / i);
> + }
> +
> + return true;
> +}
> +
> void pmu_init(void)
> {
> uint32_t dfr0;
> @@ -218,13 +321,19 @@ void pmu_init(void)
> pmccfiltr_write(0); /* count cycles in EL0, EL1, but not EL2 */
> }
>
> -int main(void)
> +int main(int argc, char *argv[])
> {
> + int cpi = 0;
> +
> + if (argc >= 1)
^ this '=' shouldn't be here
> + cpi = atol(argv[0]);
^ sigh, this is still zero...
Looks like you forgot all my comments from the last review round...
> +
> report_prefix_push("pmu");
>
> pmu_init();
> report("Control register", check_pmcr());
> report("Monotonically increasing cycle count", check_cycles_increase());
> + report("Cycle/instruction ratio", check_cpi(cpi));
>
> return report_summary();
> }
> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> index 7645180..2050dc8 100644
> --- a/arm/unittests.cfg
> +++ b/arm/unittests.cfg
> @@ -59,3 +59,17 @@ groups = selftest
> [pmu]
> file = pmu.flat
> groups = pmu
> +
> +# Test PMU support (TCG) with -icount IPC=1
> +[pmu-tcg-icount-1]
> +file = pmu.flat
> +extra_params = -icount 0 -append '1'
> +groups = pmu
> +accel = tcg
> +
> +# Test PMU support (TCG) with -icount IPC=256
> +[pmu-tcg-icount-256]
> +file = pmu.flat
> +extra_params = -icount 8 -append '256'
> +groups = pmu
> +accel = tcg
> --
> 1.8.3.1
>
drew
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Daniel Vetter @ 2016-11-21 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118233733.GP1041@n2100.armlinux.org.uk>
On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Hi,
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
>
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
>
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
>
> So, I patched the HDLCD to do this, and testing it with Xorg after
> several repetitions seems to work.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> What I think is going on is that the FIFO or address generator for
> reading data from the AXI bus is not properly reset when changing the
> resolution, and the enable-disable-enable cycle causes the HDLCD
> hardware to sort itself out. It's (eg) significantly out - for example,
> to properly align the display, I have to program an address of
> 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> before the real start of the frame buffer.
>
> With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> and xf86-video-armada, I have LXDE running on the Juno.
>
> Something I also noticed is this:
>
> scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> plane->state->crtc_y * plane->state->fb->pitches[0] +
> plane->state->crtc_x * bpp / 8;
>
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window. To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.
>
> Another note is that since the CRTC can't place the plane in arbitary
> positions and sizes within the active area, should the atomic_check
> ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> size of the active area?
Yup, it should. See drm_plane_helper_check_state() and its caller for a
helper to make this easier. Long-term computing this stuff by default and
having a bunch of igts to regression-test it would be good I think, but
that needs CRC support. And lots of work, since we have lots of drivers.
-Daniel
>
> drivers/gpu/drm/arm/hdlcd_crtc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae22ddb..3e97acf6e2a7 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> clk_prepare_enable(hdlcd->clk);
> hdlcd_crtc_mode_set_nofb(crtc);
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> }
>
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v16 06/15] clocksource/drivers/arm_arch_timer: separate out arch_timer_uses_ppi init code to prepare for GTDT.
From: Fu Wei @ 2016-11-21 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118193054.GK1197@leverpostej>
Hi Mark,
On 19 November 2016 at 03:30, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Nov 16, 2016 at 09:48:59PM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> The patch refactor original arch_timer_uses_ppi init code:
>> (1) Extract a subfunction: arch_timer_uses_ppi_init
>> (2) Use the new subfunction in arch_timer_of_init and
>> arch_timer_acpi_init
>
> This isn't a strict refactoring, since this now assigns
> ARCH_TIMER_PHYS_NONSECURE_PPI to arch_timer_uses_ppi, which we didn't do
> previously.
>
> As a general note, please write your commit messages as prose rather
> than a list of bullet points. Please also explain the rationale for the
> change, rather than enumerating the changes. Call out things which are
> important and/or likely to surprise reviewers, for example:
>
> * Can 32-bit ARM still use non-secure interrupts afer this change?
>
> * Does the "arm,cpu-registers-not-fw-configured" proeprty still work?
>
> That will make it vastly easier to have this code reviewed, and it will
> be far more helpful for anyone looking at this in future.
>
> For example:
>
> arm_arch_timer: rework PPI determination
>
> Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to
> mean the driver will use the secure PPI *and* potentialy also use the
> non-secure PPI. This is somewhat confusing.
>
> For arm64, where it never makes sense to use the secure PPI, this
> means we must always request the useless secure PPI, adding to the
> confusion. For ACPI, where we may not even have a valid secure PPI
> number, this is additionally problematic. We need the driver to be
> able to use *only* the non-secure PPI.
>
> The logic to choose which PPI to use is intertwined with other logic
> in arch_timer_init(). This patch factors the PPI determination out
> into a new function, and then reworks it so that we can handle having
> only a non-secure PPI.
Great thanks for your example, will use this, :-)
maybe add :
For ARM32, it still can use non-secure interrupts after this change, and
the "arm,cpu-registers-not-fw-configured" property still works.
>
> [...]
>
>> +/*
>> + * If HYP mode is available, we know that the physical timer
>> + * has been configured to be accessible from PL1. Use it, so
>> + * that a guest can use the virtual timer instead.
>> + *
>> + * If no interrupt provided for virtual timer, we'll have to
>> + * stick to the physical timer. It'd better be accessible...
>> + * On ARM64, we we only use ARCH_TIMER_PHYS_NONSECURE_PPI in Linux.
>
> It would be better to say that for arm64 we never use the secure
> interrupt.
For ARM64, we never use the secure interrupt, so it will be set to
ARCH_TIMER_PHYS_NONSECURE_PPI instead.
>
>> + *
>> + * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
>> + * accesses to CNTP_*_EL1 registers are silently redirected to
>> + * their CNTHP_*_EL2 counterparts, and use a different PPI
>> + * number.
>> + */
>> +static int __init arch_timer_uses_ppi_init(void)
>
> It would be better to call this something like arch_timer_select_ppi().
> As it stands, the name is difficult to read.
Yes, good idea, will do
>
>> @@ -902,6 +904,10 @@ static int __init arch_timer_of_init(struct device_node *np)
>> of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
>> arch_timer_uses_ppi = ARCH_TIMER_PHYS_SECURE_PPI;
>>
>> + ret = arch_timer_uses_ppi_init();
>> + if (ret)
>> + return ret;
>
> This is clearly broken if you consider what the statement above is
> doing.
Maybe I misunderstand this, I tried to follow the original logic.
Are you saying: we should use arch_timer_select_ppi() first,
then (maybe) change arch_timer_uses_ppi according to
"arm,cpu-registers-not-fw-configured"?
Please correct me, if I misunderstand this.
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH] mtd: nand: tango: Use nand_to_mtd() instead of directly accessing chip->mtd
From: Marc Gonzalez @ 2016-11-21 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479718984-26491-1-git-send-email-boris.brezillon@free-electrons.com>
On 21/11/2016 10:03, Boris Brezillon wrote:
> The nand_to_mtd() helper is here to hide internal mtd_info <-> nand_chip
> association and ease future refactors.
>
> Make use of this helper instead of directly accessing chip->mtd.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/mtd/nand/tango_nand.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
Acked-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Regards.
^ permalink raw reply
* [PATCH v9 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-21 10:01 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is v9 of a previous posting:
https://lkml.org/lkml/2016/11/16/386
v8 -> v9
- Updated bypass flag handling in ARM SMMU v3 according to
reviews
- Removed SMMUv1/v2 configuration interrupt handling
- Rebased against v4.9-rc5
- Updated tags
v7 -> v8
- Renamed fwnode iommu_ops registration API according to review
- Minor change in ARM SMMU driver DT/ACPI split
- Added review tags
v6 -> v7
- Rebased against v4.9-rc4
- Fixed IORT probing on ACPI systems with missing IORT table
- Fixed SMMUv1/v2 global interrupt detection
- Updated iommu_ops firmware look-up
v5 -> v6
- Rebased against v4.9-rc1
- Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
- Moved platform devices creation into IORT code
- Updated fwnode handling
- Added default dma masks initialization
v4 -> v5
- Added SMMUv1/v2 support
- Rebased against v4.8-rc5 and dependencies series
- Consolidated IORT platform devices creation
v3 -> v4
- Added single mapping API (for IORT named components)
- Fixed arm_smmu_iort_xlate() return value
- Reworked fwnode registration and platform device creation
ordering to fix probe ordering dependencies
- Added code to keep device_node ref count with new iommu
fwspec API
- Added patch to make iommu_fwspec arch agnostic
- Dropped RFC status
- Rebased against v4.8-rc2
v2 -> v3
- Rebased on top of dependencies series [1][2][3](v4.7-rc3)
- Added back reliance on ACPI early probing infrastructure
- Patch[1-3] merged through other dependent series
- Added back IOMMU fwnode generalization
- Move SMMU v3 static functions configuration to IORT code
- Implemented generic IOMMU fwspec API
- Added code to implement fwnode platform device look-up
v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2
owing to patch series dependencies [1]
- Moved platform device creation logic to IORT code to
generalize its usage for ARM SMMU v1-v2-v3 components
- Removed reliance on ACPI early device probing
- Created IORT specific iommu_xlate() translation hook leaving
OF code unchanged according to v1 reviews
The ACPI IORT table provides information that allows instantiating
ARM SMMU devices and carrying out id mappings between components on
ARM based systems (devices, IOMMUs, interrupt controllers).
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Building on basic IORT support, this patchset enables ARM SMMUs support
on ACPI systems.
Most of the code is aimed at building the required generic ACPI
infrastructure to create and enable IOMMU components and to bring
the IOMMU infrastructure for ACPI on par with DT, which is going to
make future ARM SMMU components easier to integrate.
PATCH (1) adds a FWNODE_ACPI_STATIC type to the struct fwnode_handle type.
It is required to attach a fwnode identifier to platform
devices allocated/detected through static ACPI table entries
(ie IORT tables entries).
IOMMU devices have to have an identifier to look them up
eg IOMMU core layer carrying out id translation. This can be
done through a fwnode_handle (ie IOMMU platform devices created
out of IORT tables are not ACPI devices hence they can't be
allocated as such, otherwise they would have a fwnode_handle of
type FWNODE_ACPI).
PATCH (2) makes use of the ACPI early probing API to add a linker script
section for probing devices via IORT ACPI kernel code.
PATCH (3) provides IORT support for registering IOMMU IORT node through
their fwnode handle.
PATCH (4) make of_iommu_{set/get}_ops() functions DT agnostic and
rename the registration API.
PATCH (5) convert ARM SMMU driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (6) convert ARM SMMU v3 driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (7) implements the of_dma_configure() API in ACPI world -
acpi_dma_configure() - and patches PCI and ACPI core code to
start making use of it.
PATCH (8) provides an IORT function to detect existence of specific type
of IORT components.
PATCH (9) creates the kernel infrastructure required to create ARM SMMU
platform devices for IORT nodes.
PATCH (10) refactors the ARM SMMU v3 driver so that the init functions are
split in a way that groups together code that probes through DT
and code that carries out HW registers FW agnostic probing, in
preparation for adding the ACPI probing path.
PATCH (11) adds ARM SMMU v3 IORT IOMMU operations to create and probe
ARM SMMU v3 components.
PATCH (12) refactors the ARM SMMU v1/v2 driver so that the init functions
are split in a way that groups together code that probes
through DT and code that carries out HW registers FW agnostic
probing, in preparation for adding the ACPI probing path.
PATCH (13) adds ARM SMMU v1/v2 IORT IOMMU operations to create and
probe ARM SMMU v1/v2 components.
PATCH (14) Extend the IORT iort_node_map_rid() to work on a type mask
instead of a single type so that the translation API can
be used on a range of components.
PATCH (15) Add IORT API to carry out id mappings for components that do
do not have an input identifier/RIDs (ie named components).
PATCH (16) provides IORT infrastructure to carry out IOMMU configuration
for devices and hook it up to the previously introduced ACPI
DMA configure API.
This patchset is provided for review/testing purposes here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/iort-smmu-v9
Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
Lorenzo Pieralisi (16):
drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
drivers: acpi: iort: introduce linker section for IORT entries probing
drivers: acpi: iort: add support for IOMMU fwnode registration
drivers: iommu: make of_iommu_set/get_ops() DT agnostic
drivers: iommu: arm-smmu: convert struct device of_node to fwnode
usage
drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode
usage
drivers: acpi: implement acpi_dma_configure
drivers: acpi: iort: add node match function
drivers: acpi: iort: add support for ARM SMMU platform devices
creation
drivers: iommu: arm-smmu-v3: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu-v3: add IORT configuration
drivers: iommu: arm-smmu: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu: add IORT configuration
drivers: acpi: iort: replace rid map type with type mask
drivers: acpi: iort: add single mapping function
drivers: acpi: iort: introduce iort_iommu_configure
drivers/acpi/arm64/iort.c | 585 +++++++++++++++++++++++++++++++++++++-
drivers/acpi/glue.c | 4 +-
drivers/acpi/scan.c | 45 +++
drivers/iommu/arm-smmu-v3.c | 102 +++++--
drivers/iommu/arm-smmu.c | 148 ++++++++--
drivers/iommu/iommu.c | 40 +++
drivers/iommu/of_iommu.c | 39 ---
drivers/pci/probe.c | 3 +-
include/acpi/acpi_bus.h | 2 +
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi.h | 26 ++
include/linux/acpi_iort.h | 14 +
include/linux/fwnode.h | 3 +-
include/linux/iommu.h | 14 +
include/linux/of_iommu.h | 12 +-
15 files changed, 934 insertions(+), 104 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v9 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
From: Lorenzo Pieralisi @ 2016-11-21 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121100148.24769-1-lorenzo.pieralisi@arm.com>
On systems booting with a device tree, every struct device is associated
with a struct device_node, that provides its DT firmware representation.
The device node can be used in generic kernel contexts (eg IRQ
translation, IOMMU streamid mapping), to retrieve the properties
associated with the device and carry out kernel operations accordingly.
Owing to the 1:1 relationship between the device and its device_node,
the device_node can also be used as a look-up token for the device (eg
looking up a device through its device_node), to retrieve the device in
kernel paths where the device_node is available.
On systems booting with ACPI, the same abstraction provided by
the device_node is required to provide look-up functionality.
The struct acpi_device, that represents firmware objects in the
ACPI namespace already includes a struct fwnode_handle of
type FWNODE_ACPI as their member; the same abstraction is missing
though for devices that are instantiated out of static ACPI tables
entries (eg ARM SMMU devices).
Add a new fwnode_handle type to associate devices created out
of static ACPI table entries to the respective firmware components
and create a simple ACPI core layer interface to dynamically allocate
and free the corresponding firmware nodes so that kernel subsystems
can use it to instantiate the nodes and associate them with the
respective devices.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
include/linux/acpi.h | 21 +++++++++++++++++++++
include/linux/fwnode.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 61a3d90..996a29c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,27 @@ static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
acpi_fwnode_handle(adev) : NULL)
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
+static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
+{
+ struct fwnode_handle *fwnode;
+
+ fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
+ if (!fwnode)
+ return NULL;
+
+ fwnode->type = FWNODE_ACPI_STATIC;
+
+ return fwnode;
+}
+
+static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
+{
+ if (WARN_ON(!fwnode || fwnode->type != FWNODE_ACPI_STATIC))
+ return;
+
+ kfree(fwnode);
+}
+
/**
* ACPI_DEVICE_CLASS - macro used to describe an ACPI device with
* the PCI-defined class-code information
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 8516717..8bd28ce 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -17,8 +17,9 @@ enum fwnode_type {
FWNODE_OF,
FWNODE_ACPI,
FWNODE_ACPI_DATA,
+ FWNODE_ACPI_STATIC,
FWNODE_PDATA,
- FWNODE_IRQCHIP,
+ FWNODE_IRQCHIP
};
struct fwnode_handle {
--
2.10.0
^ permalink raw reply related
* [PATCH v9 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing
From: Lorenzo Pieralisi @ 2016-11-21 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121100148.24769-1-lorenzo.pieralisi@arm.com>
Since commit e647b532275b ("ACPI: Add early device probing
infrastructure") the kernel has gained the infrastructure that allows
adding linker script section entries to execute ACPI driver callbacks
(ie probe routines) for all subsystems that register a table entry
in the respective kernel section (eg clocksource, irqchip).
Since ARM IOMMU devices data is described through IORT tables when
booting with ACPI, the ARM IOMMU drivers must be made able to hook ACPI
callback routines that are called to probe IORT entries and initialize
the respective IOMMU devices.
To avoid adding driver specific hooks into IORT table initialization
code (breaking therefore code modularity - ie ACPI IORT code must be made
aware of ARM SMMU drivers ACPI init callbacks), this patch adds code
that allows ARM SMMU drivers to take advantage of the ACPI early probing
infrastructure, so that they can add linker script section entries
containing drivers callback to be executed on IORT tables detection.
Since IORT nodes are differentiated by a type, the callback routines
can easily parse the IORT table entries, check the IORT nodes and
carry out some actions whenever the IORT node type associated with
the driver specific callback is matched.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/acpi/arm64/iort.c | 13 ++++++++++---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi_iort.h | 3 +++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b81746..2c46ebc 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -361,8 +361,15 @@ void __init acpi_iort_init(void)
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
- if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- const char *msg = acpi_format_exception(status);
- pr_err("Failed to get table, %s\n", msg);
+ if (ACPI_FAILURE(status)) {
+ if (status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err("Failed to get table, %s\n", msg);
+ }
+
+ return;
}
+
+ acpi_probe_device_table(iort);
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 31e1d63..9e3aa34 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -566,6 +566,7 @@
IRQCHIP_OF_MATCH_TABLE() \
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(clksrc) \
+ ACPI_PROBE_TABLE(iort) \
EARLYCON_TABLE()
#define INIT_TEXT \
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 0e32dac..d16fdda 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,4 +39,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
{ return NULL; }
#endif
+#define IORT_ACPI_DECLARE(name, table_id, fn) \
+ ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
+
#endif /* __ACPI_IORT_H__ */
--
2.10.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox